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

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