idnits 2.17.1 draft-ietf-nsis-qspec-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2041. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2018. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2031. ** 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 (October 2005) is 6767 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 1280, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 1294, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 1673, but not defined == Missing Reference: 'RFC2212' is mentioned on line 1010, but not defined == Missing Reference: 'QOS-SIG' is mentioned on line 887, but not defined == Missing Reference: 'RFC3297' is mentioned on line 1019, but not defined == Missing Reference: 'S' is mentioned on line 1287, but not defined == Missing Reference: 'MTU' is mentioned on line 1346, but not defined == Missing Reference: 'RFC 3140' is mentioned on line 1358, but not defined == Missing Reference: 'RFC 3181' is mentioned on line 1437, but not defined == Missing Reference: 'RFC3181' is mentioned on line 1455, but not defined -- Looks like a reference, but probably isn't: '2215' on line 1673 -- Looks like a reference, but probably isn't: '2212' on line 1673 == Missing Reference: 'Ctot' is mentioned on line 1680, but not defined == Missing Reference: 'Dtot' is mentioned on line 1688, but not defined == Missing Reference: 'Csum' is mentioned on line 1696, but not defined == Missing Reference: 'Dsum' is mentioned on line 1704, but not defined == Missing Reference: 'RFC2434' is mentioned on line 1736, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'DSCP-REGISTRY' is defined on line 1756, but no explicit reference was found in the text == Unused Reference: 'PHBID-CODES-REGISTRY' is defined on line 1757, but no explicit reference was found in the text == Unused Reference: 'RFC1832' is defined on line 1762, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 1769, but no explicit reference was found in the text == Unused Reference: 'RFC2215' is defined on line 1775, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1778, but no explicit reference was found in the text == Unused Reference: 'RFC3140' is defined on line 1789, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV-CLASS' is defined on line 1799, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 1801, but no explicit reference was found in the text == Unused Reference: 'METWORK-BYTE-ORDER' is defined on line 1806, but no explicit reference was found in the text == Unused Reference: 'RFC1633' is defined on line 1812, 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. 'GIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) ** 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: 8 errors (**), 0 flaws (~~), 29 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft NSIS Working Group Jerry Ash 3 Internet Draft AT&T 4 Attila Bader 5 Expiration Date: April 2006 Ericsson 6 Cornelia Kappler 7 Siemens AG 9 October 2005 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 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 3, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The QoS NSLP protocol is used to signal QoS reservations and is 45 independent of a specific QoS model (QOSM) such as IntServ or 46 DiffServ. Rather, all information specific to a QOSM is encapsulated 47 in a separate object, the QSPEC. This draft defines a template for 48 the QSPEC, which contains both the QoS description and QSPEC control 49 information. The QSPEC format is defined, as are a number of QSPEC 50 parameters. The QSPEC parameters provide a common language to be 51 re-used in several QOSMs. To a certain extent QSPEC parameters 52 ensure interoperability of QOSMs. Optional QSPEC parameters aim to 53 ensure the extensibility of QoS NSLP to other QOSMs in the future. 54 The node initiating the NSIS signaling adds an Initiator QSPEC that 55 must not be removed, thereby ensuring the intention of the NSIS 56 initiator is preserved along the signaling path. 58 Table of Contents 60 1. Conventions Used in This Document . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. QSPEC Parameters, Processing, & Extensibility . . . . . . . . . 6 64 4.1 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 6 65 4.2 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 6 66 4.3 Example of NSLP/QSPEC Operation . . . . . . . . . . . . . . 8 67 4.4 Treatment of QSPEC Parameters . . . . . . . . . . . . . . . 11 68 4.4.1 Mandatory and Optional QSPEC Parameters . . . . . . . 11 69 4.4.2 Read-only and Read-write QSPEC Parameters . . . . . . 11 70 4.5 Inability to handle parameters . . . . . . . . . . . . . . 12 71 4.5.1 Error Conditions . . . . . . . . . . . . . . . . . . 12 72 4.5.2 Inability to interpret and update parameters . . . . 12 73 4.6 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 13 74 5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 13 75 5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 14 76 5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 14 77 5.2.1 . . . . . . . . . . . . . . . . . . . . 14 78 5.2.2 . . . . . . . . . . . . . . . . . . . 16 79 5.2.3 . . . . . . . . . . . . . . . . . . . 18 80 5.2.4 . . . . . . . . . . . . . . . . . . . . 18 81 6. QSPEC Procedures & Examples . . . . . . . . . . . . . . . . . . 18 82 6.1 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 18 83 6.1.1 Sender-Initiated Reservations . . . . . . . . . . . . 19 84 6.1.2 Receiver-Initiated Reservations . . . . . . . . . . . 20 85 6.1.3 Resource Queries . . . . . . . . . . . . . . . . . . 20 86 6.1.4 Bidirectional Reservations . . . . . . . . . . . . . 21 87 6.2 QSPEC Examples . . . . . . . . . . . . . . . . . . . . . . 21 88 7. QSPEC Functional Specification . . . . . . . . . . . . . . . . 22 89 7.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 23 90 7.2 Parameter Coding . . . . . . . . . . . . . . . . . . . . . 25 91 7.2.1 Parameter . . . . . . . . . . . . . . 25 92 7.2.2 Parameter . . . . . . . . . . . . 26 93 7.2.3 . . . . . . . . . . . . . . . . . . . . . 26 94 7.2.4 Parameter . . . . . . . . . . . . . . . 27 95 7.2.5 Parameters . . . . . . . . . . . . . . 27 96 7.2.6 Parameters . . . . . . . . . . . . . . . 28 97 7.2.6.1 Parameter . . . . . . . . . . . . 28 98 7.2.6.2 Parameter . . . . . . . . 29 99 7.2.6.3 Parameter . . . . . . . . . 30 100 7.2.7 Priority Parameters . . . . . . . . . . . . . . . . . 30 101 7.2.7.1 & 102 Parameters . . . . . . . . . . . . . . . . . 30 103 7.2.7.2 Parameter . . . . . . 30 104 7.2.8 Parameter . . . . . . . . . . . . . . 32 105 7.2.9 Parameter . . . . . . . . . . . . . . . 33 106 7.2.10 Parameter . . . . . . . . . . . . . . . . 33 107 7.2.11 Parameter . . . . . . . . . . . . . . . . 34 108 7.2.12 Parameters . . . . . . . 35 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 36 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 36 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 112 11. Normative References . . . . . . . . . . . . . . . . . . . . . 36 113 12. Informative References . . . . . . . . . . . . . . . . . . . . 37 114 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38 115 Appendix A: QoS Models and QSPECs . . . . . . . . . . . . . . . . 40 116 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved 117 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 40 118 Appendix C: Main Changes Since Last Version & Open Issues . . . . 41 119 C.1 Main Changes Since Version -04 . . . . . . . . . . 41 120 C.2 Open Issues . . . . . . . . . . . . . . . . . . . 41 121 Intellectual Property Statement . . . . . . . . . . . . . . . . . 41 122 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 42 123 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 42 125 1. Conventions Used in This Document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 2. Introduction 133 The QoS NSLP establishes and maintains state at nodes along the path 134 of a data flow for the purpose of providing forwarding resources 135 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually 136 similar to RSVP [RFC2205], and meets the requirements of [RFC3726]. 138 A QoS-enabled domain supports a particular QoS model (QOSM), which is 139 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 140 provisioning methods and a QoS architecture. It defines the behavior 141 of the resource management function (RMF), including inputs and 142 outputs, and how QSPEC information is interpreted on traffic 143 description, resources required, resources available, and control 144 information required by the RMF. A QOSM also specifies a set of 145 mandatory and optional QSPEC parameters that describe the QoS and how 146 resources will be managed by the RMF. QoS NSLP can support signaling 147 for different QOSMs, such as for IntServ, DiffServ admission control, 148 and those specified in [Y.1541-QOSM, INTSERV-QOSM, RMD-QOSM]. For 149 more information on QOSMs see Section 7.2 and Appendix A. 151 One of the major differences between RSVP and QoS-NSLP is that 152 QoS-NSLP supports signaling for different QOSMs along the data path, 153 all with one signaling message. For example, the data path may start 154 in a domain supporting DiffServ and end in a domain supporting 155 Y.1541. However, because some typical QoS parameters are 156 standardized and can be reused in different QOSMs, some degree of 157 interoperability between QOSMs exists. 159 The QSPEC travels in QoS-NSLP messages and is opaque to the QoS NSLP. 160 It is only interpreted by the RMF. The content of the QSPEC is QOSM 161 specific. Since QoS-NSLP signaling operation can be different for 162 different QOSMs, the QSPEC contains two kinds of information, QSPEC 163 control information and QoS description. 165 QSPEC control information contains parameters that governs the RMF. 166 An example of QSPEC control information is how the excess traffic is 167 treated in the RMF queuing functions. 169 The QoS description is composed of QSPEC objects loosely 170 corresponding to the TSpec, RSpec and AdSpec objects specified in 171 RSVP. This is, the QSPEC may contain a description of QoS desired 172 and QoS reserved. It can also collect information about available 173 resources. Going beyond RSVP functionality, the QoS description 174 also allows indicating a range of acceptable QoS by defining a QSPEC 175 object denoting minimum QoS. Usage of these QSPEC objects is not 176 bound to particular message types thus allowing for flexibility. A 177 QSPEC object collecting information about available resources MAY 178 travel in any QoS-NSLP message, for example a QUERY message or a 179 RESERVE message. 181 3. Terminology 183 Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 184 if applicable to the underlying QOSM and a QNE MUST interpret, if 185 populated. 187 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 188 any QNE. Together with a description of QoS Desired or QoS 189 Available, it allows the QNI to specify a QoS range, i.e. an upper 190 and lower bound. If the QoS Desired cannot be reserved, QNEs are 191 going to decrease the reservation until the minimum QoS is hit. 193 Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 194 if applicable to the underlying QOSM, and a QNE SHOULD interpret if 195 populated and applicable to the QOSM(s) supported by the QNE. (A QNE 196 MAY ignore if it does not support a QOSM needing the optional QSPEC 197 parameter). 199 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 201 QNI: QoS NSIS Initiator, a node initiating QoS-NSLP signaling. 203 QNR: QoS NSIS Receiver, a node terminating QoS-NSLP signaling. 205 QoS Description: Describes the actual QoS in QSPEC objects QoS 206 Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC 207 objects are input or output parameters of the RMF. In a valid QSPEC, 208 at least one QSPEC object of the type QoS Desired, QoS Available or 209 QoS Reserved MUST be included. 211 QoS Available: QSPEC object containing parameters describing the 212 available resources. They are used to collect information along a 213 reservation path. 215 QoS Desired: QSPEC object containing parameters describing the 216 desired QoS for which the sender requests reservation. 218 QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g., 219 IntServ Controlled Load. A QOSM specifies a set of mandatory and 220 optional QSPEC parameters that describe the QoS and how resources 221 will be managed by the RMF. It furthermore specifies how to use QoS 222 NSLP to signal for this QOSM. 224 QoS Reserved: QSPEC object containing parameters describing the 225 reserved resources and related QoS parameters, for example, 226 bandwidth. 228 QSPEC Control Information: Control information that is specific to a 229 QSPEC, and contains parameters that govern the RMF. 231 QSPEC: QSPEC is the object of QoS-NSLP containing all QOSM-specific 232 information. 234 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 235 QoS description and QSPEC control information parameters, for 236 example, bandwidth, token bucket, and excess treatment parameters. 238 QSPEC Object: Main building blocks of QoS Description containing a 239 QSPEC parameter set that is input or output of an RMF operation. 241 Resource Management Function (RMF): Functions that are related to 242 resource management, specific to a QOSM. It processes the QoS 243 description parameters and QSPEC control parameters. 245 Read-only Parameter: QSPEC Parameter that is set by initiating or 246 responding QNE and is not changed during the processing of the QSPEC 247 along the path. 249 Read-write Parameter: QSPEC Parameter that can be changed during the 250 processing of the QSPEC by any QNE along the path. 252 4. QSPEC Parameters, Processing, & Extensibility 254 4.1 QSPEC Parameters 256 The definition of a QOSM includes the specification of how the 257 requested QoS resources will be described and how they will be 258 managed by the RMF. For this purpose, the QOSM specifies a set of 259 QSPEC parameters that describe the QoS and QoS resource control in 260 the RMF. A given QOSM defines which of the mandatory and optional 261 QSPEC parameters it uses, and it MAY define additional optional QSPEC 262 parameters. Mandatory and optional QSPEC parameters provide a common 263 language for QOSM developers to build their QSPECs and are likely to 264 be re-used in several QOSMs. Mandatory and optional QSPEC parameters 265 are defined in this document, and additional optional QSPEC 266 parameters can be defined in separate documents. Specification of 267 additional optional QSPEC parameters requires standards action, as 268 defined in Section 4.5. 270 4.2 QSPEC Processing 272 The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control 273 information and the QoS description are interpreted and MAY be 274 modified by the RMF in a QNE (see description in [QoS-SIG]). 276 A QoS-enabled domain supports a particular QOSM, e.g. DiffServ 277 admission control. If this domain supports QoS-NSLP signaling, its 278 QNEs MUST support the DiffServ admission control QOSM. The QNEs MAY 279 also support additional QOSMs. 281 A QoS NSLP message can contain a stack of at most 2. The first on 282 the stack is the Initiator QSPEC. This is a QSPEC provided by the 283 QNI, which travels end-to-end, and therefore the stack always has at 284 least depth 1. QSPEC parameters MUST NOT be deleted from or added to 285 the Initiator QSPEC. In addition, the stack MAY contain a Local 286 QSPEC stacked on top of the Initiator QSPEC. A QNE only considers 287 the topmost QSPEC. 289 At the ingress edge of a local QoS domain, a Local QSPEC MAY be 290 pushed on the stack in order to describe the requested resources in a 291 domain-specific manner. Also, the Local QSPEC is popped from the 292 stack at the egress edge of the local QoS domain. 294 This draft provides a template for the QSPEC, which is needed in 295 order to help define individual QOSMs and in order to promote 296 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 297 is composed of QSPEC control information and QoS description. QoS 298 description in turn is composed of up to four QSPEC objects (not all 299 of them need to be present), namely QoS Desired, QoS Available, QoS 300 Reserved and Minimum QoS. Each of these QSPEC Objects, as well as 301 QSPEC Control Information, consists of a number of mandatory and 302 optional QSPEC parameters. 304 +-------------+---------------------------------------+ 305 |QSPEC Control| QoS | 306 | Information | Description | 307 +-------------+---------------------------------------+ 309 \________________ ______________________/ 310 V 311 +----------+----------+---------+-------+ \ 312 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC 313 +----------+----------+---------+-------+ / Objects 315 \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/ 316 V V V V V 318 +-------------+... +-------------+... 319 |QSPEC Para. 1| |QSPEC Para. n| 320 +-------------+... +-------------+... 322 Figure 1: Structure of the QSPEC 324 The internal structure of each QSPEC object and the QSPEC control 325 information, with mandatory and optional parameters, is illustrated 326 in Figure 2. 328 +------------------+-----------------+---------------+ 329 | QSPEC/Ctrl Info | Mandatory QSPEC |Optional QSPEC | 330 | Object ID | Parameters | Parameters | 331 +------------------+-----------------+---------------+ 333 Figure 2: Structure of QSPEC Objects & Control Information 335 4.3 Example of NSLP/QSPEC Operation 337 This Section illustrates the operation and use of the QSPEC within 338 the NSLP. The example configuration in shown in Figure 3. 340 +----------+ /-------\ /--------\ /--------\ 341 | Laptop | | Home | | Cable | | DiffServ | 342 | Computer |-----| Network |-----| Network |-----| Network |----+ 343 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 344 \-------/ \--------/ \--------/ | 345 | 346 +-----------------------------------------------+ 347 | 348 | /--------\ +----------+ 349 | | "X"G | | Handheld | 350 +---| Wireless |-----| Device | 351 | XG QOSM | +----------+ 352 \--------/ 354 Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC 355 Operation 357 In this configuration, a laptop computer and a handheld wireless 358 device are the endpoints for some application that has QoS 359 requirements. Assume initially that the two endpoints are stationary 360 during the application session, later we consider mobile endpoints. 361 For this session, the laptop computer is connected to a home network 362 that has no QoS support. The home network is connected to a 363 CableLabs-type cable access network with dynamic QoS (DQOS) support, 364 such as specified in the 'CMS to CMS Signaling Specification' [CMSS] 365 for cable access networks. That network is connected to a DiffServ 366 core network that uses the RMD QOSM [RMD-QOSM]. On the other side of 367 the DiffServ core is a wireless access network built on generation 368 "X" technology with QoS support as defined by generation "X". And 369 finally the handheld endpoint is connected to the wireless access 370 network. 372 We assume that the Laptop is the QNI and handheld device is the QNR. 374 The QNI will populate an Initiator QSPEC to achieve the QoS desired 375 on the path. In this example we consider two different ways to 376 perform sender-initiated signaling for QoS: 378 Case 1) The QNI sets , and possibly 379 QSPEC objects in the Initiator QSPEC, and initializes 380 to . Since this is a reservation in a 381 heterogenic network with different QOSMs supported in different 382 domains, each QNE on the path reads and interprets those parameters 383 in the Initiator QSPEC that it needs to implement the QOSM within its 384 domain (as described below). Each QNE along the path checks to see if 385 resources can be reserved, and if not, the QNE 386 reduces the respective parameter values in and 387 reserves these values. The minimum parameter values are given in 388 , if populated, otherwise zero if is not 389 included. If one or more parameters in fails to 390 satisfy the corresponding minimum values in Minimum QoS, the QNE 391 notifies the QNI and the reservation is aborted. Otherwise, the QNR 392 notifies the QNI of the for the reservation. 394 Case 2) The QNI populated the Initiator QSPEC with . 395 Since this is a reservation in a heterogenic network with different 396 QOSMs supported in different domains, each QNE on the path reads and 397 interprets those parameters in the Initiator QSPEC that it needs to 398 implement the QOSM within its domain (as described below). If a QNE 399 cannot reserve resources, the reservation fails. 401 In both cases, the QNI populates mandatory and optional QSPEC to 402 ensure correct treatment of its traffic in domains down the path. 403 Since the QNI does not know the QOSM used in downstream domains, it 404 includes values for those mandatory and optional QSPEC parameters it 405 cares about. Let us assume the QNI wants to achieve IntServ-like QoS 406 guarantees, and also is interested in what path latency it can 407 achieve. The QNI therefore includes in the QSPEC the QOSM ID for 408 IntServ Controlled Load Service. The QSPEC objects are populated with 409 all parameters necessary for IntServ Controlled Load and additionally 410 the parameter to measure path latency, as follows: 412 = 413 = 415 In both cases, each QNE on the path reads and interprets those 416 parameters in the Initiator QSPEC that it needs to implement the QOSM 417 within its domain. It may need additional parameters for its QOSM, 418 which are not specified in the Initiator QSPEC. If possible, these 419 parameters must be inferred from those that are present, according to 420 rules defined in the QOSM implemented by this QNE. 422 There are two possibilities when a RESERVE message is received at a 423 QNE at a domain border (we illustrate both possibilities in the 424 example): 426 - the QNE can stack a local QSPEC on top of the Initiator QSPEC (this 427 is new in QoS NSLP, RSVP does not do this). 429 - the QNE can tunnel the Initiator RESERVE message through its domain 430 and issue its own Local RESERVE message. For this new Local RESERVE 431 message, the QNE acts as the QNI, and the QSPEC in the domain is an 432 Initiator QSPEC. This procedure is also used by RSVP in making 433 aggregate reservations, in which case there is not a new intra-domain 434 (aggregate) RESERVE for each newly arriving interdomain (per-flow) 435 RESERVE, but the aggregate reservation is updated by the border QNE 436 (QNI) as need be. This is also how RMD works [RMD-QOSM]. 438 For example, at the RMD domain, a local RESERVE with its own RMD 439 Initiator QSPEC corresponding to the RMD-QOSM is generated based on 440 the original Initiator QSPEC according to the procedures described in 441 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE 442 to the RMD domain must map the QSPEC parameters contained in the 443 original Initiator QSPEC into the RMD QSPEC. The RMD QSPEC for 444 example needs and . is generated 445 from the parameter. Information on , 446 however, is not provided. According to the rules laid out in the RMD 447 QOSM, the ingress QNE infers from the fact that an IntServ Controlled 448 Load QOSM was signaled that the EF PHB is appropriate to set the parameter. These RMD QSPEC parameters are populated in the 450 RMD Initiator QSPEC generated within the RMD domain. 452 Furthermore, the node at the egress to the RMD domain updates on behalf of the entire RMD domain if it can. If it 454 cannot, it raises the parameter-specific, 'not-supported' flag, 455 warning the QNR that the final value of these parameters in QoS 456 Available is imprecise. 458 In the XG domain, the Initiator QSPEC is translated into a Local 459 QSPEC using a similar procedure as described above. The Local QSPEC 460 becomes the current QSPEC used within the XG domain, that is, the 461 it becomes the first QSPEC on the stack, and the Initiator QSPEC is 462 second. This saves the QNEs within the XG domain the trouble of 463 re-translating the Initiator QSPEC. At the egress edge of the XG 464 domain, the translated Local QSPEC is popped, and the Initiator QSPEC 465 returns to the number one position. 467 If the reservation was successful, eventually the RESERVE request 468 arrives at the QNR (otherwise the QNE at which the reservation failed 469 would have aborted the RESERVE and sent an error RESPONSE back to the 470 QNI). The QNR generates a positive RESPONSE with QSPEC objects - and for case 1 - additionally . The 472 parameters appearing in are the same as in , with values copied from in case 1, and with 474 the original values from in case 2. That is, it is not 475 necessary to transport the object back to the QNI since 476 the QNI knows what it signaled originally, and the information is not 477 useful for QNEs in the reverse direction. The object 478 should transport all necessary information, although the and objects may end up transporting some of 480 the same information. 482 Hence, the QNR populates the following QSPEC objects: 484 = 485 = 487 If the handheld device on the right of Figure 3 is mobile, and moves 488 through different "XG" wireless networks, then the QoS might change 489 on the path since different XG wireless networks might support 490 different QOSMs. As a result, QoS-NSLP/QSPEC processing will have to 491 renegotiate the on the path. From a QSPEC 492 perspective, this is like a new reservation on the new section of the 493 path and is basically the same as any other rerouting event - to the 494 QNEs on the new path it looks like a new reservation. That is, in 495 this mobile scenario, the new segment may support a different QOSM 496 than the old segment, and the QNI would now signal a new reservation 497 (explicitly, or implicitly with the next refreshing RESERVE message) 498 to account for the different QOSM in the XG wireless domain. Further 499 details on rerouting are specified in [QoS-SIG]. 501 4.4 Treatment of QSPEC Parameters 503 4.4.1 Mandatory and Optional QSPEC Parameters 505 Mandatory and optional QSPEC parameters are defined in this document 506 and are applicable to a number of QOSMs. Mandatory QSPEC parameters 507 are treated as follows: 509 o A QNI SHOULD populate mandatory QSPEC parameters if applicable to 510 the underlying QOSM. 511 o QNEs MUST interpret mandatory QSPEC parameters, if populated. 513 Optional QSPEC parameters are treated as follows: 515 o A QNI SHOULD populate optional QSPEC parameters if applicable to 516 the QOSM for which it is signaling. 518 o QNEs SHOULD interpret optional QSPEC parameters, if populated and 519 applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore 520 the optional QSPEC parameter if it does not support a QOSM needing 521 the optional QSPEC parameter). 523 4.4.2 Read-only and Read-write QSPEC Parameters 525 Both mandatory and optional QSPEC parameters can be read-only or 526 read-write. Read-write parameters can be changed by any QNE, whereas 527 read-only parameters are fixed by the QNI and/or QNR. For example in 528 a RESERVE message, all parameters in are read-write 529 parameters, which are updated by intermediate QNEs. Read-only 530 parameters are, for example, all parameters in as sent 531 by the QNI. 533 QoS description parameters can be both read-only or read-write, 534 depending on which QSPEC object, and which message, they appear in. 535 In particular, all parameters in and are 536 read-only for all messages. More details are provided in Sec. 7.1. 538 In the QSPEC Control Information Object, the property of being 539 read-write or read-only is parameter specific. 541 4.5 Inability to handle parameters 543 A QNE may not be able to interpret or update the QSPEC or individual 544 parameters for several reasons. For example, the QSPEC cannot be 545 read or interpreted because it is erroneous, or because of a QNE 546 fault. This is an error condition. Another reason is that a 547 parameter type is unknown because it is optional, or a parameter 548 value in QoS Available cannot be updated because QoS NSLP was 549 tunneled to the QNE. These are not error conditions. 551 4.5.1 Error Conditions 553 When an RMF cannot interpret the QSPEC because the coding is 554 erroneous, it raises corresponding flags in the QSPEC. A more 555 detailed report of the problem is provided in QoS NSLP. That is, the 556 'error flags' are located in each QSPEC Object and in each parameter. 557 If such a flag is set, at least one QNE along the data transmission 558 path between the QNI and QNR cannot interpret a mandatory or optional 559 QSPEC parameter or the QSPEC object for any reason, such as a 560 protocol error, QNE fault, etc. In this case, more detailed error 561 information may be given in the QoS NSLP error message. That is, if 562 possible the RMF must communicate error details to the QoS NSLP 563 processing. QoS NSLP [QoS-SIG] describes how the erroneous message 564 is handled further. 566 When the error can be located in a particular parameter, the QNE 567 detecting the error raises the error flag in this parameter. 568 Additionally, it raises the error flag in the corresponding QSPEC 569 Object. If the error cannot be located at the parameter level, only 570 the error flag in the QSPEC object is raised. 572 4.5.2 Inability to interpret and update parameters 574 Each QSPEC parameter has an associated 'not-supported flag'. If such 575 a flag is set, at least one QNE along the data transmission path 576 between the QNI and QNR can not support the specified QSPEC 577 parameter. The not-supported flag is set to 1 if an optional QSPEC 578 parameter is not supported by a QNE. If the not-supported flag is 579 set, then at least one QNE along the data transmission path between 580 the QNI and QNR can not support the specified optional parameter. 581 This means the value collected in the corresponding parameter is a 582 lower bound to the "real" value. A QNE MUST be able to set the 583 not-supported flag if it does not support the optional parameter. 585 Each QSPEC parameter has an associated 'tunneled-parameter flag', 586 which is set to 1 if a mandatory or optional QSPEC parameter is 587 tunneled through a QOSM domain, and the edge node is unable to set 588 the QSPEC parameter. When a RESERVE message is tunneled through a 589 domain, QNEs inside the domain cannot update read-write parameters. 590 The egress QNE in a domain has two choices: either it is configured 591 to have the knowledge to update the parameters correctly. Or it 592 cannot update the parameters. In this case it MUST set the 593 tunneled-parameter flag to tell the QNI (or QNR) that the information 594 contained in the read-write parameter is most likely incorrect (or a 595 lower bound). 597 The formats and semantics of all flags are given in Section 6.1. 599 4.6 QSPEC Extensibility 601 Additional optional QSPEC parameters MAY need to be defined in the 602 future. Additional optional QSPEC parameters are defined in separate 603 Informational documents specific to a given QOSM. For example, 604 optional QSPEC parameters are defined in [RMD-QOSM] and 605 [Y.1541-QOSM]. 607 5. QSPEC Format Overview 609 QSPEC = 610 612 As described above, the QSPEC contains an identifier for the QOSM, 613 the actual resource description (QoS description) as well as QSPEC 614 control information. Note that all QSPEC parameters defined in the 615 following Sections are mandatory QSPEC parameters unless specifically 616 designated as optional QSPEC parameters. 618 A QSPEC object ID identifies whether the object is or . As described below, the is further broken down into , , , and objects. A QSPEC 622 parameter ID is assigned to identify each QSPEC parameter defined 623 below. 625 identifies the QSPEC version number, and 626 identifies the particular QOSM being used by the QNI (the QSPEC 627 Version and QOSM ID are assigned by IANA). The tells a QNE 628 which parameters to expect. This may simplify processing and error 629 analysis. Furthermore, it may be helpful for a QNE or a domain 630 supporting more than one QOSM to learn which QOSM the QNI would like 631 to have in order to use the most suitable QOSM. Note that the QSPEC 632 parameters do not uniquely define the QNI QOSM since more parameters 633 than required by the QNI QOSM can be included by the QNI. QOSM IDs 634 are assigned by IANA. 636 5.1 QSPEC Control Information 638 QSPEC control information is used for signaling QOSM RMF functions 639 not defined in QoS-NSLP. It enables building new RMF functions 640 required by a QOSM within a QoS-NSLP signaling framework, such as 641 specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. 643 = 644 646 Note that is a read-write parameter. and are read-only parameters. 649 is an identifier for which QSPEC 650 procedures are used, as defined in Section 7.1. 652 is a flag bit telling the QNR (or QNI in a RESPONSE 653 message) whether or not a particular QOSM is supported by each QNE 654 in the path between the QNI and QNR. A QNE sets the 655 flag parameter if it does not support the relevant QOSM 656 specification. If the QNR finds this bit set, at least one QNE along 657 the data transmission path between the QNI and QNR can not support 658 the specified QOSM.In a local QSPEC, refers to the 659 QoS-NSLP peers of the local QOSM domain. 661 The parameter describes how the QNE will process 662 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 663 be dropped, shaped and/or remarked. The excess treatment parameter is 664 initially set by the QNI and is read-only. 666 5.2 QoS Description 668 The QoS Description is broken down into the following QSPEC objects: 670 = 671 673 Of these QSPEC objects, QoS Desired, QoS Available and QoS Reserved 674 MUST be supported by QNEs. Minimum QoS MAY be supported. 676 5.2.1 678 = 679 681 These parameters describe the resources the QNI desires to reserve 682 and hence this is a read-only QSPEC object. The 683 resources that the QNI wishes to reserve are of course directly 684 related to the traffic the QNI is going to inject into the network. 685 Therefore, when used in the object, refers to traffic injected by the QNI into the network. 688 = 690 = link bandwidth needed by flow [RFC 2212, RFC 2215] 692 =

