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

[RFC 2210] 705 Note that the Path MTU Discovery (PMTUD) working group is currently 706 specifying a robust method for determining the MTU supported over an 707 end-to-end path. This new method is expected to update RFC1191 and 708 RFC1981, the current standards track protocols for this purpose. 710 = 712 An application MAY like to reserve resources for packets with a 713 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 714 [RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class 715 type [RFC3564]. 717 = 718 720 is the priority of the new flow compared with 721 the defending priority of previously admitted flows. Once a flow is 722 admitted, the preemption priority becomes irrelevant. is used to compare with the preemption priority of new 724 flows. For any specific flow, its preemption priority MUST always be 725 less than or equal to the defending priority. 726 and provide an essential way to differentiate flows 727 for emergency services, ETS, E911, etc., and assign them a higher 728 admission priority than normal priority flows and best-effort 729 priority flows. 731 Appropriate security measures need to be taken to prevent abuse of 732 the parameters, see Section 8 on Security Considerations. 734 [Y.1540] defines packet transfer outcomes, as follows: 736 Successful: packet arrives within the preset waiting time with no 737 errors 739 Lost: packet fails to arrive within the waiting time 741 Errored: packet arrives in time, but has one or more bit errors 742 in the header or payload 744 Packet Loss Ratio (PLR) = total packets lost/total packets sent 746 Packet Error Ratio (PER) = total errored packets/total packets sent 748 , , , and are 749 optional parameters describing the desired path latency, path jitter 750 and path bit error rate respectively. Since these parameters are 751 cumulative, an individual QNE cannot decide whether the desired path 752 latency, etc., is available, and hence they cannot decide whether a 753 reservation fails. Rather, when these parameters are included in 754 , the QNI SHOULD also include corresponding parameters 755 in a QSPEC object in order to facilitate collecting 756 this information. 758 5.2.2 760 = 761 762 764 When used in the object, refers 765 to traffic resources available at a QNE in the network. 767 The Object collects information on the resources 768 currently available on the path when it travels in a RESERVE or QUERY 769 message and hence in this case this QSPEC object is read-write. Each 770 QNE MUST inspect all parameters of this QSPEC object, and if 771 resources available to this QNE are less than what a particular 772 parameter says currently, the QNE MUST adapt this parameter 773 accordingly. Hence when the message arrives at the recipient of the 774 message, reflects the bottleneck of the resources 775 currently available on a path. It can be used in a QUERY message, 776 for example, to collect the available resources along a data path. 778 When travels in a RESPONSE message, it in fact just 779 transports the result of a previous measurement performed by a 780 RESERVE or QUERY message back to the initiator. Therefore in this 781 case, is read-only. 783 The parameters and provide information, 784 for example, about the bandwidth available along the path followed by 785 a data flow. The local parameter is an estimate of the bandwidth the 786 QNE has available for packets following the path. Computation of the 787 value of this parameter SHOULD take into account all information 788 available to the QNE about the path, taking into consideration 789 administrative and policy controls on bandwidth, as well as physical 790 resources. The composition rule for this parameter is the MIN 791 function. The composed value is the minimum of the QNE's value and 792 the previously composed value. This quantity, when composed 793 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 794 minimal bandwidth link along the path from QNI to QNR. 796 The parameter accumulates the latency of the packet 797 forwarding process associated with each QNE, where the latency is 798 defined to be the mean packet delay added by each QNE. This delay 799 results from speed-of-light propagation delay, from packet processing 800 limitations, or both. It does not include any variable queuing delay 801 that may be present. Each QNE MUST add the propagation delay of its 802 outgoing link, which includes the QNR adding the associated delay for 803 the egress link. Furthermore, the QNI MUST add the propagation delay 804 of the ingress link. The composition rule for the 805 parameter is summation with a clamp of (2**32 - 1) on the maximum 806 value. This quantity, when composed end-to-end, informs the QNR (or 807 QNI in a RESPONSE message) of the minimal packet delay along the path 808 from QNI to QNR. The purpose of this parameter is to provide a 809 minimum path latency for use with services which provide estimates or 810 bounds on additional path delay [RFC 2212]. Together with the 811 queuing delay bound, this parameter gives the application knowledge 812 of both the minimum and maximum packet delivery delay. Knowing both 813 the minimum and maximum latency experienced by data packets allows 814 the receiving application to know the bound on delay variation and 815 de-jitter buffer requirements. 817 The parameter accumulates the jitter of the packet 818 forwarding process associated with each QNE, where the jitter is 819 defined to be the nominal jitter added by each QNE. IP packet 820 jitter, or delay variation, is defined in [RFC3393], Section 3.4 821 (Type-P-One-way-ipdv), and where the selection function includes the 822 packet with minimum delay such that the distribution is equivalent to 823 2-point delay variation in [Y.1540]. The suggested evaluation 824 interval is 1 minute. Note that the method to estimate IP delay 825 variation without active measurements requires more study. This 826 jitter results from packet processing limitations, and includes any 827 variable queuing delay which may be present. Each QNE MUST add the 828 jitter of its outgoing link, which includes the QNR adding the 829 associated jitter for the egress link. Furthermore, the QNI MUST 830 add the jitter of the ingress link. The composition method for the 831 parameter is the combination of several statistics 832 describing the delay variation distribution with a clamp on the 833 maximum value (note that the methods of accumulation and estimation 834 of nominal QNE jitter are under study). This quantity, when composed 835 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 836 nominal packet jitter along the path from QNI to QNR. The purpose of 837 this parameter is to provide a nominal path jitter for use with 838 services that provide estimates or bounds on additional path delay 839 [RFC2212]. Together with the and the queuing delay 840 bound, this parameter gives the application knowledge of the typical 841 packet delivery delay variation. 843 The parameter accumulates the packet loss rate (PLR) of 844 the packet forwarding process associated with each QNE, where the PLR 845 is defined to be the PLR added by each QNE. Each QNE MUST add the 846 PLR of its outgoing link, which includes the QNR adding the 847 associated PLR for the egress link. Furthermore, the QNI MUST add 848 the PLR of the ingress link. The composition rule for the parameter is summation with a clamp on the maximum value (this 850 assumes sufficiently low PLR values such that summation error is not 851 significant). This quantity, when composed end-to-end, informs the 852 QNR (or QNI in a RESPONSE message) of the minimal packet PLR along 853 the path from QNI to QNR. As with , the method to 854 estimate requires more study. 856 , , , : Error terms C and D represent how the 857 element's implementation of the guaranteed service deviates from the 858 fluid model. These two parameters have an additive composition rule. 859 The error term C is the rate-dependent error term. It represents the 860 delay a datagram in the flow might experience due to the rate 861 parameters of the flow. The error term D is the rate-independent, 862 per-element error term and represents the worst case non-rate-based 863 transit time variation through the service element. If the 864 composition function is applied along the entire path to compute the 865 end-to-end sums of C and D ( and ) and the resulting 866 values are then provided to the QNR (or QNI in a RESPONSE message). 867 and are the sums of the parameters C and D between the 868 last reshaping point and the current reshaping point. 870 5.2.3 872 = 874 These parameters describe the QoS reserved by the QNEs along the data 875 path, and hence the QoS reserved QSPEC object is read-write. 877 , and are defined above. 879 = slack term, which is the difference between desired delay and 880 delay obtained by using bandwidth reservation, and which is used to 881 reduce the resource reservation for a flow [RFC 2212]. This is an 882 optional parameter. 884 5.2.4 886 = 888 does not have an equivalent in RSVP. It allows the QNI 889 to define a range of acceptable QoS levels by including both the 890 desired QoS value and the minimum acceptable QoS in the same message. 891 It is a read-only QSPEC object. The desired QoS is included with a 892 and/or a QSPEC object seeded to the 893 desired QoS value. The minimum acceptable QoS value MAY be coded in 894 the QSPEC object. As the message travels towards the 895 QNR, is updated by QNEs on the path. If its value 896 drops below the value of the reservation fails and is 897 aborted. When this method is employed, the QNR SHOULD signal back to 898 the QNI the value of attained in the end, because the 899 reservation MAY need to be adapted accordingly. 901 6. QSPEC Procedures & Examples 903 6.1 QSPEC Procedures 905 While the QSPEC template aims to put minimal restrictions on usage of 906 QSPEC objects in , interoperability between QNEs and 907 between QOSMs must be ensured. We therefore give below an exhaustive 908 list of QSPEC object combinations for the message sequences described 909 in QoS NSLP [QOS-SIG]. A specific QOSM may prescribe that only a 910 subset of the procedures listed below may be used. 912 6.1.1 Sender-Initiated Reservations 914 Here the QNI issues a RESERVE, which is replied to by a RESPONSE. 915 This response is generated either by the QNR or, in case the 916 reservation was unsuccessful, by a QNE. The following possibilities 917 for QSPEC object usage exist: 919 ID | RESERVE | RESPONSE 920 --------------------------------------------------------------- 921 1 | QoS Desired | QoS Reserved 922 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 923 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 925 (1) If only QoS Desired is included in the RESERVE, the implicit 926 assumption is that exactly these resources must be reserved. If this 927 is not possible the reservation fails. The parameters in QoS 928 Reserved are copied from the parameters in QoS Desired. 930 (2) When QoS Available is included in the RESERVE also, some 931 parameters will appear only in QoS Available and not in QoS Desired. 932 It is assumed that the value of these parameters is collected for 933 informational purposes only (e.g. path latency). 935 However, some parameters in QoS Available can be the same as in QoS 936 Desired. For these parameters the implicit message is that the QNI 937 would be satisfied by a reservation with lower parameter values than 938 specified in QoS Desired. For these parameters, the QNI seeds the 939 parameter values in QoS Available to those in QoS Desired (except for 940 cumulative parameters such as ). 942 Each QNE downgrades the parameters in QoS Available according to its 943 current capabilities. Reservations in each QNE are hence based on 944 current parameter values in QoS Available (and additionally those 945 parameters that only appear in QoS Desired). The drawback of this 946 approach is that, if the resulting resource reservation becomes 947 gradually smaller towards the QNR, QNEs close to the QNI have an 948 oversized reservation, possibly resulting in unnecessary costs for 949 the user. Of course, in the RESPONSE the QNI learns what the actual 950 reservation is (from the QoS RESERVED object) and can immediately 951 issue a properly sized refreshing RESERVE. The advantage of the 952 approach is that the reservation is performed in half-a-roundtrip 953 time. 955 The parameter types included in QoS Reserved in the RESPONSE MUST be 956 the same as those in QoS Desired in RESERVE. For those parameters 957 that were also included in QoS Available in RESERVE, their value is 958 copied into QoS Desired. For the other parameters, the value is 959 copied from QoS Desired (the reservation would fail if the 960 corresponding QoS could not be reserved). 962 All parameters in the QoS Available QSPEC object in the RESPONSE are 963 copied with their values from the QoS Available QSPEC object in the 964 RESERVE (irrespective of whether they have also been copied into QoS 965 Desired). Note that the parameters in QoS Available are read-write 966 in the RESERVE message, whereas they are read-only in the RESPONSE. 968 (3) this case is handled as case (2), except that the reservation 969 fails when QoS Available becomes less than Minimum QoS for one 970 parameter. If a parameter appears in QoS Available but not in 971 Minimum QoS it is assumed that there is no minimum value for this 972 parameter. 974 Regarding Control Information, the rule is that all parameters that 975 have been included in the RESERVE message by the QNI MUST also be 976 included in the RESPONSE message by the QNR with the value they had 977 when arriving at the QNR. When traveling in the RESPONSE message, 978 all Control Information parameters are read-only. 980 6.1.2 Receiver-Initiated Reservations 982 Here the QNR issues a QUERY which is replied to by the QNI with a 983 RESERVE if the reservation was successful. The QNR in turn sends a 984 RESPONSE to the QNI. 986 ID| QUERY | RESERVE | RESPONSE 987 --------------------------------------------------------------------- 988 1 |QoS Des. | QoS Des. | QoS Res. 989 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 990 3 |Qos Des. QoS Avl. | QoS Des., QoS Avl. | QoS Res. 992 (1) and (2) The idea is that the sender (QNR in this scenario) needs 993 to inform the receiver (QNI in this scenario) about the QoS it 994 desires. To this end the sender sends a QUERY message to the 995 receiver including a QoS Desired QSPEC object. If the QoS is 996 negotiable it additionally includes a (possibly zero) Minimum QoS, as 997 in Case b. 999 The RESERVE message includes QoS Available if the sender signaled QoS 1000 is negotiable (i.e. it included Minimum QoS). If the Minimum QoS 1001 received from the sender is non-zero, the QNR also includes Minimum 1002 QoS. 1004 (3) This is the "RSVP-style" scenario. The sender (QNR) issues a 1005 QUERY with QoS Desired informing the receiver (QNI) about the QoS it 1006 desires as above. It also includes a QoS Available object to collect 1007 path properties. Note that here, path properties are collected with 1008 the QUERY message, whereas in the previous model (2), path properties 1009 were collected in the RESERVE message. 1011 Some parameters in QoS Available may the same as in QoS Desired. For 1012 these parameters the implicit message is that the sender would be 1013 satisfied by a reservation with lower parameter values than specified 1014 in QoS Desired. 1016 It is possible for QoS Available to contain parameters that do not 1017 appear in QoS Desired. It is assumed that the value of these 1018 parameters is collected for informational purposes only (e.g. path 1019 latency). 1021 Parameter values in QoS Available are seeded according to the senders 1022 capabilities. Each QNE downgrades or cumulates the parameter values 1023 according to its current capabilities. 1025 The receiver (QNI) populates QoS Desired as follows: For those 1026 parameters that appear in both QoS Available and QoS Desired in the 1027 QUERY message, it takes the (possibly downgraded) parameter values 1028 from QoS Available. For those parameters that only appear in QoS 1029 Desired, it adopts the parameter values from QoS Desired. 1031 The parameters in the QoS Available QSPEC object in the RESERVE 1032 message are copied with their values from the QoS Available QSPEC 1033 object in the QUERY message. Note that the parameters in QoS 1034 Available are read-write in the QUERY message, whereas they are 1035 read-only in the RESERVE message. 1037 The advantage of this model compared to the sender-initiated 1038 reservation (model 2) is that the situation of over-reservation in 1039 QNEs close to the QNI as described above does not occur. On the 1040 other hand, the QUERY may find, for example, a particular bandwidth 1041 is not available. When the actual reservation is performed, however, 1042 the desired bandwidth may meanwhile have become free. That is, the 1043 'RSVP style' may result in a smaller reservation than necessary. 1045 Regarding Control Information in receiver-initiated reservations, the 1046 sender includes all Control Information it cares about in the QUERY 1047 message. Read-write parameters are updated by QNEs as the QUERY 1048 message travels towards the receiver. The receiver includes all 1049 Control Information parameters arriving in the QUERY message also in 1050 the RESERVE message, as read-only parameters with the value they had 1051 when arriving at the receiver. 1053 6.1.3 Resource Queries 1055 Here the QNI issues a QUERY in order to investigate what resources 1056 are currently available. The QNR replies with a RESPONSE. 1058 ID | QUERY | RESPONSE 1059 -------------------------------------------- 1060 1 | QoS Available | QoS Available 1062 Note QoS Available when traveling in the QUERY is read-write, whereas 1063 in the RESPONSE it is read-only. 1065 6.1.4 Bidirectional Reservations 1067 On a QSPEC level, bidirectional reservations are no different from 1068 uni-directional reservations, since QSPECs for different directions 1069 never travel in the same message. 1071 6.2 QSPEC Examples 1073 This Section provides an example QSPEC for DiffServ admission 1074 control. The QSPEC for IntServ controlled load service is 1075 specified in [INTSERV-QOSM] (note that the QOSMs for IntServ 1076 Controlled Load Service and IntServ Guaranteed Service are defined in 1077 [RFC2211] and [RFC2212], respectively). 1079 The QSPEC for DiffServ admission control may be composed, for 1080 example, of the QSPEC objects and , as 1081 well as . Which QSPEC object is present in a 1082 particular QSPEC depends on the message type (RESERVE, QUERY etc) in 1083 which the QSPEC travels. Parameters in the QSPEC for DiffServ 1084 requesting bandwidth for different PHBs are as follows: 1086 Example QSPEC for the DiffServ EF PHB [RFC3297]: 1088 = 1089 = 1090 = 1091 = 1092 = 1093 = 1094 = 1096 In general, the EF PHB is a property of the service that is NOT 1097 dependent on the input traffic characteristics. A server of rate R 1098 and latency E that is compliant with the EF PHB must deliver at least 1099 the configured service rate R with at most latency E for any traffic 1100 characterization. Therefore, strictly speaking, there is no specific 1101 traffic descriptor required to deliver the EF PHB (which by 1102 definition is a local per-hop characterization). However, in order 1103 to deliver a reasonable end-to-end delay, it is typically assumed 1104 that EF traffic is shaped at the ingress. A typical assumption is 1105 that input traffic at any ingress is constrained by a single rate 1106 token bucket. Therefore, a single rate token bucket is sufficient 1107 to signal in QoS-NSLP/QSPEC for the DiffServ-QOSM. 1109 Example QSPEC for the DiffServ AFxy PHB [RFC2597]: 1111 = 1112 = 1113 = 1114 = 1115 1116 = 1117 = 1118 = 1120 The AF1 PHB class is signaled consisting of the three AF1x PHBs. See 1121 [RFC3140 and [RFC2597] for construction of the PHBID for the AF1 PHB 1122 class as the concatenation: AF11 recommended DSCP | 8 x 0 bits | 10, 1123 i.e., 001010 00000000 10 = 0x2802. 1125 QNEs process two sets of token bucket parameters to implement the 1126 DiffServ AF QOSM, one token bucket for the average (CBS) traffic and 1127 one token bucket for the burst (EBS) traffic. These 2 token buckets 1128 are sufficient to cover most of the ways in which one would 1129 distinguish among 3 levels of drop precedence at the queuing 1130 mechanics level, as described in the Appendix to [RFC2597]. 1132 QoS-NSLP/QSPEC can support signaling the parameters required for the 1133 DiffServ marker elements described in [RFC2697] and [RFC2698]. 1134 [RFC2697] defines a Single Rate Three Color Marker (srTCM), which 1135 can be used as component in a DiffServ traffic conditioner [RFC2475, 1136 RFC2474]. The srTCM meters a traffic stream and marks its packets 1137 according to three traffic parameters, Committed Information Rate 1138 (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be 1139 either green, yellow, or red. A packet is marked green if it does 1140 not exceed the CBS, yellow if it does exceed the CBS, but not the 1141 EBS, and red otherwise. 1143 RFC 2697 and RFC 2698 provide specific procedures, where in essence, 1144 RFC 2697 is using two token buckets that run at the same rate. 1146 The parameter (see Section 7.2.5) includes values for 1147 Token Bucket Rate [r], Token Bucket Size [b], Peak Data Rate [p], 1148 Minimum Policed Unit [m], and Maximum Packet Size [MTU]. Most 1149 DiffServ discussions of token buckets consider only Token Bucket Rate 1150 and Token Bucket Size. To realize this sort of basic token bucket, 1151 the peak rate value [p] is set to positive infinity, the Minimum 1152 Policed Unit [m] to zero, and the Maximum Packet Size [MTU] to a very 1153 large number (e.g., the maximum positive 32-bit integer). Most 1154 DiffServ implementations can be expected to ignore these three 1155 values. Note that [RFC2215] adds p, m, and MTU to get a 1156 TOKEN_BUCKET_TSPEC, however DiffServ does not use these three added 1157 values. 1159 The srTCM [RFC 2697] may be signaled by using the same Committed 1160 Information Rate as the rate [r] for both Token Buckets (#1 and #2) 1161 and carrying the Committed Burst Size as the size of Token Bucket #1 1162 and the Excess Burst Size as the size of Token Bucket #2. The trTCM 1163 [RFC2698] can be realized by carrying the Committed Information 1164 Rate and Committed Burst Size in Token Bucket #1 and the Peak 1165 Information Rate and Peak Burst Size in Token Bucket #2. Note that 1166 this approach does not capture color-blind versus color-aware 1167 configurations of a trTCM. However, the QSPEC carries the traffic 1168 description, for which two token buckets are enough, and detailed 1169 DiffServ configuration to deal with this is handled via other means. 1171 7. QSPEC Functional Specification 1173 This Section defines the encodings of the QSPEC parameters and QSPEC 1174 control information defined in Section 5. We first give the general 1175 QSPEC formats and then the formats of the QSPEC objects and 1176 parameters. 1178 Note that all QoS Description parameters can be either read-write or 1179 read-only, depending on which object and which message they appear 1180 in. However, in a given QSPEC object, all objects are either 1181 read-write or read-only. In order to simplify keeping track of 1182 whether an object is read-write or read-only, a corresponding flag is 1183 associated with each object. 1185 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1186 well as 32-bit floating point numbers, are as specified in [RFC1832, 1187 IEEE754, NETWORK-BYTE-ORDER]. 1189 7.1 General QSPEC Formats 1191 The format of the QSPEC closely follows that used in GIST [GIST] and 1192 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1193 general format: 1195 o The overall format is Type-Length-Value (in that order). 1197 o Some parts of the type field are set aside for control flags. 1199 o Length has the units of 32-bit words, and measures the length of 1200 Value. If there is no Value, Length=0. The Object length excludes 1201 the header. 1203 o Value is a whole number of 32-bit words. If there is any padding 1204 required, the length and location MUST be defined by the 1205 object-specific format information; objects that contain variable 1206 length types may need to include additional length subfields to do 1207 so. 1209 o Any part of the object used for padding or defined as reserved("r") 1210 MUST be set to 0 on transmission and MUST be ignored on reception. 1212 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1214 o Duplicate objects, duplicate parameters, and/or multiple 1215 occurrences of a parameter MUST NOT be used. 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Common QSPEC Header | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 // QSPEC Control Information // 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 // QSPEC QoS Objects // 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 The Common QSPEC Header is a fixed 4-byte long object containing the 1228 QOSM ID and an identifier for the QSPEC Procedure (see Section 6.1): 1230 0 1 2 3 1231 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 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Vers. | QOSM ID | QSPEC Proc. | Reserved | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 Note that a length field is not necessary since the overall length of 1237 the QSPEC is contained in the higher level QoS NSLP data object. 1239 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1241 QOSM ID: Identifies the particular QOSM being used by the QNI. It is 1242 assigned by IANA. 1244 QSPEC Proc.: Is composed of two times 4 bits. The first set of bits 1245 identifies the Message Sequence, the second set 1246 identifies the QSPEC Object Combination used for this 1247 particular message sequence: 1249 0 1 2 3 4 5 6 7 1250 +-+-+-+-+-+-+-+-+ 1251 |Mes.Sq |Obj.Cmb| 1252 +-+-+-+-+-+-+-+-+ 1254 The Message Sequence field can attain the following 1255 values: 1257 0: Sender-Initiated Reservations, as defined in Section 1258 6.1.1 1259 1: Receiver-Initiated Reservations, as defined in 1260 Section 6.1.2 1261 2: Resource Queries, as defined in Section 6.1.3 1262 The Object Combination field can take the values between 1263 1 and 3 indicated in the tables in Section 6.1.1 to 1264 6.1.3. 1266 The QSPEC Control Information is a variable length object containing 1267 one or more parameters. The QSPEC Objects field is a collection of 1268 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1269 common format and each contain several parameters. 1271 Both the QSPEC Control Information object and the QSPEC QoS objects 1272 share a common header format: 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 |R|E|r|r| Object Type |r|r|r|r| Length | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 R Flag: If set the parameters contained in the object are read-only. 1281 Otherwise they are read-write. Note that in the case of 1282 Object Type = 0 (Control Information), this value is 1283 overwritten by parameter-specific values. 1285 E Flag: Set if an error occurs on object level 1287 Object Type = 0: control information 1288 = 1: QoS Desired 1289 = 2: QoS Available 1290 = 3: QoS Reserved 1291 = 4: Minimum QoS 1293 The r-flags are reserved. 1295 Each optional or mandatory parameter within an object can be 1296 similarly encoded in TLV format using a similar parameter header: 1298 0 1 2 3 1299 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 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 |M|E|N|T| Parameter ID |r|r|r|r| Length | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 M Flag: When set indicates the subsequent parameter is a mandatory 1305 parameter and MUST be interpreted. Otherwise the parameter is 1306 optional and can be ignored if not understood. 1307 E Flag: When set indicates an error occurred when this parameter was 1308 being interpreted. 1309 N Flag: Not-supported Flag (see Section 4.5). For mandatory 1310 parameters the value of this flag is always zero. 1311 T Flag: Tunneled-parameter Flag (see Section 4.5) 1312 Parameter Type: Assigned to each parameter (see below) 1314 7.2 Parameter Coding 1316 Parameters are usually coded individually, for example, the Bandwidth 1317 Parameter (Section 7.2.3). However, it is also possible to combine 1318 several parameters into one parameter field, which is called 1319 "container coding". This coding is useful if either a) the 1320 parameters always occur together, as for example the several 1321 parameters that jointly make up the token bucket, or b) in order to 1322 make coding more efficient because the length of each parameter value 1323 is much less than a 32-bit word (as for example described in 1324 [RMD-QOSM]). 1326 7.2.1 Parameter 1328 0 1 2 3 1329 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 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 |1|E|0|T| 0 |r|r|r|r| 1 | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | NON QOSM Hop | Reserved | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 NON QOSM Hop: This field is set to 1 if a non QOSM-aware QNE is 1337 encountered on the path from the QNI to the QNR. It is a read-write 1338 parameter. 1340 7.2.2 Parameter 1342 0 1 2 3 1343 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 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 |1|E|0|T| 1 |r|r|r|r| 1 | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Excess Trtmnt | Reserved | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 1351 Traffic, that is, traffic not covered by the Traffic Description. 1352 The excess treatment parameter is set by the QNI. It is a read-only 1353 parameter. Allowed values are as follows: 1355 0: drop 1356 1: shape 1357 2: remark 1358 3: no metering or policing is permitted 1360 If the excess treatment is unspecified, then the 1361 parameter SHOULD be omitted. The default excess treatment in case 1362 that none is specified is that there are no guarantees to excess 1363 traffic, i.e. a QNE can do whatever it finds suitable. 1365 If 'no metering or policing is permitted' is signaled, the QNE should 1366 accept the parameter set by the sender with 1367 special care so that excess traffic should not cause a problem. To 1368 request the Null Meter [RFC3290] is especially strong, and should be 1369 used with caution. 1371 A NULL metering application [RFC2997] would not include the traffic 1372 profile, and conceptually it should be possible to support this with 1373 the QSPEC. A QSPEC without a traffic profile is not excluded by the 1374 current specification. However, note that the traffic profile is 1375 important even in those cases when the excess treatment is not 1376 specified, e.g., in negotiating bandwidth for the best effort 1377 aggregate. However, a "NULL Service QOSM" would need to be specified 1378 where the desired QNE Behavior and the corresponding QSPEC format are 1379 described. 1381 As an example behavior for a NULL metering, in the properly 1382 configured DiffServ router, the resources are shared between the 1383 aggregates by the scheduling disciplines. Thus, if the incoming rate 1384 increases, it will influence the state of a queue within that 1385 aggregate, while all the other aggregates will be provided sufficient 1386 bandwidth resources. NULL metering is useful for best effort and 1387 signaling data, where there is no need to meter and police this data 1388 as it will be policed implicitly by the allocated bandwidth and, 1389 possibly, active queue management mechanism. 1391 7.2.3 [RFC 2212, RFC 2215] 1393 0 1 2 3 1394 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 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 |1|E|0|T| 2 |r|r|r|r| 1 | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Bandwidth (32-bit IEEE floating point number) | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 The parameter MUST be nonnegative and is measured in 1402 bytes per second and has the same range and suggested representation 1403 as the bucket and peak rates of the . can 1404 be represented using single-precision IEEE floating point. The 1405 representation MUST be able to express values ranging from 1 byte per 1406 second to 40 terabytes per second. For values of this parameter only 1407 valid non-negative floating point numbers are allowed. Negative 1408 numbers (including "negative zero"), infinities, and NAN's are not 1409 allowed. 1411 A QNE MAY export a local value of zero for this parameter. A network 1412 element or application receiving a composed value of zero for this 1413 parameter MUST assume that the actual bandwidth available is unknown. 1415 7.2.4 Parameter [RFC 2212, RFC 2215] 1417 0 1 2 3 1418 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 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 |0|E|N|T| 3 |r|r|r|r| 1 | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Slack Term [S] (32-bit integer) | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 Slack term S MUST be nonnegative and is measured in microseconds. 1426 The Slack term, S, can be represented as a 32-bit integer. Its value 1427 can range from 0 to (2**32)-1 microseconds. 1429 7.2.5 Parameters [RFC 2215] 1431 The parameters are represented by three floating 1432 point numbers in single-precision IEEE floating point format followed 1433 by two 32-bit integers in network byte order. The first floating 1434 point value is the rate (r), the second floating point value is the 1435 bucket size (b), the third floating point is the peak rate (p), the 1436 first unsigned integer is the minimum policed unit (m), and the 1437 second unsigned integer is the maximum datagram size (MTU). 1439 Note that the two sets of parameters can be 1440 distinguished, as could be needed for example to support DiffServ 1441 applications (see Section 7.2). 1443 Token Bucket #1 Parameter ID = 4 1444 Token Bucket #1: Mandatory QSPEC Parameter 1446 Parameter Values: 1448 0 1 2 3 1449 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 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 |1|E|0|T| 4 |r|r|r|r| 5 | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Token Bucket Size [b] (32-bit IEEE floating point number) | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Peak Data Rate [p] (32-bit IEEE floating point number) | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Minimum Policed Unit [m] (32-bit unsigned integer) | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Maximum Packet Size [MTU] (32-bit unsigned integer) | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 Token Bucket #2 Parameter ID = 5 1464 Token Bucket #2: Optional QSPEC Parameter 1466 Parameter Values: 1468 0 1 2 3 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 |0|E|N|T| 5 |r|r|r|r| 5 | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Token Bucket Size [b] (32-bit IEEE floating point number) | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Peak Data Rate [p] (32-bit IEEE floating point number) | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Minimum Policed Unit [m] (32-bit unsigned integer) | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Maximum Packet Size [MTU] (32-bit unsigned integer) | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 When r, b, and p terms are represented as IEEE floating point values, 1485 the sign bit MUST be zero (all values MUST be non-negative). 1486 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1487 than 162 (i.e., positive 35) are discouraged, except for specifying a 1488 peak rate of infinity. Infinity is represented with an exponent of 1489 all ones (255) and a sign bit and mantissa of all zeroes. 1491 7.2.6 Parameters 1493 7.2.6.1 Parameter [RFC 3140] 1495 As prescribed in RFC 3140, the encoding for a single PHB is the 1496 recommended DSCP value for that PHB, left-justified in the 16 bit 1497 field, with bits 6 through 15 set to zero. 1499 0 1 2 3 1500 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 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 |1|E|0|T| 6 |r|r|r|r| 1 | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | DSCP |0 0 0 0 0 0 0 0 0 0| Reserved | 1505 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1507 The registries needed to use RFC 3140 already exist, see [DSCP- 1508 REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs to be 1509 created for this purpose. 1511 7.2.6.2 Parameter [Y.1541] 1513 0 1 2 3 1514 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 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 |1|E|0|T| 7 |r|r|r|r| 1 | 1517 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1518 |Y.1541 QoS Cls.| Reserved | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 1522 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 1524 Class 0: 1525 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1526 Real-time, highly interactive applications, sensitive to jitter. 1527 Application examples include VoIP, Video Teleconference. 1529 Class 1: 1530 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1531 Real-time, interactive applications, sensitive to jitter. 1532 Application examples include VoIP, Video Teleconference. 1534 Class 2: 1535 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 1536 10^-3. Highly interactive transaction data. Application examples 1537 include signaling. 1539 Class 3: 1540 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 1541 10^-3. Interactive transaction data. Application examples include 1542 signaling. 1544 Class 4: 1545 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 1546 10^-3. Low Loss Only applications. Application examples include 1547 short transactions, bulk data, video streaming. 1549 Class 5: 1550 Mean delay unspecified, delay variation unspecified, loss ratio 1551 unspecified. Unspecified applications. Application examples include 1552 traditional applications of default IP networks. 1554 Class 6: 1555 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1556 Applications that are highly sensitive to loss, such as television 1557 transport, high-capacity TCP transfers, and TDM circuit emulation. 1559 Class 7: 1560 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1561 Applications that are highly sensitive to loss, such as television 1562 transport, high-capacity TCP transfers, and TDM circuit emulation. 1564 7.6.2.3 Parameter [RFC3564] 1566 DSTE class type is defined as follows: 1568 0 1 2 3 1569 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 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 |1|E|0|T| 8 |r|r|r|r| 1 | 1572 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1573 |DSTE Cls. Type | Reserved | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 DSTE Class Type: Indicates the DSTE class type. Values currently 1577 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 1579 7.2.7 Priority Parameters 1581 7.2.7.1 & Parameters 1582 [RFC 3181] 1584 0 1 2 3 1585 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 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 |1|E|0|T| 9 |r|r|r|r| 1 | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Preemption Priority | Defending Priority | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 Preemption Priority: The priority of the new flow compared with the 1593 defending priority of previously admitted flows. Higher values 1594 represent higher priority. 1596 Defending Priority: Once a flow is admitted, the preemption priority 1597 becomes irrelevant. Instead, its defending priority is used to 1598 compare with the preemption priority of new flows. 1600 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 1602 parameter is used. 1604 7.2.7.2 Parameter [PRIORITY-RQMTS] 1606 0 1 2 3 1607 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 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 |1|E|0|T| 10 |r|r|r|r| 1 | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 + Admission | Reserved | 1612 + Priority | | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 High priority flows, normal priority flows, and best-effort priority 1616 flows can have access to resources depending on their admission 1617 priority value, as described in [PRIORITY-RQMTS], as follows: 1619 Admission Priority: 1621 0 - high priority flow 1622 1 - normal priority flow 1623 2 - best-effort priority flow 1625 7.2.7.3 Parameter [SIP-PRIORITY] 1627 0 1 2 3 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 |1|E|0|T| 11 |r|r|r|r| 1 | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 + RPH Namespace | RPH Priority | Reserved | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 [SIP-PRIORITY] defines a resource priority header (RPH) with 1636 parameters "RPH Namespace" and "RPH Priority" combination, 1637 and if populated is applicable only to flows with high reservation 1638 priority, as follows: 1640 RPH Namespace: 1642 0 - dsn 1643 1 - drsn 1644 2 - q735 1645 3 - ets 1646 4 - wps 1647 5 - not populated 1649 RPH Priority: 1650 Each namespace has a finite list of relative priority-values. Each 1651 is listed here in the order of lowest priority to highest priority: 1653 4 - dsn.routine 1654 3 - dsn.priority 1655 2 - dsn.immediate 1656 1 - dsn.flash 1657 0 - dsn.flash-override 1659 5 - drsn.routine 1660 4 - drsn.priority 1661 3 - drsn.immediate 1662 2 - drsn.flash 1663 1 - drsn.flash-override 1664 0 - drsn.flash-override-override 1666 4 - q735.4 1667 3 - q735.3 1668 2 - q735.2 1669 1 - q735.1 1670 0 - q735.0 1672 4 - ets.4 1673 3 - ets.3 1674 2 - ets.2 1675 1 - ets.1 1676 0 - ets.0 1678 4 - wps.4 1679 3 - wps.3 1680 2 - wps.2 1681 1 - wps.1 1682 0 - wps.0 1684 Note that additional work is needed to communicate these flow 1685 priority values to bearer-level network elements 1686 [VERTICAL-INTERFACE]. 1688 7.2.8 Parameter [RFC 2210, 2215] 1690 0 1 2 3 1691 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 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 |0|E|N|T| 12 |r|r|r|r| 1 | 1694 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1695 | Path Latency (32-bit integer) | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 The Path Latency is a single 32-bit integer in network byte order. 1699 The composition rule for the parameter is summation 1700 with a clamp of (2**32 - 1) on the maximum value. The latencies are 1701 average values reported in units of one microsecond. A system with 1702 resolution less than one microsecond MUST set unused digits to zero. 1703 An individual QNE can advertise a latency value between 1 and 2**28 1704 (somewhat over two minutes) and the total latency added across all 1705 QNEs can range as high as (2**32)-2. If the sum of the different 1706 elements delays exceeds (2**32)-2, the end-to-end advertised delay 1707 SHOULD be reported as indeterminate. A QNE that cannot accurately 1708 predict the latency of packets it is processing MUST raise the 1709 not-supported flagand either leave the value of Path Latency as is, 1710 or add its best estimate of its lower bound. A raised not-supported 1711 flagflag indicates the value of Path Latency is a lower bound of the 1712 real Path Latency. The distinguished value (2**32)-1 is taken to 1713 mean indeterminate latency because the composition function limits 1714 the composed sum to this value, it indicates the range of the 1715 composition calculation was exceeded. 1717 7.2.9 Parameter 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| 13 |r|r|r|r| 3 | 1723 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1724 | Path Jitter STAT1(variance) (32-bit integer) | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Path Jitter STAT3(reserved) (32-bit integer) | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 The Path Jitter is a set of three 32-bit integers in network byte 1732 order. The Path Jitter parameter is the combination of three 1733 statistics describing the Jitter distribution with a clamp of 1734 (2**32 - 1) on the maximum of each value. The jitter STATs are 1735 reported in units of one microsecond. A system with resolution less 1736 than one microsecond MUST set unused digits to zero. An individual 1737 QNE can advertise jitter values between 1 and 2**28 (somewhat over 1738 two minutes) and the total jitter computed across all QNEs can range 1739 as high as (2**32)-2. If the combination of the different element 1740 values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be 1741 reported as indeterminate. A QNE that cannot accurately predict the 1742 jitter of packets it is processing MUST raise the not-supported flag 1743 and either leave the value of Path Jitter as is, or add its best 1744 estimate of its STAT values. A raised not-supported flag indicates 1745 the value of Path Jitter is a lower bound of the real Path Jitter. 1746 The distinguished value (2**32)-1 is taken to mean indeterminate 1747 jitter. A QNE that cannot accurately predict the jitter of packets 1748 it is processing SHOULD set its local parameter to this value. 1749 Because the composition function limits the total to this value, 1750 receipt of this value at a network element or application indicates 1751 that the true path jitter is not known. This MAY happen because one 1752 or more network elements could not supply a value, or because the 1753 range of the composition calculation was exceeded. 1755 NOTE: The Jitter composition function makes use of the 1756 parameter. Composition functions for loss, latency and jitter may be 1757 found in [Y.1541]. Additional study is in-progress. 1759 7.2.10 Parameter 1761 0 1 2 3 1762 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 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 |0|E|N|T| 14 |r|r|r|r| 1 | 1765 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1766 | Path Packet Loss Ratio (32-bit floating point) | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 The Path PLR is a single 32-bit single precision IEEE floating point 1770 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1772 value. The PLRs are reported in units of 10^-11. A system with 1773 resolution less than one microsecond MUST set unused digits to zero. 1774 An individual QNE can advertise a PLR value between zero and 10^-2 1775 and the total PLR added across all QNEs can range as high as 10^-1. 1776 If the sum of the different elements values exceeds 10^-1, the 1777 end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE 1778 that cannot accurately predict the PLR of packets it is processing 1779 MUST raise the not-supported flag and either leave the value of Path 1780 PLR as is, or add its best estimate of its lower bound. A raised 1781 not-supported flag indicates the value of Path PLR is a lower bound 1782 of the real Path PLR. The distinguished value 10^-1 is taken to mean 1783 indeterminate PLR. A QNE which cannot accurately predict the PLR of 1784 packets it is processing SHOULD set its local parameter to this 1785 value. Because the composition function limits the composed sum to 1786 this value, receipt of this value at a network element or application 1787 indicates that the true path PLR is not known. This MAY happen 1788 because one or more network elements could not supply a value, or 1789 because the range of the composition calculation was exceeded. 1791 7.2.11 Parameter 1793 0 1 2 3 1794 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 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 |0|E|N|T| 15 |r|r|r|r| 1 | 1797 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1798 | Path Packet Error Ratio (32-bit floating point) | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 The Path PER is a single 32-bit single precision IEEE floating point 1802 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1804 value. The PERs are reported in units of 10^-11. A system with 1805 resolution less than one microsecond MUST set unused digits to zero. 1806 An individual QNE can advertise a PER value between zero and 10^-2 1807 and the total PER added across all QNEs can range as high as 10^-1. 1809 If the sum of the different elements values exceeds 10^-1, the 1810 end-to-end advertised PER SHOULD be reported as indeterminate. A QNE 1811 that cannot accurately predict the PER of packets it is processing 1812 MUST raise the not-supported flag and either leave the value of Path 1813 PER as is, or add its best estimate of its lower bound. A raised 1814 not-supported flag indicates the value of Path PER is a lower bound 1815 of the real Path PER. The distinguished value 10^-1 is taken to mean 1816 indeterminate PER. A QNE which cannot accurately predict the PER of 1817 packets it is processing SHOULD set its local parameter to this 1818 value. Because the composition function limits the composed sum to 1819 this value, receipt of this value at a network element or application 1820 indicates that the true path PER is not known. This MAY happen 1821 because one or more network elements could not supply a value, or 1822 because the range of the composition calculation was exceeded. 1824 7.2.12 Parameters [RFC 2210, 2212, 2215] 1826 0 1 2 3 1827 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 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 |0|E|N|T| 16 |r|r|r|r| 1 | 1830 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1831 | End-to-end composed value for C [Ctot] (32-bit integer) | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 0 1 2 3 1835 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 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 |0|E|N|T| 17 |r|r|r|r| 1 | 1838 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1839 | End-to-end composed value for D [Dtot] (32-bit integer) | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 0 1 2 3 1843 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 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 |0|E|N|T| 18 |r|r|r|r| 1 | 1846 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1847 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 0 1 2 3 1851 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 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 |0|E|N|T| 19 |r|r|r|r| 1 | 1854 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1855 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 The error term C is measured in units of bytes. An individual QNE 1859 can advertise a C value between 1 and 2**28 (a little over 250 1860 megabytes) and the total added over all QNEs can range as high as 1861 (2**32)-1. Should the sum of the different QNEs delay exceed 1862 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 1863 error term D is measured in units of one microsecond. An individual 1864 QNE can advertise a delay value between 1 and 2**28 (somewhat over 1865 two minutes) and the total delay added over all QNEs can range as 1866 high as (2**32)-1. Should the sum of the different QNEs delay 1867 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 1869 8. Security Considerations 1871 The priority parameter raises possibilities for Theft of Service 1872 Attacks because users could claim an emergency priority for their 1873 flows without real need, thereby effectively preventing serious 1874 emergency calls to get through. Several options exist for countering 1875 such attacks, for example 1877 - only some user groups (e.g. the police) are authorized to set the 1878 emergency priority bit 1880 - any user is authorized to employ the emergency priority bit for 1881 particular destination addresses (e.g. police) 1883 9. IANA Considerations 1885 This section defines the registries and initial codepoint assignments 1886 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 1887 It also defines the procedural requirements to be followed by IANA in 1888 allocating new codepoints. Guidelines on the technical criteria to 1889 be followed in evaluating requests for new codepoint assignments are 1890 given for the overall NSIS protocol suite in a separate NSIS 1891 extensibility document [NSIS-EXTENSIBILITY]. 1893 This specification allocates the following codepoints in existing 1894 registries: 1896 PHB Class Parameter [RFC 3140] (Section 7.2.6.1) 1898 The registries needed to use RFC 3140 already exist [DSCP-REGISTRY, 1899 PHBID-CODES-REGISTRY]. 1901 This specification creates the following registries with the 1902 structures as defined below: 1904 Object Types (12 bits): 1905 The following values are allocated by this specification: 1906 0-4: assigned as specified in Section 7. 1907 The allocation policies for further values are as follows: 1908 5-63: Standards Action 1909 64-127: Private/Experimental Use 1910 128-4095: Reserved 1911 Guidelines on the technical criteria to be followed in evaluating 1912 requests for new codepoint assignments are given for the overall NSIS 1913 protocol suite in a separate NSIS extensibility document 1914 [NSIS-EXTENSIBILITY]. 1916 QSPEC Version (4 bits): 1917 The following value is allocated by this specification: 1918 0: assigned to Version 0 QSPEC 1919 The allocation policies for further values are as follows: 1920 1-15: Standards Action 1922 QOSM ID (12 bits): 1923 The following values are allocated by this specification: 1924 0: IntServ Controlled Load Service QOSM [INTSERV-QOSM] 1925 1: RMD QOSM [RMD-QOSM] 1926 2: Y.1541 QOSM [Y.1541-QOSM] 1927 The allocation policies for further values are as follows: 1928 3-63: Specification Required 1929 64-127: Private/Experimental Use 1930 128-4095: Reserved 1932 QSPEC Procedure (8 bits): 1933 Broken down into 1934 Message Sequence (4 bits): 1935 The following values are allocated by this specification: 1936 0-2: assigned as specified in Section 7.1 1937 The allocation policies for further values are as follows: 1938 3-15: Standards Action 1939 Object Combination: 1940 The following values are allocated by this specification: 1941 0-2: assigned as specified in tables in Section 6.1.1 --> 6.1.3 1942 The allocation policies for further values are as follows: 1943 3-15: Standards Action 1945 Parameter ID (12 bits): 1946 The following values are allocated by this specification: 1947 0-18: assigned as specified in Sections 7.2.1 --> 7.2.12. 1948 The allocation policies for further values are as follows: 1949 19-63: Standards Action (for mandatory parameters) 1950 64-127: Specification Required (for optional parameters) 1951 128-255: Private/Experimental Use 1952 255-4095: Reserved 1954 Excess Treatment Parameter (8 bits): 1955 The following values are allocated by this specification: 1956 0-3: assigned as specified in Section 7.2.2 1957 The allocation policies for further values are as follows: 1958 4-63: Standards Action 1959 64-255: Reserved 1960 Y.1541 QoS Class Parameter (12 bits): 1961 The following values are allocated by this specification: 1962 0-7: assigned as specified in Section 7.2.6.2 1963 The allocation policies for further values are as follows: 1964 8-63: Standards Action 1965 64-4095: Reserved 1967 DSTE Class Type Parameter (12 bits): 1968 The following values are allocated by this specification: 1969 0-7: assigned as specified in Section 7.2.6.3 1970 The allocation policies for further values are as follows: 1971 8-63: Standards Action 1972 64-4095: Reserved 1974 Admission Priority Parameter (8 bits): 1975 The following values are allocated by this specification: 1976 0-2: assigned as specified in Section 7.2.6.2 1977 The allocation policies for further values are as follows: 1978 3-63: Standards Action 1979 64-255: Reserved 1981 RPH Namespace Parameter (16 bits): 1982 The following values are allocated by this specification: 1983 0-5: assigned as specified in Section 7.2.7.2 1984 The allocation policies for further values are as follows: 1985 6-63: Standards Action 1986 64-65535: Reserved 1988 RPH Priority Parameter (8 bits): 1989 dsn namespace: 1990 The following values are allocated by this specification: 1991 0-4: assigned as specified in Section 7.2.7.2 1992 The allocation policies for further values are as follows: 1993 5-63: Standards Action 1994 64-255: Reserved 1995 drsn namespace: 1996 The following values are allocated by this specification: 1997 0-5: assigned as specified in Section 7.2.7.2 1998 The allocation policies for further values are as follows: 1999 6-63: Standards Action 2000 64-255: Reserved 2001 Q735 namespace: 2002 The following values are allocated by this specification: 2003 0-4: assigned as specified in Section 7.2.7.2 2004 The allocation policies for further values are as follows: 2005 5-63: Standards Action 2006 64-255: Reserved 2007 ets namespace: 2008 The following values are allocated by this specification: 2009 0-4: assigned as specified in Section 7.2.7.2 2010 The allocation policies for further values are as follows: 2012 5-63: Standards Action 2013 64-255: Reserved 2014 wts namespace: 2015 The following values are allocated by this specification: 2016 0-4: assigned as specified in Section 7.2.7.2 2017 The allocation policies for further values are as follows: 2018 5-63: Standards Action 2019 64-255: Reserved 2021 10. Acknowledgements 2023 The authors would like to thank (in alphabetical order) David Black, 2024 Anna Charny, Matthias Friedrich, Xiaoming Fu, Robert Hancock, Chris 2025 Lang, Jukka Manner, Dave Oran, Tom Phelan, Alexander Sayenko, Bernd 2026 Schloer, Hannes Tschofenig, and Sven van den Bosch for their very 2027 helpful suggestions. 2029 11. Normative References 2031 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 2032 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 2033 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 2034 Signaling Transport," work in progress. 2035 [NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work 2036 in progress. 2037 [QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service 2038 Signaling," work in progress. 2039 [RFC1832] Srinivasan, R., "XDR: External Data Representation 2040 Standard," RFC 1832, August 1995. 2041 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2042 Requirement Levels", BCP 14, RFC 2119, March 1997. 2043 [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 2044 -- Version 1 Functional Specification," RFC 2205, September 1997. 2045 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2046 Services", RFC 2210, September 1997. 2047 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 2048 Network Element Service", RFC 2211, Sept. 1997. 2049 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 2050 of Service," September 1997. 2051 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 2052 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 2053 1997. 2054 [RFC2474] Nichols, K., et. al., "Definition of the Differentiated 2055 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 2056 December 1998. 2057 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 2058 Services", RFC 2475, December 1998. 2059 [RFC2597] Heinanen, J., et. al., "Assured Forwarding PHB Group," RFC 2060 2597, June 1999. 2061 [RFC2697] Heinanen, J., Guerin, R., "A Single Rate Three Color 2062 Marker," RFC 2697, September 1999. 2064 [RFC2698] Heinanen, J., Guerin, R., "A Two Rate Three Color Marker," 2065 RFC 2698, September 1999. 2066 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2067 Codes," June 2001. 2068 [RFC3297]Charny, A., et. al., "Supplemental Information for the New 2069 Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)," 2070 RFC 3297, March 2002. 2072 12. Informative References 2074 [CMSS] "PacketCable (TM) CMS to CMS Signaling Specification, 2075 PKT-SP-CMSS-103-040402, April 2004. 2076 [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines 2077 for DiffServ Service Classes," work in progress. 2078 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 2079 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 2080 754-1985, August 1985. 2081 [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 2082 Controlled-Load Service with NSIS," work in progress. 2083 [NETWORK-BYTE-ORDER] Wikipedia, "Endianness," 2084 http://en.wikipedia.org/wiki/Endianness. 2085 [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels 2086 for IP Networks and Services," T1A1/2003-196 R3, November 2004. 2087 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 2088 Protocol - Capability Set 3" Sep. 2003 2089 [RFC1633] Braden, B., et. al., "Integrated Services in the Internet 2090 Architecture: an Overview," RFC 1633, June 1994. 2091 [RFC2997] Bernet, Y., et. al., "Specification of the Null Service 2092 Type," RFC 2997, November 2000. 2093 [RFC3290] Bernet, Y., et. al., "An Informal Management Model for 2094 Diffserv Routers," RFC 3290, May 2002. 2095 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 2096 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 2097 [RFC3564] Le Faucheur, F., et. al., Requirements for Support of 2098 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 2099 July 2003 2100 [RFC3726] Brunner, M., et. al., "Requirements for Signaling 2101 Protocols", RFC 3726, April 2004. 2102 [RMD-QOSM] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling 2103 Policy Model for Networks 2104 Using Resource Management in DiffServ (RMD)," work in progress. 2105 [SIP-PRIORITY] Schulzrinne, H., Polk, J., "Communications Resource 2106 Priority for the Session Initiation Protocol(SIP)." work in 2107 progress. 2108 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 2109 on Associating of Control Signaling Messages with Media Priority 2110 Levels," T1S1.7 & PRQC, October 2004. 2111 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 2112 Communication Service - IP Packet Transfer and Availability 2113 Performance Parameters," December 2002. 2115 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 2116 for IP-Based Services," May 2002. 2117 [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 2118 Networks Using Y.1541 QoS Classes," work in progress. 2120 13. Authors' & Contributors' Addresses 2122 Jerry Ash (Editor) 2123 AT&T 2124 Room MT D5-2A01 2125 200 Laurel Avenue 2126 Middletown, NJ 07748, USA 2127 Phone: +1-(732)-420-4578 2128 Fax: +1-(732)-368-8659 2129 Email: gash@att.com 2131 Attila Bader (Editor) 2132 Traffic Lab 2133 Ericsson Research 2134 Ericsson Hungary Ltd. 2135 Laborc u. 1 H-1037 2136 Budapest Hungary 2137 Email: Attila.Bader@ericsson.com 2139 Cornelia Kappler (Editor) 2140 Siemens AG 2141 Siemensdamm 62 2142 Berlin 13627 2143 Germany 2144 Email: cornelia.kappler@siemens.com 2146 Chuck Dvorak 2147 AT&T 2148 Room 2A37 2149 180 Park Avenue, Building 2 2150 Florham Park, NJ 07932 2151 Phone: + 1 973-236-6700 2152 Fax:+1 973-236-7453 2153 Email: cdvorak@att.com 2155 Yacine El Mghazli 2156 Alcatel 2157 Route de Nozay 2158 91460 Marcoussis cedex 2159 FRANCE 2160 Phone: +33 1 69 63 41 87 2161 Email: yacine.el_mghazli@alcatel.fr 2163 Georgios Karagiannis 2164 University of Twente 2165 P.O. BOX 217 2166 7500 AE Enschede 2167 The Netherlands 2168 Email: g.karagiannis@ewi.utwente.nl 2170 Andrew McDonald 2171 Siemens/Roke Manor Research 2172 Roke Manor Research Ltd. 2173 Romsey, Hants SO51 0ZN 2174 UK 2175 Email: andrew.mcdonald@roke.co.uk 2177 Al Morton 2178 AT&T 2179 Room D3-3C06 2180 200 S. Laurel Avenue 2181 Middletown, NJ 07748 2182 Phone: + 1 732 420-1571 2183 Fax: +.1 732 368-1192 2184 Email: acmorton@att.com 2186 Percy Tarapore 2187 AT&T 2188 Room D1-33 2189 200 S. Laurel Avenue 2190 Middletown, NJ 07748 2191 Phone: + 1 732 420-4172 2192 Email: tarapore@.att.com 2194 Lars Westberg 2195 Ericsson Research 2196 Torshamnsgatan 23 2197 SE-164 80 Stockholm, Sweden 2198 Email: Lars.Westberg@ericsson.com 2200 Appendix A: QoS Models and QSPECs 2202 This Appendix gives a description of QoS Models and QSPECs and 2203 explains what is the relation between them. Once these descriptions 2204 are contained in a stable form in the appropriate IDs this Appendix 2205 will be removed. 2207 QoS NSLP is a generic QoS signaling protocol that can signal for many 2208 QOSMs. A QOSM is a particular QoS provisioning method or QoS 2209 architecture such as IntServ Controlled Load or Guaranteed Service, 2210 DiffServ, or RMD for DiffServ. 2212 The definition of the QOSM is independent from the definition of QoS 2213 NSLP. Existing QOSMs do not specify how to use QoS NSLP to signal 2214 for them. Therefore, we need to define the QOSM specific signaling 2215 functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM]. 2217 A QOSM MUST include the following information: 2219 - Role of QNEs in this QOSM: E.g., location, frequency, statefulness, 2220 etc. 2221 - QSPEC Definition: A QOSM MUST specify the QSPEC, including a value 2222 for the QOSM ID, and which QSPEC parameters must be included. 2223 Furthermore it needs to explain how QSPEC parameters not used in 2224 this QOSM are mapped onto parameters defined therein. 2225 - QSPEC procedures: A QOSM MUST describe which QSPEC procedures are 2226 applicable to this QOSM. 2227 - Processing rules in QNEs: It describes how QSPEC info is treated 2228 and interpreted in the RMF and QOSM specific processing. E.g., 2229 admission control, scheduling, policy control, QoS parameter 2230 accumulation (e.g., delay). 2231 - QSPEC example: It includes at least one bit-level QSPEC example. 2233 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved of 2234 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 2236 The union of QoS Desired, QoS Available and QoS Reserved can provide 2237 all functionality of the objects specified in RSVP IntServ, however 2238 it is difficult to provide an exact mapping. 2240 In RSVP, the Sender TSpec specifies the traffic an application is 2241 going to send (e.g. token bucket). The AdSpec can collect path 2242 characteristics (e.g. delay). Both are issued by the sender. The 2243 receiver sends the FlowSpec which includes a Receiver TSpec 2244 describing the resources reserved using the same parameters as the 2245 Sender TSpec, as well as a RSpec which provides additional IntServ 2246 QoS Model specific parameters, e.g. Rate and Slack. 2248 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 2249 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 2250 knowledge of the authors it is not possible for the sender to specify 2251 a desired maximum delay except implicitly and mutably by seeding the 2252 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 2253 the receiver-issued RSVP RESERVE message. For this reason our 2254 discussion at this point leads us to a slightly different mapping of 2255 necessary functionality to objects, which should result in more 2256 flexible signaling models. 2258 Appendix C: Main Changes Since Last Version & Open Issues 2260 C.1 Main Changes Since Version -04 2262 Version -05: 2264 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 2265 - discarded QSPEC parameter (Maximum packet size) since MTU 2266 discovery is expected to be handled by procedure currently defined 2267 by PMTUD WG 2268 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 2269 efficiency 2270 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 2271 - revised Section 6.2.2 on SIP priorities 2272 - added QSPEC procedures for "RSVP-style reservation", resource 2273 queries and bidirectional reservations in Sec. 7.1 2274 - reworked Section 7.2 2276 Version -06: 2278 - defined "not-supported flag" and "tunneled parameter flag" 2279 (subsumes "optional parameter flag") 2280 - defined "error flag" for error handling 2281 - updated bit error rate (BER) parameter to packet loss ratio (PLR) 2282 parameter 2283 - added packet error ratio (PER) parameter 2284 - coding checked by independent expert 2285 - coding updated to include RE flags in QSPEC objects and MENT flags 2286 in QSPEC parameters 2288 Version -07: 2290 - added text (from David Black) on DiffServ QSPEC example in Section 2291 6 2292 - re-numbered QSPEC parameter IDs to start with 0 (Section 7) 2293 - expanded IANA Considerations Section 9 2295 Version -08: 2297 - update to 'RSVP-style' reservation in Section 6.1.2 to mirror what 2298 is done in RSVP 2299 - modified text (from David Black) on DiffServ QSPEC example in 2300 Section 6.2 2301 - update to general QSPEC parameter formats in Section 7.1 (length 2302 restrictions, etc.) 2303 - re-numbered QSPEC parameter IDs in Section 7.2 2304 - modified parameter values in Section 7.2.2 2305 - update to reservation priority Section 7.2.7 2306 - specify the 3 "STATS" in the parameter, Section 2307 7.2.9.4 2308 - minor updates to IANA Considerations Section 9 2310 C.2 Open Issues 2312 None. 2314 Intellectual Property Statement 2316 The IETF takes no position regarding the validity or scope of any 2317 Intellectual Property Rights or other rights that might be claimed to 2318 pertain to the implementation or use of the technology described in 2319 this document or the extent to which any license under such rights 2320 might or might not be available; nor does it represent that it has 2321 made any independent effort to identify any such rights. Information 2322 on the procedures with respect to rights in RFC documents can be 2323 found in BCP 78 and BCP 79. 2325 Copies of IPR disclosures made to the IETF Secretariat and any 2326 assurances of licenses to be made available, or the result of an 2327 attempt made to obtain a general license or permission for the use of 2328 such proprietary rights by implementers or users of this 2329 specification can be obtained from the IETF on-line IPR repository at 2330 http://www.ietf.org/ipr. 2332 The IETF invites any interested party to bring to its attention any 2333 copyrights, patents or patent applications, or other proprietary 2334 rights that may cover technology that may be required to implement 2335 this standard. Please address the information to the IETF at 2336 ietf-ipr@ietf.org. 2338 Disclaimer of Validity 2340 This document and the information contained herein are provided on an 2341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2343 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2344 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2345 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2348 Copyright Statement 2350 Copyright (C) The Internet Society (2005). This document is subject 2351 to the rights, licenses and restrictions contained in BCP 78, and 2352 except as set forth therein, the authors retain all their rights.