idnits 2.17.1 draft-ietf-nsis-qspec-11.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 3097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3087. ** 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 : ---------------------------------------------------------------------------- == 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 (August 2006) is 6462 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: 'MTU' is mentioned on line 2350, but not defined == Missing Reference: 'Ctot' is mentioned on line 2505, but not defined == Missing Reference: 'Dtot' is mentioned on line 2513, but not defined == Missing Reference: 'Csum' is mentioned on line 2521, but not defined == Missing Reference: 'Dsum' is mentioned on line 2529, but not defined == Missing Reference: 'S' is mentioned on line 2549, but not defined == Unused Reference: 'RFC1832' is defined on line 2821, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 2856, but no explicit reference was found in the text == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2861, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-1' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-2' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSCP-REGISTRY' -- Possible downref: Non-RFC (?) normative reference: ref. 'PHBID-CODES-REGISTRY' -- Possible downref: Non-RFC (?) normative reference: ref. 'GIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 3290 -- Duplicate reference: RFC3181, mentioned in 'RFC2434', was also mentioned in 'RFC3181'. Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 15 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: February 2007 Ericsson 6 Cornelia Kappler 7 Siemens AG 9 August 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 August, 2007. 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 document defines a template 48 for the QSPEC, which contains both the QoS description and QSPEC 49 control information. The QSPEC format is defined, as are a number of 50 QSPEC parameters. The QSPEC-1 parameters provide a common language 51 to be re-used in several QOSMs. QSPEC-2 parameters aim to ensure 52 the extensibility of QoS NSLP to other QOSMs in the future. To a 53 certain extent QSPEC parameters ensure interoperability of QOSMs. 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. QOSM Concept & QOSM Specification Requirements, QSPEC Objects & 64 Parameters, QSPEC Processing, QSPEC Extensibility . . . . . . . 8 65 4.1 QOSM Concept & Specification Requirements . . . . . . . . . 8 66 4.2 QSPEC Objects & Parameters . . . . . . . . . . . . . . . . 10 67 4.2.1 QSPEC Objects . . . . . . . . . . . . . . . . . . . . 10 68 4.2.2 QSPEC Parameters . . . . . . . . . . . . . . . . . . 11 69 4.2.2.1 QSPEC-1 and QSPEC-2 Parameters . . . . . . . 11 70 4.2.2.2 Read-only and Read-write QSPEC Parameters . . 11 71 4.3 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 12 72 4.3.1 Interpreting QSPEC Parameters . . . . . . . . . . . . 12 73 4.3.2 QSPEC Stacking . . . . . . . . . . . . . . . . . . . 13 74 4.3.3 Reservation Success/Failure, QSPEC Error Codes, & 75 INFO_SPEC Notification . . . . . . . . . . . . . . . 15 76 4.3.3.1 Reservation Failure & Error E-Flag . . . . . 16 77 4.3.3.2 Non-QOSM-Hop Q-Flag & Remapped QSPEC 78 Parameter R-flag . . . . . . . . . . . . . . 17 79 4.3.3.3 QSPEC Parameter Not Supported N-Flag . . . . 17 80 4.3.3.4 INFO_SPEC Coding of Reservation Outcome . . . 18 81 4.3.3.5 QNE Generation of a RESPONSE message . . . . 18 82 4.3.3.6 Special Cases of QSPEC Stacking . . . . . . . 20 83 4.3.4 Example of QSPEC Processing . . . . . . . . . . . . 20 84 4.4 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 23 85 5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 24 86 5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 25 87 5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 26 88 5.2.1 . . . . . . . . . . . . . . . . . . . . 26 89 5.2.2 . . . . . . . . . . . . . . . . . . . 27 90 5.2.3 . . . . . . . . . . . . . . . . . . . 30 91 5.2.4 . . . . . . . . . . . . . . . . . . . . 30 92 6. QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . . . 30 93 6.1 Sender-Initiated Reservations . . . . . . . . . . . . . . . 31 94 6.2 Receiver-Initiated Reservations . . . . . . . . . . . . . . 32 95 6.3 Resource Queries . . . . . . . . . . . . . . . . . . . . . 34 96 6.4 Bidirectional Reservations . . . . . . . . . . . . . . . . 34 97 6.5 Preemption . . . . . . . . . . . . . . . . . . . . . . . . 35 98 7. QSPEC Functional Specification . . . . . . . . . . . . . . . . 35 99 7.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 35 100 7.2 QSPEC-1 Parameter Coding . . . . . . . . . . . . . . . . . 38 101 7.2.1 Parameter . . . . . . . . . . . . . . 38 102 7.2.2 Parameter . . . . . . . . . . . . . . . . . . . 40 103 7.2.2.1 Sub-Parameter . . . . . . . . . . 40 104 7.2.2.2 Sub-Parameters . . . . . . . 41 105 7.2.3 Parameter . . . . . . . . . . . . . . . . 41 106 7.2.3.1 Sub-Parameter . . . . . . . . . . 42 107 7.2.3.2 Sub-Parameter . . . . . . . 43 108 7.2.3.3 Sub-Parameter . . . . . . 43 109 7.2.4 Parameter . . . . . . . . . . . . . . . . 44 110 7.2.4.1 & 111 Sub-Parameters . . . . . . . . . . . . . . . 45 112 7.2.4.2 Sub-Parameter . . . . . 45 113 7.2.4.3 Sub-Parameter . . . . . . . . 46 114 7.3 QSPEC-2 Parameter Coding . . . . . . . . . . . . . . . . . 47 115 7.3.1 Parameter . . . . . . . . . . . . . 47 116 7.3.2 Parameter . . . . . . . . . . . . . . 47 117 7.3.3 Parameter . . . . . . . . . . . . . . . 48 118 7.3.4 Parameter . . . . . . . . . . . . . . . . 49 119 7.3.5 Parameter . . . . . . . . . . . . . . . . 49 120 7.3.6 Parameters . . . . . . . 50 121 7.3.7 Parameter . . . . . . . . . . . . . . . 51 122 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 51 123 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 51 124 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 125 11. Normative References . . . . . . . . . . . . . . . . . . . . . 56 126 12. Informative References . . . . . . . . . . . . . . . . . . . . 57 127 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 58 128 Appendix A: Mapping of QoS Desired, QoS Available & QoS Reserved 129 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 58 130 Appendix B: Main Changes Since Last Version & Open Issues . . . . 59 131 B.1 Main Changes Since Version -04 . . . . . . . . . . 59 132 B.2 Open Issues . . . . . . . . . . . . . . . . . . . 61 133 Intellectual Property Statement . . . . . . . . . . . . . . . . . 61 134 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 61 135 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 62 137 Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 1. Contributors 145 This document is the result of the NSIS Working Group effort. In 146 addition to the authors/editors listed in Section 13, the following 147 people contributed to the document: 149 Chuck Dvorak 150 AT&T 151 Room 2A37 152 180 Park Avenue, Building 2 153 Florham Park, NJ 07932 154 Phone: + 1 973-236-6700 155 Fax:+1 973-236-7453 156 Email: cdvorak@att.com 158 Yacine El Mghazli 159 Alcatel 160 Route de Nozay 161 91460 Marcoussis cedex 162 FRANCE 163 Phone: +33 1 69 63 41 87 164 Email: yacine.el_mghazli@alcatel.fr 166 Georgios Karagiannis 167 University of Twente 168 P.O. BOX 217 169 7500 AE Enschede 170 The Netherlands 171 Email: g.karagiannis@ewi.utwente.nl 173 Andrew McDonald 174 Siemens/Roke Manor Research 175 Roke Manor Research Ltd. 176 Romsey, Hants SO51 0ZN 177 UK 178 Email: andrew.mcdonald@roke.co.uk 180 Al Morton 181 AT&T 182 Room D3-3C06 183 200 S. Laurel Avenue 184 Middletown, NJ 07748 185 Phone: + 1 732 420-1571 186 Fax: +.1 732 368-1192 187 Email: acmorton@att.com 189 Percy Tarapore 190 AT&T 191 Room D1-33 192 200 S. Laurel Avenue 193 Middletown, NJ 07748 194 Phone: + 1 732 420-4172 195 Email: tarapore@.att.com 197 Lars Westberg 198 Ericsson Research 199 Torshamnsgatan 23 200 SE-164 80 Stockholm, Sweden 201 Email: Lars.Westberg@ericsson.com 203 2. Introduction 205 The QoS NSIS signaling layer protocol (NSLP) [QoS-SIG] establishes 206 and maintains state at nodes along the path of a data flow for the 207 purpose of providing forwarding resources (QoS) for that flow. The 208 design of QoS NSLP is conceptually similar to RSVP [RFC2205], and 209 meets the requirements of [RFC3726]. 211 A QoS-enabled domain supports a particular QoS model (QOSM), which is 212 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 213 provisioning methods and a QoS architecture. It defines the behavior 214 of the resource management function (RMF) defined in [QoS-SIG], 215 including inputs and outputs. 217 The QoS NSLP protocol is used to signal QoS reservations and supports 218 signaling for different QOSMs, such as for IntServ, DiffServ 219 admission control, and those specified in [Y.1541-QOSM, CL-QOSM, 220 RMD-QOSM]. All information specific to a QOSM is encapsulated in 221 the QoS specification (QSPEC) object, which is QOSM specific, and 222 this document defines a template for the QSPEC. A particular QOSM 223 specifies a) a set of QSPEC-1 and QSPEC-2 parameters, and b) how the 224 QSPEC information is interpreted by the RMF with respect to the QoS 225 description, resources desired, resources available, and control 226 information. Here 'interpret' means that the RMF either a) strictly 227 interprets a QSPEC parameter, as specified in normative, referenced 228 procedures, or b) remaps or otherwise does not strictly interpret the 229 parameter, as specified in QOSM specification documents. In the 230 latter case, for example, a token bucket parameter may be simply 231 interpreted by the RMF as bandwidth. 233 Since QoS NSLP signaling operation can be different for different 234 QOSMs, the QSPEC contains two kinds of information, QSPEC control 235 information and QoS description. QSPEC control information contains 236 parameters that governs the behavior of the RMF. An example of QSPEC 237 control information is how the excess traffic is treated in the RMF 238 queuing functions. The QoS description parameters include, for 239 example, parameters, such as and 240 , and constraints parameters, such as and 241 . 243 The QoS description is composed of QSPEC objects loosely 244 corresponding to the TSpec, RSpec and AdSpec objects specified in 245 RSVP. This is, the QSPEC may contain a description of QoS desired 246 and QoS reserved. It can also collect information about available 247 resources. Going beyond RSVP functionality, the QoS description 248 also allows indicating a range of acceptable QoS by defining a QSPEC 249 object denoting minimum QoS. Usage of these QSPEC objects is not 250 bound to particular message types thus allowing for flexibility. 251 A QSPEC object collecting information about available resources may 252 travel in any QoS NSLP message, for example a QUERY message or a 253 RESERVE message. The QSPEC travels in QoS NSLP messages but is 254 opaque to the QoS NSLP, and is only interpreted by the RMF. 256 Interoperability between QoS NSIS entities (QNEs) in different 257 domains that implement different QOSMs is enhanced (but not 258 guaranteed) by the definition of a common set of QSPEC-1 and 259 QSPEC-2 parameters. QSPEC-1 parameters in the QSPEC must be 260 interpreted by all QNEs in the path, independent of which QOSM they 261 support. This way, NSIS provides a mechanism for interdomain QoS 262 signaling and interworking. QSPEC-2 parameters, in contrast, may be 263 skipped if not understood. Additional QSPEC-2 parameters can be 264 defined by QOSM specification documents, and thereby ensure the 265 extensibility and flexibility of QoS NSLP. 267 A QoS NSIS initiator (QNI) initiating the QoS NSLP signaling adds an 268 initiator QSPEC object containing parameters describing the desired 269 QoS based on the QOSM it supports. A local QSPEC can be stacked on 270 the initiator QSPEC to accommodate different QOSMs being used in 271 different domains. A domain supporting a different local QOSM than 272 the QNI can interpret the initiator QSPEC and stack a local QSPEC 273 to meet the local QOSM requirements. If the local domain cannot 274 fully interpret the initiator QSPEC, it can flag the condition and 275 either continue to forward the reservation or possibly reject the 276 reservation. 278 Thus, one of the major differences between RSVP and QoS NSLP is that 279 QoS NSLP supports signaling for different QOSMs along the data path, 280 all with one signaling message. For example, the data path may start 281 in a domain supporting DiffServ and end in a domain supporting 282 Y.1541. The ability to achieve end-to-end QoS through multiple 283 Internet domains is also an important requirement, and illustrated 284 in this document. 286 3. Terminology 288 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 289 any QNE. Together with a description of QoS Desired or QoS 290 Available, it allows the QNI to specify a QoS range, i.e. an upper 291 and lower bound. If the QoS Desired cannot be reserved, QNEs are 292 going to decrease the reservation until the minimum QoS is hit. 294 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 296 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 298 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 300 QoS Description: Describes the actual QoS in QSPEC objects QoS 301 Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC 302 objects are input or output parameters of the RMF. In a valid QSPEC, 303 at least one QSPEC object of the type QoS Desired, QoS Available or 304 QoS Reserved MUST be included. 306 QoS Available: QSPEC object containing parameters describing the 307 available resources. They are used to collect information along a 308 reservation path. 310 QoS Desired: QSPEC object containing parameters describing the 311 desired QoS for which the sender requests reservation. 313 QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g., 314 IntServ Controlled Load. A QOSM specifies a set of QSPEC-1 and 315 QSPEC-2 parameters that describe the QoS and how resources 316 will be managed by the RMF. It furthermore specifies how to use QoS 317 NSLP to signal for this QOSM. 319 QoS Reserved: QSPEC object containing parameters describing the 320 reserved resources and related QoS parameters, for example, 321 bandwidth. 323 QSPEC Control Information: Control information that is specific to a 324 QSPEC, and contains parameters that govern the RMF. 326 QSPEC: QSPEC is the object of QoS NSLP containing all QOSM-specific 327 information. 329 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 330 QoS description and QSPEC control information parameters, for 331 example, bandwidth, token bucket, and excess treatment parameters. 333 QSPEC Object: Main building blocks of QoS Description containing a 334 QSPEC parameter set that is input or output of an RMF operation. 336 QSPEC-1 parameter: QSPEC parameter that a QNI SHOULD populate if 337 applicable to the underlying QOSM and a QNE MUST interpret, if 338 populated. 340 QSPEC-2 parameter: QSPEC parameter that a QNI SHOULD populate if 341 applicable to the underlying QOSM, and a QNE SHOULD interpret if 342 populated and applicable to the QOSM(s) supported by the QNE. (A QNE 343 MAY ignore if it does not support a QOSM needing the QSPEC-2 344 parameter). 346 Resource Management Function (RMF): Functions that are related to 347 resource management, specific to a QOSM. It processes the QoS 348 description parameters and QSPEC control parameters. 350 Read-only Parameter: QSPEC Parameter that is set by initiating or 351 responding QNE and is not changed during the processing of the QSPEC 352 along the path. 354 Read-write Parameter: QSPEC Parameter that can be changed during the 355 processing of the QSPEC by any QNE along the path. 357 4. QOSM Concept & QOSM Specification Requirements, QSPEC Objects & 358 Parameters, QSPEC Processing, QSPEC Extensibility 360 The general framework for the QoS NSLP is that [QoS-SIG] defines QoS 361 signaling and semantics, the QSPEC template defines the container and 362 semantics for QoS parameters and objects, and QOSM specifications 363 define QoS methods and procedures for using QoS signaling and 364 QSPEC parameters/objects within specific QoS deployments. QoS NSLP 365 is a generic QoS signaling protocol that can signal for many QOSMs. 367 4.1 QOSM Concept & QOSM Specification Requirements 369 A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ 370 controlled load [CL-QOSM], resource management with DiffServ 371 [RMD-QOSM), and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM]. 372 A QOSM specifies a set of QSPEC-1 and QSPEC-2 parameters that 373 describe the QoS and how resources will be managed by the RMF. It 374 furthermore specifies how to use QoS NSLP to signal for this QOSM. 375 The QSPEC is the object of QoS NSLP containing all QOSM-specific 376 information, and contains QSPEC objects and parameters. QSPEC 377 objects are the main building blocks of the QoS description 378 containing a QSPEC parameter set that is input or output of an RMF 379 operation. QSPEC parameters are the parameters appearing in a QSPEC, 380 which include both QoS description parameters (e.g., bandwidth) and 381 QSPEC control information parameters (e.g., excess treatment). The 382 RMF implements functions that are related to resource management, 383 specific to a QOSM. It processes the QoS description parameters and 384 QSPEC control information parameters. 386 The QOSM specification includes how the requested QoS resources will 387 be described and how they will be managed by the RMF. For this 388 purpose, the QOSM specification defines a set of QSPEC-1 and QSPEC-2 389 parameters it uses to describe the desired QoS and QoS resource 390 control in the RMF, and it may define additional QSPEC-2 parameters. 391 QSPEC-1 parameters provide a common language for QOSM developers to 392 build their QSPECs and are likely to be re-used in several QOSMs. 393 QSPEC-1 parameters are populated by a QNI if they are applicable to 394 the underlying QOSM the QNI supports and that a QNE must interpret, 395 if populated. QSPEC-2 parameters are populated by a QNI if they are 396 applicable to the underlying QOSM a QNI supports, and a QNE should 397 interpret if populated and applicable to the QOSM(s) supported by the 398 QNE. Note that a QNE may ignore a QSPEC-2 parameter if it does not 399 support a QOSM needing the QSPEC-2 parameter. QSPEC-1 and QSPEC-2 400 parameters are defined in this document, and additional QSPEC-2 401 parameters may be defined in separate QOSM specification documents. 402 For example, QSPEC-2 parameters are defined in [RMD-QOSM] and 403 [Y.1541-QOSM]. The set of QSPEC-1 parameters in NSIS is based on 404 DiffServ and IntServ/RSVP. Note that in effect all parameters are 405 QSPEC-1 in RSVP since it does not have the QSPEC-1/QSPEC-2 concept. 407 In this document the term 'interpret' means, in relation to RMF 408 processing of QSPEC parameters, either that the RMF a) strictly 409 interprets a QSPEC parameter, or b) remaps, approximates, or 410 otherwise does not strictly interpret the parameter. Furthermore, 411 the terminology 'strictly interpret' means that the QSPEC parameter 412 is processed by the RMF according to the commonly accepted normative 413 procedures specified by references given for each QSPEC parameter. 414 Otherwise the QSPEC parameter may be remapped or approximately 415 interpreted. For example a token bucket parameter may be remapped to 416 bandwidth and simply interpreted by the RMF as bandwidth. Note also 417 that a QNE must interpret a QSPEC-1 parameter only if it is populated 418 in the QSPEC object by the QNI. If a QSPEC-1 parameter is not there 419 in the QSPEC, the QNE does not interpret it of course. To test 420 compliance, however, a QNE would need to be tested that it properly 421 implements/interprets all QSPEC-1 parameters. 423 A QNE MUST support at least one QOSM. A QoS-enabled domain supports 424 a particular QOSM, and the QNEs in the domain MUST also support the 425 QOSM. 427 A QOSM specification MUST include the following: 429 - role of QNEs, e.g., location, frequency, statefulness, etc. 430 - QSPEC definition including QOSM ID, QSPEC parameters 431 - QSPEC procedures applicable to this QOSM 432 - QNE processing rules describing how QSPEC information is treated 433 and interpreted in the RMF and QOSM specific processing. E.g., 434 admission control, scheduling, policy control, QoS parameter 435 accumulation (e.g., delay). 436 - QSPEC example to include at least one bit-level QSPEC example. 437 - QSPEC parameter behavior for new QSPEC-2 parameters the QOSM 438 specification defines 439 - QSPEC parameter behavior for remapping of existing QSPEC 440 parameters, as described in Section 4.3.1. Remapping may result 441 in slight modification to the intended specification when strict 442 interpretation is not possible. Unless otherwise specified in the 443 QOSM specification document, the default QOSM behaviors for all 444 QSPEC-1 parameters is to strictly interpret the QSPEC-1 parameters 445 as defined in this document through the references that precisely 446 define the QSPEC parameter behaviors. 447 - define what happens in case of preemption if the default QNI 448 behavior (tear down preempted reservation) is not followed (see 449 Section 6.5) 451 A QOSM specification MAY include the following: 453 - QOSM-specific control information parameters and processing rules 454 for those parameters 455 - define additional QOSM-specific error codes, as discussed in 456 Section 4.3.3.4 457 - specify the conditions for a QNI rejecting a reservation when the 458 non-QOSM-hop Q-flag and remapped QSPEC parameter R-flags are sent 459 back in the RESPONSE message (in the absence of such procedures, 460 the default condition is 'success' if all QSPEC parameters are met 461 and 'reservation failure' if one or more QSPEC parameters are not 462 met) 464 4.2 QSPEC Objects & Parameters 466 4.2.1 QSPEC Objects 468 This document provides a template for the QSPEC, which is needed in 469 order to help define individual QOSMs and in order to promote 470 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 471 is composed of QSPEC control information and QoS description. QoS 472 description in turn is composed of up to four QSPEC objects (not all 473 of them need to be present), namely QoS Desired, QoS Available, QoS 474 Reserved and Minimum QoS. Each of these QSPEC Objects, as well as 475 QSPEC Control Information, consists of a number of QSPEC-1 and 476 QSPEC-2 parameters. 478 +-------------+---------------------------------------+ 479 |QSPEC Control| QoS | 480 | Information | Description | 481 +-------------+---------------------------------------+ 483 \________________ ______________________/ 484 V 485 +----------+----------+---------+-------+ \ 486 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC 487 +----------+----------+---------+-------+ / Objects 489 \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/ 490 V V V V V 492 +-------------+... +-------------+... 493 |QSPEC Para. 1| |QSPEC Para. n| 494 +-------------+... +-------------+... 496 Figure 1: Structure of the QSPEC 498 The internal structure of each QSPEC object and the QSPEC control 499 information, with QSPEC-1 and QSPEC-2 parameters, is illustrated 500 in Figure 2. 502 +------------------+-----------------+------------------+ 503 | QSPEC/Ctrl Info | QSPEC-1 | QSPEC-2 | 504 | Object ID | Parameters | Parameters | 505 +------------------+-----------------+------------------+ 507 Figure 2: Structure of QSPEC Objects & Control Information 509 4.2.2 QSPEC Parameters 511 4.2.2.1 QSPEC-1 and QSPEC-2 Parameters 513 QSPEC-1 and QSPEC-2 parameters are defined in this document and are 514 applicable to a number of QOSMs. QSPEC-1 parameters are treated as 515 follows: 517 o A QNI SHOULD populate QSPEC-1 parameters if applicable to the 518 underlying QOSM. 519 o QNEs/QNR MUST interpret QSPEC-1 parameters, if signaled. 521 QSPEC-2 parameters are treated as follows: 523 o A QNI SHOULD populate QSPEC-2 parameters if applicable to the QOSM 524 for which it is signaling. 526 o QNEs/QNR SHOULD interpret QSPEC-2 parameters, if signaled and 527 applicable to the QOSM(s) supported by the QNE/QNR. (A QNE/QNR MAY 528 ignore the QSPEC-2 parameter if it does not support a QOSM needing 529 the QSPEC-2 parameter). 531 Note that the QNI referred to above can be an ingress QNE in a local 532 domain initiating a local QSPEC object. When there are two stacked 533 QSPECs in a local domain, the QNEs in the interior local domain need 534 only process the local (topmost) QSPEC and can ignore the initiator 535 (bottom) QSPEC. However, edge QNEs in the local domain indeed must 536 interpret the QSPEC-1 parameters populated in the initiator 537 QSPEC. 539 This specification defines 4 QSPEC-1 parameters: , 540 , , and . The coding for these 541 parameters is specified in Section 7.2. This specification also 542 defines 10 QSPEC-2 parameters, and the coding for these parameters 543 is specified in Section 7.3. 545 4.2.2.2 Read-only and Read-write QSPEC Parameters 547 Both QSPEC-1 and QSPEC-2 parameters can be read-only or read-write. 548 Read-write parameters can be changed by any QNE, whereas read-only 549 parameters are fixed by the QNI and/or QNR. For example in a RESERVE 550 message, all parameters in the QoS Available object are read-write 551 parameters, which are updated by intermediate QNEs. Read-only 552 parameters are, for example, all parameters in the QoS Desired 553 object as sent by the QNI. 555 QoS description parameters can be either read-only or read-write, 556 depending on which QSPEC object, and which message, they appear in. 557 In particular, all parameters in the QoS Desired object, QoS 558 Reserved\ object, and Minimum QoS object are read-only for all 559 messages. All parameters in the QoS Available object are normally 560 read-write parameters. However, the parameters in the QoS 561 Available object are read-write when the QoS Available object 562 appears for the first time e.g. in the RESERVE message or QUERY 563 message from QNI to QNR. However, on its way back, all parameters in 564 the object are read-only, e.g., in the RESPONSE 565 message or RESERVE message from QNR to QNI. This is because on its 566 way back the QoS Available object just transports the information it 567 collected before. 569 In the QSPEC control information object, the property of being 570 read-write or read-only is parameter specific. Note that the only 571 control information parameter specified in this document is the 572 parameter, which is a read-only parameter. 574 4.3 QSPEC Processing 576 The QSPEC is opaque to the QoS NSLP processing, as described in 577 [QoS-SIG]. The QSPEC control information and the QoS description are 578 interpreted by the QNE's RMF and may be modified by the RMF. This 579 section discusses QSPEC processing and how the QNE/RMF interprets 580 QSPEC parameters, stacks QSPECs, determines reservation 581 success/failure, and signals QSPEC errors and INFO_SPEC 582 notifications. An example of QSPEC processing is given in the final 583 sub-section. 585 4.3.1 Interpreting QSPEC Parameters 587 The QSPEC contains a QOSM ID that identifies which QOSM is being 588 signaled by the QNI. If a QSPEC arrives at a QNE that does not 589 support the QOSM being signaled, it must still interpret the QSPEC 590 content, at least to a basic degree, since QSPEC-1 parameters have 591 been defined as a common language for interoperability of different 592 QOSMs being support in different domains. That is, a QNE must at 593 least interpret all the QSPEC-1 parameters in a QSPEC even if it does 594 not support the corresponding QOSM. 596 Hence a QNE must either a) strictly interpret a QSPEC parameter, or 597 b) remap, approximate, or otherwise not strictly interpret the QSPEC 598 parameter. Here 'strictly interpret' means that the parameter is 599 implemented by the QNE/RMF according to the commonly accepted 600 procedures as specified by references given for each QSPEC parameter 601 in this document. In the latter case of a remapped QSPEC parameter, 602 the QNE/RMF must raise the remapped parameter R-flag and non-QOSM-hop 603 Q-flag defined in Section 4.3.3.2, and the remapping must be 604 specified in the QOSM specification. For example, in case a), a 605 parameter must be strictly interpreted as a token 606 bucket, and in case b), a parameter may be remapped to 607 a parameter. 609 In the latter case b), the remapping of the to 610 must be specified in the QOSM specification document. 612 For example, QOSM X exclusively uses the parameter . It 613 must define a mapping of the QSPEC-1 parameter . 614 The mapping consists of interpreting the Token Bucket Rate as 615 the parameter and disregarding the other Token Bucket 616 parameters. Clearly, some information contained in the parameter is lost by this mapping, and the resulting QoS may 618 not be quite what was intended by the QNI. Therefore, QOSM X also 619 specifies that the non-QOSM-hop Q-flag be raised. Thus, a QNE using 620 QOSM X is able to make an informed decision whether to admit a 621 reservation described in terms of , and at the same 622 time (by means of the non-QOSM-hop Q-flag) signals to the QNI/QNR 623 that the exact intention of the QNI may not be met. 625 Other examples of remapping QSPEC-1 parameters are as follows: 627 - : bandwidth remapped to token bucket rate and the other 628 token bucket parameters set to zero or some large value 629 - : DSTE QoS class to PHB QoS class 630 - : Y.1541 QoS class remapped to PHB QoS class 631 - : admission/RPH = high priority remapping to 632 admission/RPH = normal priority 634 Remapping between different QSPEC-1 parameter types, e.g., from to , is more complex but is allowed if defined in the 636 QOSM specification document. If a remapping for a QSPEC-1 parameter 637 is not defined in the QOSM specification document, the default is 638 that the QOSM must strictly interpret the QSPEC-1 parameter. 640 Editor's note: We should have a separate document that defines 641 typical remapping of QSPEC parameters, perhaps included in a QOSM 642 definition document. This is to avoid misinterpretation of what is 643 allowed by remapping QSPEC parameters. 645 Editor's note: Based on list discussions we may need to allow a QOSM 646 in justifiable cases to ignore a QSPEC-1 parameter. One example 647 given is that some parameters may be illegal (e.g., preemption in the 648 U.S. PSTN). In other cases a QOSM may simply not want to support a 649 QSPEC-1 parameter. In the latter case justification may be more 650 Difficult, however there is a filter on reasonableness in that QOSM 651 specifications must be reviewed and approved by the IETF. 653 4.3.2 QSPEC Stacking 655 A QoS NSLP message can contain a stack of at most two QSPECs. The 656 first on the stack is the initiator QSPEC. This is a QSPEC provided 657 by the QNI, which travels end-to-end, and therefore the stack always 658 has at least depth 1. QSPEC parameters MUST NOT be deleted from or 659 added to the initiator QSPEC. In addition, the stack MAY contain a 660 local QSPEC stacked on top of the initiator QSPEC. A QNE only 661 considers the topmost QSPEC. 663 A QNE at the edge of a local domain may either a) translate the 664 initiator QSPEC into a local QSPEC and stack the local QSPEC on top 665 of the initiator QSPEC in the RESERVE message, or b) tunnel the 666 initiator QSPEC through the local domain and reserve resources by 667 generating a new RESERVE message through the local domain containing 668 the local QSPEC. In either case the initiator QSPEC parameters are 669 interpreted at the local domain edges. 671 Therefore when reserving resources with a RESERVE message, a local 672 QSPEC MAY be pushed on the stack at the ingress edge of a local QoS 673 domain, in order to describe the requested resources in a 674 domain-specific manner. Here the terms 'ingress' and 'egress' refer 675 to the direction of the RESERVE message rather than the direction of 676 the flow. Also, the local QSPEC is popped from the stack at the 677 egress edge of the local QoS domain. When a RESPONSE message 678 corresponding to the RESERVE message arrives on its way back at the 679 egress edge, a local QSPEC MUST again be generated, describing the 680 reserved resources in a domain-specific manner. This local QSPEC is 681 popped from the stack at the ingress edge. 683 A domain supporting a different local QOSM than the initiator (QNI) 684 domain inspects all QSPEC-1 parameters and consults its local QOSM as 685 to how to interpret these parameters and decides whether it can 686 accommodate the flow. This analysis can have these various outcomes: 688 a) RMF determines that it can accommodate the flow with the QoS 689 specified by the QNI, 690 b) RMF determines that some initiator QSPEC parameters cannot be 691 satisfied with the available resources, and marks the appropriate 692 error flags (see Section 4.3.3), but does not reject the 693 reservation, or 694 c) RMF determines that some initiator QSPEC parameters cannot be 695 satisfied with the available resources, marks the appropriate 696 error flags (see Section 4.3.3), and also rejects the reservation. 697 The QNE also in any event sets the non-QOSM-hop Q-flag, as 698 described in Section 4.3.3.2. 700 When a reservation is successful, the information is passed from the 701 RMF to QoS NSLP processing and translated into the QoS NSLP INFO_SPEC 702 code class 'success' [QoS-SIG]. 704 QNEs generating a local QSPEC have two possible approaches to 705 processing the QSPEC-1 parameters in the initiator QSPEC: 707 a) The local QSPEC includes all QSPEC-1 parameters in the initiator 708 QSPEC (possibly remapped according to the local QOSM). For 709 example, the initiator QSPEC specifies a token bucket parameter, 710 and it is remapped into the bandwidth parameter in the local 711 QSPEC. The ingress QNE in the local domain does not populate 712 the token bucket parameter in the local QSPEC, rather it populates 713 the bandwidth parameter is the local QSPEC and stacks the local 714 QSPEC on top of the initiator QSPEC. The local QSPEC is 715 interpreted by the QNEs in the local domain, and the egress QNE in 716 the local domain pops the local QSPEC and populates token bucket 717 in the initiator QSPEC with just the bandwidth parameter for the 718 token bucket (and not the other token bucket parameters). Note 719 that without QSPEC stacking, all QNEs must do this same thing in 720 the local domain, that is, interpret all QSPEC-1 parameters in the 721 initiator QSPEC, which would include remapping the token bucket 722 parameter to the bandwidth parameter. 724 b) The local QSPEC does not include all QSPEC-1 parameters in the 725 initiator QSPEC, but the egress QNE in the local domain has 726 information configured that allows it to update/process the 727 QSPEC-1 parameters in the initiator QSPEC accordingly. In this 728 case the local QSPEC may carry neither the bandwidth nor token 729 bucket in the above example, if the egress QNE in the local domain 730 has some other means to interpret the token bucket parameter of 731 the initiator QSPEC (e.g., local data base or controller). 732 For example, in a DiffServ domain with a bandwidth broker, the 733 bandwidth broker could inform the egress QNE, or if RSVP is used 734 in the local domain, the information could be obtained from RSVP, 735 or if it is an MPLS domain where LSPs have a particular bandwidth, 736 then the egress QNE knows what is available by counting the 737 reservations that come out of the tunnel. Normally the egress QNE 738 in the local domain interprets the initiator QSPEC parameters, 739 since doing this in the ingress QNE may require the ingress QNE to 740 inform the egress QNE that it has done this (this is not precluded 741 however). 743 QSPEC stacking with a local QSPEC saves interior QNEs from 744 individually interpreting the initiator QSPEC within their local 745 QOSM. Instead, the ingress/egress QNEs do this for them, and in 746 this way consistent processing within a domain is simplified. That 747 is, the equivalent normal behavior is achieved in the local domain as 748 if all QNEs in the domain interpret the initiator QSPEC individually. 750 4.3.3 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 751 Notification 753 A reservation may not be successful for several reasons: 755 - a reservation may fail because the desired resources are not 756 available. This is a reservation failure condition. 758 - a reservation may fail because the QSPEC is erroneous, or because 759 of a QNE fault. This is an error condition. 761 A reservation may be successful, but still some parameters could not 762 be interpreted or updated properly: 764 - a QSPEC parameter cannot be interpreted because it is an unknown 765 QSPEC-2 parameter type. This is a QSPEC parameter not supported 766 condition. The reservation however does not fail. The QNI can 767 still decide whether to keep or tear down the reservation depending 768 on the procedures specified by the QNI's QOSM. 770 - a QSPEC parameter value is remapped, approximated, or otherwise not 771 strictly interpreted. This is a QSPEC parameter remapped 772 condition. The reservation however does not fail. The QNI can 773 still decide whether to keep or tear down the reservation. 775 The following sections describe the handling of unsuccessful 776 reservations in more detail, as follows: 778 - details on flags used inside the QSPEC to convey information on 779 success or failure of individual parameters. The formats and 780 semantics of all flags are given in Section 7. 781 - the content of the INFO_SPEC [QoS-SIG], which carries a code 782 indicating the outcome of reservations. 783 - the generation of a RESPONSE message to the QNI containing both 784 QSPEC and INFO_SPEC objects. 786 4.3.3.1 Reservation Failure & Error E-Flag 788 The QSPEC parameters each have a 'reservation failure error E-flag' 789 to indicate which (if any) parameters could not be satisfied. When a 790 resource cannot be satisfied for a particular parameter, the QNE 791 detecting the problem raises the E-flag in this parameter. Note that 792 all QSPEC parameters MUST be examined by the RMF and appropriately 793 flagged. Additionally, the E-flag in the corresponding QSPEC object 794 MUST be raised. If the reservation failure problem cannot be located 795 at the parameter level, only the E-flag in the QSPEC object is 796 raised. 798 When an RMF cannot interpret the QSPEC because the coding is 799 erroneous, it raises corresponding reservation failure E-flags in the 800 QSPEC. Normally all QSPEC parameters MUST be examined by the RMF 801 and the erroneous parameters appropriately flagged. In some cases, 802 however, an error condition may occur and the E-flag of the 803 error-causing QSPEC parameter is raised (if possible), but the 804 processing of further parameters may be aborted. 806 Note that if the QSPEC and/or any QSPEC parameter is found to be 807 erroneous, then any QSPEC parameters not satisfied are ignored and 808 the E-Flags in the QSPEC object MUST NOT be set for those parameters 809 (unless they are erroneous). 811 Whether E-flags denote reservation failure or error can be determined 812 by the corresponding error code in the INFO_SPEC in QoS NSLP, as 813 discussed below. 815 4.3.3.2 Non-QOSM-Hop Q-Flag & Remapped QSPEC Parameter R-flag 817 The non-QOSM-hop Q-flag is a flag bit telling the QNR (or QNI in a 818 RESPONSE message) whether or not the initiator QOSM is supported by 819 each QNE in the path between the QNI and QNR. A QNE MUST set the 820 non-QOSM-hop Q-flag parameter if it does not support the relevant 821 initiator QOSM specification. If the QNR finds this bit set, at 822 least one QNE along the data transmission path between the QNI and 823 QNR can not support the specified initiator QOSM. In a local QSPEC, 824 the non-QOSM-hop Q-flag refers to the QoS NSLP peers of the local 825 QOSM domain. The RESERVE message should continue to be forwarded 826 with the non-QOSM-hop Q-flag set, and the QNI has the option of not 827 accepting the reservation. 829 A QNE detecting that one or more QSPEC parameters have to be 830 remapped, approximated, or otherwise not strictly interpreted MUST 831 set the remapped QSPEC parameter R-flag for each QSPEC parameter that 832 is remapped. The RESERVE message should continue to be forwarded 833 with the R-flags set, and the QNI has the option of not accepting the 834 reservation. This condition might occur, for example, when a QNE's 835 local QOSM is different from the QNI's initiator QOSM, and the local 836 QOSM specifies that some QSPEC parameters are to be remapped. See 837 the example in Section 4.3.3 for an illustration of this condition. 838 The R-flag is interpreted by the QNI, ingress QNE (start of tunnel) 839 in a domain), egress QNE (end of tunnel) in a local domain, or QNR. 841 When a RESERVE message is tunneled through a local domain, QNEs 842 inside the domain cannot update read-write QSPEC parameters in the 843 initiator QSPEC. The egress QNE in the local domain either a) is 844 configured to have the knowledge to interpret the parameters 845 correctly, or b) cannot accurately interpret the parameters. In the 846 latter case the egress QNE in the local domain MUST set the R-flag 847 for each QSPEC parameter it cannot interpret to tell the QNI (or QNR) 848 that the information contained in the read-write parameter is most 849 likely incorrect (or a lower bound). Note that if possible the edge 850 QNEs in the local domain must interpret the QSPEC-1 parameters 851 populated in the initiator QSPEC and MUST NOT use the R-flag to 852 'ignore' a QSPEC-1 parameter populated in the initiator QSPEC. 854 4.3.3.3 QSPEC Parameter Not Supported N-Flag 856 When the QOSM ID is not known to a QNE, it MUST interpret at least 857 the QSPEC-1 parameters. 859 Each QSPEC-2 parameter has an associated 'not supported N-flag'. If 860 the not supported N-flag is set, then at least one QNE along the data 861 transmission path between the QNI and QNR cannot interpret the 862 specified QSPEC-2 parameter. A QNE MUST set the not supported N-flag 863 if it cannot interpret the QSPEC-2 parameter. In that case the 864 message should continue to be forwarded but with the N-flag set, and 865 the QNI has the option of not accepting the reservation. 867 If a QNE in the path does not support a QSPEC-2 parameter, e.g., 868 , and sets the N-flag, then downstream QNEs that 869 support the parameter SHOULD still update the parameter, even if the 870 N-flag is set. However, the presence of the N-flag will make the 871 cumulative value unreliable, and the QNI/QNR decides whether or not 872 to accept the reservation with the N-flag set. 874 4.3.3.4 INFO_SPEC Coding of Reservation Outcome 876 As prescribed by [QoS-SIG], the RESPONSE message always contains the 877 INFO_SPEC with an appropriate 'error' code. It usually also contains 878 a QSPEC with QSPEC objects, as described in Section 6 on QoS 879 Procedures. The RESPONSE message MAY omit the QSPEC in case of a 880 successful reservation. 882 The following guidelines are provided in setting the error codes in 883 the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of 884 [QoS-SIG]: 886 - INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success): 887 This code is set when all QSPEC parameters have been satisfied 888 (possibly with remapping). In this case no E-Flag is set, however 889 the Q-flag, N-flags or R-flags may be set. 891 - INFO_SPEC error class 0x04 (Transient Failure) / 0x08 (Reservation 892 Failure): 893 This code is set when at least one parameter could not be 894 satisfied. E-flags are set for the parameters that could not be 895 satisfied up to the QNE issuing the RESPONSE message. In this case 896 QNEs receiving the RESPONSE message MUST remove the corresponding 897 reservation. 899 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0c (Malformed 900 QSPEC): 901 Some QSPEC parameters had associated errors, E-Flags are set for 902 parameters that had errors, and the RMF rejects the reservation. 904 - INFO_SPEC error class 0x06 (QoS Model Error): 905 QOSM error codes can be defined by QOSM specification documents. A 906 registry is defined in Section 9 IANA Considerations. 908 4.3.3.5 QNE Generation of a RESPONSE message 910 - Successful Reservation Condition 912 When a RESERVE message arrives at a QNR and no E-Flag is set, the 913 reservation is successful. A RESPONSE message may be generated with 914 INFO_SPEC code 'Reservation Success' as described above and in the 915 QSPEC Procedures described in Section 6. 917 A raised non-QOSM-hop Q-flag in the QSPEC of the RESERVE message 918 indicates that a local QOSM is encountered that differs from the 919 initiator QOSM and that some QSPEC parameters may have been remapped, 920 approximated, or otherwise not strictly interpreted, as indicated by 921 raised R-flags on these QSPEC parameters. The non-QOSM-hop Q-flag 922 and R-flags are sent back in the RESPONSE message and the QNI then 923 makes the final determination as to whether to continue or tear down 924 the reservation that has been established. A QOSM specification may 925 specify the conditions for rejecting a reservation under such 926 conditions. However, in the absence of such procedures, the default 927 condition SHOULD be 'success' if all QSPEC parameters are met and 928 'reservation failure' if one or more QSPEC parameters are not met. 930 - Reservation Failure Condition 932 When a QNE detects that a reservation failure occurs for at least one 933 parameter, the QNE sets the E-Flags for the QSPEC parameters and 934 QSPEC object that failed to be satisfied. According to [QoS-SIG], 935 the QNE behavior depends on whether it is stateful or not. When a 936 stateful QNE determines the reservation failed, it formulates a 937 RESPONSE message that includes an INFO_SPEC with the 'reservation 938 failure' error code and QSPEC object. The QSPEC in the RESPONSE 939 message includes the failed QSPEC parameters marked with the E-Flag 940 to clearly identify them. 942 The default action for a stateless QoS NSLP QNE that detects a 943 reservation failure condition is that it MUST continue to forward the 944 RESERVE message to the next stateful QNE, with the E-Flags 945 appropriately set for each QSPEC parameter. The next stateful QNE 946 then formulates the RESPONSE message as described above. 948 - Malformed QSPEC Error Condition 950 When a stateful QNE detects that one or more QSPEC parameters are 951 erroneous, the QNE sets the error code 'malformed QSPEC' in the 952 INFO_SPEC. In this case the QSPEC object with the E-Flags 953 appropriately set for the erroneous parameters is returned within 954 the INFO_SPEC object. The QSPEC object can be truncated or fully 955 included within the INFO_SPEC. 957 According to [QoS-SIG], the QNE behavior depends on whether it is 958 stateful or not. When a stateful QNE determines a malformed QSPEC 959 error condition, it formulates a RESPONSE message that includes an 960 INFO_SPEC with the 'malformed QSPEC' error code and QSPEC object. 961 The QSPEC in the RESPONSE message includes, if possible, only the 962 erroneous QSPEC parameters and no others. The erroneous QSPEC 963 parameter(s) are marked with the E-Flag to clearly identify them. If 964 QSPEC parameters are returned in the INFO-SPEC that are not marked 965 with the E-flag, then any values of these parameters are irrelevant 966 and MUST be ignored by the QNI. 968 The default action for a stateless QoS NSLP QNE that detects a 969 Malformed QSPEC error condition is that it MUST continue to forward 970 the RESERVE message to the next stateful QNE, with the E-Flags 971 appropriately set for each QSPEC parameter. The next stateful QNE 972 will then act as described in [QoS-SIG]. 974 A 'malformed QSPEC' error code takes precedence over the 'reservation 975 failure' error code, and therefore the case of reservation failure 976 and QSPEC/RMF error conditions are disjoint and the same E-Flag can 977 be used in both cases without ambiguity. 979 4.3.3.6 Special Cases of QSPEC Stacking 981 When an unsuccessful reservation problem occurs inside a local domain 982 where QSPEC stacking is used, only the topmost (local) QSPEC is 983 affected (e.g. E-flags are raised, etc.). The initiator QSPEC at the 984 bottom is untouched. When the message (RESPONSE in case of stateful 985 QNEs, RESERVE in case of stateless QNEs) however reaches the edge of 986 the stacking domain, the local QSPEC is popped, and its content, 987 including flags, is translated into the initiator QSPEC. 989 4.3.4 Example of QSPEC Processing 991 This section illustrates the operation and use of the QSPEC within 992 the NSLP. The example configuration in shown in Figure 3. 994 +----------+ /-------\ /--------\ /--------\ 995 | Laptop | | Home | | Cable | | DiffServ | 996 | Computer |-----| Network |-----| Network |-----| Network |----+ 997 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 998 \-------/ \--------/ \--------/ | 999 | 1000 +-----------------------------------------------+ 1001 | 1002 | /--------\ +----------+ 1003 | | "X"G | | Handheld | 1004 +---| Wireless |-----| Device | 1005 | XG QOSM | +----------+ 1006 \--------/ 1008 Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC 1009 Operation 1011 In this configuration, a laptop computer and a handheld wireless 1012 device are the endpoints for some application that has QoS 1013 requirements. Assume initially that the two endpoints are stationary 1014 during the application session, later we consider mobile endpoints. 1015 For this session, the laptop computer is connected to a home network 1016 that has no QoS support. The home network is connected to a 1017 CableLabs-type cable access network with dynamic QoS (DQOS) support, 1018 such as specified in the 'CMS to CMS Signaling Specification' [DQOS] 1019 for cable access networks. That network is connected to a DiffServ 1020 core network that uses the RMD QOSM [RMD-QOSM]. On the other side of 1021 the DiffServ core is a wireless access network built on generation 1022 "X" technology with QoS support as defined by generation "X". And 1023 finally the handheld endpoint is connected to the wireless access 1024 network. 1026 We assume that the Laptop is the QNI and handheld device is the QNR. 1028 The QNI will signal an initiator QSPEC object to achieve the QoS 1029 desired on the path. As stated in Section 4.1, the QNI MUST support 1030 at least one QOSM, but it may not know the QOSM supported by the 1031 network. In any case, if the QNI supports only one QOSM, it would 1032 normally signal a reservation according to the requirements of that 1033 QOSM. Furthermore, the QNI would most likely support the QOSM that 1034 matches its functionality. For example, the default QOSM for mobile 1035 phones might be the XG-QOSM, while the CL-QOSM might be the 1036 default for workstations. 1038 Referring to Figure 3, the laptop computer may choose the 1039 CL-QOSM because it is connected to a wired network. If the 1040 handheld device acts as the QNI, it may choose the XG-QOSM because it 1041 is connected to the XG wireless network. On the other hand, a 1042 particular QOSM could be configured if a user/administrator knows 1043 that some particular QOSM is used. For example, if the laptop 1044 computer is connected to the XG network via the XG phone, which acts 1045 as a modem, then it reasonable to specify the XG-QOSM since resources 1046 are accessed through the XG network, 1048 In this example we consider two different ways to perform 1049 sender-initiated signaling for QoS: 1051 Case 1) The QNI sets , and possibly 1052 QSPEC objects in the initiator QSPEC, and initializes 1053 to . Since this is a reservation in a 1054 heterogenic network with different QOSMs supported in different 1055 domains, each QNE on the path reads and interprets those parameters 1056 in the initiator QSPEC that it needs to implement the QOSM within its 1057 domain (as described below). Each QNE along the path checks to see if 1058 resources can be reserved, and if not, the QNE 1059 reduces the respective parameter values in and 1060 reserves these values. The minimum parameter values are given in 1061 , if populated, otherwise zero if is not 1062 included. If one or more parameters in fails to 1063 satisfy the corresponding minimum values in Minimum QoS, the QNE 1064 generates a RESPONSE message to the QNI and the reservation is 1065 aborted. Otherwise, the QNR generates a RESPONSE to the QNI with the 1066 for the reservation. 1068 Case 2) The QNI signals the initiator QSPEC with . 1069 Since this is a reservation in a heterogenic network with different 1070 QOSMs supported in different domains, each QNE on the path reads and 1071 interprets those parameters in the initiator QSPEC that it needs to 1072 implement the QOSM within its domain (as described below). If a QNE 1073 cannot reserve resources, the reservation fails. 1075 In both cases, the QNI populates QSPEC-1 and QSPEC-2 to 1076 ensure correct treatment of its traffic in domains down the path. 1077 Since the QNI does not know the QOSM used in downstream domains, it 1078 includes values for those QSPEC-1 and QSPEC-2 parameters 1079 consistent with the QOSM it is signaling and any additional 1080 parameters it cares about. Let us assume the QNI wants to achieve 1081 IntServ-like QoS guarantees, and also is interested in what path 1082 latency it can achieve. The QNI therefore includes in the QSPEC the 1083 QOSM ID for IntServ Controlled Load Service. The QSPEC objects are 1084 signaled with all parameters necessary for IntServ Controlled Load 1085 and additionally the parameter to measure path latency, as follows: 1087 = 1088 = 1090 In both cases, each QNE on the path reads and interprets those 1091 parameters in the initiator QSPEC that it needs to implement the QOSM 1092 within its domain. It may need additional parameters for its QOSM, 1093 which are not specified in the initiator QSPEC. If possible, these 1094 parameters must be inferred from those that are present, according to 1095 rules defined in the QOSM implemented by this QNE. 1097 There are three possibilities when a RESERVE message is received at a 1098 QNE at a domain border (we illustrate these possibilities in the 1099 example): 1101 - the QNE just leaves the QSPEC as-is. 1103 - the QNE can stack a local QSPEC on top of the initiator QSPEC (this 1104 is new in QoS NSLP, RSVP does not do this). 1106 - the QNE can tunnel the initiator RESERVE message through its domain 1107 and issue its own local RESERVE message. For this new local 1108 RESERVE message, the QNE acts as the QNI, and the QSPEC in the 1109 domain is an initiator QSPEC. This procedure is also used by RSVP 1110 in making aggregate reservations, in which case there is not a new 1111 intra-domain (aggregate) RESERVE for each newly arriving 1112 interdomain (per-flow) RESERVE, but the aggregate reservation is 1113 updated by the border QNE (QNI) as need be. This is also how RMD 1114 works [RMD-QOSM]. 1116 For example, at the RMD domain, a local RESERVE with its own RMD 1117 initiator QSPEC corresponding to the RMD-QOSM is generated based on 1118 the original initiator QSPEC according to the procedures described in 1119 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE 1120 to the RMD domain must map the QSPEC parameters contained in the 1121 original initiator QSPEC into the RMD QSPEC. The RMD QSPEC for 1122 example needs and . is generated 1123 from the parameter. Information on , 1124 however, is not provided. According to the rules laid out in the RMD 1125 QOSM, the ingress QNE infers from the fact that an IntServ Controlled 1126 Load QOSM was signaled that the EF PHB is appropriate to set the parameter. These RMD QSPEC parameters are populated in the 1128 RMD initiator QSPEC generated within the RMD domain. 1130 Furthermore, the node at the egress to the RMD domain updates on behalf of the entire RMD domain if it can. If it 1132 cannot, it raises the parameter-specific, 'not-supported' flag, 1133 warning the QNR that the final value of these parameters in QoS 1134 Available is imprecise. 1136 In the XG domain, the initiator QSPEC is translated into a local 1137 QSPEC using a similar procedure as described above. The local QSPEC 1138 becomes the current QSPEC used within the XG domain, that is, the 1139 it becomes the first QSPEC on the stack, and the initiator QSPEC is 1140 second. This saves the QNEs within the XG domain the trouble of 1141 re-translating the initiator QSPEC. At the egress edge of the XG 1142 domain, the translated local QSPEC is popped, and the initiator QSPEC 1143 returns to the number one position. 1145 If the reservation was successful, eventually the RESERVE request 1146 arrives at the QNR (otherwise the QNE at which the reservation failed 1147 would have aborted the RESERVE and sent an error RESPONSE back to the 1148 QNI). The QNR generates a positive RESPONSE with QSPEC objects - and for case 1 - additionally . The 1150 parameters appearing in are the same as in , with values copied from in case 1, and with 1152 the original values from in case 2. That is, it is not 1153 necessary to transport the object back to the QNI since 1154 the QNI knows what it signaled originally, and the information is not 1155 useful for QNEs in the reverse direction. The object 1156 should transport all necessary information, although the and objects may end up transporting some of 1158 the same information. 1160 Hence, the QNR includes the following QSPEC objects: 1162 = 1163 = 1165 If the handheld device on the right of Figure 3 is mobile, and moves 1166 through different "XG" wireless networks, then the QoS might change 1167 on the path since different XG wireless networks might support 1168 different QOSMs. As a result, QoS NSLP/QSPEC processing will have to 1169 renegotiate the on the path. From a QSPEC 1170 perspective, this is like a new reservation on the new section of the 1171 path and is basically the same as any other rerouting event - to the 1172 QNEs on the new path it looks like a new reservation. That is, in 1173 this mobile scenario, the new segment may support a different QOSM 1174 than the old segment, and the QNI would now signal a new reservation 1175 (explicitly, or implicitly with the next refreshing RESERVE message) 1176 to account for the different QOSM in the XG wireless domain. Further 1177 details on rerouting are specified in [QoS-SIG]. 1179 For bit-level examples of QSPECs see the documents specifying QOSMs 1180 [CL-QOSM, Y.1541-QOSM, RMD-QOSM]. 1182 4.4 QSPEC Extensibility 1184 This document defines both QSPEC-1 and QSPEC-2 parameters. The 1185 set of QSPEC-1 parameters defined herein is at this point in time 1186 considered complete. The QSPEC-2 parameters in this document 1187 correspond to some of the QSPEC-2 parameters considered in QOSMs 1188 currently being defined. 1190 Additional QSPEC-1 parameters may be defined in the future. However, 1191 since this requires an update of all QNEs, this should be considered 1192 carefully. The definition of new QSPEC-1 parameter requires 1193 standards action and an update of this document. Such an update also 1194 needs a new QSPEC version number. Furthermore, all QOSM definitions 1195 must be updated to include how the new QSPEC-1 parameter is to be 1196 interpreted in the respective QOSM. 1198 Additional QSPEC-2 parameters MAY need to be defined in the future 1199 and are defined in separate informational documents specific to a 1200 given QOSM. For example, QSPEC-2 parameters are defined in 1201 [RMD-QOSM] and [Y.1541-QOSM]. 1203 Guidelines on the technical criteria to be followed in evaluating 1204 requests for new codepoint assignments for QSPEC objects and QSPEC 1205 parameters are given in Section 9 (IANA Considerations). 1207 Guidelines on the technical criteria to be followed in evaluating 1208 requests for new codepoint assignments beyond QSPEC objects and 1209 QSPEC parameters for the NSIS protocol suite are given in a separate 1210 NSIS extensibility document [NSIS-EXTENSIBILITY]. 1212 5. QSPEC Format Overview 1214 QSPEC = 1215 1217 As described above, the QSPEC contains an identifier for the QOSM, 1218 the actual resource description (QoS description) as well as QSPEC 1219 control information. QSPEC-1 parameters defined in the following 1220 sections include , , , and 1221 . All other QSPEC parameters defined in the following 1222 sections are QSPEC-2 parameters. 1224 A QSPEC object ID identifies whether the object is or . As described below, the is further broken down into , , , and objects. A QSPEC 1228 parameter ID is assigned to identify each QSPEC parameter defined 1229 below. 1231 identifies the QSPEC version number. Later QSPEC 1232 versions MUST be backward compatible with earlier QSPEC versions. 1233 That is, a version n+1 device must support a version n (or earlier) 1234 QSPEC and QSPEC parameters. If the version n device receives 1235 QSPEC-1 parameters (with the M-flag set, as defined in Section 7) 1236 that are not supported in version n (only supported in version 1237 n+1), then the version n device concludes that either a) the M-flag 1238 is set incorrectly for an QSPEC-2 parameter it does not support, or 1239 b) the M-flag is correctly set for a QSPEC-1 parameter it does not 1240 support. In either case, the version n device responds with a 1241 'Malformed QSPEC' error code (0x03), as discussed in Section 4.3.3. 1243 A new QSPEC version MUST be defined whenever this document is 1244 reissued, for example, whenever a new QSPEC-1 parameter is added. 1245 QSPEC-1 parameters in a new QSPEC version MUST be a superset of 1246 those in the previous QSPEC version. 1248 The identifies the particular QOSM being used by the QNI 1249 and tells a QNE which parameters to expect. This may simplify 1250 processing and error analysis. Furthermore, it may be helpful for a 1251 QNE or a domain supporting more than one QOSM to learn which QOSM the 1252 QNI would like to have in order to use the most suitable QOSM. Even 1253 if a QNE does not support the QOSM it MUST interpret at least the 1254 QSPEC-1 parameters. Note that more parameters than required by the 1255 QOSM can be included by the QNI. QSPEC version and QOSM IDs are 1256 assigned by IANA. 1258 5.1 QSPEC Control Information 1260 QSPEC control information is used for signaling QOSM RMF functions 1261 not defined in QoS NSLP. It enables building new RMF functions 1262 required by a QOSM within a QoS NSLP signaling framework, such as 1263 specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. 1265 = 1267 The parameter describes how the QNE will process 1268 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 1269 be dropped, shaped and/or remarked. The excess treatment parameter is 1270 initially set by the QNI and is read-only. 1272 5.2 QoS Description 1274 The QoS Description is broken down into the following QSPEC objects: 1276 = 1277 1279 Any subset of the QSPEC objects on the right hand side of the equal 1280 sign can be included in the QSPEC. Of these QSPEC objects, QoS 1281 Desired, QoS Available and QoS Reserved MUST be supported by QNEs. 1282 Minimum QoS MAY be supported. 1284 5.2.1 1286 = 1287 1289 Any subset of the QSPEC parameters on the right hand side of the 1290 equal sign can be included in the object. These 1291 parameters describe the resources the QNI desires to reserve and 1292 hence this is a read-only QSPEC object. The resources 1293 that the QNI wishes to reserve are of course directly related to the 1294 traffic the QNI is going to inject into the network. Therefore, when 1295 used in the object, refers to traffic 1296 injected by the QNI into the network. 1298 = 1300 Either sub-parameter on the right hand side of the equal sign can be 1301 included in the parameter. Here 1303 = link bandwidth needed by flow [RFC2212, RFC2215] 1305 =