[RFC 2210] 694 Note that the Path MTU Discovery (PMTUD) working group is currently 695 specifying a robust method for determining the MTU supported over an 696 end-to-end path. This new method is expected to update RFC1191 and 697 RFC1981, the current standards track protocols for this purpose. 699 = 701 An application MAY like to reserve resources for packets with a 702 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 703 [RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class 704 type [RFC3564]. 706 = 707 709 is an essential way to differentiate flows for 710 emergency services, ETS, E911, etc., and assign them a higher 711 admission priority than normal priority flows and best-effort 712 priority flows. is the priority of the new 713 flow compared with the defending priority of previously admitted 714 flows. Once a flow is admitted, the preemption priority becomes 715 irrelevant. is used to compare with the 716 preemption priority of new flows. For any specific flow, its 717 preemption priority MUST always be less than or equal to the 718 defending priority. 720 Appropriate security measures need to be taken to prevent abuse of 721 the parameters, see Section 8 on Security Considerations. 723 [Y.1540] defines packet transfer outcomes, as follows: 725 Successful: packet arrives within the preset waiting time with no 726 errors 728 Lost: packet fails to arrive within the waiting time 730 Errored: packet arrives in time, but has one or more bit errors 731 in the header or payload 733 Packet Loss Ratio (PLR) = total packets lost/total packets sent 734 Packet Error Ratio (PER) = total errored packets/total packets sent 736 , , , and are 737 optional parameters describing the desired path latency, path jitter 738 and path bit error rate respectively. Since these parameters are 739 cumulative, an individual QNE cannot decide whether the desired path 740 latency, etc., is available, and hence they cannot decide whether a 741 reservation fails. Rather, when these parameters are included in 742 , the QNI SHOULD also include corresponding parameters 743 in a QSPEC object in order to facilitate collecting 744 this information. 746 5.2.2 748 QNE MUST inspect all parameters of this QSPEC object, and if 749 resources available to this QNE are less than what a particular 750 parameter says currently, the QNE MUST adapt this parameter 751 accordingly. Hence when the message arrives at the recipient of the 752 message, reflects the bottleneck of the resources 753 currently available on a path. It can be used in a QUERY message, 754 for example, to collect the available resources along a data path. 756 When travels in a RESPONSE message, it in fact just 757 transports the result of a previous measurement performed by a 758 RESERVE or QUERY message back to the initiator. Therefore in this 759 case, is read-only. 761 The parameters and provide information, 762 for example, about the bandwidth available along the path followed by 763 a data flow. The local parameter is an estimate of the bandwidth the 764 QNE has available for packets following the path. Computation of the 765 value of this parameter SHOULD take into account all information 766 available to the QNE about the path, taking into consideration 767 administrative and policy controls on bandwidth, as well as physical 768 resources. The composition rule for this parameter is the MIN 769 function. The composed value is the minimum of the QNE's value and 770 the previously composed value. This quantity, when composed 771 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 772 minimal bandwidth link along the path from QNI to QNR. 774 The parameter accumulates the latency of the packet 775 forwarding process associated with each QNE, where the latency is 776 defined to be the mean packet delay added by each QNE. This delay 777 results from speed-of-light propagation delay, from packet processing 778 limitations, or both. It does not include any variable queuing delay 779 that may be present. Each QNE MUST add the propagation delay of its 780 outgoing link, which includes the QNR adding the associated delay for 781 the egress link. Furthermore, the QNI MUST add the propagation delay 782 of the ingress link. The composition rule for the 783 parameter is summation with a clamp of (2**32 - 1) on the maximum 784 value. This quantity, when composed end-to-end, informs the QNR (or 785 QNI in a RESPONSE message) of the minimal packet delay along the path 786 from QNI to QNR. The purpose of this parameter is to provide a 787 minimum path latency for use with services which provide estimates or 788 bounds on additional path delay [RFC 2212]. Together with the 789 queuing delay bound, this parameter gives the application knowledge 790 of both the minimum and maximum packet delivery delay. Knowing both 791 the minimum and maximum latency experienced by data packets allows 792 the receiving application to know the bound on delay variation and 793 de-jitter buffer requirements. 795 The parameter accumulates the jitter of the packet 796 forwarding process associated with each QNE, where the jitter is 797 defined to be the nominal jitter added by each QNE. IP packet 798 jitter, or delay variation, is defined in [RFC3393], Section 3.4 799 (Type-P-One-way-ipdv), and where the selection function includes the 800 packet with minimum delay such that the distribution is equivalent to 801 2-point delay variation in [Y.1540]. The suggested evaluation 802 interval is 1 minute. Note that the method to estimate IP delay 803 variation without active measurements requires more study. This 804 jitter results from packet processing limitations, and includes any 805 variable queuing delay which may be present. Each QNE MUST add the 806 jitter of its outgoing link, which includes the QNR adding the 807 associated jitter for the egress link. Furthermore, the QNI MUST 808 add the jitter of the ingress link. The composition method for the 809 parameter is the combination of several statistics 810 describing the delay variation distribution with a clamp on the 811 maximum value (note that the methods of accumulation and estimation 812 of nominal QNE jitter are under study). This quantity, when composed 813 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 814 nominal packet jitter along the path from QNI to QNR. The purpose of 815 this parameter is to provide a nominal path jitter for use with 816 services that provide estimates or bounds on additional path delay 817 [RFC2212]. Together with the and the queuing delay 818 bound, this parameter gives the application knowledge of the typical 819 packet delivery delay variation. 821 The parameter accumulates the packet loss rate (PLR) of 822 the packet forwarding process associated with each QNE, where the PLR 823 is defined to be the PLR added by each QNE. Each QNE MUST add the 824 PLR of its outgoing link, which includes the QNR adding the 825 associated PLR for the egress link. Furthermore, the QNI MUST add 826 the PLR of the ingress link. The composition rule for the parameter is summation with a clamp on the maximum value (this 828 assumes sufficiently low PLR values such that summation error is not 829 significant). This quantity, when composed end-to-end, informs the 830 QNR (or QNI in a RESPONSE message) of the minimal packet PLR along 831 the path from QNI to QNR. As with , the method to 832 estimate requires more study. 834 , , , : Error terms C and D represent how the 835 element's implementation of the guaranteed service deviates from the 836 fluid model. These two parameters have an additive composition rule. 837 The error term C is the rate-dependent error term. It represents the 838 delay a datagram in the flow might experience due to the rate 839 parameters of the flow. The error term D is the rate-independent, 840 per-element error term and represents the worst case non-rate-based 841 transit time variation through the service element. If the 842 composition function is applied along the entire path to compute the 843 end-to-end sums of C and D ( and ) and the resulting 844 values are then provided to the QNR (or QNI in a RESPONSE message). 845 and are the sums of the parameters C and D between the 846 last reshaping point and the current reshaping point. 848 5.2.3 850 = 852 These parameters describe the QoS reserved by the QNEs along the data 853 path, and hence the QoS reserved QSPEC object is read-write. 855 , and are defined above. 857 = slack term, which is the difference between desired delay and 858 delay obtained by using bandwidth reservation, and which is used to 859 reduce the resource reservation for a flow [RFC 2212]. This is an 860 optional parameter. 862 5.2.4 864 = 866 does not have an equivalent in RSVP. It allows the QNI 867 to define a range of acceptable QoS levels by including both the 868 desired QoS value and the minimum acceptable QoS in the same message. 869 It is a read-only QSPEC object. The desired QoS is included with a 870 and/or a QSPEC object seeded to the 871 desired QoS value. The minimum acceptable QoS value MAY be coded in 872 the QSPEC object. As the message travels towards the 873 QNR, is updated by QNEs on the path. If its value 874 drops below the value of the reservation fails and is 875 aborted. When this method is employed, the QNR SHOULD signal back to 876 the QNI the value of attained in the end, because the 877 reservation MAY need to be adapted accordingly. 879 6. QSPEC Procedures & Examples 881 6.1 QSPEC Procedures 883 While the QSPEC template aims to put minimal restrictions on usage of 884 QSPEC objects in , interoperability between QNEs and 885 between QOSMs must be ensured. We therefore give below an exhaustive 886 list of QSPEC object combinations for the message sequences described 887 in QoS NSLP [QOS-SIG]. A specific QOSM may impose more restrictions 888 on the QNI or QNR freedom. 890 6.1.1 Sender-Initiated Reservations 892 Here the QNI issues a RESERVE, which is replied to by a RESPONSE. 893 This response is generated either by the QNR or, in case the 894 reservation was unsuccessful, by a QNE. The following possibilities 895 for QSPEC object usage exist: 897 ID | RESERVE | RESPONSE 898 --------------------------------------------------------------- 899 1 | QoS Desired | QoS Reserved 900 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 901 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 903 (1) If only QoS Desired is included in the RESERVE, the implicit 904 assumption is that exactly these resources must be reserved. If this 905 is not possible the reservation fails. The parameters in QoS 906 Reserved are copied from the parameters in QoS Desired. 908 (2) When QoS Available is included in the RESERVE also, some 909 parameters will appear only in QoS Available and not in QoS Desired. 910 It is assumed that the value of these parameters is collected for 911 informational purposes only (e.g. path latency). 913 However, some parameters in QoS Available can be the same as in QoS 914 Desired. For these parameters the implicit message is that the QNI 915 would be satisfied by a reservation with lower parameter values than 916 specified in QoS Desired. For these parameters, the QNI seeds the 917 parameter values in QoS Available to those in QoS Desired (except for 918 cumulative parameters such as ). 920 Each QNE adapts the parameters in QoS Available according to its 921 current capabilities. Reservations in each QNE are hence based on 922 current parameter values in QoS Available (and additionally those 923 parameters that only appear in QoS Desired). The drawback of this 924 approach is that, if the resulting resource reservation becomes 925 gradually smaller towards the QNR, QNEs close to the QNI have an 926 oversized reservation, possibly resulting in unnecessary costs for 927 the user. Of course, in the RESPONSE the QNI learns what the actual 928 reservation is (from the QoS RESERVED object) and can immediately 929 issue a properly sized refreshing RESERVE. The advantage of the 930 approach is that the reservation is performed in half-a-roundtrip 931 time. 933 The parameter types included in QoS Reserved in the RESPONSE MUST be 934 the same as those in QoS Desired in RESERVE. For those parameters 935 that were also included in QoS Available in RESERVE, their value is 936 copied into QoS Desired. For the other parameters, the value is 937 copied from QoS Desired (the reservation would fail if the 938 corresponding QoS could not be reserved). 940 The parameters in the QoS Available QSPEC object in the RESPONSE are 941 copied with their values from the QoS Available QSPEC object in the 942 RESERVE. Note that the parameters in QoS Available are read-write 943 in the RESERVE message, whereas they are read-only in the RESPONSE. 945 (3) this case is handled as case (2), except that the reservation 946 fails when QoS Available becomes less than Minimum QoS for one 947 parameter. If a parameter appears in QoS Available but not in 948 Minimum QoS it is assumed that the minimum value for this parameter 949 is that given in QoS Available. 951 6.1.2 Receiver-Initiated Reservations 953 Here the QNR issues a QUERY which is replied to by the QNI with a 954 RESERVE if the reservation was successful. The QNR in turn sends a 955 RESPONSE to the QNI. 957 ID| QUERY | RESERVE | RESPONSE 958 --------------------------------------------------------------------- 959 1 |QoS Des. | QoS Des. | QoS Res. 960 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 961 3 |QoS Avail. | QoS Des. | QoS Res. 963 (1) and (2) The idea is that the sender (QNR in this scenario) needs 964 to inform the receiver (QNI in this scenario) about the QoS it 965 desires. To this end the sender sends a QUERY message to the 966 receiver including a QoS Desired QSPEC object. If the QoS is 967 negotiable it additionally includes a (possibly zero) Minimum QoS, as 968 in Case b. 970 The RESERVE message includes QoS Available if the sender signaled QoS 971 is negotiable (i.e. it included Minimum QoS). If the Minimum QoS 972 received from the sender is non-zero, the QNR also includes Minimum 973 QoS. 975 (3) This is the "RSVP-style" scenario. The sender (QNR) issues a 976 QUERY with QoS Available to collect path properties, and the QoS 977 Desired in the RESERVE issued by the receiver (QNI) is populated from 978 the parameter values in QoS Available from the QUERY message. The 979 advantage of this model is that the situation of over-reservation in 980 QNEs close to the QNI as described above does not occur. On the 981 other hand, the QUERY may find, for example, a particular bandwidth 982 is not available. When the actual reservation is performed, however, 983 the desired bandwidth may meanwhile have become free. That is, the 984 'RSVP style' may result in a smaller reservation than necessary. 986 6.1.3 Resource Queries 988 Here the QNI issues a QUERY in order to investigate what resources 989 are currently available. The QNR replies with a RESPONSE. 991 ID | QUERY | RESPONSE 992 -------------------------------------------- 993 1 | QoS Available | QoS Available 995 Note QoS Available when traveling in the QUERY is read-write, whereas 996 in the RESPONSE it is read-only. 998 6.1.4 Bidirectional Reservations 1000 On a QSPEC level, bidirectional reservations are no different from 1001 uni-directional reservations, since QSPECs for different directions 1002 never travel in the same message. 1004 6.2 QSPEC Examples 1006 This Section provides an example QSPEC for DiffServ admission 1007 control. The QSPEC for IntServ controlled load service is 1008 specified in [INTSERV-QOSM] (note that the QOSMs for IntServ 1009 Controlled Load Service and IntServ Guaranteed Service are defined in 1010 [RFC2211] and [RFC2212], respectively). 1012 The QSPEC for DiffServ admission control may be composed, for 1013 example, of the QSPEC objects and , as 1014 well as . Which QSPEC object is present in a 1015 particular QSPEC depends on the message type (RESERVE, QUERY etc) in 1016 which the QSPEC travels. Parameters in the QSPEC for DiffServ 1017 requesting bandwidth for different PHBs are as follows: 1019 Example QSPEC for the DiffServ EF PHB [RFC3297]: 1021 = 1022 = 1023 = 1024 = 1025 = 1026 = 1027 = 1029 In general, the EF PHB is a property of the service that is NOT 1030 dependent on the input traffic characteristics. A server of rate R 1031 and latency E that is compliant with the EF PHB must deliver at least 1032 the configured service rate R with at most latency E for any traffic 1033 characterization. Therefore, strictly speaking, there is no specific 1034 traffic descriptor required to deliver the EF PHB (which by 1035 definition is a local per-hop characterization). However, in order 1036 to deliver a reasonable end-to-end delay, it is typically assumed 1037 that EF traffic is shaped at the ingress. A typical assumption is 1038 that input traffic at any ingress is constrained by a single rate 1039 token bucket. Therefore, a single rate token bucket is sufficient 1040 to signal in QoS-NSLP/QSPEC for the DiffServ-QOSM. 1042 Example QSPEC for the DiffServ AFxy PHB [RFC2597]: 1044 = 1045 = 1046 = 1047 = 1048 1049 = 1050 = 1051 = 1053 QNEs process two sets of token bucket parameters to implement the 1054 DiffServ AF QOSM, one token bucket for the average (CBS) traffic and 1055 one token bucket for the burst (EBS) traffic. These 2 token buckets 1056 are sufficient to cover most of the ways in which one would 1057 distinguish among 3 levels of drop precedence at the queuing 1058 mechanics level, as described in the Appendix to [RFC2597]. 1060 QoS-NSLP/QSPEC can support signaling the parameters required for the 1061 DiffServ marker elements described in [RFC2697] and [RFC2698]. 1062 [RFC2697] defines a Single Rate Three Color Marker (srTCM), which 1063 can be used as component in a DiffServ traffic conditioner [RFC2475, 1064 RFC2474]. The srTCM meters a traffic stream and marks its packets 1065 according to three traffic parameters, Committed Information Rate 1066 (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be 1067 either green, yellow, or red. A packet is marked green if it does 1068 not exceed the CBS, yellow if it does exceed the CBS, but not the 1069 EBS, and red otherwise. 1071 RFC 2697 and RFC 2698 provide specific procedures, where in essence, 1072 RFC 2697 is using two token buckets that run at the same rate. 1074 7. QSPEC Functional Specification 1076 This Section defines the encodings of the QSPEC parameters and QSPEC 1077 control information defined in Section 5. We first give the general 1078 QSPEC formats and then the formats of the QSPEC objects and 1079 parameters. 1081 Note that all QoS Description parameters can be either read-write or 1082 read-only, depending on which object and which message they appear 1083 in. However, in a given QSPEC object, all objects are either 1084 read-write or read-only. In order to simplify keeping track of 1085 whether an object is read-write or read-only, a corresponding flag is 1086 associated with each object. 1088 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1089 well as 32-bit floating point numbers, are as specified in [RFC1832, 1090 IEEE754, NETWORK-BYTE-ORDER]. 1092 7.1 General QSPEC Formats 1094 The format of the QSPEC closely follows that used in GIST [GIST] and 1095 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1096 general format: 1098 o The overall format is Type-Length-Value (in that order). 1100 o Some parts of the type field are set aside for control flags. 1102 o Length has the units of 32-bit words, and measures the length of 1103 Value. If there is no Value, Length=0. 1105 o Value is a whole number of 32-bit words. If there is any padding 1106 required, the length and location MUST be defined by the 1107 object-specific format information; objects that contain variable 1108 length types may need to include additional length subfields to do 1109 so. 1111 o Any part of the object used for padding or defined as reserved("r") 1112 MUST be set to 0 on transmission and MUST be ignored on reception. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Common QSPEC Header | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 // QSPEC Control Information // 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 // QSPEC QoS Objects // 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 The Common QSPEC Header is a fixed 4-byte long object containing the 1125 QOSM ID and an identifier for the QSPEC Procedure (see Section 6.1): 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Vers. | QOSM ID | QSPEC Proc. | Reserved | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 Note that a length field is not necessary since the overall length of 1134 the QSPEC is contained in the higher level QoS NSLP data object. 1136 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1138 QOSM ID: Identifies the particular QOSM being used by the QNI. It is 1139 assigned by IANA. 1141 QSPEC Proc.: Is composed of two times 4 bits. The first set of bits 1142 identifies the Message Sequence, the second set 1143 identifies the QSPEC Object Combination used for this 1144 particular message sequence: 1146 0 1 2 3 4 5 6 7 1147 +-+-+-+-+-+-+-+-+ 1148 |Mes.Sq |Obj.Cmb| 1149 +-+-+-+-+-+-+-+-+ 1151 The Message Sequence field can attain the following 1152 values: 1154 0: Sender-Initiated Reservations, as defined in Section 1155 6.1.1 1156 1: Receiver-Initiated Reservations, as defined in 1157 Section 6.1.2 1158 2: Resource Queries, as defined in Section 6.1.3 1160 The Object Combination field can take the values between 1161 1 and 3 indicated in the tables in Section 6.1.1 to 1162 6.1.3. 1164 The QSPEC Control Information is a variable length object containing 1165 one or more parameters. The QSPEC Objects field is a collection of 1166 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1167 common format and each contain several parameters. 1169 Both the QSPEC Control Information object and the QSPEC QoS objects 1170 share a common header format: 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 |R|E|r|r| Object Type |r|r|r|r| Length | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 R Flag: If set the parameters contained in the object are read-only. 1179 Otherwise they are read-write. Note that in the case of 1180 Object Type = 0 (Control Information), this value is 1181 overwritten by parameter-specific values. 1183 E Flag: Set if an error occurs on object level 1185 Object Type = 0: control information 1186 = 1: QoS Desired 1187 = 2: QoS Available 1188 = 3: QoS Reserved 1189 = 4: Minimum QoS 1191 The r-flags are reserved. 1193 Each optional or mandatory parameter within an object can be 1194 similarly encoded in TLV format using a similar parameter header: 1196 0 1 2 3 1197 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 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 |M|E|N|T| Parameter ID |r|r|r|r| Length | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 M Flag: When set indicates the subsequent parameter is a mandatory 1203 parameter and MUST be interpreted. Otherwise the parameter is 1204 optional and can be ignored if not understood. 1205 E Flag: When set indicates an error occurred when this parameter was 1206 being interpreted. 1207 N Flag: Not-supported Flag (see Section 4.5) 1208 T Flag: Tunneled-parameter Flag (see Section 4.5) 1209 Parameter Type: Assigned to each parameter (see below) 1211 7.2 Parameter Coding 1213 Parameters are usually coded individually, for example, the Bandwidth 1214 Parameter (Section 7.2.2). However, it is also possible to combine 1215 several parameters into one parameter field, which is called 1216 "container coding". This coding is useful if either a) the 1217 parameters always occur together, as for example the several 1218 parameters that jointly make up the token bucket, or b) in order to 1219 make coding more efficient because the length of each parameter value 1220 is much less than a 32-bit word (as for example described in 1221 [RMD-QOSM]). 1223 7.2.1 Parameter 1225 0 1 2 3 1226 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 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 |1|E|N|T| 1 |r|r|r|r| 1 | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | NON QOSM Hop| Reserved | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 NON QOSM Hop: This field is set to 1 if a non QOSM-aware QNE is 1234 encountered on the path from the QNI to the QNR. It is a read-write 1235 parameter. 1237 7.2.2 Parameter 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 |1|E|N|T| 2 |r|r|r|r| 1 | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 |Excess Trtmnt| Reserved | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 1248 traffic. The excess treatment parameter is set by the QNI. It is a 1249 read-only parameter. Allowed values are as follows: 1251 0: drop 1252 1: shape 1253 2: remark 1254 3: don't care 1256 7.2.3 [RFC 2212, RFC 2215] 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 |1|E|N|T| 3 |r|r|r|r| 1 | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Bandwidth (32-bit IEEE floating point number) | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 The parameter MUST be nonnegative and is measured in 1267 bytes per second and has the same range and suggested representation 1268 as the bucket and peak rates of the . can 1269 be represented using single-precision IEEE floating point. The 1270 representation MUST be able to express values ranging from 1 byte per 1271 second to 40 terabytes per second. For values of this parameter only 1272 valid non-negative floating point numbers are allowed. Negative 1273 numbers (including "negative zero"), infinities, and NAN's are not 1274 allowed. 1276 A QNE MAY export a local value of zero for this parameter. A network 1277 element or application receiving a composed value of zero for this 1278 parameter MUST assume that the actual bandwidth available is unknown. 1280 7.2.4 Parameter [RFC 2212, RFC 2215] 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 |0|E|N|T| 4 |r|r|r|r| 1 | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Slack Term [S] (32-bit integer) | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 Slack term S MUST be nonnegative and is measured in microseconds. 1291 The Slack term, S, can be represented as a 32-bit integer. Its value 1292 can range from 0 to (2**32)-1 microseconds. 1294 7.2.5 Parameters [RFC 2215] 1296 The parameters are represented by three floating 1297 point numbers in single-precision IEEE floating point format followed 1298 by two 32-bit integers in network byte order. The first floating 1299 point value is the rate (r), the second floating point value is the 1300 bucket size (b), the third floating point is the peak rate (p), the 1301 first integer is the minimum policed unit (m), and the second integer 1302 is the maximum datagram size (MTU). 1304 Note that the two sets of parameters can be 1305 distinguished, as could be needed for example to support DiffServ 1306 applications (see Section 7.2). 1308 Token Bucket #1 Parameter ID = 5 1309 Token Bucket #1: Mandatory QSPEC Parameter 1311 Parameter Values: 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 |1|E|N|T| 5 |r|r|r|r| 5 | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Token Bucket Size [b] (32-bit IEEE floating point number) | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Peak Data Rate [p] (32-bit IEEE floating point number) | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Minimum Policed Unit [m] (32-bit integer) | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Maximum Packet Size [MTU] (32-bit integer) | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 Token Bucket #2 Parameter ID = 6 1329 Token Bucket #2: Optional QSPEC Parameter 1331 Parameter Values: 1333 0 1 2 3 1334 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 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 |0|E|N|T| 6 |r|r|r|r| 5 | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Token Bucket Size [b] (32-bit IEEE floating point number) | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Peak Data Rate [p] (32-bit IEEE floating point number) | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Minimum Policed Unit [m] (32-bit integer) | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Maximum Packet Size [MTU] (32-bit integer) | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 When r, b, p, and R terms are represented as IEEE floating point 1350 values, the sign bit MUST be zero (all values MUST be non-negative). 1351 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1352 than 162 (i.e., positive 35) are discouraged, except for specifying a 1353 peak rate of infinity. Infinity is represented with an exponent of 1354 all ones (255) and a sign bit and mantissa of all zeroes. 1356 7.2.6 Parameters 1358 7.2.6.1 Parameter [RFC 3140] 1360 As prescribed in RFC 3140, the encoding for a single PHB is the 1361 recommended DSCP value for that PHB, left-justified in the 16 bit 1362 field, with bits 6 through 15 set to zero. 1364 0 1 2 3 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 |1|E|N|T| 7 |r|r|r|r| 1 | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | DSCP |0 0 0 0 0 0 0 0 0 0| Reserved | 1370 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1372 The registries needed to use RFC 3140 already exist, see [DSCP- 1373 REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs to be 1374 created for this purpose. 1376 7.2.6.2 Parameter [Y.1541] 1378 0 1 2 3 1379 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 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 |1|E|N|T| 8 |r|r|r|r| 1 | 1382 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1383 |Y.1541 QoS Cls.| Reserved | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 1387 allowed are 0, 1, 2, 3, 4, 5. 1389 Class 0: 1390 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1391 Real-time, highly interactive applications, sensitive to jitter. 1392 Application examples include VoIP, Video Teleconference. 1394 Class 1: 1395 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1396 Real-time, interactive applications, sensitive to jitter. 1397 Application examples include VoIP, Video Teleconference. 1399 Class 2: 1400 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 1401 10^-3. Highly interactive transaction data. Application examples 1402 include signaling. 1404 Class 3: 1405 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 1406 10^-3. Interactive transaction data. Application examples include 1407 signaling. 1409 Class 4: 1410 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 1411 10^-3. Low Loss Only applications. Application examples include 1412 short transactions, bulk data, video streaming. 1414 Class 5: 1415 Mean delay unspecified, delay variation unspecified, loss ratio 1416 unspecified. Unspecified applications. Application examples include 1417 traditional applications of default IP networks. 1419 7.2.6.3 Parameter [RFC3564] 1421 DSTE class type is defined as follows: 1423 0 1 2 3 1424 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 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 |1|E|N|T| 9 |r|r|r|r| 1 | 1427 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1428 |DSTE Cls. Type | Reserved | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 DSTE Class Type: Indicates the DSTE class type. Values currently 1432 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 1434 7.2.7 Priority Parameters 1436 7.2.7.1 & Parameters 1437 [RFC 3181] 1439 0 1 2 3 1440 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 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 |1|E|N|T| 10 |r|r|r|r| 1 | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Preemption Priority | Defending Priority | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 Preemption Priority: The priority of the new flow compared with the 1448 defending priority of previously admitted flows. Higher values 1449 represent higher priority. 1451 Defending Priority: Once a flow is admitted, the preemption priority 1452 becomes irrelevant. Instead, its defending priority is used to 1453 compare with the preemption priority of new flows. 1455 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 1457 parameter is used. 1459 7.2.7.2 Parameter [PRIORITY-RQMTS, SIP-PRIORITY] 1461 0 1 2 3 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 |1|E|N|T| 11 |r|r|r|r| 1 | 1465 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1466 + Admission | RPH Namespace | RPH Priority | 1467 + Priority | | | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 High priority flows, normal priority flows, and best-effort priority 1470 flows can have access to resources depending on their admission 1471 priority value, as described in [PRIORITY-RQMTS], as follows: 1473 Admission Priority: 1475 0 - high priority flow 1476 1 - normal priority flow 1477 2 - best-effort priority flow 1479 [SIP-PRIORITY] defines a resource priority header (RPH) with 1480 parameters "RPH Namespace" and "RPH Priority" combination, 1481 and if populated is applicable only to flows with high reservation 1482 priority, as follows: 1484 RPH Namespace: 1486 0 - dsn 1487 1 - drsn 1488 2 - q735 1489 3 - ets 1490 4 - wps 1491 5 - not populated 1493 RPH Priority: 1494 Each namespace has a finite list of relative priority-values. Each 1495 is listed here in the order of lowest priority to highest priority: 1497 4 - dsn.routine 1498 3 - dsn.priority 1499 2 - dsn.immediate 1500 1 - dsn.flash 1501 0 - dsn.flash-override 1503 5 - drsn.routine 1504 4 - drsn.priority 1505 3 - drsn.immediate 1506 2 - drsn.flash 1507 1 - drsn.flash-override 1508 0 - drsn.flash-override-override 1510 4 - q735.4 1511 3 - q735.3 1512 2 - q735.2 1513 1 - q735.1 1514 0 - q735.0 1516 4 - ets.4 1517 3 - ets.3 1518 2 - ets.2 1519 1 - ets.1 1520 0 - ets.0 1522 4 - wps.4 1523 3 - wps.3 1524 2 - wps.2 1525 1 - wps.1 1526 0 - wps.0 1528 Note that SIP nodes can send multiple NameSpace.Priority tupple 1529 values in the same message, in part because end nodes may not know 1530 what Namespace "domain" it resides in, nor which Namespace "domains" 1531 it may traverse. Therefore multiple 1532 parameters MAY be sent in a given QSPEC, which is turn contain 1533 multiple RPH Namespace/Priority combinations. 1535 Note that additional work is needed to communicate these flow 1536 priority values to bearer-level network elements 1537 [VERTICAL-INTERFACE]. 1539 7.2.8 Parameter [RFC 2210, 2215] 1541 0 1 2 3 1542 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 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 |0|E|N|T| 12 |r|r|r|r| 1 | 1545 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1546 | Path Latency (32-bit integer) | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 The Path Latency is a single 32-bit integer in network byte order. 1550 The composition rule for the parameter is summation 1551 with a clamp of (2**32 - 1) on the maximum value. The latencies are 1552 average values reported in units of one microsecond. A system with 1553 resolution less than one microsecond MUST set unused digits to zero. 1554 An individual QNE can advertise a latency value between 1 and 2**28 1555 (somewhat over two minutes) and the total latency added across all 1556 QNEs can range as high as (2**32)-2. If the sum of the different 1557 elements delays exceeds (2**32)-2, the end-to-end advertised delay 1558 SHOULD be reported as indeterminate. A QNE that cannot accurately 1559 predict the latency of packets it is processing MUST raise the 1560 not-supported flagand either leave the value of Path Latency as is, 1561 or add its best estimate of its lower bound. A raised not-supported 1562 flagflag indicates the value of Path Latency is a lower bound of the 1563 real Path Latency. The distinguished value (2**32)-1 is taken to 1564 mean indeterminate latency because the composition function limits 1565 the composed sum to this value, it indicates the range of the 1566 composition calculation was exceeded. 1568 7.2.9 Parameter 1570 0 1 2 3 1571 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 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 |0|E|N|T| 13 |r|r|r|r| 3 | 1574 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1575 | Path Jitter STAT1 (32-bit integer) | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | Path Jitter STAT2 (32-bit integer) | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | Path Jitter STAT3 (32-bit integer) | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 The Path Jitter is a set of three 32-bit integers in network byte 1583 order. The Path Jitter parameter is the combination of three 1584 statistics describing the Jitter distribution with a clamp of 1585 (2**32 - 1) on the maximum of each value. The jitter STATs are 1586 reported in units of one microsecond. A system with resolution less 1587 than one microsecond MUST set unused digits to zero. An individual 1588 QNE can advertise jitter values between 1 and 2**28 (somewhat over 1589 two minutes) and the total jitter computed across all QNEs can range 1590 as high as (2**32)-2. If the combination of the different element 1591 values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be 1592 reported as indeterminate. A QNE that cannot accurately predict the 1593 jitter of packets it is processing MUST raise the not-supported flag 1594 and either leave the value of Path Jitter as is, or add its best 1595 estimate of its STAT values. A raised not-supported flag indicates 1596 the value of Path Jitter is a lower bound of the real Path Jitter. 1597 The distinguished value (2**32)-1 is taken to mean indeterminate 1598 jitter. A QNE that cannot accurately predict the jitter of packets 1599 it is processing SHOULD set its local parameter to this value. 1600 Because the composition function limits the total to this value, 1601 receipt of this value at a network element or application indicates 1602 that the true path jitter is not known. This MAY happen because one 1603 or more network elements could not supply a value, or because the 1604 range of the composition calculation was exceeded. 1606 NOTE: The Jitter composition function and the statistics to use are a 1607 subject of active development in IETF IPPM WG and ITU-T SG 12. 1608 Resolution of this topic is expected shortly. 1610 7.2.10 Parameter 1612 0 1 2 3 1613 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 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 |0|E|N|T| 14 |r|r|r|r| 1 | 1616 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1617 | Path Packet Loss Ratio (32-bit floating point) | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 The Path PLR is a single 32-bit single precision IEEE floating point 1620 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1622 value. The PLRs are reported in units of 10^-11. A system with 1623 resolution less than one microsecond MUST set unused digits to zero. 1624 An individual QNE can advertise a PLR value between zero and 10^-2 1625 and the total PLR added across all QNEs can range as high as 10^-1. 1626 If the sum of the different elements values exceeds 10^-1, the 1627 end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE 1628 that cannot accurately predict the PLR of packets it is processing 1629 MUST raise the not-supported flag and either leave the value of Path 1630 PLR as is, or add its best estimate of its lower bound. A raised 1631 not-supported flag indicates the value of Path PLR is a lower bound 1632 of the real Path PLR. The distinguished value 10^-1 is taken to mean 1633 indeterminate PLR. A QNE which cannot accurately predict the PLR of 1634 packets it is processing SHOULD set its local parameter to this 1635 value. Because the composition function limits the composed sum to 1636 this value, receipt of this value at a network element or application 1637 indicates that the true path PLR is not known. This MAY happen 1638 because one or more network elements could not supply a value, or 1639 because the range of the composition calculation was exceeded. 1641 7.2.11 Parameter 1643 0 1 2 3 1644 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 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 |0|E|N|T| 15 |r|r|r|r| 1 | 1647 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1648 | Path Packet Error Ratio (32-bit floating point) | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 The Path PER is a single 32-bit single precision IEEE floating point 1652 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1654 value. The PERs are reported in units of 10^-11. A system with 1655 resolution less than one microsecond MUST set unused digits to zero. 1656 An individual QNE can advertise a PER value between zero and 10^-2 1657 and the total PER added across all QNEs can range as high as 10^-1. 1658 If the sum of the different elements values exceeds 10^-1, the 1659 end-to-end advertised PER SHOULD be reported as indeterminate. A QNE 1660 that cannot accurately predict the PER of packets it is processing 1661 MUST raise the not-supported flag and either leave the value of Path 1662 PER as is, or add its best estimate of its lower bound. A raised 1663 not-supported flag indicates the value of Path PER is a lower bound 1664 of the real Path PER. The distinguished value 10^-1 is taken to mean 1665 indeterminate PER. A QNE which cannot accurately predict the PER of 1666 packets it is processing SHOULD set its local parameter to this 1667 value. Because the composition function limits the composed sum to 1668 this value, receipt of this value at a network element or application 1669 indicates that the true path PER is not known. This MAY happen 1670 because one or more network elements could not supply a value, or 1671 because the range of the composition calculation was exceeded. 1673 7.2.12 Parameters [RFC 2210, 2212, 2215] 1675 0 1 2 3 1676 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 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 |0|E|N|T| 16 |r|r|r|r| 1 | 1679 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1680 | End-to-end composed value for C [Ctot] (32-bit integer) | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 0 1 2 3 1684 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 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 |0|E|N|T| 17 |r|r|r|r| 1 | 1687 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1688 | End-to-end composed value for D [Dtot] (32-bit integer) | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 0 1 2 3 1692 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 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 |0|E|N|T| 18 |r|r|r|r| 1 | 1695 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1696 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 0 1 2 3 1700 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 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 |0|E|N|T| 19 |r|r|r|r| 1 | 1703 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1704 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 The error term C is measured in units of bytes. An individual QNE 1708 can advertise a C value between 1 and 2**28 (a little over 250 1709 megabytes) and the total added over all QNEs can range as high as 1710 (2**32)-1. Should the sum of the different QNEs delay exceed 1711 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 1712 error term D is measured in units of one microsecond. An individual 1713 QNE can advertise a delay value between 1 and 2**28 (somewhat over 1714 two minutes) and the total delay added over all QNEs can range as 1715 high as (2**32)-1. Should the sum of the different QNEs delay 1716 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 1718 8. Security Considerations 1720 The priority parameter raises possibilities for Theft of Service 1721 Attacks because users could claim an emergency priority for their 1722 flows without real need, thereby effectively preventing serious 1723 emergency calls to get through. Several options exist for countering 1724 such attacks, for example 1726 - only some user groups (e.g. the police) are authorized to set the 1727 emergency priority bit 1729 - any user is authorized to employ the emergency priority bit for 1730 particular destination addresses (e.g. police) 1732 9. IANA Considerations 1734 This section provides guidance to the Internet Assigned Numbers 1735 Authority (IANA) regarding registration of values related to the 1736 QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 1738 [QoS-SIG] requires IANA to create a new registry for QoS Signaling 1739 Model Identifiers. The QoS Signaling Model Identifier (QOSM ID) is 1740 a 4 byte value carried in a QSPEC. The allocation policy for 1741 new QOSM IDs is TBD. 1743 This document also defines 4 objects and 20 parameters for the QSPEC 1744 Template, as detailed in Section 7. Values are to be assigned for 1745 them from the NTLP Object Type registry. 1747 10. Acknowledgements 1749 The authors would like to thank (in alphabetical order) David Black, 1750 Anna Charny, Xiaoming Fu, Robert Hancock, Chris Lang, Dave Oran, Tom 1751 Phelan, Hannes Tschofenig, and Sven van den Bosch, for their very 1752 helpful suggestions. 1754 11. Normative References 1756 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 1757 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 1758 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 1759 Signaling Transport," work in progress. 1760 [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 1761 Signaling," work in progress. 1762 [RFC1832] Srinivasan, R., "XDR: External Data Representation 1763 Standard," RFC 1832, August 1995. 1764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1765 Requirement Levels", BCP 14, RFC 2119, March 1997. 1766 [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 1767 -- Version 1 Functional Specification," RFC 2205, September 1997. 1769 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1770 Services", RFC 2210, September 1997. 1771 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 1772 Network Element Service", RFC 2211, Sept. 1997. 1773 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 1774 of Service," September 1997. 1775 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 1776 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 1777 1997. 1778 [RFC2474] Nichols, K., et. al., "Definition of the Differentiated 1779 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 1780 December 1998. 1781 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 1782 Services", RFC 2475, December 1998. 1783 [RFC2597] Heinanen, J., et. al., "Assured Forwarding PHB Group," RFC 1784 2597, June 1999. 1785 [RFC2697] Heinanen, J., Guerin, R., "A Single Rate Three Color 1786 Marker," RFC 2697, September 1999. 1787 [RFC2698] Heinanen, J., Guerin, R., "A Two Rate Three Color Marker," 1788 RFC 2698, September 1999. 1789 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 1790 Codes," June 2001. 1791 [RFC3297]Charny, A., et. al., "Supplemental Information for the New 1792 Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)," 1793 RFC 3297, March 2002. 1795 12. Informative References 1797 [CMSS] "PacketCable (TM) CMS to CMS Signaling Specification, 1798 PKT-SP-CMSS-103-040402, April 2004. 1799 [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines 1800 for DiffServ Service Classes," work in progress. 1801 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 1802 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 1803 754-1985, August 1985. 1804 [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 1805 Controlled-Load Service with NSIS," work in progress. 1806 [METWORK-BYTE-ORDER] Wikipedia, "Endianness," 1807 http://en.wikipedia.org/wiki/Endianness. 1808 [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels 1809 for IP Networks and Services," T1A1/2003-196 R3, November 2004. 1810 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 1811 Protocol - Capability Set 3" Sep. 2003 1812 [RFC1633] Braden, B., et. al., "Integrated Services in the Internet 1813 Architecture: an Overview," RFC 1633, June 1994. 1814 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 1815 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 1816 [RFC3564] Le Faucheur, F., et. al., Requirements for Support of 1817 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 1818 July 2003 1820 [RFC3726] Brunner, M., et. al., "Requirements for Signaling 1821 Protocols", RFC 3726, April 2004. 1822 [RMD-QOSM] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling 1823 Policy Model for Networks 1824 Using Resource Management in DiffServ (RMD)," work in progress. 1825 [SIP-PRIORITY] Schulzrinne, H., Polk, J., "Communications Resource 1826 Priority for the Session Initiation Protocol(SIP)." work in 1827 progress. 1828 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 1829 on Associating of Control Signaling Messages with Media Priority 1830 Levels," T1S1.7 & PRQC, October 2004. 1831 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 1832 Communication Service - IP Packet Transfer and Availability 1833 Performance Parameters," December 2002. 1834 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 1835 for IP-Based Services," May 2002. 1836 [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 1837 Networks Using Y.1541 QoS Classes," work in progress. 1839 13. Authors' Addresses 1841 Jerry Ash (Editor) 1842 AT&T 1843 Room MT D5-2A01 1844 200 Laurel Avenue 1845 Middletown, NJ 07748, USA 1846 Phone: +1-(732)-420-4578 1847 Fax: +1-(732)-368-8659 1848 Email: gash@att.com 1850 Attila Bader (Editor) 1851 Traffic Lab 1852 Ericsson Research 1853 Ericsson Hungary Ltd. 1854 Laborc u. 1 H-1037 1855 Budapest Hungary 1856 Email: Attila.Bader@ericsson.com 1858 Cornelia Kappler (Editor) 1859 Siemens AG 1860 Siemensdamm 62 1861 Berlin 13627 1862 Germany 1863 Email: cornelia.kappler@siemens.com 1865 Chuck Dvorak 1866 AT&T 1867 Room 2A37 1868 180 Park Avenue, Building 2 1869 Florham Park, NJ 07932 1870 Phone: + 1 973-236-6700 1871 Fax:+1 973-236-7453 1872 Email: cdvorak@att.com 1874 Yacine El Mghazli 1875 Alcatel 1876 Route de Nozay 1877 91460 Marcoussis cedex 1878 FRANCE 1879 Phone: +33 1 69 63 41 87 1880 Email: yacine.el_mghazli@alcatel.fr 1882 Georgios Karagiannis 1883 University of Twente 1884 P.O. BOX 217 1885 7500 AE Enschede 1886 The Netherlands 1887 Email: g.karagiannis@ewi.utwente.nl 1889 Andrew McDonald 1890 Siemens/Roke Manor Research 1891 Roke Manor Research Ltd. 1892 Romsey, Hants SO51 0ZN 1893 UK 1894 Email: andrew.mcdonald@roke.co.uk 1896 Al Morton 1897 AT&T 1898 Room D3-3C06 1899 200 S. Laurel Avenue 1900 Middletown, NJ 07748 1901 Phone: + 1 732 420-1571 1902 Fax: +.1 732 368-1192 1903 Email: acmorton@att.com 1905 Percy Tarapore 1906 AT&T 1907 Room D1-33 1908 200 S. Laurel Avenue 1909 Middletown, NJ 07748 1910 Phone: + 1 732 420-4172 1911 Email: tarapore@.att.com 1913 Lars Westberg 1914 Ericsson Research 1915 Torshamnsgatan 23 1916 SE-164 80 Stockholm, Sweden 1917 Email: Lars.Westberg@ericsson.com 1919 Appendix A: QoS Models and QSPECs 1921 This Appendix gives a description of QoS Models and QSPECs and 1922 explains what is the relation between them. Once these descriptions 1923 are contained in a stable form in the appropriate IDs this Appendix 1924 will be removed. 1926 QoS NSLP is a generic QoS signaling protocol that can signal for many 1927 QOSMs. A QOSM is a particular QoS provisioning method or QoS 1928 architecture such as IntServ Controlled Load or Guaranteed Service, 1929 DiffServ, or RMD for DiffServ. 1931 The definition of the QOSM is independent from the definition of QoS 1932 NSLP. Existing QOSMs do not specify how to use QoS NSLP to signal 1933 for them. Therefore, we need to define the QOSM specific signaling 1934 functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM]. 1936 A QOSM SHOULD include the following information: 1938 - Role of QNEs in this QOSM: 1939 E.g. location, frequency, statefulness... 1940 - QSPEC Definition: 1941 A QOSM SHOULD specify the QSPEC, including QSPEC parameters. 1942 Furthermore it needs to explain how QSPEC parameters not used in this 1943 QOSM are mapped onto parameters defined therein. 1944 - Message Format 1945 QSPEC objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY 1946 - State Management 1947 It describes how QSPEC info is treated and interpreted in the 1948 RMF and QOSM specific processing. E.g. 1949 admission control, scheduling, policy control, QoS parameter 1950 accumulation (e.g. delay). 1951 - Operation and Sequence of Events 1952 Usage of QoS-NSLP messages to signal the QOSM. 1954 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved of 1955 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 1957 The union of QoS Desired, QoS Available and QoS Reserved can provide 1958 all functionality of the objects specified in RSVP IntServ, however 1959 it is difficult to provide an exact mapping. 1961 In RSVP, the Sender TSpec specifies the traffic an application is 1962 going to send (e.g. token bucket). The AdSpec can collect path 1963 characteristics (e.g. delay). Both are issued by the sender. The 1964 receiver sends the FlowSpec which includes a Receiver TSpec 1965 describing the resources reserved using the same parameters as the 1966 Sender TSpec, as well as a RSpec which provides additional IntServ 1967 QoS Model specific parameters, e.g. Rate and Slack. 1969 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 1970 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 1971 knowledge of the authors it is not possible for the sender to specify 1972 a desired maximum delay except implicitly and mutably by seeding the 1973 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 1974 the receiver-issued RSVP RESERVE message. For this reason our 1975 discussion at this point leads us to a slightly different mapping of 1976 necessary functionality to objects, which should result in more 1977 flexible signaling models. 1979 Appendix C: Main Changes Since Last Version & Open Issues 1981 C.1 Main Changes Since Version -04 1983 Version -05: 1985 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 1986 - discarded QSPEC parameter (Maximum packet size) since MTU 1987 discovery is expected to be handled by procedure currently defined 1988 by PMTUD WG 1989 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 1990 efficiency 1991 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 1992 - revised Section 6.2.2 on SIP priorities 1993 - added QSPEC procedures for "RSVP-style reservation", resource 1994 queries and bidirectional reservations in Sec. 7.1 1995 - reworked Section 7.2 1997 Version -06: 1999 - defined "not-supported flag" and "tunneled parameter flag" 2000 (subsumes "optional parameter flag") 2001 - defined "error flag" for error handling 2002 - coding checked by independent expert 2003 - coding of QSPEC Procedure ID 2005 C.2 Open Issues 2007 - none 2009 Intellectual Property Statement 2011 The IETF takes no position regarding the validity or scope of any 2012 Intellectual Property Rights or other rights that might be claimed to 2013 pertain to the implementation or use of the technology described in 2014 this document or the extent to which any license under such rights 2015 might or might not be available; nor does it represent that it has 2016 made any independent effort to identify any such rights. Information 2017 on the procedures with respect to rights in RFC documents can be 2018 found in BCP 78 and BCP 79. 2020 Copies of IPR disclosures made to the IETF Secretariat and any 2021 assurances of licenses to be made available, or the result of an 2022 attempt made to obtain a general license or permission for the use of 2023 such proprietary rights by implementers or users of this 2024 specification can be obtained from the IETF on-line IPR repository at 2025 http://www.ietf.org/ipr. 2027 The IETF invites any interested party to bring to its attention any 2028 copyrights, patents or patent applications, or other proprietary 2029 rights that may cover technology that may be required to implement 2030 this standard. Please address the information to the IETF at 2031 ietf-ipr@ietf.org. 2033 Disclaimer of Validity 2035 This document and the information contained herein are provided on an 2036 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2037 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2038 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2039 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2040 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2041 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2043 Copyright Statement 2045 Copyright (C) The Internet Society (2005). This document is subject 2046 to the rights, licenses and restrictions contained in BCP 78, and 2047 except as set forth therein, the authors retain all their rights.