idnits 2.17.1 draft-ietf-nsis-qspec-09.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 2292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2282. ** 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 (March 2006) is 6615 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 1343, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 1357, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 1762, but not defined == Missing Reference: 'RFC2212' is mentioned on line 868, but not defined == Missing Reference: 'QOS-SIG' is mentioned on line 936, but not defined == Missing Reference: 'S' is mentioned on line 1350, but not defined == Missing Reference: 'MTU' is mentioned on line 1410, but not defined == Missing Reference: 'RFC 3140' is mentioned on line 1833, but not defined == Missing Reference: 'RFC 3181' is mentioned on line 1511, but not defined == Missing Reference: 'RFC3181' is mentioned on line 1529, but not defined -- Looks like a reference, but probably isn't: '2215' on line 1762 -- Looks like a reference, but probably isn't: '2212' on line 1762 == Missing Reference: 'Ctot' is mentioned on line 1769, but not defined == Missing Reference: 'Dtot' is mentioned on line 1776, but not defined == Missing Reference: 'Csum' is mentioned on line 1784, but not defined == Missing Reference: 'Dsum' is mentioned on line 1792, but not defined == Missing Reference: 'RFC2434' is mentioned on line 1823, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'DSCP-REGISTRY' is defined on line 1967, but no explicit reference was found in the text == Unused Reference: 'PHBID-CODES-REGISTRY' is defined on line 1968, but no explicit reference was found in the text == Unused Reference: 'RFC1832' is defined on line 1976, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 1982, but no explicit reference was found in the text == Unused Reference: 'RFC2211' is defined on line 1984, but no explicit reference was found in the text == Unused Reference: 'RFC2215' is defined on line 1988, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1991, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 1996, but no explicit reference was found in the text == Unused Reference: 'RFC2697' is defined on line 1998, but no explicit reference was found in the text == Unused Reference: 'RFC2698' is defined on line 2000, but no explicit reference was found in the text == Unused Reference: 'RFC3140' is defined on line 2002, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV-CLASS' is defined on line 2012, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 2014, but no explicit reference was found in the text == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2019, but no explicit reference was found in the text == Unused Reference: 'RFC1633' is defined on line 2026, 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 (~~), 33 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: September 2006 Ericsson 6 Cornelia Kappler 7 Siemens AG 9 March 2006 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 September 5, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . 5 64 4.1 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 6 65 4.2 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 6 66 4.3 Example of NSLP/QSPEC Operation . . . . . . . . . . . . . . 7 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 . . . . . . 12 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 . . . . 13 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 . . . . . . . . . . . . . . . . . . . 19 80 5.2.4 . . . . . . . . . . . . . . . . . . . . 19 81 6. QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . . . 19 82 6.1 Sender-Initiated Reservations . . . . . . . . . . . . . . . 19 83 6.2 Receiver-Initiated Reservations . . . . . . . . . . . . . . 20 84 6.3 Resource Queries . . . . . . . . . . . . . . . . . . . . . 22 85 6.4 Bidirectional Reservations . . . . . . . . . . . . . . . . 22 86 7. QSPEC Functional Specification . . . . . . . . . . . . . . . . 22 87 7.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 23 88 7.2 Parameter Coding . . . . . . . . . . . . . . . . . . . . . 25 89 7.2.1 Parameter . . . . . . . . . . . . . . 25 90 7.2.2 Parameter . . . . . . . . . . . . 26 91 7.2.3 . . . . . . . . . . . . . . . . . . . . . 27 92 7.2.4 Parameter . . . . . . . . . . . . . . . 27 93 7.2.5 Parameters . . . . . . . . . . . . . . 27 94 7.2.6 Parameters . . . . . . . . . . . . . . . 29 95 7.2.6.1 Parameter . . . . . . . . . . . . 29 96 7.2.6.2 Parameter . . . . . . . . 29 97 7.2.6.3 Parameter . . . . . . . . . 30 98 7.2.7 Priority Parameters . . . . . . . . . . . . . . . . . 30 99 7.2.7.1 & 100 Parameters . . . . . . . . . . . . . . . . . 30 101 7.2.7.2 Parameter . . . . . . . 31 102 7.2.7.3 Parameter . . . . . . . . . . 31 104 7.2.8 Parameter . . . . . . . . . . . . . . 33 105 7.2.9 Parameter . . . . . . . . . . . . . . . 33 106 7.2.10 Parameter . . . . . . . . . . . . . . . . 34 107 7.2.11 Parameter . . . . . . . . . . . . . . . . 35 108 7.2.12 Parameters . . . . . . . 35 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 36 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 37 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 112 11. Normative References . . . . . . . . . . . . . . . . . . . . . 39 113 12. Informative References . . . . . . . . . . . . . . . . . . . . 40 114 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 115 Appendix A: QoS Models and QSPECs . . . . . . . . . . . . . . . . 43 116 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved 117 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 43 118 Appendix C: Main Changes Since Last Version & Open Issues . . . . 44 119 C.1 Main Changes Since Version -04 . . . . . . . . . . 44 120 C.2 Open Issues . . . . . . . . . . . . . . . . . . . 45 121 Intellectual Property Statement . . . . . . . . . . . . . . . . . 45 122 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 46 123 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 46 125 1. Conventions Used in This Document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 2. Introduction 133 The QoS NSLP establishes and maintains state at nodes along the path 134 of a data flow for the purpose of providing forwarding resources 135 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually 136 similar to RSVP [RFC2205], and meets the requirements of [RFC3726]. 138 A QoS-enabled domain supports a particular QoS model (QOSM), which is 139 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 140 provisioning methods and a QoS architecture. It defines the behavior 141 of the resource management function (RMF), including inputs and 142 outputs, and how QSPEC information is interpreted on traffic 143 description, resources required, resources available, and control 144 information required by the RMF. A QOSM also specifies a set of 145 mandatory and optional QSPEC parameters that describe the QoS and how 146 resources will be managed by the RMF. QoS NSLP can support signaling 147 for different QOSMs, such as for IntServ, DiffServ admission control, 148 and those specified in [Y.1541-QOSM, INTSERV-QOSM, RMD-QOSM]. For 149 more information on QOSMs see Section 7.2 and Appendix A. 151 One of the major differences between RSVP and QoS-NSLP is that 152 QoS-NSLP supports signaling for different QOSMs along the data path, 153 all with one signaling message. For example, the data path may start 154 in a domain supporting DiffServ and end in a domain supporting 155 Y.1541. However, because some typical QoS parameters are 156 standardized and can be reused in different QOSMs, some degree of 157 interoperability between QOSMs exists. 159 The QSPEC travels in QoS-NSLP messages and is opaque to the QoS NSLP. 160 It is only interpreted by the RMF. The content of the QSPEC is QOSM 161 specific. However, the mandatory parameters in the QSPEC MUST be 162 interpreted by all QNEs, independent of which QOSM they support. 163 Since QoS-NSLP signaling operation can be different for different 164 QOSMs, the QSPEC contains two kinds of information, QSPEC control 165 information and QoS description. 167 QSPEC control information contains parameters that governs the RMF. 168 An example of QSPEC control information is how the excess traffic is 169 treated in the RMF queuing functions. 171 The QoS description is composed of QSPEC objects loosely 172 corresponding to the TSpec, RSpec and AdSpec objects specified in 173 RSVP. This is, the QSPEC may contain a description of QoS desired 174 and QoS reserved. It can also collect information about available 175 resources. Going beyond RSVP functionality, the QoS description 176 also allows indicating a range of acceptable QoS by defining a QSPEC 177 object denoting minimum QoS. Usage of these QSPEC objects is not 178 bound to particular message types thus allowing for flexibility. A 179 QSPEC object collecting information about available resources MAY 180 travel in any QoS-NSLP message, for example a QUERY message or a 181 RESERVE message. 183 3. Terminology 185 Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 186 if applicable to the underlying QOSM and a QNE MUST interpret, if 187 populated. 189 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 190 any QNE. Together with a description of QoS Desired or QoS 191 Available, it allows the QNI to specify a QoS range, i.e. an upper 192 and lower bound. If the QoS Desired cannot be reserved, QNEs are 193 going to decrease the reservation until the minimum QoS is hit. 195 Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 196 if applicable to the underlying QOSM, and a QNE SHOULD interpret if 197 populated and applicable to the QOSM(s) supported by the QNE. (A QNE 198 MAY ignore if it does not support a QOSM needing the optional QSPEC 199 parameter). 201 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 203 QNI: QoS NSIS Initiator, a node initiating QoS-NSLP signaling. 205 QNR: QoS NSIS Receiver, a node terminating QoS-NSLP signaling. 207 QoS Description: Describes the actual QoS in QSPEC objects QoS 208 Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC 209 objects are input or output parameters of the RMF. In a valid QSPEC, 210 at least one QSPEC object of the type QoS Desired, QoS Available or 211 QoS Reserved MUST be included. 213 QoS Available: QSPEC object containing parameters describing the 214 available resources. They are used to collect information along a 215 reservation path. 217 QoS Desired: QSPEC object containing parameters describing the 218 desired QoS for which the sender requests reservation. 220 QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g., 221 IntServ Controlled Load. A QOSM specifies a set of mandatory and 222 optional QSPEC parameters that describe the QoS and how resources 223 will be managed by the RMF. It furthermore specifies how to use QoS 224 NSLP to signal for this QOSM. 226 QoS Reserved: QSPEC object containing parameters describing the 227 reserved resources and related QoS parameters, for example, 228 bandwidth. 230 QSPEC Control Information: Control information that is specific to a 231 QSPEC, and contains parameters that govern the RMF. 233 QSPEC: QSPEC is the object of QoS-NSLP containing all QOSM-specific 234 information. 236 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 237 QoS description and QSPEC control information parameters, for 238 example, bandwidth, token bucket, and excess treatment parameters. 240 QSPEC Object: Main building blocks of QoS Description containing a 241 QSPEC parameter set that is input or output of an RMF operation. 243 Resource Management Function (RMF): Functions that are related to 244 resource management, specific to a QOSM. It processes the QoS 245 description parameters and QSPEC control parameters. 247 Read-only Parameter: QSPEC Parameter that is set by initiating or 248 responding QNE and is not changed during the processing of the QSPEC 249 along the path. 251 Read-write Parameter: QSPEC Parameter that can be changed during the 252 processing of the QSPEC by any QNE along the path. 254 4. QSPEC Parameters, Processing, & Extensibility 255 4.1 QSPEC Parameters 257 The definition of a QOSM includes the specification of how the 258 requested QoS resources will be described and how they will be 259 managed by the RMF. For this purpose, the QOSM specifies a set of 260 QSPEC parameters that describe the QoS and QoS resource control in 261 the RMF. A given QOSM defines which of the mandatory and optional 262 QSPEC parameters it uses, and it MAY define additional optional QSPEC 263 parameters. Mandatory and optional QSPEC parameters provide a common 264 language for QOSM developers to build their QSPECs and are likely to 265 be re-used in several QOSMs. Mandatory and optional QSPEC parameters 266 are defined in this document, and additional optional QSPEC 267 parameters can be defined in separate documents. 269 As defined in Section 4.6, additional optional QSPEC parameters can 270 be defined in separate Informational documents specific to a given 271 QOSM. For example, optional QSPEC parameters are defined in 272 [RMD-QOSM] and [Y.1541-QOSM]. 274 4.2 QSPEC Processing 276 The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control 277 information and the QoS description are interpreted and MAY be 278 modified by the RMF in a QNE (see description in [QoS-SIG]). 280 A QNE MUST support at least one QOSM. A QoS-enabled domain supports 281 a particular QOSM, e.g. DiffServ admission control. If this domain 282 supports QoS-NSLP signaling, its QNEs MUST support the DiffServ 283 admission control QOSM. The QNEs MAY also support additional QOSMs. 285 The QSPEC contains a QOSM ID, i.e. information on what QOSM is being 286 signaled by the QNI. However, if a QSPEC arrives at a QNE that does 287 not support the QOSM being signaled, it can still understand the 288 QSPEC content, at least to a basic degree. This is because mandatory 289 parameters have been defined as a common language. Therefore, a QNE 290 MUST at least interpret all the mandatory parameters in a QSPEC even 291 if it does not support the corresponding QOSM. 293 A QoS NSLP message can contain a stack of at most 2. The first on 294 the stack is the Initiator QSPEC. This is a QSPEC provided by the 295 QNI, which travels end-to-end, and therefore the stack always has at 296 least depth 1. QSPEC parameters MUST NOT be deleted from or added to 297 the Initiator QSPEC. In addition, the stack MAY contain a Local 298 QSPEC stacked on top of the Initiator QSPEC. A QNE only considers 299 the topmost QSPEC. 301 At the ingress edge of a local QoS domain, a Local QSPEC MAY be 302 pushed on the stack in order to describe the requested resources in a 303 domain-specific manner. Also, the Local QSPEC is popped from the 304 stack at the egress edge of the local QoS domain. 306 This draft provides a template for the QSPEC, which is needed in 307 order to help define individual QOSMs and in order to promote 308 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 309 is composed of QSPEC control information and QoS description. QoS 310 description in turn is composed of up to four QSPEC objects (not all 311 of them need to be present), namely QoS Desired, QoS Available, QoS 312 Reserved and Minimum QoS. Each of these QSPEC Objects, as well as 313 QSPEC Control Information, consists of a number of mandatory and 314 optional QSPEC parameters. 316 +-------------+---------------------------------------+ 317 |QSPEC Control| QoS | 318 | Information | Description | 319 +-------------+---------------------------------------+ 321 \________________ ______________________/ 322 V 323 +----------+----------+---------+-------+ \ 324 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC 325 +----------+----------+---------+-------+ / Objects 327 \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/ 328 V V V V V 330 +-------------+... +-------------+... 331 |QSPEC Para. 1| |QSPEC Para. n| 332 +-------------+... +-------------+... 334 Figure 1: Structure of the QSPEC 336 The internal structure of each QSPEC object and the QSPEC control 337 information, with mandatory and optional parameters, is illustrated 338 in Figure 2. 340 +------------------+-----------------+---------------+ 341 | QSPEC/Ctrl Info | Mandatory QSPEC |Optional QSPEC | 342 | Object ID | Parameters | Parameters | 343 +------------------+-----------------+---------------+ 345 Figure 2: Structure of QSPEC Objects & Control Information 347 4.3 Example of NSLP/QSPEC Operation 349 This Section illustrates the operation and use of the QSPEC within 350 the NSLP. The example configuration in shown in Figure 3. 352 +----------+ /-------\ /--------\ /--------\ 353 | Laptop | | Home | | Cable | | DiffServ | 354 | Computer |-----| Network |-----| Network |-----| Network |----+ 355 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 356 \-------/ \--------/ \--------/ | 357 | 358 +-----------------------------------------------+ 359 | 360 | /--------\ +----------+ 361 | | "X"G | | Handheld | 362 +---| Wireless |-----| Device | 363 | XG QOSM | +----------+ 364 \--------/ 366 Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC 367 Operation 369 In this configuration, a laptop computer and a handheld wireless 370 device are the endpoints for some application that has QoS 371 requirements. Assume initially that the two endpoints are stationary 372 during the application session, later we consider mobile endpoints. 373 For this session, the laptop computer is connected to a home network 374 that has no QoS support. The home network is connected to a 375 CableLabs-type cable access network with dynamic QoS (DQOS) support, 376 such as specified in the 'CMS to CMS Signaling Specification' [CMSS] 377 for cable access networks. That network is connected to a DiffServ 378 core network that uses the RMD QOSM [RMD-QOSM]. On the other side of 379 the DiffServ core is a wireless access network built on generation 380 "X" technology with QoS support as defined by generation "X". And 381 finally the handheld endpoint is connected to the wireless access 382 network. 384 We assume that the Laptop is the QNI and handheld device is the QNR. 386 The QNI will populate an Initiator QSPEC to achieve the QoS desired 387 on the path. As stated in Section 4.2, the QNI MUST support at least 388 one QOSM, but it may not know the QOSM supported by the network. In 389 any case, if the QNI supports only one QOSM, it would normally signal 390 a reservation according to the requirements of that QOSM. 391 Furthermore, the QNI would most likely support the QOSM that matches 392 its functionality. For example, the default QOSM for mobile phones 393 might be the XG-QOSM, while the INTSERV-QOSM might be the default for 394 workstations. 396 Referring to Figure 3, the laptop computer may choose the 397 INTSERV-QOSM because it is connected to a wired network. If the 398 handheld device acts as the QNI, it may choose the XG-QOSM because it 399 is connected to the XG wireless network. On the other hand, a 400 particular QOSM could be configured if a user/administrator knows 401 that some particular QOSM is used. For example, if the laptop 402 computer is connected to the XG network via the XG phone, which acts 403 as a modem, then it reasonable to specify the XG-QOSM since resources 404 are accessed through the XG network, 406 In this example we consider two different ways to perform 407 sender-initiated signaling for QoS: 409 Case 1) The QNI sets , and possibly 410 QSPEC objects in the Initiator QSPEC, and initializes 411 to . Since this is a reservation in a 412 heterogenic network with different QOSMs supported in different 413 domains, each QNE on the path reads and interprets those parameters 414 in the Initiator QSPEC that it needs to implement the QOSM within its 415 domain (as described below). Each QNE along the path checks to see if 416 resources can be reserved, and if not, the QNE 417 reduces the respective parameter values in and 418 reserves these values. The minimum parameter values are given in 419 , if populated, otherwise zero if is not 420 included. If one or more parameters in fails to 421 satisfy the corresponding minimum values in Minimum QoS, the QNE 422 notifies the QNI and the reservation is aborted. Otherwise, the QNR 423 notifies the QNI of the for the reservation. 425 Case 2) The QNI populated the Initiator QSPEC with . 426 Since this is a reservation in a heterogenic network with different 427 QOSMs supported in different domains, each QNE on the path reads and 428 interprets those parameters in the Initiator QSPEC that it needs to 429 implement the QOSM within its domain (as described below). If a QNE 430 cannot reserve resources, the reservation fails. 432 In both cases, the QNI populates mandatory and optional QSPEC to 433 ensure correct treatment of its traffic in domains down the path. 434 Since the QNI does not know the QOSM used in downstream domains, it 435 includes values for those mandatory and optional QSPEC parameters 436 consistent with the QOSM it is populating and any additional 437 parameters it cares about. Let us assume the QNI wants to achieve 438 IntServ-like QoS guarantees, and also is interested in what path 439 latency it can achieve. The QNI therefore includes in the QSPEC the 440 QOSM ID for IntServ Controlled Load Service. The QSPEC objects are 441 populated with all parameters necessary for IntServ Controlled Load 442 and additionally the parameter to measure path latency, as follows: 444 = 445 = 447 In both cases, each QNE on the path reads and interprets those 448 parameters in the Initiator QSPEC that it needs to implement the QOSM 449 within its domain. It may need additional parameters for its QOSM, 450 which are not specified in the Initiator QSPEC. If possible, these 451 parameters must be inferred from those that are present, according to 452 rules defined in the QOSM implemented by this QNE. 454 There are three possibilities when a RESERVE message is received at a 455 QNE at a domain border (we illustrate these possibilities in the 456 example): 458 - the QNE just leaves the QSPEC as-is. 460 - the QNE can stack a local QSPEC on top of the Initiator QSPEC (this 461 is new in QoS NSLP, RSVP does not do this). 463 - the QNE can tunnel the Initiator RESERVE message through its domain 464 and issue its own Local RESERVE message. For this new Local RESERVE 465 message, the QNE acts as the QNI, and the QSPEC in the domain is an 466 Initiator QSPEC. This procedure is also used by RSVP in making 467 aggregate reservations, in which case there is not a new intra-domain 468 (aggregate) RESERVE for each newly arriving interdomain (per-flow) 469 RESERVE, but the aggregate reservation is updated by the border QNE 470 (QNI) as need be. This is also how RMD works [RMD-QOSM]. 472 For example, at the RMD domain, a local RESERVE with its own RMD 473 Initiator QSPEC corresponding to the RMD-QOSM is generated based on 474 the original Initiator QSPEC according to the procedures described in 475 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE 476 to the RMD domain must map the QSPEC parameters contained in the 477 original Initiator QSPEC into the RMD QSPEC. The RMD QSPEC for 478 example needs and . is generated 479 from the parameter. Information on , 480 however, is not provided. According to the rules laid out in the RMD 481 QOSM, the ingress QNE infers from the fact that an IntServ Controlled 482 Load QOSM was signaled that the EF PHB is appropriate to set the parameter. These RMD QSPEC parameters are populated in the 484 RMD Initiator QSPEC generated within the RMD domain. 486 Furthermore, the node at the egress to the RMD domain updates on behalf of the entire RMD domain if it can. If it 488 cannot, it raises the parameter-specific, 'not-supported' flag, 489 warning the QNR that the final value of these parameters in QoS 490 Available is imprecise. 492 In the XG domain, the Initiator QSPEC is translated into a Local 493 QSPEC using a similar procedure as described above. The Local QSPEC 494 becomes the current QSPEC used within the XG domain, that is, the 495 it becomes the first QSPEC on the stack, and the Initiator QSPEC is 496 second. This saves the QNEs within the XG domain the trouble of 497 re-translating the Initiator QSPEC. At the egress edge of the XG 498 domain, the translated Local QSPEC is popped, and the Initiator QSPEC 499 returns to the number one position. 501 If the reservation was successful, eventually the RESERVE request 502 arrives at the QNR (otherwise the QNE at which the reservation failed 503 would have aborted the RESERVE and sent an error RESPONSE back to the 504 QNI). The QNR generates a positive RESPONSE with QSPEC objects - and for case 1 - additionally . The 506 parameters appearing in are the same as in , with values copied from in case 1, and with 508 the original values from in case 2. That is, it is not 509 necessary to transport the object back to the QNI since 510 the QNI knows what it signaled originally, and the information is not 511 useful for QNEs in the reverse direction. The object 512 should transport all necessary information, although the and objects may end up transporting some of 514 the same information. 516 Hence, the QNR populates the following QSPEC objects: 518 = 519 = 521 If the handheld device on the right of Figure 3 is mobile, and moves 522 through different "XG" wireless networks, then the QoS might change 523 on the path since different XG wireless networks might support 524 different QOSMs. As a result, QoS-NSLP/QSPEC processing will have to 525 renegotiate the on the path. From a QSPEC 526 perspective, this is like a new reservation on the new section of the 527 path and is basically the same as any other rerouting event - to the 528 QNEs on the new path it looks like a new reservation. That is, in 529 this mobile scenario, the new segment may support a different QOSM 530 than the old segment, and the QNI would now signal a new reservation 531 (explicitly, or implicitly with the next refreshing RESERVE message) 532 to account for the different QOSM in the XG wireless domain. Further 533 details on rerouting are specified in [QoS-SIG]. 535 For bit-level examples of QSPECs see the documents specifying QOSMs 536 [INTSERV-QOSM, Y.1541-QOSM, RMD-QOSM]. 538 4.4 Treatment of QSPEC Parameters 540 4.4.1 Mandatory and Optional QSPEC Parameters 542 Mandatory and optional QSPEC parameters are defined in this document 543 and are applicable to a number of QOSMs. Mandatory QSPEC parameters 544 are treated as follows: 546 o A QNI SHOULD populate mandatory QSPEC parameters if applicable to 547 the underlying QOSM. 548 o QNEs MUST interpret mandatory QSPEC parameters, if populated. 550 Optional QSPEC parameters are treated as follows: 552 o A QNI SHOULD populate optional QSPEC parameters if applicable to 553 the QOSM for which it is signaling. 555 o QNEs SHOULD interpret optional QSPEC parameters, if populated and 556 applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore 557 the optional QSPEC parameter if it does not support a QOSM needing 558 the optional QSPEC parameter). 560 4.4.2 Read-only and Read-write QSPEC Parameters 562 Both mandatory and optional QSPEC parameters can be read-only or 563 read-write. Read-write parameters can be changed by any QNE, whereas 564 read-only parameters are fixed by the QNI and/or QNR. For example in 565 a RESERVE message, all parameters in are read-write 566 parameters, which are updated by intermediate QNEs. Read-only 567 parameters are, for example, all parameters in as sent 568 by the QNI. 570 QoS description parameters can be both read-only or read-write, 571 depending on which QSPEC object, and which message, they appear in. 572 In particular, all parameters in and are 573 read-only for all messages. More details are provided in Sec. 7.1. 575 In the QSPEC Control Information Object, the property of being 576 read-write or read-only is parameter specific. 578 4.5 Inability to handle parameters 580 A QNE may not be able to interpret or update the QSPEC or individual 581 parameters for several reasons. For example, the QSPEC cannot be 582 read or interpreted because it is erroneous, or because of a QNE 583 fault. This is an error condition. Another reason is that a 584 parameter type is unknown because it is optional, or a parameter 585 value in QoS Available cannot be updated because QoS NSLP was 586 tunneled to the QNE. These are not error conditions. 588 4.5.1 Error Conditions 590 When an RMF cannot interpret the QSPEC because the coding is 591 erroneous, it raises corresponding flags in the QSPEC. The 'error 592 flags' are located in each QSPEC Object and in each parameter. If 593 such a flag is set, at least one QNE along the data transmission path 594 between the QNI and QNR cannot interpret a mandatory or optional 595 QSPEC parameter or the QSPEC object for any reason, such as a 596 protocol error, QNE fault, etc. In this case, more detailed error 597 information may be given in the QoS NSLP error message. That is, if 598 possible the RMF must communicate error details to the QoS NSLP 599 processing. QoS NSLP [QoS-SIG] describes how the erroneous message 600 is handled further. 602 As stated in Section 5.1.3.6 (INFO_SPEC) of [QoS-SIG]: 603 "Values in the error subcode field are defined in each QOSM 604 specification separately. The default value for the subcode is 0x00. 605 A default value means that the QoS model does not want or does not 606 need to give more information about the error/result, anything else 607 in the subcode must be defined in the QoS model specification." 609 That is, any additional error codes beyond those defined in [QoS-SIG] 610 MUST be defined in individual QOSM specifications. 612 When the error can be located in a particular parameter, the QNE 613 detecting the error raises the error flag in this parameter. 614 Additionally, it raises the error flag in the corresponding QSPEC 615 Object. If the error cannot be located at the parameter level, only 616 the error flag in the QSPEC object is raised. 618 4.5.2 Inability to interpret and update parameters 620 When the QOSM ID is not known to a QNE, it MUST interpret at least 621 the mandatory parameters. 623 Each optional QSPEC parameter has an associated 'not-supported flag'. 624 If the not-supported flag is set, then at least one QNE along the 625 data transmission path between the QNI and QNR can not support the 626 specified optional parameter, or perhaps the parameter type is 627 understood but the particular parameter value is not standardized. 628 This means the value collected in the corresponding parameter is a 629 lower bound to the "real" value. A QNE MUST be able to set the 630 not-supported flag if it does not support the optional parameter. 632 Each QSPEC parameter has an associated 'tunneled-parameter flag'. 633 When a RESERVE message is tunneled through a domain, QNEs inside the 634 domain cannot update read-write parameters. The egress QNE in a 635 domain has two choices: either it is configured to have the knowledge 636 to update the parameters correctly. Or it cannot update the 637 parameters. In this case it MUST set the tunneled-parameter flag to 638 tell the QNI (or QNR) that the information contained in the 639 read-write parameter is most likely incorrect (or a lower bound). 641 The formats and semantics of all flags are given in Section 6.1. 643 4.6 QSPEC Extensibility 645 Additional optional QSPEC parameters MAY need to be defined in the 646 future. Additional optional QSPEC parameters are defined in separate 647 Informational documents specific to a given QOSM. For example, 648 optional QSPEC parameters are defined in [RMD-QOSM] and 649 [Y.1541-QOSM]. 651 5. QSPEC Format Overview 653 QSPEC = 654 656 As described above, the QSPEC contains an identifier for the QOSM, 657 the actual resource description (QoS description) as well as QSPEC 658 control information. Note that all QSPEC parameters defined in the 659 following Sections are mandatory QSPEC parameters unless specifically 660 designated as optional QSPEC parameters. 662 A QSPEC object ID identifies whether the object is or . As described below, the is further broken down into , , , and objects. A QSPEC 666 parameter ID is assigned to identify each QSPEC parameter defined 667 below. 669 identifies the QSPEC version number, and 670 identifies the particular QOSM being used by the QNI. The 671 tells a QNE which parameters to expect. This may simplify processing 672 and error analysis. Furthermore, it may be helpful for a QNE or a 673 domain supporting more than one QOSM to learn which QOSM the QNI 674 would like to have in order to use the most suitable QOSM. Even if a 675 QNE does not support the QOSM it MUST interpret at least the 676 mandatory parameters. Note that more parameters than required by the 677 QOSM can be included by the QNI. QSPEC version and QOSM IDs are 678 assigned by IANA. 680 5.1 QSPEC Control Information 682 QSPEC control information is used for signaling QOSM RMF functions 683 not defined in QoS-NSLP. It enables building new RMF functions 684 required by a QOSM within a QoS-NSLP signaling framework, such as 685 specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. 687 = 689 Note that is a read-write parameter. is a read-only parameter. 692 is a flag bit telling the QNR (or QNI in a RESPONSE 693 message) whether or not a particular QOSM is supported by each QNE 694 in the path between the QNI and QNR. A QNE sets the 695 flag parameter if it does not support the relevant QOSM 696 specification. If the QNR finds this bit set, at least one QNE along 697 the data transmission path between the QNI and QNR can not support 698 the specified QOSM.In a local QSPEC, refers to the 699 QoS-NSLP peers of the local QOSM domain. 701 The parameter describes how the QNE will process 702 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 703 be dropped, shaped and/or remarked. The excess treatment parameter is 704 initially set by the QNI and is read-only. 706 5.2 QoS Description 708 The QoS Description is broken down into the following QSPEC objects: 710 = 711 713 Of these QSPEC objects, QoS Desired, QoS Available and QoS Reserved 714 MUST be supported by QNEs. Minimum QoS MAY be supported. 716 5.2.1 718 = 719 721 These parameters describe the resources the QNI desires to reserve 722 and hence this is a read-only QSPEC object. The 723 resources that the QNI wishes to reserve are of course directly 724 related to the traffic the QNI is going to inject into the network. 725 Therefore, when used in the object, refers to traffic injected by the QNI into the network. 728 = 730 = link bandwidth needed by flow [RFC 2212, RFC 2215] 732 =

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