[RFC2210] 1307 All of the sub-parameters on the right hand side of the equal sign 1308 MUST be included in the parameter. Note that the Path 1309 MTU Discovery (PMTUD) working group is currently specifying a robust 1310 method for determining the MTU supported over an end-to-end path. 1311 This new method is expected to update RFC1191 and RFC1981, the 1312 current standards track protocols for this purpose. 1314 = 1316 Any one of the sub-parameter on the right hand side of the equal sign 1317 can be included in the parameter. 1319 An application MAY like to reserve resources for packets with a 1320 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 1321 [RFC2475], DiffServ-aware MPLS traffic engineering (DSTE) class 1322 type [RFC3564, RFC4124], or Y.1541 QoS class [Y.1541]. 1324 = 1325 1327 Any subset of the sub-parameter on the right hand side of the equal 1328 sign can be included in the parameter. 1330 is the priority of the new flow compared with 1331 the defending priority of previously admitted flows. Once a flow is 1332 admitted, the preemption priority becomes irrelevant. is used to compare with the preemption priority of new 1334 flows. For any specific flow, its preemption priority MUST always be 1335 less than or equal to the defending priority. 1336 and provide an essential way to differentiate flows 1337 for emergency services, ETS, E911, etc., and assign them a higher 1338 admission priority than normal priority flows and best-effort 1339 priority flows. 1341 Appropriate security measures need to be taken to prevent abuse of 1342 the parameters, see Section 8 on Security Considerations. 1344 [Y.1540] defines packet transfer outcomes, as follows: 1346 Successful: packet arrives within the preset waiting time with no 1347 errors 1349 Lost: packet fails to arrive within the waiting time 1351 Errored: packet arrives in time, but has one or more bit errors 1352 in the header or payload 1354 Packet Loss Ratio (PLR) = total packets lost/total packets sent 1356 Packet Error Ratio (PER) = total errored packets/total packets sent 1358 , , , and are QSPEC-2 1359 parameters describing the desired path latency, path jitter and path 1360 bit error rate respectively. Since these parameters are cumulative, 1361 an individual QNE cannot decide whether the desired path latency, 1362 etc., is available, and hence they cannot decide whether a 1363 reservation fails. Rather, when these parameters are included in 1364 , the QNI SHOULD also include corresponding parameters 1365 in a QSPEC object in order to facilitate collecting 1366 this information. 1368 5.2.2 1370 = 1371 1372 1374 Any subset of the QSPEC parameters on the right hand side of the 1375 equal sign can be included in the object. 1377 When used in the object, refers to traffic 1378 resources available at a QNE in the network. 1380 The Object collects information on the resources 1381 currently available on the path when it travels in a RESERVE or QUERY 1382 message and hence in this case this QSPEC object is read-write. Each 1383 QNE MUST inspect all parameters of this QSPEC object, and if 1384 resources available to this QNE are less than what a particular 1385 parameter says currently, the QNE MUST adapt this parameter 1386 accordingly. Hence when the message arrives at the recipient of the 1387 message, reflects the bottleneck of the resources 1388 currently available on a path. It can be used in a QUERY message, 1389 for example, to collect the available resources along a data path. 1391 When travels in a RESPONSE message, it in fact just 1392 transports the result of a previous measurement performed by a 1393 RESERVE or QUERY message back to the initiator. Therefore in this 1394 case, is read-only. 1396 The parameters and provide information, 1397 for example, about the bandwidth available along the path followed by 1398 a data flow. The local parameter is an estimate of the bandwidth the 1399 QNE has available for packets following the path. Computation of the 1400 value of this parameter SHOULD take into account all information 1401 available to the QNE about the path, taking into consideration 1402 administrative and policy controls on bandwidth, as well as physical 1403 resources. The composition rule for this parameter is the MIN 1404 function. The composed value is the minimum of the QNE's value and 1405 the previously composed value. This quantity, when composed 1406 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 1407 minimal bandwidth link along the path from QNI to QNR. 1409 The parameter accumulates the latency of the packet 1410 forwarding process associated with each QNE, where the latency is 1411 defined to be the mean packet delay added by each QNE. This delay 1412 results from speed-of-light propagation delay, from packet processing 1413 limitations, or both. The mean delay reflects the variable queuing 1414 delay that may be present. Each QNE MUST add the propagation delay 1415 of its outgoing link, if this link exists. Furthermore, the QNI MUST 1416 add the propagation delay of the ingress link, if this link exists. 1417 The composition rule for the parameter is summation 1418 with a clamp of (2**32 - 1) on the maximum value. This quantity, 1419 when composed end-to-end, informs the QNR (or QNI in a RESPONSE 1420 message) of the minimal packet delay along the path from QNI to QNR. 1421 The purpose of this parameter is to provide a minimum path latency 1422 for use with services which provide estimates or bounds on additional 1423 path delay [RFC2212]. 1425 The parameter accumulates the jitter of the packet 1426 forwarding process associated with each QNE, where the jitter is 1427 defined to be the nominal jitter added by each QNE. IP packet 1428 jitter, or delay variation, is defined in [RFC3393], Section 3.4 1429 (Type-P-One-way-ipdv), and where the selection function includes the 1430 packet with minimum delay such that the distribution is equivalent to 1431 2-point delay variation in [Y.1540]. The suggested evaluation 1432 interval is 1 minute. This jitter results from packet processing 1433 limitations, and includes any variable queuing delay which may be 1434 present. Each QNE MUST add the jitter of its outgoing link, if this 1435 link exists. Furthermore, the QNI MUST add the jitter of the ingress 1436 link, if this link exists. The composition method for the parameter is the combination of several statistics describing 1438 the delay variation distribution with a clamp on the maximum value 1439 (note that the methods of accumulation and estimation of nominal QNE 1440 jitter are specified in clause 8 of [Y.1541]). This quantity, when 1441 composed end-to-end, informs the QNR (or QNI in a RESPONSE message) 1442 of the nominal packet jitter along the path from QNI to QNR. The 1443 purpose of this parameter is to provide a nominal path jitter for use 1444 with services that provide estimates or bounds on additional path 1445 delay [RFC2212]. 1447 The parameter accumulates the packet loss rate (PLR) of 1448 the packet forwarding process associated with each QNE, where the PLR 1449 is defined to be the PLR added by each QNE. Each QNE MUST add the 1450 PLR of its outgoing link, if this link exists. Furthermore, the QNI 1451 MUST add the PLR of the ingress link, if this link exists. The 1452 composition rule for the parameter is summation with a 1453 clamp on the maximum value (this assumes sufficiently low PLR values 1454 such that summation error is not significant, however a more accurate 1455 composition function is specified in clause 8 of [Y.1541]). This 1456 quantity, when composed end-to-end, informs the QNR (or QNI in a 1457 RESPONSE message) of the minimal packet PLR along the path from QNI 1458 to QNR. 1460 The parameter accumulates the packet error rate (PER) of 1461 the packet forwarding process associated with each QNE, where the PER 1462 is defined to be the PER added by each QNE. Each QNE MUST add the 1463 PER of its outgoing link, if this link exists. Furthermore, the QNI 1464 MUST add the PER of the ingress link, if this link exists. The 1465 composition rule for the parameter is summation with a 1466 clamp on the maximum value (this assumes sufficiently low PER values 1467 such that summation error is not significant, however a more accurate 1468 composition function is specified in clause 8 of [Y.1541]). This 1469 quantity, when composed end-to-end, informs the QNR (or QNI in a 1470 RESPONSE message) of the minimal packet PER along the path from QNI 1471 to QNR. 1473 , , , : Error terms C and D represent how the 1474 element's implementation of the guaranteed service deviates from the 1475 fluid model. These two parameters have an additive composition rule. 1477 The error term C is the rate-dependent error term. It represents the 1478 delay a datagram in the flow might experience due to the rate 1479 parameters of the flow. The error term D is the rate-independent, 1480 per-element error term and represents the worst case non-rate-based 1481 transit time variation through the service element. If the 1482 composition function is applied along the entire path to compute the 1483 end-to-end sums of C and D ( and ) and the resulting 1484 values are then provided to the QNR (or QNI in a RESPONSE message). 1485 and are the sums of the parameters C and D between the 1486 last reshaping point and the current reshaping point. 1488 5.2.3 1490 = 1492 Any subset of the QSPEC parameters on the right hand side of the 1493 equal sign can be included in the object. These 1494 parameters describe the QoS reserved by the QNEs along the data path. 1496 , and are defined above. 1498 = slack term, which is the difference between desired delay and 1499 delay obtained by using bandwidth reservation, and which is used to 1500 reduce the resource reservation for a flow [RFC2212]. This is an 1501 QSPEC-2 parameter. 1503 5.2.4 1505 = 1507 Any subset of the QSPEC parameters on the right hand side of the 1508 equal sign can be included in the object. 1510 does not have an equivalent in RSVP. It allows the QNI 1511 to define a range of acceptable QoS levels by including both the 1512 desired QoS value and the minimum acceptable QoS in the same message. 1513 It is a read-only QSPEC object. The desired QoS is included with a 1514 and/or a QSPEC object seeded to the 1515 desired QoS value. The minimum acceptable QoS value MAY be coded in 1516 the QSPEC object. As the message travels towards the 1517 QNR, is updated by QNEs on the path. If its value 1518 drops below the value of the reservation fails and is 1519 aborted. When this method is employed, the QNR SHOULD signal back to 1520 the QNI the value of attained in the end, because the 1521 reservation MAY need to be adapted accordingly. 1523 6. QSPEC Procedures 1525 While the QSPEC template aims to put minimal restrictions on usage of 1526 QSPEC objects in , interoperability between QNEs and 1527 between QOSMs must be ensured. We therefore give below an exhaustive 1528 list of QSPEC object combinations for the message sequences described 1529 in QoS NSLP [QoS-SIG]. A specific QOSM may prescribe that only a 1530 subset of the procedures listed below may be used. 1532 Note that QoS NSLP does not mandate the usage of a RESPONSE message. 1533 In fact, a RESPONSE message will only be generated if the QNI 1534 includes an RII (Request Identification Information) in the RESERVE 1535 message. Some of the QSPEC procedures below, however, are only 1536 meaningful when a RESPONSE message is possible. The QNI SHOULD in 1537 these cases include an RII. 1539 6.1 Sender-Initiated Reservations 1541 Here the QNI issues a RESERVE message, which may be replied to by a 1542 RESPONSE message. The following 3 cases for QSPEC object usage 1543 exist: 1545 ID | RESERVE | RESPONSE 1546 --------------------------------------------------------------- 1547 1 | QoS Desired | QoS Reserved 1548 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1549 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1551 Case 1: 1553 If only QoS Desired is included in the RESERVE message, the implicit 1554 assumption is that exactly these resources must be reserved. If this 1555 is not possible the reservation fails. The parameters in QoS 1556 Reserved are copied from the parameters in QoS Desired. If the 1557 reservation is successful, the RESPONSE message can be omitted in 1558 this case. If a RESPONSE message was requested by a QNE on the 1559 path, the QSPEC in the RESPONSE message can be omitted. 1561 Case 2: 1563 When QoS Available is included in the RESERVE message also, some 1564 parameters will appear only in QoS Available and not in QoS Desired. 1565 It is assumed that the value of these parameters is collected for 1566 informational purposes only (e.g. path latency). 1568 However, some parameters in QoS Available can be the same as in QoS 1569 Desired. For these parameters the implicit message is that the QNI 1570 would be satisfied by a reservation with lower parameter values than 1571 specified in QoS Desired. For these parameters, the QNI seeds the 1572 parameter values in QoS Available to those in QoS Desired (except for 1573 cumulative parameters such as ). 1575 Each QNE remaps or approximately interprets the parameters in QoS 1576 Available according to its current capabilities. Reservations in 1577 each QNE are hence based on current parameter values in QoS Available 1578 (and additionally those parameters that only appear in QoS Desired). 1580 The drawback of this approach is that, if the resulting resource 1581 reservation becomes gradually smaller towards the QNR, QNEs close to 1582 the QNI have an oversized reservation, possibly resulting in 1583 unnecessary costs for the user. Of course, in the RESPONSE the QNI 1584 learns what the actual reservation is (from the QoS RESERVED object) 1585 and can immediately issue a properly sized refreshing RESERVE. The 1586 advantage of the approach is that the reservation is performed in 1587 half-a-roundtrip time. 1589 The QSPEC parameter IDs and values included in the QoS Reserved 1590 object in the RESPONSE message MUST be the same as those in the QoS 1591 Desired object in the RESERVE message. For those QSPEC parameters 1592 that were also included in the QoS Available object in the RESERVE 1593 message, their value is copied into the QoS Desired object. For the 1594 other QSPEC parameters, the value is copied from the QoS Desired 1595 object (the reservation would fail if the corresponding QoS could 1596 not be reserved). 1598 All parameters in the QoS Available object in the RESPONSE message 1599 are copied with their values from the QoS Available object in the 1600 RESERVE message (irrespective of whether they have also been copied 1601 into the QoS Desired object). Note that the parameters in the QoS 1602 Available object are read-write in the RESERVE message, whereas they 1603 are read-only in the RESPONSE message. 1605 In this case, the QNI SHOULD request a RESPONSE message since it will 1606 otherwise not learn what QoS is available. 1608 Case 3: 1610 This case is handled as case 2, except that the reservation fails 1611 when QoS Available becomes less than Minimum QoS for one parameter. 1612 If a parameter appears in the QoS Available object but not in the 1613 Minimum QoS object it is assumed that there is no minimum value for 1614 this parameter. 1616 Regarding QSPEC Control Information, the default rule is that all 1617 QSPEC parameters that have been included in the RESERVE message by 1618 the QNI are also included in the RESPONSE message by the QNR with the 1619 value they had when arriving at the QNR. When traveling in the 1620 RESPONSE message, all QSPEC Control Information parameters are 1621 read-only. Note that a QOSM specification may define its own 1622 QOSM-specific Control Information parameters and processing rules. 1623 Also in this case, the QNI SHOULD request a RESPONSE message since it 1624 will otherwise not learn what QoS is available. 1626 6.2 Receiver-Initiated Reservations 1628 Here the QNR issues a QUERY message which is replied to by the QNI 1629 with a RESERVE message if the reservation was successful. The QNR in 1630 turn sends a RESPONSE message to the QNI. The following 3 cases for 1631 QSPEC object usage exist: 1633 ID| QUERY | RESERVE | RESPONSE 1634 --------------------------------------------------------------------- 1635 1 |QoS Des. | QoS Des. | QoS Res. 1636 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1637 3 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl. | QoS Res. 1639 Cases 1 and 2: 1641 The idea is that the sender (QNR in this scenario) needs to inform 1642 the receiver (QNI in this scenario) about the QoS it desires. To 1643 this end the sender sends a QUERY message to the receiver including a 1644 QoS Desired QSPEC object. If the QoS is negotiable it additionally 1645 includes a (possibly zero) Minimum QoS object, as in Case 2. 1647 The RESERVE message includes the QoS Available object if the sender 1648 signaled that QoS is negotiable (i.e. it included the Minimum QoS 1649 object). If the Minimum QoS object received from the sender is 1650 included in the QUERY message, the QNR also includes the Minimum QoS 1651 object in the RESERVE message. 1653 For a successful reservation, the RESPONSE message in case 1 is 1654 optional (as is the QSPEC inside). In case 2 however, the RESPONSE 1655 message is necessary in order for the QNI to learn about the QoS 1656 available. 1658 Case 3: 1660 This is the 'RSVP-style' scenario. The sender (QNR in this scenario) 1661 issues a QUERY message with a QoS Desired object informing the 1662 receiver (QNI in this scenario) about the QoS it desires as above. 1663 It also includes a QoS Available object to collect path properties. 1664 Note that here path properties are collected with the QUERY message, 1665 whereas in the previous case 2 path properties were collected in the 1666 RESERVE message. 1668 Some parameters in the QoS Available object may the same as in the 1669 QoS Desired object. For these parameters the implicit message is 1670 that the sender would be satisfied by a reservation with lower 1671 parameter values than specified in QoS Desired. 1673 It is possible for the QoS Available object to contain parameters 1674 that do not appear in the QoS Desired object. It is assumed that the 1675 value of these parameters is collected for informational purposes 1676 only (e.g. path latency). Parameter values in the QoS Available 1677 object are seeded according to the sender's capabilities. Each QNE 1678 remaps or approximately interprets the parameter values according to 1679 its current capabilities. 1681 The receiver (QNI in this scenario) signals the QoS Desired object as 1682 follows: For those parameters that appear in both the QoS Available 1683 object and QoS Desired object in the QUERY message, it takes the 1684 (possibly remapped) QSPEC parameter values from the QoS Available 1685 object. For those parameters that only appear in the QoS Desired 1686 object, it adopts the parameter values from the QoS Desired object. 1688 The parameters in the QoS Available QSPEC object in the RESERVE 1689 message are copied with their values from the QoS Available QSPEC 1690 object in the QUERY message. Note that the parameters in the QoS 1691 Available object are read-write in the QUERY message, whereas they 1692 are read-only in the RESERVE message. 1694 The advantage of this model compared to the sender-initiated 1695 reservation is that the situation of over-reservation in QNEs close 1696 to the QNI as described above does not occur. On the other hand, the 1697 QUERY message may find, for example, a particular bandwidth is not 1698 available. When the actual reservation is performed, however, the 1699 desired bandwidth may meanwhile have become free. That is, the 'RSVP 1700 style' may result in a smaller reservation than necessary. 1702 Regarding QSPEC Control Information in receiver-initiated 1703 reservations, the sender includes all QSPEC Control Information it 1704 cares about in the QUERY message. Read-write parameters are updated 1705 by QNEs as the QUERY message travels towards the receiver. The 1706 receiver includes all QSPEC Control Information parameters arriving 1707 in the QUERY message also in the RESERVE message, as read-only 1708 parameters with the value they had when arriving at the receiver. 1709 Again, QOSM-specific Control Information parameters and procedures 1710 may be defined in QOSM specification documents. 1712 Also in this scenario, the QNI SHOULD request a RESPONSE message 1713 since it will otherwise not learn what QoS is available. 1715 6.3 Resource Queries 1717 Here the QNI issues a QUERY message in order to investigate what 1718 resources are currently available. The QNR replies with a RESPONSE 1719 message. 1721 ID | QUERY | RESPONSE 1722 -------------------------------------------- 1723 1 | QoS Available | QoS Available 1725 Note that the QoS Available object when traveling in the QUERY 1726 message is read-write, whereas in the RESPONSE message it is 1727 read-only. 1729 6.4 Bidirectional Reservations 1731 On a QSPEC level, bidirectional reservations are no different from 1732 uni-directional reservations, since QSPECs for different directions 1733 never travel in the same message. 1735 6.5 Preemption 1737 A flow can be preempted by a QNE based on the values of the QSPEC 1738 Priority parameter (see Section 7.2.4). In this case the reservation 1739 state for this flow is torn down in this QNE, and the QNE sends a 1740 NOTIFY message to the QNI, as described in [QoS-SIG]. No QSPEC is 1741 carried in the NOTIFY message. The NOTIFY message carries only the 1742 Session ID and a INFO_SPEC with the error code as described in 1743 [QoS-SIG]. The QNI would normally tear down the preempted 1744 reservation by sending a RESERVE message with the TEAR flag set using 1745 the SII of the preempted reservation. However, the QNI can follow 1746 other procedures as specified in its QOSM specification document. 1748 7. QSPEC Functional Specification 1750 This section defines the encodings of the QSPEC parameters and QSPEC 1751 control information defined in Section 5. We first give the general 1752 QSPEC formats and then the formats of the QSPEC objects and 1753 parameters. 1755 Note that all QoS description parameters can be either read-write or 1756 read-only, depending on which object and which message they appear 1757 in. All parameters in the QoS Desired object, QoS Reserved object, 1758 and Minimum QoS object are read-only for all messages. All 1759 parameters in the QoS Available object are normally read-write 1760 parameters. However, as discussed in Section 6, the parameters in 1761 the QoS Available object are read-write when the QoS Available object 1762 appears for the first time e.g. in the RESERVE message or QUERY 1763 message from QNI to QNR. However, on its way back, all parameters in 1764 the object are read-only, e.g., in the RESPONSE 1765 message or RESERVE message from QNR to QNI. For QSPEC control 1766 information parameters, the property of being read-write or read-only 1767 is parameter specific. Note that the only control information 1768 parameter specified in this document is the 1769 parameter, which is a read-only parameter. 1771 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1772 well as 32-bit floating point numbers, are as specified in [RFC1832, 1773 IEEE754, NETWORK-BYTE-ORDER]. 1775 7.1 General QSPEC Formats 1777 The format of the QSPEC closely follows that used in GIST [GIST] and 1778 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1779 general format: 1781 o The overall format is Type-Length-Value (in that order). 1783 o Some parts of the type field are set aside for control flags. 1785 o Length has the units of 32-bit words, and measures the length of 1786 Value. If there is no Value, Length=0. The Object length 1787 excludes the header. 1789 o Value is a whole number of 32-bit words. If there is any padding 1790 required, the length and location MUST be defined by the 1791 object-specific format information; objects that contain variable 1792 length types may need to include additional length subfields to do 1793 so. 1795 o Any part of the object used for padding or defined as reserved("r") 1796 MUST be set to 0 on transmission and MUST be ignored on reception. 1798 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1800 o Duplicate objects, duplicate parameters, and/or multiple 1801 occurrences of a parameter MUST NOT be used. 1803 0 1 2 3 1804 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 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Common QSPEC Header | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 // QSPEC Control Information // 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 // QSPEC QoS Description Objects // 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 The Common QSPEC Header is a fixed 4-byte long object containing the 1814 QOSM ID and an identifier for the QSPEC Procedure (see Section 6): 1816 0 1 2 3 1817 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 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Vers. | QOSM ID | QSPEC Proc. | Reserved | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 Note that a length field is not necessary since the overall length of 1823 the QSPEC is contained in the higher level QoS NSLP data object. 1825 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1827 QOSM ID: Identifies the particular QOSM being used by the QNI. It is 1828 assigned by IANA. 1830 QSPEC Proc.: Is composed of two times 4 bits. The first set of bits 1831 identifies the Message Sequence, the second set 1832 identifies the QSPEC Object Combination used for this 1833 particular message sequence: 1835 0 1 2 3 4 5 6 7 1836 +-+-+-+-+-+-+-+-+ 1837 |Mes.Sq |Obj.Cmb| 1838 +-+-+-+-+-+-+-+-+ 1840 The Message Sequence field can attain the following 1841 values: 1843 0: Sender-Initiated Reservations 1844 1: Receiver-Initiated Reservations 1845 2: Resource Queries 1847 The Object Combination field can take the values between 1848 1 and 3 indicated in the tables in Section 6: 1849 Message Sequence: 0 1850 Object Combination: 1, 2, 3 1851 Semantic: see table in Section 6.1 1852 Message Sequence: 1 1853 Object Combination: 1, 2, 3 1854 Semantic: see table in Section 6.2 1855 Message Sequence: 2 1856 Object Combination: 1, 2, 3 1857 Semantic: see table in Section 6.3 1859 The QSPEC Control Information is a variable length object containing 1860 one or more parameters. The QSPEC Objects field is a collection of 1861 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1862 common format and each contain several parameters. 1864 Both the QSPEC Control Information object and the QSPEC QoS objects 1865 share a common header format: 1867 0 1 2 3 1868 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 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 |E|Q|r|r| Object Type |r|r|r|r| Length | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 E Flag: Set if an error occurs on object level 1874 Q Flag: NON QOSM Hop flag: This field is set to 1 if a QOSM different 1875 from the initiator QOSM is encountered by the QNE. 1876 Object Type = 0: control information (read-only/read-write status is 1877 parameter specific) 1878 = 1: QoS Desired (parameters are all read-only) 1879 = 2: QoS Available (parameters are either all read-write 1880 rr all read-only; see Section 6) 1881 = 3: QoS Reserved (parameters are all read-only) 1882 = 4: Minimum QoS (parameters are all read-only) 1884 Note that parameters contained in QoS Description objects are all 1885 read-write or all read-only, as specified above. In the Control 1886 Information object, read-only or read-write is parameter specific. 1888 The r bits are reserved. 1890 Each QSPEC-1 or QSPEC-2 parameter within an object can be similarly 1891 encoded in TLV format using a similar parameter header: 1893 0 1 2 3 1894 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 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 |M|E|N|R| Parameter ID |r|r|r|r| Length | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 M Flag: When set indicates the subsequent parameter is a QSPEC-1 1900 parameter and MUST be interpreted. Otherwise the parameter is 1901 QSPEC-2 and can be ignored if not understood. 1902 E Flag: When set indicates either a) a reservation failure where the 1903 QSPEC parameter is not met, or b) an error occurred when this 1904 parameter was being interpreted (see Section 4.3.3.1). 1905 N Flag: Not-supported QSPEC parameter flag (see Section 4.3.3.3). 1906 For QSPEC-1 parameters the value of this flag is always zero. 1907 R Flag: Remapped, approximated, or otherwise not strictly interpreted 1908 QSPEC parameter flag (see Section 4.3.3.2) 1909 Parameter ID: Assigned to each parameter (see below) 1911 Parameters are usually coded individually, for example, the parameter (Section 7.2.1). However, it is also possible 1913 to combine several sub-parameters into one parameter field, which is 1914 called 'container coding'. This coding is useful if either a) the 1915 sub-parameters always occur together, as for example the several 1916 sub-parameters that jointly make up the token bucket, or b) in order 1917 to make coding more efficient when the length of each sub-parameter 1918 value is much less than a 32-bit word (as for example described in 1919 [RMD-QOSM]) and to avoid header overload. When a container is 1920 defined, the Parameter ID and the M, E, N, and R flags refer to the 1921 container. Examples of container parameters are , , , and , as specified below, and the 1923 PHR container parameter specified in [RMD-QOSM]. 1925 7.2 QSPEC-1 Parameter Coding 1927 7.2.1 Parameter 1929 0 1 2 3 1930 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 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 |1|E|0|R| 1 |r|r|r|r| 1 | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | Excess Trtmnt | Remark Value | Reserved | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 1937 traffic, that is, traffic not covered by the parameter. 1938 The excess treatment parameter is set by the QNI. It is a read-only 1939 parameter. Allowed values are as follows: 1941 0: drop 1942 1: shape 1943 2: remark 1944 3: no metering or policing is permitted 1946 The default excess treatment in case that none is specified is that 1947 there are no guarantees to excess traffic, i.e. a QNE can do whatever 1948 it finds suitable. 1950 When excess treatment is set to 'drop', all marked traffic MUST be 1951 dropped by the QNE/RMF. 1953 When excess treatment is set to 'shape', it is expected that the 1954 QoS Desired object carries a token bucket parameter. Excess traffic 1955 is to be shaped to this token bucket. When the shaping causes 1956 unbounded queue grow at the shaper traffic can be dropped. 1958 When excess treatment is set to 'remark', the excess treatment 1959 parameter MUST carry the remark value, and the remark values and 1960 procedures MUST be specified in the QOSM specification document. 1961 For example, packets may be remarked to drop remarked to pertain to a 1962 particular QoS class". In the latter case, remarking relates to a 1963 DiffServ-type model, where packets arrive marked as belonging to a 1964 certain QoS class, and when they are identified as excess, they 1965 should then be remarked to a different QoS Class. 1967 If 'no metering or policing is permitted' is signaled, the QNE should 1968 accept the excess treatment parameter set by the sender with special 1969 care so that excess traffic should not cause a problem. To request 1970 the Null Meter [RFC3290] is especially strong, and should be used 1971 with caution. 1973 A NULL metering application [RFC2997] would not include the traffic 1974 profile, and conceptually it should be possible to support this with 1975 the QSPEC. A QSPEC without a traffic profile is not excluded by the 1976 current specification. However, note that the traffic profile is 1977 important even in those cases when the excess treatment is not 1978 specified, e.g., in negotiating bandwidth for the best effort 1979 aggregate. However, a "NULL Service QOSM" would need to be specified 1980 where the desired QNE Behavior and the corresponding QSPEC format are 1981 described. 1983 As an example behavior for a NULL metering, in the properly 1984 configured DiffServ router, the resources are shared between the 1985 aggregates by the scheduling disciplines. Thus, if the incoming rate 1986 increases, it will influence the state of a queue within that 1987 aggregate, while all the other aggregates will be provided sufficient 1988 bandwidth resources. NULL metering is useful for best effort and 1989 signaling data, where there is no need to meter and police this data 1990 as it will be policed implicitly by the allocated bandwidth and, 1991 possibly, active queue management mechanism. 1993 7.2.2 Parameter 1995 = 1997 = link bandwidth needed by flow [RFC2212, RFC2215] 1999 =

[RFC2210] 2001 The above notation means that either or 2002 sub-parameters can be populated in the parameter. Note 2003 that an QSPEC-2 second token bucket QSPEC parameter 2004 is specified below in Section 7.3.1. The references in the following 2005 sections point to the normative procedures for processing the 2006 and sub-parameters. 2008 The coding for the parameter is as follows: 2010 0 1 2 3 2011 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 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 |1|E|0|R| 2 |r|r|r|r| 1/5 | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | Bandwidth/Token Bucket Rate-1 [r] | 2016 | (32-bit IEEE floating point number) | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | Token Bucket Size-1 [b] (32-bit IEEE floating point number) | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Maximum Packet Size-1 [MTU] (32-bit unsigned integer) | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 If Length = 1, then the parameter is interpreted as 2028 . If Length = 5, then the parameter is 2029 interpreted as . 2031 7.2.2.1 Sub-Parameter [RFC2212, RFC2215] 2033 The parameter MUST be nonnegative and is measured in 2034 bytes per second and has the same range and suggested representation 2035 as the bucket and peak rates of the . can 2036 be represented using single-precision IEEE floating point. The 2037 representation MUST be able to express values ranging from 1 byte per 2038 second to 40 terabytes per second. For values of this parameter only 2039 valid non-negative floating point numbers are allowed. Negative 2040 numbers (including "negative zero"), infinities, and NAN's are not 2041 allowed. 2043 A QNE MAY export a local value of zero for this parameter. A network 2044 element or application receiving a composed value of zero for this 2045 parameter MUST assume that the actual bandwidth available is unknown. 2047 7.2.2.2 Sub-Parameters [RFC2215] 2049 The parameters are represented by three floating point 2050 numbers in single-precision IEEE floating point format followed by 2051 two 32-bit integers in network byte order. The first floating point 2052 value is the rate (r), the second floating point value is the bucket 2053 size (b), the third floating point is the peak rate (p), the first 2054 unsigned integer is the minimum policed unit (m), and the second 2055 unsigned integer is the maximum datagram size (MTU). 2057 Note that the two sets of parameters can be 2058 distinguished, as could be needed for example to support DiffServ 2059 applications. 2061 When r, b, and p terms are represented as IEEE floating point values, 2062 the sign bit MUST be zero (all values MUST be non-negative). 2063 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 2064 than 162 (i.e., positive 35) are discouraged, except for specifying a 2065 peak rate of infinity. Infinity is represented with an exponent of 2066 all ones (255) and a sign bit and mantissa of all zeroes. 2068 7.2.3 Parameter 2070 = 2072 The above notation means that either , , 2073 or sub-parameters MAY be populated in the parameter. Normally only one of these sub-parameters is 2075 populated in . If more than one sub-parameter is 2076 populated, the QOSM specification document MUST give procedures for 2077 processing multiple sub-parameters. The references in the following 2078 sections point to the normative procedures for processing the , , and sub-parameters. 2081 The coding for the parameter is as follows: 2083 0 1 2 3 2084 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 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 |1|E|0|R| 3 |r|r|r|r| 3 | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | DSCP |0 0 0 0 0 0 0 0 0 0|DSTE Cls. Type |Y.1541 QoS Cls.| 2089 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2090 | QoS Class Parameters (Reserved) | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | QoS Class Parameters (Reserved) | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 7.2.3.1 Sub-Parameter [RFC3140] 2097 As prescribed in RFC 3140, the encoding for a single PHB is the 2098 recommended DSCP value for that PHB, left-justified in the 16 bit 2099 field, with bits 6 through 15 set to zero. 2101 The encoding for a set of PHBs is the numerically smallest of the set 2102 of encodings for the various PHBs in the set, with bit 14 set to 1. 2103 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 2104 bit 14 set to 1.) 2106 0 1 2107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | DSCP |0 0 0 0 0 0 0 0 X 0| 2110 +---+---+---+---+---+---+---+---+ 2112 PHBs not defined by standards action, i.e., experimental or 2113 local use PHBs as allowed by [RFC2474]. In this case an arbitrary 2114 12 bit PHB identification code, assigned by the IANA, is placed 2115 left-justified in the 16 bit field. Bit 15 is set to 1, and bit 14 2116 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are 2117 zero. 2119 0 1 2120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | PHD ID CODE |0 0 X 0| 2123 +---+---+---+---+---+---+---+---+ 2125 Bits 12 and 13 are reserved either for expansion of the PHB 2126 identification code, or for other use, at some point in the future. 2128 In both cases, when a single PHBID is used to identify a set of PHBs 2129 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 2130 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 2131 intra-microflow traffic reordering when different PHBs from the set 2132 are applied to traffic in the same microflow). The set of AF1x PHBs 2133 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs 2134 that do not constitute a PHB Scheduling Class can be identified by 2135 using more than one PHBID. 2137 The registries needed to use RFC 3140 already exist, see 2138 [DSCP-REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs 2139 to be created for this purpose. 2141 7.2.3.2 Sub-Parameter [RFC4124] 2143 DSTE Class Type: Indicates the DSTE class type. Values currently 2144 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 2145 that the parameter is not used. 2147 7.2.3.3 Sub-Parameter [Y.1541] 2149 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 2150 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 2151 that the parameter is not used. 2153 Class 0: 2154 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 2155 Real-time, highly interactive applications, sensitive to jitter. 2156 Application examples include VoIP, Video Teleconference. 2158 Class 1: 2159 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 2160 Real-time, interactive applications, sensitive to jitter. 2161 Application examples include VoIP, Video Teleconference. 2163 Class 2: 2164 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 2165 10^-3. Highly interactive transaction data. Application examples 2166 include signaling. 2168 Class 3: 2169 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 2170 10^-3. Interactive transaction data. Application examples include 2171 signaling. 2173 Class 4: 2174 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 2175 10^-3. Low Loss Only applications. Application examples include 2176 short transactions, bulk data, video streaming. 2178 Class 5: 2179 Mean delay unspecified, delay variation unspecified, loss ratio 2180 unspecified. Unspecified applications. Application examples include 2181 traditional applications of default IP networks. 2183 Class 6: 2184 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 2185 Applications that are highly sensitive to loss, such as television 2186 transport, high-capacity TCP transfers, and TDM circuit emulation. 2188 Class 7: 2189 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 2190 Applications that are highly sensitive to loss, such as television 2191 transport, high-capacity TCP transfers, and TDM circuit emulation. 2193 7.2.4 Parameter 2195 = 2196 2198 The above notation means that either , 2199 , , and/or 2200 sub-parameters MAY be populated in the parameter. Any or 2201 all of these sub-parameters may be populated in the 2202 parameter. The references in the following sections point to the 2203 normative procedures for processing the , 2204 , , and 2205 sub-parameters. 2207 The following cases are permissible (procedures specified in 2208 references): 2210 1 parameter: [Y.1571] 2211 2 parameters: , [RFC4412] 2212 2 parameters: , [RFC3181] 2213 3 parameters: , , 2214 [3GPP-1, 3GPP-2, 3GPP-3] 2215 4 parameers: , , 2216 , [3GPP-1, 3GPP-2, 2217 3GPP-3] 2219 It is permissible to have without , but not permissible to have without 2221 (alternatively is ignored in 2222 instances without ). 2224 eMLPP-like functionality (as defined in [3GPP-1, 3GPP-2]) specifies 2225 use of corresponding to the 'queuing allowed' 2226 part of eMLPP as well as 2227 corresponding to the 'preemption capable' and 'may be preempted' 2228 parts of eMLPP. 2230 The coding for the parameter is as follows: 2232 0 1 2 3 2233 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 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 |1|E|0|R| 4 |r|r|r|r| 4 | 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | Preemption Priority | Defending Priority | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 + Admission | RPH Namespace | RPH Priority | 2240 + Priority | | | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | Priority Parameters(Reserved) | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Priority Parameters(Reserved) | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 7.2.4.1 & Sub-Parameters 2248 [RFC3181] 2250 Preemption Priority: The priority of the new flow compared with the 2251 defending priority of previously admitted flows. Higher values 2252 represent higher priority. 2254 Defending Priority: Once a flow is admitted, the preemption priority 2255 becomes irrelevant. Instead, its defending priority is used to 2256 compare with the preemption priority of new flows. 2258 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 2260 parameter is used. 2262 7.2.4.2 Sub-Parameter [Y.1571] 2264 High priority flows, normal priority flows, and best-effort priority 2265 flows can have access to resources depending on their admission 2266 priority value, as described in [Y.1571], as follows: 2268 Admission Priority: 2270 0 - best-effort priority flow 2271 1 - normal priority flow 2272 2 - high priority flow 2273 255 - not used 2275 A reservation without an sub-parameter (i.e., 2276 set to 255) MUST be treated as a reservation with an = 1. 2279 7.2.4.3 Sub-Parameter [RFC4412] 2281 [RFC4412] defines a resource priority header (RPH) with parameters 2282 "RPH Namespace" and "RPH Priority" combination, and if populated is 2283 applicable only to flows with high admission priority, as follows: 2285 RPH Namespace: 2287 0 - dsn 2288 1 - drsn 2289 2 - q735 2290 3 - ets 2291 4 - wps 2292 255 - not used 2294 RPH Priority: 2295 Each namespace has a finite list of relative priority-values. Each 2296 is listed here in the order of lowest priority to highest priority 2297 (note that dsn and drsn priority values are TBD): 2299 4 - q735.4 2300 3 - q735.3 2301 2 - q735.2 2302 1 - q735.1 2303 0 - q735.0 2305 4 - ets.4 2306 3 - ets.3 2307 2 - ets.2 2308 1 - ets.1 2309 0 - ets.0 2311 4 - wps.4 2312 3 - wps.3 2313 2 - wps.2 2314 1 - wps.1 2315 0 - wps.0 2317 Note that the parameter MAY be used in 2318 combination with the parameter, which depends on the 2319 supported QOSM. Furthermore, if more then one RPH namespace is 2320 supported by a QOSM, then the QOSM MUST specify how the mapping 2321 between the priorities belonging to the different RPH namespaces are 2322 mapped to each other. 2324 Note also that additional work is needed to communicate these flow 2325 priority values to bearer-level network elements 2326 [VERTICAL-INTERFACE]. 2328 7.3 QSPEC-2 Parameter Coding 2330 7.3.1 Parameter [RFC2215] 2332 A second, QSPEC-2 parameter is specified, as could 2333 be needed for example to support DiffServ applications [xxxx]. 2335 Parameter Values: 2337 0 1 2 3 2338 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 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 |0|E|N|R| 5 |r|r|r|r| 5 | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | Token Bucket Rate-2 [r] (32-bit IEEE floating point number) | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | Token Bucket Size-2 [b] (32-bit IEEE floating point number) | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Maximum Packet Size-2 [MTU] (32-bit unsigned integer) | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 When r, b, and p terms are represented as IEEE floating point values, 2354 the sign bit MUST be zero (all values MUST be non-negative). 2355 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 2356 than 162 (i.e., positive 35) are discouraged, except for specifying a 2357 peak rate of infinity. Infinity is represented with an exponent of 2358 all ones (255) and a sign bit and mantissa of all zeroes. 2360 7.3.2 Parameter [RFC2210, RFC2215] 2362 0 1 2 3 2363 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 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 |0|E|N|R| 6 |r|r|r|r| 1 | 2366 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2367 | Path Latency (32-bit integer) | 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 The Path Latency is a single 32-bit integer in network byte order. 2371 The composition rule for the parameter is summation 2372 with a clamp of (2**32 - 1) on the maximum value. The latencies are 2373 average values reported in units of one microsecond. A system with 2374 resolution less than one microsecond MUST set unused digits to zero. 2375 An individual QNE can advertise a latency value between 1 and 2**28 2376 (somewhat over two minutes) and the total latency added across all 2377 QNEs can range as high as (2**32)-2. If the sum of the different 2378 elements delays exceeds (2**32)-2, the end-to-end advertised delay 2379 SHOULD be reported as indeterminate. A QNE that cannot accurately 2380 predict the latency of packets it is processing MUST raise the 2381 not-supported flagand either leave the value of Path Latency as is, 2382 or add its best estimate of its lower bound. A raised not-supported 2383 flagflag indicates the value of Path Latency is a lower bound of the 2384 real Path Latency. The distinguished value (2**32)-1 is taken to 2385 mean indeterminate latency because the composition function limits 2386 the composed sum to this value, it indicates the range of the 2387 composition calculation was exceeded. 2389 7.3.3 Parameter 2391 0 1 2 3 2392 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 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 |0|E|N|R| 7 |r|r|r|r| 3 | 2395 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2396 | Path Jitter STAT1(variance) (32-bit integer) | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | Path Jitter STAT4(Reserved) (32-bit integer) | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 The Path Jitter is a set of four 32-bit integers in network byte 2406 order. The Path Jitter parameter is the combination of four 2407 statistics describing the Jitter distribution with a clamp of 2408 (2**32 - 1) on the maximum of each value. The jitter STATs are 2409 reported in units of one microsecond. A system with resolution less 2410 than one microsecond MUST set unused digits to zero. An individual 2411 QNE can advertise jitter values between 1 and 2**28 (somewhat over 2412 two minutes) and the total jitter computed across all QNEs can range 2413 as high as (2**32)-2. If the combination of the different element 2414 values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be 2415 reported as indeterminate. A QNE that cannot accurately predict the 2416 jitter of packets it is processing MUST raise the not-supported flag 2417 and either leave the value of Path Jitter as is, or add its best 2418 estimate of its STAT values. A raised not-supported flag indicates 2419 the value of Path Jitter is a lower bound of the real Path Jitter. 2420 The distinguished value (2**32)-1 is taken to mean indeterminate 2421 jitter. A QNE that cannot accurately predict the jitter of packets 2422 it is processing SHOULD set its local parameter to this value. 2423 Because the composition function limits the total to this value, 2424 receipt of this value at a network element or application indicates 2425 that the true path jitter is not known. This MAY happen because one 2426 or more network elements could not supply a value, or because the 2427 range of the composition calculation was exceeded. 2429 NOTE: The Jitter composition function makes use of the 2430 parameter. Composition functions for loss, latency and jitter may be 2431 found in [Y.1541]. 2433 7.3.4 Parameter 2435 0 1 2 3 2436 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 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 |0|E|N|R| 8 |r|r|r|r| 1 | 2439 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2440 | Path Packet Loss Ratio (32-bit floating point) | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 The Path PLR is a single 32-bit single precision IEEE floating point 2444 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 2446 value. The PLRs are reported in units of 10^-11. A system with 2447 resolution less than one microsecond MUST set unused digits to zero. 2448 An individual QNE can advertise a PLR value between zero and 10^-2 2449 and the total PLR added across all QNEs can range as high as 10^-1. 2450 If the sum of the different elements values exceeds 10^-1, the 2451 end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE 2452 that cannot accurately predict the PLR of packets it is processing 2453 MUST raise the not-supported flag and either leave the value of Path 2454 PLR as is, or add its best estimate of its lower bound. A raised 2455 not-supported flag indicates the value of Path PLR is a lower bound 2456 of the real Path PLR. The distinguished value 10^-1 is taken to mean 2457 indeterminate PLR. A QNE which cannot accurately predict the PLR of 2458 packets it is processing SHOULD set its local parameter to this 2459 value. Because the composition function limits the composed sum to 2460 this value, receipt of this value at a network element or application 2461 indicates that the true path PLR is not known. This MAY happen 2462 because one or more network elements could not supply a value, or 2463 because the range of the composition calculation was exceeded. 2465 7.3.5 Parameter 2467 0 1 2 3 2468 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 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 |0|E|N|R| 9 |r|r|r|r| 1 | 2471 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2472 | Path Packet Error Ratio (32-bit floating point) | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 The Path PER is a single 32-bit single precision IEEE floating point 2476 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 2478 value. The PERs are reported in units of 10^-11. A system with 2479 resolution less than one microsecond MUST set unused digits to zero. 2480 An individual QNE can advertise a PER value between zero and 10^-2 2481 and the total PER added across all QNEs can range as high as 10^-1. 2482 If the sum of the different elements values exceeds 10^-1, the 2483 end-to-end advertised PER SHOULD be reported as indeterminate. A QNE 2484 that cannot accurately predict the PER of packets it is processing 2485 MUST raise the not-supported flag and either leave the value of Path 2486 PER as is, or add its best estimate of its lower bound. A raised 2487 not-supported flag indicates the value of Path PER is a lower bound 2488 of the real Path PER. The distinguished value 10^-1 is taken to mean 2489 indeterminate PER. A QNE which cannot accurately predict the PER of 2490 packets it is processing SHOULD set its local parameter to this 2491 value. Because the composition function limits the composed sum to 2492 this value, receipt of this value at a network element or application 2493 indicates that the true path PER is not known. This MAY happen 2494 because one or more network elements could not supply a value, or 2495 because the range of the composition calculation was exceeded. 2497 7.3.6 Parameters [RFC2210, RFC2212, 2498 RFC2215] 2500 0 1 2 3 2501 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 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 |0|E|N|R| 10 |r|r|r|r| 1 | 2504 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2505 | End-to-end composed value for C [Ctot] (32-bit integer) | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 0 1 2 3 2509 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 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 |0|E|N|R| 11 |r|r|r|r| 1 | 2512 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2513 | End-to-end composed value for D [Dtot] (32-bit integer) | 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 0 1 2 3 2517 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 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 |0|E|N|R| 12 |r|r|r|r| 1 | 2520 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2521 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 0 1 2 3 2525 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 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 |0|E|N|R| 13 |r|r|r|r| 1 | 2528 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2529 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 The error term C is measured in units of bytes. An individual QNE 2532 can advertise a C value between 1 and 2**28 (a little over 250 2533 megabytes) and the total added over all QNEs can range as high as 2534 (2**32)-1. Should the sum of the different QNEs delay exceed 2535 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 2536 error term D is measured in units of one microsecond. An individual 2537 QNE can advertise a delay value between 1 and 2**28 (somewhat over 2538 two minutes) and the total delay added over all QNEs can range as 2539 high as (2**32)-1. Should the sum of the different QNEs delay 2540 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 2542 7.3.7 Parameter [RFC2212, RFC2215] 2544 0 1 2 3 2545 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 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 |0|E|N|R| 14 |r|r|r|r| 1 | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | Slack Term [S] (32-bit integer) | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 Slack term S MUST be nonnegative and is measured in microseconds. 2553 The Slack term, S, can be represented as a 32-bit integer. Its value 2554 can range from 0 to (2**32)-1 microseconds. 2556 8. Security Considerations 2558 The priority parameter raises possibilities for theft of service 2559 attacks because users could claim an emergency priority for their 2560 flows without real need, thereby effectively preventing serious 2561 emergency calls to get through. Several options exist for countering 2562 such attacks, for example 2564 - only some user groups (e.g. the police) are authorized to set the 2565 emergency priority bit 2567 - any user is authorized to employ the emergency priority bit for 2568 particular destination addresses (e.g. police) 2570 9. IANA Considerations 2572 This section defines the registries and initial codepoint assignments 2573 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 2574 It also defines the procedural requirements to be followed by IANA in 2575 allocating new codepoints. 2577 This specification creates the following registries with the 2578 structures as defined below: 2580 Object Types (12 bits): 2581 The following values are allocated by this specification: 2583 0-4: assigned as specified in Section 7: 2584 Object Type = 0: control information 2585 = 1: QoS Desired 2586 = 2: QoS Available 2587 = 3: QoS Reserved 2588 = 4: Minimum QoS 2589 The allocation policies for further values are as follows: 2590 5-63: Standards Action 2591 64-127: Private/Experimental Use 2592 128-4095: Reserved 2593 (Note: 'Reserved' just means 'do not give these out'.) 2595 QSPEC Version (4 bits): 2596 The following value is allocated by this specification: 2597 0: assigned to Version 0 QSPEC 2598 The allocation policies for further values are as follows: 2599 1-15: Standards Action 2600 A specification is required to depreciate, delete, or modify QSPEC 2601 versions. 2603 QOSM ID (12 bits): 2604 The allocation policies are as follows: 2605 0-63: Specification Required 2606 64-127: Private/Experimental Use 2607 128-4095: Reserved 2608 A specification is required to depreciate, delete, or modify QOSM 2609 IDs. 2611 QSPEC Procedure (8 bits): 2612 Broken down into 2613 Message Sequence (4 bits): 2614 The following values are allocated by this specification: 2615 0-2: assigned as specified in Section 7.1: 2616 Message Sequence 0: 2617 Semantic: QSPEC Procedure = Sender-Initiated Reservations 2618 (see Section 6.1) 2619 Message Sequence 1: 2620 Semantic: QSPEC Procedure = Receiver-Initiated Reservations 2621 (see Section 6.2) 2622 Message Sequence 2: 2623 Semantic: QSPEC Procedure = Resource Queries (see Section 6.3) 2624 The allocation policies for further values are as follows: 2625 3-15: Standards Action 2626 Object Combination (4 bits): 2627 The following values are allocated by this specification: 2628 The Object Combination field can take the values between 2629 1 and 3 indicated in the tables in Section 6: 2630 Message Sequence: 0 2631 Object Combination: 1, 2, 3 2632 Semantic: see table in Section 6.1 2633 Message Sequence: 1 2634 Object Combination: 1, 2, 3 2635 Semantic: see table in Section 6.2 2636 Message Sequence: 2 2637 Object Combination: 1, 2, 3 2638 Semantic: see table in Section 6.3 2639 The allocation policies for further values are as follows: 2640 3-15: Standards Action 2641 A specification is required to depreciate, delete, or modify QSPEC 2642 Procedures. 2644 Error Code (16 bits) 2645 The allocation policies are as follows: 2646 0-127: Specification Required 2647 128-255: Private/Experimental Use 2648 255-65535: Reserved 2649 A specification is required to depreciate, delete, or modify Error 2650 Codes. 2652 Parameter ID (12 bits): 2653 The following values are allocated by this specification: 2654 1-14: assigned as specified in Sections 7.2 and 7.3: 2655 Parameter ID 1: Parameter 2656 2: Parameter 2657 3: Parameter 2658 4: Parameter 2659 5: Parameter 2660 6: Parameter 2661 7: Parameter 2662 8: Parameter 2663 9: Parameter 2664 10: Parameter 2665 11: Parameter 2666 12: Parameter 2667 13: Parameters 2668 14: Parameter 2669 The allocation policies for further values are as follows: 2670 15-63: Standards Action (for QSPEC-1 parameters) 2671 64-127: Specification Required (for QSPEC-2 parameters) 2672 128-255: Private/Experimental Use 2673 255-4095: Reserved 2675 A specification is required to depreciate, delete, or modify 2676 Parameter IDs. Note that if additional QSPEC-1 parameters are 2677 defined in the future, this requires a standards action equivalent to 2678 reissuing this document as a QSPEC-bis. 2680 Excess Treatment Parameter (8 bits): 2681 The following values are allocated by this specification: 2682 0-3: assigned as specified in Section 7.2.1: 2683 Excess Treatment Parameter 0: drop 2684 1: shape 2685 2: remark 2686 3: no metering or policing is 2687 permitted 2688 The allocation policies for further values are as follows: 2689 4-63: Standards Action 2690 64-255: Reserved 2691 Remark Value (8 bits) 2692 The allocation policies are as follows: 2693 0-63: Specification Required 2694 64-127: Private/Experimental Use 2695 128-255: Reserved 2697 DSTE Class Type Sub-Parameter (8 bits): 2698 The following values are allocated by this specification: 2699 0-7: assigned as specified in Section 7.2.3: 2700 DSTE Class Type Sub-Parameter 0: DSTE Class Type 0 2701 1: DSTE Class Type 1 2702 2: DSTE Class Type 2 2703 3: DSTE Class Type 3 2704 4: DSTE Class Type 4 2705 5: DSTE Class Type 5 2706 6: DSTE Class Type 6 2707 7: DSTE Class Type 7 2708 The allocation policies for further values are as follows: 2709 8-63: Standards Action 2710 64-255: Reserved 2712 Y.1541 QoS Class Sub-Parameter (8 bits): 2713 The following values are allocated by this specification: 2714 0-7: assigned as specified in Section 7.2.3: 2715 Y.1541 QoS Class Sub-Parameter 0: Y.1541 QoS Class 0 2716 1: Y.1541 QoS Class 1 2717 2: Y.1541 QoS Class 2 2718 3: Y.1541 QoS Class 3 2719 4: Y.1541 QoS Class 4 2720 5: Y.1541 QoS Class 5 2721 6: Y.1541 QoS Class 6 2722 7: Y.1541 QoS Class 7 2723 The allocation policies for further values are as follows: 2724 8-63: Standards Action 2725 64-255: Reserved 2727 Admission Priority Parameter (8 bits): 2728 The following values are allocated by this specification: 2729 0-2: assigned as specified in Section 7.2.4: 2730 Admission Priority 0: best-effort priority flow 2731 1: normal priority flow 2732 2: high priority flow 2733 255: admission priority not used 2734 The allocation policies for further values are as follows: 2735 3-63: Standards Action 2736 64-254: Reserved 2738 RPH Namespace Parameter (16 bits): 2739 Note that [RFC4412] creates a registry for RPH Namespace and Priority 2740 values already (see Section 12.6 of [RFC4412]). A QSPEC registry is 2741 also created because the assigned values are being mapped to QSPEC 2742 parameter values. The following values are allocated by this 2743 specification: 2744 0-5: assigned as specified in Section 7.2.4: 2745 The allocation policies for further values are as follows: 2746 6-63: Standards Action 2747 64-65535: Reserved 2749 RPH Priority Parameter (8 bits): 2750 dsn namespace: 2751 The allocation policies are as follows: 2752 0-63: Standards Action 2753 64-255: Reserved 2754 drsn namespace: 2755 The allocation policies are as follows: 2756 0-63: Standards Action 2757 64-255: Reserved 2758 Q735 namespace: 2759 The following values are allocated by this specification: 2760 0-4: assigned as specified in Section 7.2.4: 2761 Q735 priority 4: q735.4 2762 3: q735.3 2763 2: q735.2 2764 1: q735.1 2765 0: q735.0 2766 The allocation policies for further values are as follows: 2767 5-63: Standards Action 2768 64-255: Reserved 2769 ets namespace: 2770 The following values are allocated by this specification: 2771 0-4: assigned as specified in Section 7.2.4: 2772 ETS priority 4: ets.4 2773 3: ets.3 2774 2: ets.2 2775 1: ets.1 2776 0: ets.0 2777 The allocation policies for further values are as follows: 2778 5-63: Standards Action 2779 64-255: Reserved 2780 wts namespace: 2781 The following values are allocated by this specification: 2782 0-4: assigned as specified in Section 7.2.4: 2783 WPS priority 4: wps.4 2784 3: wps.3 2785 2: wps.2 2786 1: wps.1 2787 0: wps.0 2788 The allocation policies for further values are as follows: 2789 5-63: Standards Action 2790 64-255: Reserved 2792 10. Acknowledgements 2794 The authors would like to thank (in alphabetical order) David Black, 2795 Ken Carlberg, Anna Charny, Adrian Farrel, Matthias Friedrich, 2796 Xiaoming Fu, Janet Gunn, Robert Hancock, Chris Lang, Jukka Manner, An 2797 Nguyen, Dave Oran, Tom Phelan, James Polk, Alexander Sayenko, John 2798 Rosenberg, Bernd Schloer, Hannes Tschofenig, and Sven van den Bosch 2799 for their very helpful suggestions. 2801 11. Normative References 2803 [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd 2804 Generation Partnership Project; Technical Specification Group 2805 Services and System Aspects; enhanced Multi Level Precedence and 2806 Preemption service (eMLPP) - Stage 1 (Release 7). 2807 [3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd 2808 Generation Partnership Project; Technical Specification Group Core 2809 Network; enhanced Multi-Level Precedence and Preemption service 2810 (eMLPP) - Stage 2 (Release 7). 2811 [3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd 2812 Generation Partnership Project; Technical Specification Group Core 2813 Network; enhanced Multi-Level Precedence and Preemption service 2814 (eMLPP) - Stage 3 (Release 6). 2815 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 2816 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 2817 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 2818 Signaling Transport," work in progress. 2819 [QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service 2820 Signaling," work in progress. 2821 [RFC1832] Srinivasan, R., "XDR: External Data Representation 2822 Standard," RFC 1832, August 1995. 2823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2824 Requirement Levels", BCP 14, RFC 2119, March 1997. 2825 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2826 Services", RFC 2210, September 1997. 2827 [RFC2212] Shenker, S., et. al., "Specification of Guaranteed Quality 2828 of Service," September 1997. 2829 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 2830 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 2831 1997. 2832 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 2833 Services", RFC 2475, December 1998. 2834 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2835 Codes," June 2001. 2836 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element," 2837 RFC 3181, October 2001. 2839 [RFC3290] Bernet, Y., et. al., "An Informal Management Model for 2840 Diffserv Routers," RFC 3290, May 2002. 2841 [RFC4124] Le Faucheur, F., et. al., "Protocol Extensions for Support 2842 of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2005. 2843 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 2844 Priority for the Session Initiation Protocol(SIP)," RFC 4412, 2845 February 2006. 2846 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 2847 for IP-Based Services," May 2002. 2848 [Y.1571] ITU-T Recommendation Y.1571, "Admission Control Priority 2849 Levels in Next Generation Networks," July 2006. 2851 12. Informative References 2853 [DQOS] Cablelabs, "PacketCable Dynamic Quality of Service 2854 Specification," CableLabs Specification PKT-SP-DQOS-I12-050812, 2855 August 2005. 2856 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 2857 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 2858 754-1985, August 1985. 2859 [CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 2860 Controlled-Load Service with NSIS," work in progress. 2861 [NETWORK-BYTE-ORDER] Wikipedia, "Endianness," 2862 http://en.wikipedia.org/wiki/Endianness. 2863 [NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work 2864 in progress. 2865 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 2866 Protocol - Capability Set 3" Sep. 2003 2867 [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 2868 -- Version 1 Functional Specification," RFC 2205, September 1997. 2869 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 2870 IANA Considerations Section in RFCs," RFC 3181, October 1998. 2871 [RFC2474] Nichols, K., et. al., "Definition of the Differentiated 2872 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 2873 December 1998. 2874 [RFC2597] Heinanen, J., et. al., "Assured Forwarding PHB Group," RFC 2875 2597, June 1999. 2876 [RFC2997] Bernet, Y., et. al., "Specification of the Null Service 2877 Type," RFC 2997, November 2000. 2878 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2879 Codes," RFC 3140, June 2001. 2880 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 2881 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 2882 [RFC3564] Le Faucheur, F., et. al., Requirements for Support of 2883 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 2884 July 2003 2885 [RFC3726] Brunner, M., et. al., "Requirements for Signaling 2886 Protocols", RFC 3726, April 2004. 2887 [RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management 2888 in Diffserv QOS Model," work in progress. 2889 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 2890 on Associating of Control Signaling Messages with Media Priority 2891 Levels," T1S1.7 & PRQC, October 2004. 2892 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 2893 Communication Service - IP Packet Transfer and Availability 2894 Performance Parameters," December 2002. 2895 [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 2896 Networks Using Y.1541 QoS Classes," work in progress. 2898 13. Authors' Addresses 2900 Jerry Ash (Editor) 2901 AT&T 2902 Room MT D5-2A01 2903 200 Laurel Avenue 2904 Middletown, NJ 07748, USA 2905 Phone: +1-(732)-420-4578 2906 Fax: +1-(732)-368-8659 2907 Email: gash@att.com 2909 Attila Bader (Editor) 2910 Traffic Lab 2911 Ericsson Research 2912 Ericsson Hungary Ltd. 2913 Laborc u. 1 H-1037 2914 Budapest Hungary 2915 Email: Attila.Bader@ericsson.com 2917 Cornelia Kappler (Editor) 2918 Siemens AG 2919 Siemensdamm 62 2920 Berlin 13627 2921 Germany 2922 Email: cornelia.kappler@siemens.com 2924 Appendix A: Mapping of QoS Desired, QoS Available and QoS Reserved of 2925 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 2927 The union of QoS Desired, QoS Available and QoS Reserved can provide 2928 all functionality of the objects specified in RSVP IntServ, however 2929 it is difficult to provide an exact mapping. 2931 In RSVP, the Sender TSpec specifies the traffic an application is 2932 going to send (e.g. token bucket). The AdSpec can collect path 2933 characteristics (e.g. delay). Both are issued by the sender. The 2934 receiver sends the FlowSpec which includes a Receiver TSpec 2935 describing the resources reserved using the same parameters as the 2936 Sender TSpec, as well as a RSpec which provides additional IntServ 2937 QoS Model specific parameters, e.g. Rate and Slack. 2939 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 2940 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 2941 knowledge of the authors it is not possible for the sender to specify 2942 a desired maximum delay except implicitly and mutably by seeding the 2943 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 2944 the receiver-issued RSVP RESERVE message. For this reason our 2945 discussion at this point leads us to a slightly different mapping of 2946 necessary functionality to objects, which should result in more 2947 flexible signaling models. 2949 Appendix B: Main Changes Since Last Version & Open Issues 2951 B.1 Main Changes Since Version -04 2953 Version -05: 2955 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 2956 - discarded QSPEC parameter (Maximum packet size) since MTU 2957 discovery is expected to be handled by procedure currently defined 2958 by PMTUD WG 2959 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 2960 efficiency 2961 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 2962 - revised Section 6.2.2 on SIP priorities 2963 - added QSPEC procedures for "RSVP-style reservation", resource 2964 queries and bidirectional reservations in Sec. 7.1 2965 - reworked Section 7.2 2967 Version -06: 2969 - defined "not-supported flag" and "tunneled parameter flag" 2970 (subsumes "QSPEC-2 parameter flag") 2971 - defined "error flag" for error handling 2972 - updated bit error rate (BER) parameter to packet loss ratio (PLR) 2973 parameter 2974 - added packet error ratio (PER) parameter 2975 - coding checked by independent expert 2976 - coding updated to include RE flags in QSPEC objects and MENT flags 2977 in QSPEC parameters 2979 Version -07: 2981 - added text (from David Black) on DiffServ QSPEC example in Section 2982 6 2983 - re-numbered QSPEC parameter IDs to start with 0 (Section 7) 2984 - expanded IANA Considerations Section 9 2986 Version -08: 2988 - update to 'RSVP-style' reservation in Section 6.1.2 to mirror what 2989 is done in RSVP 2990 - modified text (from David Black) on DiffServ QSPEC example in 2991 Section 6.2 2993 - update to general QSPEC parameter formats in Section 7.1 (length 2994 restrictions, etc.) 2995 - re-numbered QSPEC parameter IDs in Section 7.2 2996 - modified parameter values in Section 7.2.2 2997 - update to reservation priority Section 7.2.7 2998 - specify the 3 "STATS" in the parameter, Section 2999 7.2.9.4 3000 - minor updates to IANA Considerations Section 9 3002 Version -09: 3004 - remove the DiffServ example in Section 6.2 (intent is use text as a 3005 basis for a separate DIFFSERV-QOSM I-D) 3006 - update wording in example in Section 4.3, to reflect use of default 3007 QOSM and QOSM selection by QNI 3008 - make minor changes to Section 7.2.7.2, per the exchange on the list 3009 - add comment on error codes, after the first paragraph in Section 3010 4.5.1 3012 Version -10: 3014 - rewrote Section 2.0 for clarity 3015 - added clarifications on QSPEC-1 parameters in Section 4.2; added 3016 discussion of forwarding options when a domain supports a different 3017 QOSM than the QNI 3018 - expanded Section 4.5 on error code handling, including redefined 3019 E-Flag and editorial changes to the N-Flag and T-Flag discussions 3020 - made some editorial clarifications in Section 4.6 on defining new 3021 mandatory (QSPEC-1) parameters, and also reference the 3022 [NSIS-EXTENSIBILITY] document 3023 - Section 4.7 added to identify what a QOSM specification document 3024 must include 3025 - clarified the requirements in Section 5.0 for defining a new QSPEC 3026 Version 3027 - made editorial changes to Section 6, and added procedures for 3028 handling preemption 3029 - removed QOSM ID assignments in Section 9.0; clarified procedures 3030 for defining new QSPEC-1 parameters; added registry of QOSM error 3031 codes 3033 Version -11: 3035 - 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter' 3036 - 'QSPEC-2 parameter' replaces 'optional QSPEC parameter' 3037 - R-flag ('remapped parameter flag') introduced to denote remapping, 3038 approximating, or otherwise not strictly interpreting a QSPEC 3039 parameter 3040 - T-flag ('tunneled parameter flag') eliminated and incorporated 3041 within the R-flag 3042 - Section 4 rewritten on QOSM concept, QSPEC processing, etc. to 3043 provide a more logical flow of information 3045 - read-write/read-only flag associated with QSPEC objects eliminated 3046 and object itself defined as rw or ro without a flag 3047 - parameter redefined as non-QOSM-hop Q-flag 3048 - Section 7 on QSPEC parameter definitions revised to clearly 3049 separate QSPEC-1 parameter coding from QSPEC-2 parameter coding 3050 - , , and QSPEC-1 parameters mapped 3051 to container parameters 3052 - references updated to include normative references defining 3053 procedures to 'strictly interpret' each QSPEC parameter 3054 - Section 7.2.1 on PHB class updated to specify additional RFC 3140 3055 cases 3056 - Section 7.2.1 on excess treatment updated to specify excess 3057 treatment behaviors 3059 B.2 Open Issues 3061 - agreement on 4 QSPEC-1 (formerly called 'mandatory') parameters 3062 - agreement on what is allowed by remapping QSPEC parameters 3063 - agreement on whether to allow a QSPEC-1 parameter to be ignored 3065 Intellectual Property Statement 3067 The IETF takes no position regarding the validity or scope of any 3068 Intellectual Property Rights or other rights that might be claimed to 3069 pertain to the implementation or use of the technology described in 3070 this document or the extent to which any license under such rights 3071 might or might not be available; nor does it represent that it has 3072 made any independent effort to identify any such rights. Information 3073 on the procedures with respect to rights in RFC documents can be 3074 found in BCP 78 and BCP 79. 3076 Copies of IPR disclosures made to the IETF Secretariat and any 3077 assurances of licenses to be made available, or the result of an 3078 attempt made to obtain a general license or permission for the use of 3079 such proprietary rights by implementers or users of this 3080 specification can be obtained from the IETF on-line IPR repository at 3081 http://www.ietf.org/ipr. 3083 The IETF invites any interested party to bring to its attention any 3084 copyrights, patents or patent applications, or other proprietary 3085 rights that may cover technology that may be required to implement 3086 this standard. Please address the information to the IETF at 3087 ietf-ipr@ietf.org. 3089 Disclaimer of Validity 3091 This document and the information contained herein are provided on an 3092 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3093 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3094 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3095 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3096 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3097 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3099 Copyright Statement 3101 Copyright (C) The Internet Society (2006). This document is subject 3102 to the rights, licenses and restrictions contained in BCP 78, and 3103 except as set forth therein, the authors retain all their rights.