idnits 2.17.1 draft-ietf-nsis-qspec-12.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 3099. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3089. ** 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 (October 2006) is 6400 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 2149, but not defined == Missing Reference: 'Ctot' is mentioned on line 2304, but not defined == Missing Reference: 'Dtot' is mentioned on line 2311, but not defined == Missing Reference: 'Csum' is mentioned on line 2319, but not defined == Missing Reference: 'Dsum' is mentioned on line 2327, but not defined == Missing Reference: 'S' is mentioned on line 2348, but not defined == Unused Reference: 'RFC1832' is defined on line 2622, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 2656, but no explicit reference was found in the text == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2661, 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: April 2007 Ericsson 6 Cornelia Kappler 7 Siemens AG 9 October 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 April 4, 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/NSLP Framework . . . . . . . . . . . . . . . . . . . . . . 7 64 5. QSPEC Framework . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1 QSPEC Objects . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.2 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 11 67 5.2.1 QSPEC-1 and QSPEC-2 Parameters . . . . . . . . . . . 11 68 5.2.2 Read-only and Read-write QSPEC Parameters . . . . . . 11 69 5.3 QSPEC Formats . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.3.1 QSPEC Control Information . . . . . . . . . . . . . . 13 71 5.3.2 QoS Description . . . . . . . . . . . . . . . . . . . 13 72 5.3.2.1 . . . . . . . . . . . . . . . . 13 73 5.3.2.2 . . . . . . . . . . . . . . . 15 74 5.3.2.3 . . . . . . . . . . . . . . . 17 75 5.3.2.4 . . . . . . . . . . . . . . . . 17 76 6. QSPEC Processing & Procedures . . . . . . . . . . . . . . . . . 18 77 6.1 Interpreting QSPEC Parameters . . . . . . . . . . . . . . . 18 78 6.2 QSPEC Stacking & Tunneling . . . . . . . . . . . . . . . . 19 79 6.3 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 80 Notification . . . . . . . . . . . . . . . . . . . . . . . 21 81 6.3.1 Reservation Failure & Error E-Flag . . . . . . . . . 22 82 6.3.2 Non-QOSM-Hop Q-Flag & Remapped QSPEC Parameter 83 R-flag . . . . . . . . . . . . . . . . . . . . . . . 22 84 6.3.3 QSPEC Parameter Not Supported N-Flag . . . . . . . . 23 85 6.3.4 INFO_SPEC Coding of Reservation Outcome . . . . . . . 23 86 6.3.5 QNE Generation of a RESPONSE message . . . . . . . . 24 87 6.3.6 Domains Supporting a Different Local QOSM than the 88 QNI . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 6.3.7 Special Cases of QSPEC Stacking . . . . . . . . . . . 26 90 6.4 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 26 91 6.4.1 Sender-Initiated Reservations . . . . . . . . . . . . 26 92 6.4.2 Receiver-Initiated Reservations . . . . . . . . . . . 28 93 6.4.3 Resource Queries . . . . . . . . . . . . . . . . . . 30 94 6.4.4 Bidirectional Reservations . . . . . . . . . . . . . 30 95 6.4.5 Preemption . . . . . . . . . . . . . . . . . . . . . 30 96 6.5 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 30 97 7. QSPEC Functional Specification . . . . . . . . . . . . . . . . 31 98 7.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 32 99 7.2 QSPEC-1 Parameter Coding . . . . . . . . . . . . . . . . . 35 100 7.2.1 Parameter . . . . . . . . . . . . 35 101 7.2.2 Parameter . . . . . . . . . . . . . . . . . 36 102 7.2.2.1 Sub-Parameter . . . . . . . . . . 37 103 7.2.2.2 Sub-Parameters . . . . . . . 37 104 7.2.3 Parameter . . . . . . . . . . . . . . . . 38 105 7.2.3.1 Sub-Parameter . . . . . . . . . . 38 106 7.2.3.2 Sub-Parameter . . . . . . . 39 107 7.2.3.3 Sub-Parameter . . . . . . 39 108 7.2.4 Parameter . . . . . . . . . . . . . . . . 40 109 7.2.4.1 & 110 Sub-Parameters . . . . . . . . . . . . . . . 42 111 7.2.4.2 Sub-Parameter . . . . . 42 112 7.2.4.3 Sub-Parameter . . . . . . . . 42 113 7.3 QSPEC-2 Parameter Coding . . . . . . . . . . . . . . . . . 43 114 7.3.1 Parameter . . . . . . . . . . . . . 43 115 7.3.2 Parameter . . . . . . . . . . . . . . 44 116 7.3.3 Parameter . . . . . . . . . . . . . . . 44 117 7.3.4 Parameter . . . . . . . . . . . . . . . . 45 118 7.3.5 Parameter . . . . . . . . . . . . . . . . . . . 46 119 7.3.6 Parameters . . . . . . . 46 120 7.3.7 Parameter . . . . . . . . . . . . . . . 47 121 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 48 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 48 123 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 124 11. Normative References . . . . . . . . . . . . . . . . . . . . . 52 125 12. Informative References . . . . . . . . . . . . . . . . . . . . 53 126 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54 127 Appendix A. Example of QSPEC Processing . . . . . . . . . . . . . 55 128 Appendix B. Mapping of QoS Desired, QoS Available and QoS 129 Reserved of NSIS onto AdSpec, TSpec and RSpec of RSVP 130 IntServ . . . . . . . . . . . . . . . . . . . . . . . 59 131 Appendix C. Change History & Open Issues . . . . . . . . . . . . . 59 132 C.1 Change History (since Version -04) . . . . . . . . 59 133 C.2 Open Issues . . . . . . . . . . . . . . . . . . . 61 134 Intellectual Property Statement . . . . . . . . . . . . . . . . . 61 135 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 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. Examples of QOSMs are IntServ, DiffServ 216 admission control, and those specified in [Y.1541-QOSM, CL-QOSM, 217 RMD-QOSM]. 219 The QoS NSLP protocol is used to signal QoS reservations and supports 220 signaling for different QOSMs. All information specific to a QOSM is 221 encapsulated in the QoS specification (QSPEC) object, which is QOSM 222 specific, and this document defines a template for the QSPEC. 224 Since QoS NSLP signaling operation can be different for different 225 QOSMs, the QSPEC contains two kinds of information, QSPEC control 226 information and QoS description. QSPEC control information contains 227 parameters that governs the behavior of the RMF. An example of QSPEC 228 control information is how the excess traffic is treated in the RMF 229 queuing functions. The QoS description parameters include, for 230 example, parameters, such as and 231 , and constraints parameters, such as and 232 . 234 The QoS description is composed of QSPEC objects loosely 235 corresponding to the TSpec, RSpec and AdSpec objects specified in 236 RSVP. This is, the QSPEC may contain a description of QoS desired 237 and QoS reserved. It can also collect information about available 238 resources. Going beyond RSVP functionality, the QoS description 239 also allows indicating a range of acceptable QoS by defining a QSPEC 240 object denoting minimum QoS. Usage of these QSPEC objects is not 241 bound to particular message types thus allowing for flexibility. 242 A QSPEC object collecting information about available resources may 243 travel in any QoS NSLP message, for example a QUERY message or a 244 RESERVE message. The QSPEC travels in QoS NSLP messages but is 245 opaque to the QoS NSLP, and is only interpreted by the RMF. 247 Interoperability between QoS NSIS entities (QNEs) in different 248 domains that implement different QOSMs is enhanced (but not 249 guaranteed) by the definition of a common set of QSPEC-1 and 250 QSPEC-2 parameters. QSPEC-1 parameters in the QSPEC must be 251 interpreted by all QNEs in the path, independent of which QOSM they 252 support. This way, NSIS provides a mechanism for interdomain QoS 253 signaling and interworking. QSPEC-2 parameters, in contrast, may be 254 skipped if not understood. Additional QSPEC-2 parameters can be 255 defined by QOSM specification documents, and thereby ensure the 256 extensibility and flexibility of QoS NSLP. 258 A QoS NSIS initiator (QNI) initiating the QoS NSLP signaling adds an 259 initiator QSPEC object containing parameters describing the desired 260 QoS based on the QOSM it supports. A local QSPEC can be stacked on 261 the initiator QSPEC to accommodate different QOSMs being used in 262 different domains. A domain supporting a different local QOSM than 263 the QNI can interpret the initiator QSPEC and stack a local QSPEC 264 to meet the local QOSM requirements. If the local domain cannot 265 fully interpret the initiator QSPEC, it can flag the condition and 266 either continue to forward the reservation or possibly reject the 267 reservation. 269 Thus, one of the major differences between RSVP and QoS NSLP is that 270 QoS NSLP supports signaling for different QOSMs along the data path, 271 all with one signaling message. For example, the data path may start 272 in a domain supporting DiffServ and end in a domain supporting 273 Y.1541. The ability to achieve end-to-end QoS through multiple 274 Internet domains is also an important requirement, and illustrated 275 in this document. 277 3. Terminology 279 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 280 any QNE. Together with a description of QoS Desired or QoS 281 Available, it allows the QNI to specify a QoS range, i.e. an upper 282 and lower bound. If the QoS Desired cannot be reserved, QNEs are 283 going to decrease the reservation until the minimum QoS is hit. 285 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 287 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 289 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 291 QoS Description: Describes the actual QoS in QSPEC objects QoS 292 Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC 293 objects are input or output parameters of the RMF. In a valid QSPEC, 294 at least one QSPEC object of the type QoS Desired, QoS Available or 295 QoS Reserved MUST be included. 297 QoS Available: QSPEC object containing parameters describing the 298 available resources. They are used to collect information along a 299 reservation path. 301 QoS Desired: QSPEC object containing parameters describing the 302 desired QoS for which the sender requests reservation. 304 QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g., 305 IntServ Controlled Load. A QOSM specifies a set of QSPEC-1 and 306 QSPEC-2 parameters that describe the QoS and how resources 307 will be managed by the RMF. It furthermore specifies how to use QoS 308 NSLP to signal for this QOSM. 310 QoS Reserved: QSPEC object containing parameters describing the 311 reserved resources and related QoS parameters, for example, 312 bandwidth. 314 QSPEC Control Information: Control information that is specific to a 315 QSPEC, and contains parameters that govern the RMF. 317 QSPEC: QSPEC is the object of QoS NSLP containing all QOSM-specific 318 information. 320 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 321 QoS description and QSPEC control information parameters, for 322 example, bandwidth, token bucket, and excess treatment parameters. 324 QSPEC Object: Main building blocks of QoS Description containing a 325 QSPEC parameter set that is input or output of an RMF operation. 327 QSPEC-1 parameter: QSPEC parameter that a QNI SHOULD populate if 328 applicable to the QOSM supported by the QNI and a QNE MUST interpret, 329 if populated. 331 QSPEC-2 parameter: QSPEC parameter that a QNI SHOULD populate if 332 applicable to the QOSM supported by the QNI, and a QNE SHOULD 333 interpret if populated and applicable to the QOSM(s) supported by the 334 QNE. (A QNE MAY ignore if it does not support a QOSM needing the 335 QSPEC-2 parameter). 337 Resource Management Function (RMF): Functions that are related to 338 resource management, specific to a QOSM. It processes the QoS 339 description parameters and QSPEC control parameters. 341 Read-only Parameter: QSPEC Parameter that is set by initiating or 342 responding QNE and is not changed during the processing of the QSPEC 343 along the path. 345 Read-write Parameter: QSPEC Parameter that can be changed during the 346 processing of the QSPEC by any QNE along the path. 348 4. QOSM/NSLP Framework 350 The overall framework for the QoS NSLP is that [QoS-SIG] defines QoS 351 signaling and semantics, the QSPEC template defines the container and 352 semantics for QoS parameters and objects, and QOSM specifications 353 define QoS methods and procedures for using QoS signaling and QSPEC 354 parameters/objects within specific QoS deployments. QoS NSLP is a 355 generic QoS signaling protocol that can signal for many QOSMs. 357 A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ 358 controlled load [CL-QOSM], resource management with DiffServ 359 [RMD-QOSM], and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM]. 360 A QOSM specifies a set of QSPEC parameters that describe the QoS 361 desired and how resources will be managed by the RMF. It furthermore 362 specifies how to use QoS NSLP to signal for this QOSM. The QSPEC is 363 the object of QoS NSLP containing all QOSM-specific information, 364 which is described in the next section, such as QoS description 365 parameters (e.g., bandwidth) and QSPEC control information parameters 366 (e.g., excess treatment). The RMF implements functions that are 367 related to resource management, specific to a QOSM and processes the 368 QSPEC parameters. 370 The QOSM specification includes how the requested QoS resources will 371 be described and how they will be managed by the RMF. For this 372 purpose, the QOSM specification defines a set of QSPEC-1 and QSPEC-2 373 parameters it uses to describe the desired QoS and QoS resource 374 control in the RMF, and it may define additional QSPEC-2 parameters. 375 QSPEC-1 parameters are populated by a QNI if they are applicable to 376 the underlying QOSM the QNI supports and that a QNE must interpret, 377 if populated. QSPEC-2 parameters are populated by a QNI if they are 378 applicable to the underlying QOSM a QNI supports, and a QNE should 379 interpret if populated and applicable to the QOSM(s) supported by the 380 QNE. 382 A QNE MUST support at least one QOSM. A QoS-enabled domain supports 383 a particular QOSM, and the QNEs in the domain MUST also support the 384 QOSM. 386 A QOSM specification MUST include the following: 388 - role of QNEs, e.g., location, frequency, statefulness, etc. 389 - QSPEC definition including QOSM ID, QSPEC parameters 390 - QSPEC procedures applicable to this QOSM 391 - QNE processing rules describing how QSPEC information is treated 392 and interpreted in the RMF and QOSM specific processing. E.g., 393 admission control, scheduling, policy control, QoS parameter 394 accumulation (e.g., delay). 395 - at least one bit-level QSPEC example 396 - QSPEC parameter behavior for new QSPEC-2 parameters the QOSM 397 specification defines 398 - QSPEC parameter behavior for remapping of existing QSPEC 399 parameters, as described in Section 6.3.2. Remapping may result 400 in slight modification to the intended specification when strict 401 interpretation is not possible. Unless otherwise specified in the 402 QOSM specification document, the default QOSM behaviors for all 403 QSPEC-1 parameters is to strictly interpret the QSPEC-1 parameters 404 as defined in this document through the references that precisely 405 define the QSPEC parameter behaviors. 406 - define what happens in case of preemption if the default QNI 407 behavior (tear down preempted reservation) is not followed (see 408 Section 6.3.5) 410 A QOSM specification MAY include the following: 412 - QOSM-specific control information parameters and processing rules 413 for those parameters 414 - define additional QOSM-specific error codes, as discussed in 415 Section 6.3.4 416 - specify the conditions for rejecting a reservation when the 417 non-QOSM-hop Q-flag and remapped QSPEC parameter R-flags are sent 418 back in the RESPONSE message (in the absence of such procedures, 419 the default condition is 'success' if all QSPEC parameters are met 420 and 'reservation failure' if one or more QSPEC parameters are not 421 met) 423 5. QSPEC Framework 425 The QSPEC is the object of QoS NSLP containing all QOSM-specific 426 information, and contains QSPEC objects and parameters. QSPEC 427 objects are the main building blocks of the QoS description 428 containing a QSPEC parameter set that is input or output of an RMF 429 operation. QSPEC parameters are the parameters appearing in a QSPEC, 430 which include both QoS description parameters (e.g., bandwidth) and 431 QSPEC control information parameters (e.g., excess treatment). The 432 RMF implements functions that are related to resource management, 433 specific to a QOSM. It processes the QoS description parameters and 434 QSPEC control information parameters. 436 QSPEC-1 parameters provide a common language for QOSM developers to 437 build their QSPECs and are likely to be re-used in several QOSMs. 438 QSPEC-1 parameters are populated by a QNI if they are applicable to 439 the underlying QOSM the QNI supports and that a QNE must interpret, 440 if populated. QSPEC-2 parameters are populated by a QNI if they are 441 applicable to the underlying QOSM a QNI supports, and a QNE should 442 interpret if populated and applicable to the QOSM(s) supported by the 443 QNE. Note that a QNE may ignore a QSPEC-2 parameter if it does not 444 support a QOSM needing the QSPEC-2 parameter. QSPEC-1 and QSPEC-2 445 parameters are defined in this document, and additional QSPEC-2 446 parameters may be defined in separate QOSM specification documents. 447 For example, QSPEC-2 parameters are defined in [RMD-QOSM] and 448 [Y.1541-QOSM]. The set of QSPEC-1 parameters in NSIS is based on 449 DiffServ and IntServ/RSVP. Note that in effect all parameters are 450 QSPEC-1 in RSVP since it does not have the QSPEC-1/QSPEC-2 concept. 452 In this document the term 'interpret' means, in relation to RMF 453 processing of QSPEC parameters, either that the RMF a) strictly 454 interprets a QSPEC parameter, or b) remaps, approximates, or 455 otherwise does not strictly interpret the parameter. Furthermore, 456 the terminology 'strictly interpret' means that the QSPEC parameter 457 is processed by the RMF according to the commonly accepted normative 458 procedures specified by references given for each QSPEC parameter. 459 Otherwise the QSPEC parameter may be remapped or approximately 460 interpreted. For example a token bucket parameter may be remapped to 461 bandwidth and simply interpreted by the RMF as bandwidth. Note also 462 that a QNE must interpret a QSPEC-1 parameter only if it is populated 463 in the QSPEC object by the QNI. If a QSPEC-1 parameter is not there 464 in the QSPEC, the QNE does not interpret it of course. To test 465 compliance, however, a QNE would need to be tested that it properly 466 implements/interprets all QSPEC-1 parameters. 468 5.1 QSPEC Objects 470 This document provides a template for the QSPEC, which is needed in 471 order to help define individual QOSMs and in order to promote 472 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 473 is composed of QSPEC control information and QoS description. QoS 474 description in turn is composed of up to four QSPEC objects (not all 475 of them need to be present), namely QoS Desired, QoS Available, QoS 476 Reserved and Minimum QoS. Each of these QSPEC Objects, as well as 477 QSPEC Control Information, consists of a number of QSPEC-1 and 478 QSPEC-2 parameters. 480 +-------------+---------------------------------------+ 481 |QSPEC Control| QoS | 482 | Information | Description | 483 +-------------+---------------------------------------+ 485 \________________ ______________________/ 486 V 487 +----------+----------+---------+-------+ \ 488 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC 489 +----------+----------+---------+-------+ / Objects 491 \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/ 492 V V V V V 494 +-------------+... +-------------+... 495 |QSPEC Para. 1| |QSPEC Para. n| 496 +-------------+... +-------------+... 498 Figure 1: Structure of the QSPEC 500 The internal structure of each QSPEC object and the QSPEC control 501 information, with QSPEC-1 and QSPEC-2 parameters, is illustrated 502 in Figure 2. 504 +------------------+-----------------+------------------+ 505 | QSPEC/Ctrl Info | QSPEC-1 | QSPEC-2 | 506 | Object ID | Parameters | Parameters | 507 +------------------+-----------------+------------------+ 509 Figure 2: Structure of QSPEC Objects & Control Information 511 5.2 QSPEC Parameters 513 5.2.1 QSPEC-1 and QSPEC-2 Parameters 515 QSPEC-1 and QSPEC-2 parameters are defined in this document and are 516 applicable to a number of QOSMs. QSPEC-1 parameters are treated as 517 follows: 519 o A QNI SHOULD populate QSPEC-1 parameters if applicable to the 520 QOSM supported by the QNI. 521 o QNEs/QNR MUST interpret QSPEC-1 parameters, if signaled. 523 QSPEC-2 parameters are treated as follows: 525 o A QNI SHOULD populate QSPEC-2 parameters if applicable to the QOSM 526 for which it is signaling. 528 o QNEs/QNR SHOULD interpret QSPEC-2 parameters, if signaled and 529 applicable to the QOSM(s) supported by the QNE/QNR. (A QNE/QNR MAY 530 ignore the QSPEC-2 parameter if it does not support a QOSM needing 531 the QSPEC-2 parameter). 533 Note that a QNE that stacks 2 QSPECs should follow the same rules as 534 a QNI. That is, when there are two stacked QSPECs in a local domain, 535 the QNEs in the interior local domain need only process the local 536 (topmost) QSPEC and can ignore the initiator (bottom) QSPEC. 537 However, edge QNEs in the local domain indeed must interpret the 538 QSPEC-1 parameters populated in the initiator QSPEC. 540 This specification defines 4 QSPEC-1 parameters: , 541 , , and . The coding for these 542 parameters is specified in Section 7.2. Due to a lack of sufficient 543 deployment experience this is a best guess, which should be reviewed 544 once operational experience requires or allows such a review. This 545 specification also defines 10 QSPEC-2 parameters, and the coding for 546 these parameters is specified in Section 7.3. 548 5.2.2 Read-only and Read-write QSPEC Parameters 550 QoS description parameters can be either read-only or read-write, 551 depending on which QSPEC object, and which message, they appear in. 552 In particular, all parameters in the QoS Desired object, QoS Reserved 553 object, and Minimum QoS object are read-only for all messages. 554 Parameters in the QoS Available object are normally read-write 555 parameters when the QoS Available object appears for the first time 556 e.g. in the RESERVE message or QUERY message from QNI to QNR. 557 However, on its way back, all parameters in the 558 object are read-only, e.g., in the RESPONSE message or RESERVE 559 message from QNR to QNI. This is because on its way back the QoS 560 Available object just transports the information it collected before. 562 In the QSPEC control information object, the property of being 563 read-write or read-only is parameter specific. Note that the only 564 control information parameter specified in this document is the 565 parameter, which is a read-only parameter. 567 5.3 QSPEC Formats 569 QSPEC = 570 572 As described above, the QSPEC contains an identifier for the QOSM, 573 the actual resource description (QoS description) as well as QSPEC 574 control information. QSPEC-1 parameters defined in the following 575 sections include , , , and 576 . All other QSPEC parameters defined in the following 577 sections are QSPEC-2 parameters. 579 A QSPEC object ID identifies whether the object is or . As described below, the is further broken down into , , , and objects. A QSPEC 583 parameter ID is assigned to identify each QSPEC parameter defined 584 below. 586 identifies the QSPEC version number. Later QSPEC 587 versions MUST be backward compatible with earlier QSPEC versions. 588 That is, a version n+1 device must support a version n (or earlier) 589 QSPEC and QSPEC parameters. If the version n device receives 590 QSPEC-1 parameters (with the M-flag set, as defined in Section 7) 591 that are not supported in version n (only supported in version 592 n+1), then the version n device concludes that either a) the M-flag 593 is set incorrectly for an QSPEC-2 parameter it does not support, or 594 b) the M-flag is correctly set for a QSPEC-1 parameter it does not 595 support. In either case, the version n device responds with a 596 'Malformed QSPEC' error code (0x03), as discussed in Section 6.3.1. 598 A new QSPEC version MUST be defined whenever this document is 599 reissued, for example, whenever a new QSPEC-1 parameter is added. 600 QSPEC-1 parameters in a new QSPEC version MUST be a superset of 601 those in the previous QSPEC version. 603 The identifies the particular QOSM being used by the QNI 604 and tells a QNE which parameters to expect. This may simplify 605 processing and error analysis. Furthermore, it may be helpful for a 606 QNE or a domain supporting more than one QOSM to learn which QOSM the 607 QNI would like to have in order to use the most suitable QOSM. Even 608 if a QNE does not support the QOSM it MUST interpret at least the 609 QSPEC-1 parameters. Note that more parameters than required by the 610 QOSM can be included by the QNI. QSPEC version and QOSM IDs are 611 assigned by IANA. 613 5.3.1 QSPEC Control Information 615 QSPEC control information is used for signaling QOSM RMF functions 616 not defined in QoS NSLP. It enables building new RMF functions 617 required by a QOSM within a QoS NSLP signaling framework, such as 618 specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. 620 = 622 The parameter describes how the QNE will process 623 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 624 be dropped, shaped and/or remarked. The excess treatment parameter is 625 initially set by the QNI and is read-only. 627 5.3.2 QoS Description 629 The QoS Description is broken down into the following QSPEC objects: 631 = 632 634 Any subset of the QSPEC objects on the right hand side of the equal 635 sign can be included in the QSPEC. Of these QSPEC objects, QoS 636 Desired, QoS Available and QoS Reserved MUST be supported by QNEs. 637 Minimum QoS MAY be supported. 639 5.3.2.1 641 = 642 644 Any subset of the QSPEC parameters on the right hand side of the 645 equal sign can be included in the object. These 646 parameters describe the resources the QNI desires to reserve and 647 hence this is a read-only QSPEC object. The resources 648 that the QNI wishes to reserve are of course directly related to the 649 traffic the QNI is going to inject into the network. Therefore, when 650 used in the object, refers to traffic 651 injected by the QNI into the network. 653 = 655 Either sub-parameter on the right hand side of the equal sign can be 656 included in the parameter. Here 657 = link bandwidth needed by flow [RFC2212, RFC2215] 659 =

[RFC2210] 661 All of the sub-parameters on the right hand side of the equal sign 662 MUST be included in the parameter. Note that the Path 663 MTU Discovery (PMTUD) working group is currently specifying a robust 664 method for determining the MTU supported over an end-to-end path. 665 This new method is expected to update RFC1191 and RFC1981, the 666 current standards track protocols for this purpose. 668 = 670 Any one of the sub-parameter on the right hand side of the equal sign 671 can be included in the parameter. 673 An application MAY like to reserve resources for packets with a 674 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 675 [RFC2475], DiffServ-aware MPLS traffic engineering (DSTE) class 676 type [RFC3564, RFC4124], or Y.1541 QoS class [Y.1541]. 678 = 679 681 Any subset of the sub-parameter on the right hand side of the equal 682 sign can be included in the parameter. 684 is the priority of the new flow compared with 685 the defending priority of previously admitted flows. Once a flow is 686 admitted, the preemption priority becomes irrelevant. is used to compare with the preemption priority of new 688 flows. For any specific flow, its preemption priority MUST always be 689 less than or equal to the defending priority. 690 and provide an essential way to differentiate flows 691 for emergency services, ETS, E911, etc., and assign them a higher 692 admission priority than normal priority flows and best-effort 693 priority flows. 695 Appropriate security measures need to be taken to prevent abuse of 696 the parameters, see Section 8 on Security Considerations. 698 [Y.1540] defines packet transfer outcomes, as follows: 700 Successful: packet arrives within the preset waiting time with no 701 errors 703 Lost: packet fails to arrive within the waiting time 705 Errored: packet arrives in time, but has one or more bit errors 706 in the header or payload 708 Packet Loss Ratio (PLR) = total packets lost/total packets sent 710 Packet Error Ratio (PER) = total errored packets/total packets sent 712 , , , and are QSPEC-2 713 parameters describing the desired path latency, path jitter and path 714 bit error rate respectively. Since these parameters are cumulative, 715 an individual QNE cannot decide whether the desired path latency, 716 etc., is available, and hence they cannot decide whether a 717 reservation fails. Rather, when these parameters are included in 718 , the QNI SHOULD also include corresponding parameters 719 in a QSPEC object in order to facilitate collecting 720 this information. 722 5.3.2.2 724 = 725 726 728 Any subset of the QSPEC parameters on the right hand side of the 729 equal sign can be included in the object. 731 When used in the object, refers to traffic 732 resources available at a QNE in the network. 734 The Object collects information on the resources 735 currently available on the path when it travels in a RESERVE or QUERY 736 message and hence in this case this QSPEC object is read-write. Each 737 QNE MUST inspect all parameters of this QSPEC object, and if 738 resources available to this QNE are less than what a particular 739 parameter says currently, the QNE MUST adapt this parameter 740 accordingly. Hence when the message arrives at the recipient of the 741 message, reflects the bottleneck of the resources 742 currently available on a path. It can be used in a QUERY message, 743 for example, to collect the available resources along a data path. 745 When travels in a RESPONSE message, it in fact just 746 transports the result of a previous measurement performed by a 747 RESERVE or QUERY message back to the initiator. Therefore in this 748 case, is read-only. 750 The parameters and provide information, 751 for example, about the bandwidth available along the path followed by 752 a data flow. The local parameter is an estimate of the bandwidth the 753 QNE has available for packets following the path. Computation of the 754 value of this parameter SHOULD take into account all information 755 available to the QNE about the path, taking into consideration 756 administrative and policy controls on bandwidth, as well as physical 757 resources. The composition rule for this parameter is the MIN 758 function. The composed value is the minimum of the QNE's value and 759 the previously composed value. This quantity, when composed 760 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 761 minimal bandwidth link along the path from QNI to QNR. 763 The parameter accumulates the latency of the packet 764 forwarding process associated with each QNE, where the latency is 765 defined to be the mean packet delay added by each QNE. This delay 766 results from speed-of-light propagation delay, from packet processing 767 limitations, or both. The mean delay reflects the variable queuing 768 delay that may be present. Each QNE MUST add the propagation delay 769 of its outgoing link, if this link exists. Furthermore, the QNI MUST 770 add the propagation delay of the ingress link, if this link exists. 771 The composition rule for the parameter is summation 772 with a clamp of (2**32 - 1) on the maximum value. This quantity, 773 when composed end-to-end, informs the QNR (or QNI in a RESPONSE 774 message) of the minimal packet delay along the path from QNI to QNR. 775 The purpose of this parameter is to provide a minimum path latency 776 for use with services which provide estimates or bounds on additional 777 path delay [RFC2212]. 779 The parameter accumulates the jitter of the packet 780 forwarding process associated with each QNE, where the jitter is 781 defined to be the nominal jitter added by each QNE. IP packet 782 jitter, or delay variation, is defined in [RFC3393], Section 3.4 783 (Type-P-One-way-ipdv), and where the selection function includes the 784 packet with minimum delay such that the distribution is equivalent to 785 2-point delay variation in [Y.1540]. The suggested evaluation 786 interval is 1 minute. This jitter results from packet processing 787 limitations, and includes any variable queuing delay which may be 788 present. Each QNE MUST add the jitter of its outgoing link, if this 789 link exists. Furthermore, the QNI MUST add the jitter of the ingress 790 link, if this link exists. The composition method for the parameter is the combination of several statistics describing 792 the delay variation distribution with a clamp on the maximum value 793 (note that the methods of accumulation and estimation of nominal QNE 794 jitter are specified in clause 8 of [Y.1541]). This quantity, when 795 composed end-to-end, informs the QNR (or QNI in a RESPONSE message) 796 of the nominal packet jitter along the path from QNI to QNR. The 797 purpose of this parameter is to provide a nominal path jitter for use 798 with services that provide estimates or bounds on additional path 799 delay [RFC2212]. 801 The parameter accumulates the packet loss rate (PLR) of 802 the packet forwarding process associated with each QNE, where the PLR 803 is defined to be the PLR added by each QNE. Each QNE MUST add the 804 PLR of its outgoing link, if this link exists. Furthermore, the QNI 805 MUST add the PLR of the ingress link, if this link exists. The 806 composition rule for the parameter is summation with a 807 clamp on the maximum value (this assumes sufficiently low PLR values 808 such that summation error is not significant, however a more accurate 809 composition function is specified in clause 8 of [Y.1541]). This 810 quantity, when composed end-to-end, informs the QNR (or QNI in a 811 RESPONSE message) of the minimal packet PLR along the path from QNI 812 to QNR. 814 The parameter accumulates the packet error rate (PER) of 815 the packet forwarding process associated with each QNE, where the PER 816 is defined to be the PER added by each QNE. Each QNE MUST add the 817 PER of its outgoing link, if this link exists. Furthermore, the QNI 818 MUST add the PER of the ingress link, if this link exists. The 819 composition rule for the parameter is summation with a 820 clamp on the maximum value (this assumes sufficiently low PER values 821 such that summation error is not significant, however a more accurate 822 composition function is specified in clause 8 of [Y.1541]). This 823 quantity, when composed end-to-end, informs the QNR (or QNI in a 824 RESPONSE message) of the minimal packet PER along the path from QNI 825 to QNR. 827 , , , : Error terms C and D represent how the 828 element's implementation of the guaranteed service deviates from the 829 fluid model. These two parameters have an additive composition rule. 830 The error term C is the rate-dependent error term. It represents the 831 delay a datagram in the flow might experience due to the rate 832 parameters of the flow. The error term D is the rate-independent, 833 per-element error term and represents the worst case non-rate-based 834 transit time variation through the service element. If the 835 composition function is applied along the entire path to compute the 836 end-to-end sums of C and D ( and ) and the resulting 837 values are then provided to the QNR (or QNI in a RESPONSE message). 838 and are the sums of the parameters C and D between the 839 last reshaping point and the current reshaping point. 841 5.3.2.3 843 = 845 Any subset of the QSPEC parameters on the right hand side of the 846 equal sign can be included in the object. These 847 parameters describe the QoS reserved by the QNEs along the data path. 849 , and are defined above. 851 = slack term, which is the difference between desired delay and 852 delay obtained by using bandwidth reservation, and which is used to 853 reduce the resource reservation for a flow [RFC2212]. This is an 854 QSPEC-2 parameter. 856 5.3.2.4 858 = 859 Any subset of the QSPEC parameters on the right hand side of the 860 equal sign can be included in the object. 862 does not have an equivalent in RSVP. It allows the QNI 863 to define a range of acceptable QoS levels by including both the 864 desired QoS value and the minimum acceptable QoS in the same message. 865 It is a read-only QSPEC object. The desired QoS is included with a 866 and/or a QSPEC object seeded to the 867 desired QoS value. The minimum acceptable QoS value MAY be coded in 868 the QSPEC object. As the message travels towards the 869 QNR, is updated by QNEs on the path. If its value 870 drops below the value of the reservation fails and is 871 aborted. When this method is employed, the QNR SHOULD signal back to 872 the QNI the value of attained in the end, because the 873 reservation MAY need to be adapted accordingly. 875 6. QSPEC Processing & Procedures 877 The QSPEC is opaque to the QoS NSLP processing, as described in 878 [QoS-SIG]. The QSPEC control information and the QoS description are 879 interpreted by the QNE's RMF and may be modified by the RMF. This 880 section discusses QSPEC processing and how the QNE/RMF interprets 881 QSPEC parameters, stacks QSPECs, determines reservation 882 success/failure, and signals QSPEC errors and INFO_SPEC 883 notifications. An example of QSPEC processing is given in the final 884 sub-section. 886 6.1 Interpreting QSPEC Parameters 888 The QSPEC contains a QOSM ID that identifies which QOSM is being 889 signaled by the QNI. If a QSPEC arrives at a QNE that does not 890 support the QOSM being signaled, it must still interpret the QSPEC 891 content, at least to a basic degree, since QSPEC-1 parameters have 892 been defined as a common language for interoperability of different 893 QOSMs being support in different domains. That is, a QNE must at 894 least interpret all the QSPEC-1 parameters in a QSPEC even if it does 895 not support the corresponding QOSM. 897 Hence a QNE must either a) strictly interpret a QSPEC parameter, or 898 b) remap, approximate, or otherwise not strictly interpret the QSPEC 899 parameter. Here 'strictly interpret' means that the parameter is 900 implemented by the QNE/RMF according to the commonly accepted 901 procedures as specified by references given for each QSPEC parameter 902 in this document. In the latter case of a remapped QSPEC parameter, 903 the QNE/RMF must raise the remapped parameter R-flag and non-QOSM-hop 904 Q-flag defined in Section 6.3.2, and the remapping must be 905 specified in the QOSM specification. For example, in case a), a 906 parameter must be strictly interpreted as a token 907 bucket, and in case b), a parameter may be remapped to 908 a parameter. 910 In the latter case b), the remapping of the to 911 must be specified in the QOSM specification document. 912 For example, QOSM X exclusively uses the parameter . It 913 must define a mapping of the QSPEC-1 parameter . 914 The mapping consists of interpreting the Token Bucket Rate as 915 the parameter and disregarding the other Token Bucket 916 parameters. Clearly, some information contained in the parameter is lost by this mapping, and the resulting QoS may 918 not be quite what was intended by the QNI. Therefore, QOSM X also 919 specifies that the non-QOSM-hop Q-flag be raised. Thus, a QNE using 920 QOSM X is able to make an informed decision whether to admit a 921 reservation described in terms of , and at the same 922 time (by means of the non-QOSM-hop Q-flag) signals to the QNI/QNR 923 that the exact intention of the QNI may not be met. 925 Other examples of remapping QSPEC-1 parameters are as follows: 927 - : bandwidth remapped to token bucket rate and the other 928 token bucket parameters set to zero or some large value 929 - : DSTE QoS class to PHB QoS class 930 - : Y.1541 QoS class remapped to PHB QoS class 931 - : admission/RPH = high priority remapping to 932 admission/RPH = normal priority 934 Remapping between different QSPEC-1 parameter types, e.g., from to , is more complex but is allowed if defined in the 936 QOSM specification document. If a remapping for a QSPEC-1 parameter 937 is not defined in the QOSM specification document, the default is 938 that the QOSM must strictly interpret the QSPEC-1 parameter. 940 In some cases a QNE may need to reject a reservation because of 941 possible incompatibilities among QSPEC parameters. One example is 942 that some parameters may be illegal (e.g., preemption in the U.S. 943 PSTN). In such a case a QNE must reject a reservation where 944 preemption cannot be accommodated. 946 6.2 QSPEC Stacking & Tunneling 948 A QNE at the edge of a local domain may either a) translate the 949 initiator QSPEC into a local QSPEC and stack the local QSPEC on top 950 of the initiator QSPEC in the RESERVE message, or b) tunnel the 951 initiator QSPEC through the local domain and reserve resources by 952 generating a new RESERVE message through the local domain containing 953 the local QSPEC. In either case the initiator QSPEC parameters are 954 interpreted at the local domain edges. 956 Therefore when reserving resources with a RESERVE message, a local 957 QSPEC MAY be pushed on the stack at the ingress edge of a local QoS 958 domain, in order to describe the requested resources in a 959 domain-specific manner. Here the terms 'ingress' and 'egress' refer 960 to the direction of the RESERVE message rather than the direction of 961 the flow. Also, the local QSPEC is popped from the stack at the 962 egress edge of the local QoS domain. When a RESPONSE message 963 corresponding to the RESERVE message arrives on its way back at the 964 egress edge, a local QSPEC MUST again be generated, describing the 965 reserved resources in a domain-specific manner. This local QSPEC is 966 popped from the stack at the ingress edge. 968 A QoS NSLP message can contain a stack of at most two QSPECs. The 969 first on the stack is the initiator QSPEC. This is a QSPEC provided 970 by the QNI, which travels end-to-end, and therefore the stack always 971 has at least depth 1. QSPEC parameters MUST NOT be deleted from or 972 added to the initiator QSPEC. In addition, the stack MAY contain a 973 local QSPEC stacked on top of the initiator QSPEC. A QNE only 974 considers the topmost QSPEC. 976 QNEs generating a local QSPEC for the purpose of stacking or 977 tunneling have two possible approaches to processing the QSPEC-1 978 parameters in the initiator QSPEC: 980 a) The local QSPEC includes all QSPEC-1 parameters in the initiator 981 QSPEC (possibly remapped according to the local QOSM). For 982 example, the initiator QSPEC specifies a token bucket parameter, 983 and it is remapped into the bandwidth parameter in the local 984 QSPEC. The ingress QNE in the local domain does not populate 985 the token bucket parameter in the local QSPEC, rather it populates 986 the bandwidth parameter is the local QSPEC and stacks the local 987 QSPEC on top of the initiator QSPEC. The local QSPEC is 988 interpreted by the QNEs in the local domain, and the egress QNE in 989 the local domain populates token bucket in the initiator QSPEC 990 with just the bandwidth parameter for the token bucket (and not 991 the other token bucket parameters). Note that without QSPEC 992 stacking or tunneling, all QNEs must do this same thing in the 993 local domain, that is, interpret all QSPEC-1 parameters in the 994 initiator QSPEC, which would include remapping the token bucket 995 parameter to the bandwidth parameter. 997 b) The local QSPEC does not include all QSPEC-1 parameters in the 998 initiator QSPEC, but the egress QNE in the local domain has 999 information configured that allows it to update/process the 1000 QSPEC-1 parameters in the initiator QSPEC accordingly. In this 1001 case the local QSPEC may carry neither the bandwidth nor token 1002 bucket in the above example, if the egress QNE in the local domain 1003 has some other means to interpret the token bucket parameter of 1004 the initiator QSPEC (e.g., local data base or controller). 1005 For example, in a DiffServ domain with a bandwidth broker, the 1006 bandwidth broker could inform the egress QNE, or if RSVP is used 1007 in the local domain, the information could be obtained from RSVP, 1008 or if it is an MPLS domain where LSPs have a particular bandwidth, 1009 then the egress QNE knows what is available by counting the 1010 reservations that come out of the tunnel. Normally the egress QNE 1011 in the local domain interprets the initiator QSPEC parameters, 1012 since doing this in the ingress QNE may require the ingress QNE to 1013 inform the egress QNE that it has done this (this is not precluded 1014 however). 1016 Note that in the above cases the Q-Flag is set whenever a QOSM is 1017 encountered on the path that is different from the Initiator QSPEC, 1018 e.g., the Q-Flag is set in both cases a) and b). Also, the R-flag is 1019 set for any Initiator QSPEC parameter that is remapped. 1021 QSPEC stacking with a local QSPEC saves interior QNEs from 1022 individually interpreting the initiator QSPEC within their local 1023 QOSM. Instead, the ingress/egress QNEs do this for them, and in 1024 this way consistent processing within a domain is simplified. That 1025 is, the equivalent normal behavior is achieved in the local domain as 1026 if all QNEs in the domain interpret the initiator QSPEC individually. 1028 6.3 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 1029 Notification 1031 A reservation may not be successful for several reasons: 1033 - a reservation may fail because the desired resources are not 1034 available. This is a reservation failure condition. 1036 - a reservation may fail because the QSPEC is erroneous, or because 1037 of a QNE fault. This is an error condition. 1039 A reservation may be successful even though some parameters could not 1040 be interpreted or updated properly: 1042 - a QSPEC parameter cannot be interpreted because it is an unknown 1043 QSPEC-2 parameter type. This is a QSPEC parameter not supported 1044 condition. The reservation however does not fail. The QNI can 1045 still decide whether to keep or tear down the reservation depending 1046 on the procedures specified by the QNI's QOSM. 1048 - a QSPEC parameter value is remapped, approximated, or otherwise not 1049 strictly interpreted. This is a QSPEC parameter remapped 1050 condition. The reservation however does not fail. The QNI can 1051 still decide whether to keep or tear down the reservation. 1053 The following sections describe the handling of unsuccessful 1054 reservations and reservations where some parameters could not be met 1055 in more detail, as follows: 1057 - details on flags used inside the QSPEC to convey information on 1058 success or failure of individual parameters. The formats and 1059 semantics of all flags are given in Section 7. 1060 - the content of the INFO_SPEC [QoS-SIG], which carries a code 1061 indicating the outcome of reservations. 1062 - the generation of a RESPONSE message to the QNI containing both 1063 QSPEC and INFO_SPEC objects. 1065 6.3.1 Reservation Failure & Error E-Flag 1067 The QSPEC parameters each have a 'reservation failure error E-flag' 1068 to indicate which (if any) parameters could not be satisfied. When a 1069 resource cannot be satisfied for a particular parameter, the QNE 1070 detecting the problem raises the E-flag in this parameter. Note that 1071 all QSPEC parameters MUST be examined by the RMF and appropriately 1072 flagged. Additionally, the E-flag in the corresponding QSPEC object 1073 MUST be raised. If the reservation failure problem cannot be located 1074 at the parameter level, only the E-flag in the QSPEC object is 1075 raised. 1077 When an RMF cannot interpret the QSPEC because the coding is 1078 erroneous, it raises corresponding reservation failure E-flags in the 1079 QSPEC. Normally all QSPEC parameters MUST be examined by the RMF 1080 and the erroneous parameters appropriately flagged. In some cases, 1081 however, an error condition may occur and the E-flag of the 1082 error-causing QSPEC parameter is raised (if possible), but the 1083 processing of further parameters may be aborted. 1085 Note that if the QSPEC and/or any QSPEC parameter is found to be 1086 erroneous, then any QSPEC parameters not satisfied are ignored and 1087 the E-Flags in the QSPEC object MUST NOT be set for those parameters 1088 (unless they are erroneous). 1090 Whether E-flags denote reservation failure or error can be determined 1091 by the corresponding error code in the INFO_SPEC in QoS NSLP, as 1092 discussed below. 1094 6.3.2 Non-QOSM-Hop Q-Flag & Remapped QSPEC Parameter R-flag 1096 The non-QOSM-hop Q-flag is a flag bit telling the QNR (or QNI in a 1097 RESPONSE message) whether or not the initiator QOSM is supported by 1098 each QNE in the path between the QNI and QNR. A QNE MUST set the 1099 non-QOSM-hop Q-flag parameter if it does not support the relevant 1100 initiator QOSM specification. If the QNR finds this bit set, at 1101 least one QNE along the data transmission path between the QNI and 1102 QNR can not support the specified initiator QOSM. In a local QSPEC, 1103 the non-QOSM-hop Q-flag refers to the QoS NSLP peers of the local 1104 QOSM domain. When the local QSPEC is popped, the R-Flags of the 1105 corresponding remapped parameters in the initiator QSPEC must be 1106 raised. The RESERVE message should continue to be forwarded with the 1107 non-QOSM-hop Q-flag set, and the QNI has the option of tearing the 1108 reservation. 1110 A QNE detecting that one or more QSPEC parameters have to be 1111 remapped, approximated, or otherwise not strictly interpreted MUST 1112 set the remapped QSPEC parameter R-flag for each QSPEC parameter that 1113 is remapped. The RESERVE message should continue to be forwarded 1114 with the R-flags set, and the QNI has the option of tearing the 1115 reservation. This condition might occur, for example, when a QNE's 1116 local QOSM is different from the QNI's initiator QOSM, and the local 1117 QOSM specifies that some QSPEC parameters are to be remapped. See 1118 the example in Appendix A for an illustration of this condition. The 1119 R-flag may be interpreted by the QNI, ingress QNE (start of tunnel) 1120 in a domain), egress QNE (end of tunnel) in a local domain, or QNR. 1122 When a RESERVE message is tunneled through a local domain, QNEs 1123 inside the domain cannot update read-write QSPEC parameters in the 1124 initiator QSPEC. The egress QNE in the local domain either a) is 1125 configured to have the knowledge to interpret the parameters 1126 correctly, or b) cannot accurately interpret the parameters. In the 1127 latter case the egress QNE in the local domain MUST set the R-flag 1128 for each QSPEC parameter it cannot interpret to tell the QNI (or QNR) 1129 that the information contained in the read-write parameter is most 1130 likely incorrect (or a lower bound). Note that if possible the edge 1131 QNEs in the local domain must interpret the QSPEC-1 parameters 1132 populated in the initiator QSPEC and MUST NOT use the R-flag to 1133 'ignore' a QSPEC-1 parameter populated in the initiator QSPEC. 1135 6.3.3 QSPEC Parameter Not Supported N-Flag 1137 When the QOSM ID is not known to a QNE, it MUST interpret at least 1138 the QSPEC-1 parameters. 1140 Each QSPEC-2 parameter has an associated 'not supported N-flag'. If 1141 the not supported N-flag is set, then at least one QNE along the data 1142 transmission path between the QNI and QNR cannot interpret the 1143 specified QSPEC-2 parameter. A QNE MUST set the not supported N-flag 1144 if it cannot interpret the QSPEC-2 parameter. In that case the 1145 message should continue to be forwarded but with the N-flag set, and 1146 the QNI has the option of tearing the reservation. 1148 If a QNE in the path does not support a QSPEC-2 parameter, e.g., 1149 , and sets the N-flag, then downstream QNEs that 1150 support the parameter SHOULD still update the parameter, even if the 1151 N-flag is set. However, the presence of the N-flag will make the 1152 cumulative value unreliable, and the QNI/QNR decides whether or not 1153 to accept the reservation with the N-flag set. 1155 6.3.4 INFO_SPEC Coding of Reservation Outcome 1157 As prescribed by [QoS-SIG], the RESPONSE message always contains the 1158 INFO_SPEC with an appropriate 'error' code. It usually also contains 1159 a QSPEC with QSPEC objects, as described in Section 6.3 on QSPEC 1160 Procedures. The RESPONSE message MAY omit the QSPEC in case of a 1161 successful reservation. 1163 The following guidelines are provided in setting the error codes in 1164 the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of 1166 [QoS-SIG]: 1168 - INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success): 1169 This code is set when all QSPEC parameters have been satisfied 1170 (possibly with remapping). In this case no E-Flag is set, however 1171 the Q-flag, N-flags or R-flags may be set. 1173 - INFO_SPEC error class 0x04 (Transient Failure) / 0x08 (Reservation 1174 Failure): 1175 This code is set when at least one parameter could not be 1176 satisfied. E-flags are set for the parameters that could not be 1177 satisfied up to the QNE issuing the RESPONSE message. In this case 1178 QNEs receiving the RESPONSE message MUST remove the corresponding 1179 reservation. 1181 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0c (Malformed 1182 QSPEC): 1183 Some QSPEC parameters had associated errors, E-Flags are set for 1184 parameters that had errors, and the RMF rejects the reservation. 1186 - INFO_SPEC error class 0x06 (QoS Model Error): 1187 QOSM error codes can be defined by QOSM specification documents. A 1188 registry is defined in Section 9 IANA Considerations. 1190 6.3.5 QNE Generation of a RESPONSE message 1192 - Successful Reservation Condition 1194 When a RESERVE message arrives at a QNR and no E-Flag is set, the 1195 reservation is successful. A RESPONSE message may be generated with 1196 INFO_SPEC code 'Reservation Success' as described above and in the 1197 QSPEC Procedures described in Section 6.4. 1199 A raised non-QOSM-hop Q-flag in the QSPEC of the RESERVE message 1200 indicates that a local QOSM is encountered that differs from the 1201 initiator QOSM and that some QSPEC parameters may have been remapped, 1202 approximated, or otherwise not strictly interpreted, as indicated by 1203 raised R-flags on these QSPEC parameters. The non-QOSM-hop Q-flag 1204 and R-flags are sent back in the RESPONSE message and the QNI then 1205 makes the final determination as to whether to continue or tear down 1206 the reservation that has been established. A QOSM specification may 1207 specify the conditions for rejecting a reservation under such 1208 conditions. However, in the absence of such procedures, the default 1209 condition SHOULD be 'success' if all QSPEC parameters are met and 1210 'reservation failure' if one or more QSPEC parameters are not met. 1212 - Reservation Failure Condition 1214 When a QNE detects that a reservation failure occurs for at least one 1215 parameter, the QNE sets the E-Flags for the QSPEC parameters and 1216 QSPEC object that failed to be satisfied. According to [QoS-SIG], 1217 the QNE behavior depends on whether it is stateful or not. When a 1218 stateful QNE determines the reservation failed, it formulates a 1219 RESPONSE message that includes an INFO_SPEC with the 'reservation 1220 failure' error code and QSPEC object. The QSPEC in the RESPONSE 1221 message includes the failed QSPEC parameters marked with the E-Flag 1222 to clearly identify them. 1224 The default action for a stateless QoS NSLP QNE that detects a 1225 reservation failure condition is that it MUST continue to forward the 1226 RESERVE message to the next stateful QNE, with the E-Flags 1227 appropriately set for each QSPEC parameter. The next stateful QNE 1228 then formulates the RESPONSE message as described above. 1230 - Malformed QSPEC Error Condition 1232 When a stateful QNE detects that one or more QSPEC parameters are 1233 erroneous, the QNE sets the error code 'malformed QSPEC' in the 1234 INFO_SPEC. In this case the QSPEC object with the E-Flags 1235 appropriately set for the erroneous parameters is returned within 1236 the INFO_SPEC object. The QSPEC object can be truncated or fully 1237 included within the INFO_SPEC. 1239 According to [QoS-SIG], the QNE behavior depends on whether it is 1240 stateful or not. When a stateful QNE determines a malformed QSPEC 1241 error condition, it formulates a RESPONSE message that includes an 1242 INFO_SPEC with the 'malformed QSPEC' error code and QSPEC object. 1243 The QSPEC in the RESPONSE message includes, if possible, only the 1244 erroneous QSPEC parameters and no others. The erroneous QSPEC 1245 parameter(s) are marked with the E-Flag to clearly identify them. If 1246 QSPEC parameters are returned in the INFO-SPEC that are not marked 1247 with the E-flag, then any values of these parameters are irrelevant 1248 and MUST be ignored by the QNI. 1250 The default action for a stateless QoS NSLP QNE that detects a 1251 Malformed QSPEC error condition is that it MUST continue to forward 1252 the RESERVE message to the next stateful QNE, with the E-Flags 1253 appropriately set for each QSPEC parameter. The next stateful QNE 1254 will then act as described in [QoS-SIG]. 1256 A 'malformed QSPEC' error code takes precedence over the 'reservation 1257 failure' error code, and therefore the case of reservation failure 1258 and QSPEC/RMF error conditions are disjoint and the same E-Flag can 1259 be used in both cases without ambiguity. 1261 6.3.6 Domains Supporting a Different Local QOSM than the QNI 1263 A domain supporting a different local QOSM than the QNI domain 1264 inspects all QSPEC-1 parameters and consults its local QOSM as to how 1265 to interpret these parameters and decides whether it can accommodate 1266 the flow. This analysis can have these various outcomes: 1268 a) RMF determines that it can accommodate the flow with the QoS 1269 specified by the QNI, 1270 b) RMF determines that some initiator QSPEC parameters cannot be 1271 satisfied with the available resources, and marks the appropriate 1272 error flags (see Section 6.3.1), but does not reject the 1273 reservation, or 1274 c) RMF determines that some initiator QSPEC parameters cannot be 1275 satisfied with the available resources, marks the appropriate 1276 error flags (see Section 6.3.1), and also rejects the reservation. 1277 The QNE also in any event sets the non-QOSM-hop Q-flag, as 1278 described in Section 6.3.2. 1280 6.3.7 Special Cases of QSPEC Stacking 1282 When an unsuccessful reservation problem occurs inside a local domain 1283 where QSPEC stacking is used, only the topmost (local) QSPEC is 1284 affected (e.g. E-flags are raised, etc.). The initiator QSPEC at the 1285 bottom is untouched. When the message (RESPONSE in case of stateful 1286 QNEs, RESERVE in case of stateless QNEs) however reaches the edge of 1287 the stacking domain, the local QSPEC is popped, and its content, 1288 including flags, is translated into the initiator QSPEC. 1290 6.4 QSPEC Procedures 1292 While the QSPEC template aims to put minimal restrictions on usage of 1293 QSPEC objects in , interoperability between QNEs and 1294 between QOSMs must be ensured. We therefore give below an exhaustive 1295 list of QSPEC object combinations for the message sequences described 1296 in QoS NSLP [QoS-SIG]. A specific QOSM may prescribe that only a 1297 subset of the procedures listed below may be used. 1299 Note that QoS NSLP does not mandate the usage of a RESPONSE message. 1300 In fact, a RESPONSE message will only be generated if the QNI 1301 includes an RII (Request Identification Information) in the RESERVE 1302 message. Some of the QSPEC procedures below, however, are only 1303 meaningful when a RESPONSE message is possible. The QNI SHOULD in 1304 these cases include an RII. 1306 6.4.1 Sender-Initiated Reservations 1308 Here the QNI issues a RESERVE message, which may be replied to by a 1309 RESPONSE message. The following 3 cases for QSPEC object usage 1310 exist: 1312 ID | RESERVE | RESPONSE 1313 --------------------------------------------------------------- 1314 1 | QoS Desired | QoS Reserved 1315 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1316 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1318 Case 1: 1320 If only QoS Desired is included in the RESERVE message, the implicit 1321 assumption is that exactly these resources must be reserved. If this 1322 is not possible the reservation fails. The parameters in QoS 1323 Reserved are copied from the parameters in QoS Desired. If the 1324 reservation is successful, the RESPONSE message can be omitted in 1325 this case. If a RESPONSE message was requested by a QNE on the 1326 path, the QSPEC in the RESPONSE message can be omitted. 1328 Case 2: 1330 When QoS Available is included in the RESERVE message also, some 1331 parameters will appear only in QoS Available and not in QoS Desired. 1332 It is assumed that the value of these parameters is collected for 1333 informational purposes only (e.g. path latency). 1335 However, some parameters in QoS Available can be the same as in QoS 1336 Desired. For these parameters the implicit message is that the QNI 1337 would be satisfied by a reservation with lower parameter values than 1338 specified in QoS Desired. For these parameters, the QNI seeds the 1339 parameter values in QoS Available to those in QoS Desired (except for 1340 cumulative parameters such as ). 1342 Each QNE remaps or approximately interprets the parameters in QoS 1343 Available according to its current capabilities. Reservations in 1344 each QNE are hence based on current parameter values in QoS Available 1345 (and additionally those parameters that only appear in QoS Desired). 1346 The drawback of this approach is that, if the resulting resource 1347 reservation becomes gradually smaller towards the QNR, QNEs close to 1348 the QNI have an oversized reservation, possibly resulting in 1349 unnecessary costs for the user. Of course, in the RESPONSE the QNI 1350 learns what the actual reservation is (from the QoS RESERVED object) 1351 and can immediately issue a properly sized refreshing RESERVE. The 1352 advantage of the approach is that the reservation is performed in 1353 half-a-roundtrip time. 1355 The QSPEC parameter IDs and values included in the QoS Reserved 1356 object in the RESPONSE message MUST be the same as those in the QoS 1357 Desired object in the RESERVE message. For those QSPEC parameters 1358 that were also included in the QoS Available object in the RESERVE 1359 message, their value is copied into the QoS Desired object. For the 1360 other QSPEC parameters, the value is copied from the QoS Desired 1361 object (the reservation would fail if the corresponding QoS could 1362 not be reserved). 1364 All parameters in the QoS Available object in the RESPONSE message 1365 are copied with their values from the QoS Available object in the 1366 RESERVE message (irrespective of whether they have also been copied 1367 into the QoS Desired object). Note that the parameters in the QoS 1368 Available object are read-write in the RESERVE message, whereas they 1369 are read-only in the RESPONSE message. 1371 In this case, the QNI SHOULD request a RESPONSE message since it will 1372 otherwise not learn what QoS is available. 1374 Case 3: 1376 This case is handled as case 2, except that the reservation fails 1377 when QoS Available becomes less than Minimum QoS for one parameter. 1378 If a parameter appears in the QoS Available object but not in the 1379 Minimum QoS object it is assumed that there is no minimum value for 1380 this parameter. 1382 Regarding QSPEC Control Information, the default rule is that all 1383 QSPEC parameters that have been included in the RESERVE message by 1384 the QNI are also included in the RESPONSE message by the QNR with the 1385 value they had when arriving at the QNR. When traveling in the 1386 RESPONSE message, all QSPEC Control Information parameters are 1387 read-only. Note that a QOSM specification may define its own 1388 QOSM-specific Control Information parameters and processing rules. 1389 Also in this case, the QNI SHOULD request a RESPONSE message since it 1390 will otherwise not learn what QoS is available. 1392 6.4.2 Receiver-Initiated Reservations 1394 Here the QNR issues a QUERY message which is replied to by the QNI 1395 with a RESERVE message if the reservation was successful. The QNR in 1396 turn sends a RESPONSE message to the QNI. The following 3 cases for 1397 QSPEC object usage exist: 1399 ID| QUERY | RESERVE | RESPONSE 1400 --------------------------------------------------------------------- 1401 1 |QoS Des. | QoS Des. | QoS Res. 1402 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1403 3 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl. | QoS Res. 1405 Cases 1 and 2: 1407 The idea is that the sender (QNR in this scenario) needs to inform 1408 the receiver (QNI in this scenario) about the QoS it desires. To 1409 this end the sender sends a QUERY message to the receiver including a 1410 QoS Desired QSPEC object. If the QoS is negotiable it additionally 1411 includes a (possibly zero) Minimum QoS object, as in Case 2. 1413 The RESERVE message includes the QoS Available object if the sender 1414 signaled that QoS is negotiable (i.e. it included the Minimum QoS 1415 object). If the Minimum QoS object received from the sender is 1416 included in the QUERY message, the QNR also includes the Minimum QoS 1417 object in the RESERVE message. 1419 For a successful reservation, the RESPONSE message in case 1 is 1420 optional (as is the QSPEC inside). In case 2 however, the RESPONSE 1421 message is necessary in order for the QNI to learn about the QoS 1422 available. 1424 Case 4: 1426 This is the 'RSVP-style' scenario. The sender (QNR in this scenario) 1427 issues a QUERY message with a QoS Desired object informing the 1428 receiver (QNI in this scenario) about the QoS it desires as above. 1429 It also includes a QoS Available object to collect path properties. 1430 Note that here path properties are collected with the QUERY message, 1431 whereas in the previous case 2 path properties were collected in the 1432 RESERVE message. 1434 Some parameters in the QoS Available object may the same as in the 1435 QoS Desired object. For these parameters the implicit message is 1436 that the sender would be satisfied by a reservation with lower 1437 parameter values than specified in QoS Desired. 1439 It is possible for the QoS Available object to contain parameters 1440 that do not appear in the QoS Desired object. It is assumed that the 1441 value of these parameters is collected for informational purposes 1442 only (e.g. path latency). Parameter values in the QoS Available 1443 object are seeded according to the sender's capabilities. Each QNE 1444 remaps or approximately interprets the parameter values according to 1445 its current capabilities. 1447 The receiver (QNI in this scenario) signals the QoS Desired object as 1448 follows: For those parameters that appear in both the QoS Available 1449 object and QoS Desired object in the QUERY message, it takes the 1450 (possibly remapped) QSPEC parameter values from the QoS Available 1451 object. For those parameters that only appear in the QoS Desired 1452 object, it adopts the parameter values from the QoS Desired object. 1454 The parameters in the QoS Available QSPEC object in the RESERVE 1455 message are copied with their values from the QoS Available QSPEC 1456 object in the QUERY message. Note that the parameters in the QoS 1457 Available object are read-write in the QUERY message, whereas they 1458 are read-only in the RESERVE message. 1460 The advantage of this model compared to the sender-initiated 1461 reservation is that the situation of over-reservation in QNEs close 1462 to the QNI as described above does not occur. On the other hand, the 1463 QUERY message may find, for example, a particular bandwidth is not 1464 available. When the actual reservation is performed, however, the 1465 desired bandwidth may meanwhile have become free. That is, the 'RSVP 1466 style' may result in a smaller reservation than necessary. 1468 Regarding QSPEC Control Information in receiver-initiated 1469 reservations, the sender includes all QSPEC Control Information it 1470 cares about in the QUERY message. Read-write parameters are updated 1471 by QNEs as the QUERY message travels towards the receiver. The 1472 receiver includes all QSPEC Control Information parameters arriving 1473 in the QUERY message also in the RESERVE message, as read-only 1474 parameters with the value they had when arriving at the receiver. 1475 Again, QOSM-specific Control Information parameters and procedures 1476 may be defined in QOSM specification documents. 1478 Also in this scenario, the QNI SHOULD request a RESPONSE message 1479 since it will otherwise not learn what QoS is available. 1481 6.4.3 Resource Queries 1483 Here the QNI issues a QUERY message in order to investigate what 1484 resources are currently available. The QNR replies with a RESPONSE 1485 message. 1487 ID | QUERY | RESPONSE 1488 -------------------------------------------- 1489 1 | QoS Available | QoS Available 1491 Note that the QoS Available object when traveling in the QUERY 1492 message is read-write, whereas in the RESPONSE message it is 1493 read-only. 1495 6.4.4 Bidirectional Reservations 1497 On a QSPEC level, bidirectional reservations are no different from 1498 uni-directional reservations, since QSPECs for different directions 1499 never travel in the same message. 1501 6.4.5 Preemption 1503 A flow can be preempted by a QNE based on the values of the QSPEC 1504 Priority parameter (see Section 7.2.4). In this case the reservation 1505 state for this flow is torn down in this QNE, and the QNE sends a 1506 NOTIFY message to the QNI, as described in [QoS-SIG]. No QSPEC is 1507 carried in the NOTIFY message. The NOTIFY message carries only the 1508 Session ID and a INFO_SPEC with the error code as described in 1509 [QoS-SIG]. The QNI would normally tear down the preempted 1510 reservation by sending a RESERVE message with the TEAR flag set using 1511 the SII of the preempted reservation. However, the QNI can follow 1512 other procedures as specified in its QOSM specification document. 1514 6.5 QSPEC Extensibility 1516 This document defines both QSPEC-1 and QSPEC-2 parameters. The 1517 set of QSPEC-1 parameters defined herein is at this point in time 1518 considered complete. The QSPEC-2 parameters in this document 1519 correspond to some of the QSPEC-2 parameters considered in QOSMs 1520 currently being defined. 1522 Additional QSPEC-1 parameters may be defined in the future. However, 1523 since this requires an update of all QNEs, this should be considered 1524 carefully. The definition of new QSPEC-1 parameter requires 1525 standards action and an update of this document. Such an update also 1526 needs a new QSPEC version number. Furthermore, all QOSM definitions 1527 must be updated to include how the new QSPEC-1 parameter is to be 1528 interpreted in the respective QOSM. 1530 Additional QSPEC-2 parameters MAY need to be defined in the future 1531 and are defined in separate informational documents specific to a 1532 given QOSM. For example, QSPEC-2 parameters are defined in 1533 [RMD-QOSM] and [Y.1541-QOSM]. 1535 Guidelines on the technical criteria to be followed in evaluating 1536 requests for new codepoint assignments for QSPEC objects and QSPEC 1537 parameters are given in Section 9 (IANA Considerations). 1539 Guidelines on the technical criteria to be followed in evaluating 1540 requests for new codepoint assignments beyond QSPEC objects and 1541 QSPEC parameters for the NSIS protocol suite are given in a separate 1542 NSIS extensibility document [NSIS-EXTENSIBILITY]. 1544 7. QSPEC Functional Specification 1546 This section defines the encodings of the QSPEC parameters and QSPEC 1547 control information defined in Section 5. We first give the general 1548 QSPEC formats and then the formats of the QSPEC objects and 1549 parameters. 1551 Note that all QoS description parameters can be either read-write or 1552 read-only, depending on which object and which message they appear 1553 in. All parameters in the QoS Desired object, QoS Reserved object, 1554 and Minimum QoS object are read-only for all messages. All 1555 parameters in the QoS Available object are normally read-write 1556 parameters. However, as discussed in Section 5.2.2, the parameters 1557 in the QoS Available object are read-write when the QoS Available 1558 object appears for the first time e.g. in the RESERVE message or 1559 QUERY message from QNI to QNR. However, on its way back, all 1560 parameters in the object are read-only, e.g., in the 1561 RESPONSE message or RESERVE message from QNR to QNI. For QSPEC 1562 control information parameters, the property of being read-write or 1563 read-only is parameter specific. Note that the only control 1564 information parameter specified in this document is the parameter, which is a read-only parameter. 1567 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1568 well as 32-bit floating point numbers, are as specified in [RFC1832, 1569 IEEE754, NETWORK-BYTE-ORDER]. 1571 7.1 General QSPEC Formats 1573 The format of the QSPEC closely follows that used in GIST [GIST] and 1574 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1575 general format: 1577 o The overall format is Type-Length-Value (in that order). 1579 o Some parts of the type field are set aside for control flags. 1581 o Length has the units of 32-bit words, and measures the length of 1582 Value. If there is no Value, Length=0. The Object length 1583 excludes the header. 1585 o Value is a whole number of 32-bit words. If there is any padding 1586 required, the length and location MUST be defined by the 1587 object-specific format information; objects that contain variable 1588 length types may need to include additional length subfields to do 1589 so. 1591 o Any part of the object used for padding or defined as reserved("r") 1592 MUST be set to 0 on transmission and MUST be ignored on reception. 1594 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1596 o Duplicate objects, duplicate parameters, and/or multiple 1597 occurrences of a parameter MUST NOT be used. 1599 0 1 2 3 1600 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 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Common QSPEC Header | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 // QSPEC Control Information // 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 // QSPEC QoS Description Objects // 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 The Common QSPEC Header is a fixed 4-byte long object containing the 1610 QOSM ID and an identifier for the QSPEC Procedure (see Section 6.4): 1612 0 1 2 3 1613 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | Vers. | QOSM ID | QSPEC Proc. | Reserved | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 Note that a length field is not necessary since the overall length of 1619 the QSPEC is contained in the higher level QoS NSLP data object. 1621 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1623 QOSM ID: Identifies the particular QOSM being used by the QNI. It is 1624 assigned by IANA. 1626 QSPEC Proc.: Is composed of two times 4 bits. The first set of bits 1627 identifies the Message Sequence, the second set 1628 identifies the QSPEC Object Combination used for this 1629 particular message sequence: 1631 0 1 2 3 4 5 6 7 1632 +-+-+-+-+-+-+-+-+ 1633 |Mes.Sq |Obj.Cmb| 1634 +-+-+-+-+-+-+-+-+ 1636 The Message Sequence field can attain the following 1637 values: 1639 0: Sender-Initiated Reservations 1640 1: Receiver-Initiated Reservations 1641 2: Resource Queries 1643 The Object Combination field can take the values between 1644 1 and 3 indicated in the tables in Section 6.4: 1645 Message Sequence: 0 1646 Object Combination: 1, 2, 3 1647 Semantic: see table in Section 6.4.1 1648 Message Sequence: 1 1649 Object Combination: 1, 2, 3 1650 Semantic: see table in Section 6.4.2 1651 Message Sequence: 2 1652 Object Combination: 1, 2, 3 1653 Semantic: see table in Section 6.4.3 1655 The QSPEC Control Information is a variable length object containing 1656 one or more parameters. The QSPEC Objects field is a collection of 1657 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1658 common format and each contain several parameters. 1660 Both the QSPEC Control Information object and the QSPEC QoS objects 1661 share a common header format: 1663 0 1 2 3 1664 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 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 |E|Q|r|r| Object Type |r|r|r|r| Length | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 E Flag: Set if an error occurs on object level 1670 Q Flag: NON QOSM Hop flag: This field is set to 1 if a QOSM different 1671 from the initiator QOSM is encountered by the QNE. 1672 Object Type = 0: control information (read-only/read-write status is 1673 parameter specific) 1674 = 1: QoS Desired (parameters are all read-only) 1675 = 2: QoS Available (parameters are either all read-write 1676 rr all read-only; see Section 5.2.2) 1677 = 3: QoS Reserved (parameters are all read-only) 1678 = 4: Minimum QoS (parameters are all read-only) 1680 Note that parameters contained in QoS Description objects are all 1681 read-write or all read-only, as specified above. In the Control 1682 Information object, read-only or read-write is parameter specific. 1684 The r bits are reserved. 1686 Each QSPEC-1 or QSPEC-2 parameter within an object is similarly 1687 encoded in TLV format using a similar parameter header: 1689 0 1 2 3 1690 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 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 |M|E|N|R| Parameter ID |r|r|r|r| Length | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 M Flag: When set indicates the subsequent parameter is a QSPEC-1 1696 parameter and MUST be interpreted. Otherwise the parameter is 1697 QSPEC-2 and can be ignored if not understood. 1698 E Flag: When set indicates either a) a reservation failure where the 1699 QSPEC parameter is not met, or b) an error occurred when this 1700 parameter was being interpreted (see Section 6.3.1). 1701 N Flag: Not-supported QSPEC parameter flag (see Section 6.3.3). 1702 For QSPEC-1 parameters the value of this flag is always zero. 1703 R Flag: Remapped, approximated, or otherwise not strictly interpreted 1704 QSPEC parameter flag (see Section 6.3.2) 1705 Parameter ID: Assigned to each parameter (see below) 1707 Parameters are usually coded individually, for example, the parameter (Section 7.2.1). However, it is also possible 1709 to combine several sub-parameters into one parameter field, which is 1710 called 'container coding'. This coding is useful if either a) the 1711 sub-parameters always occur together, as for example the several 1712 sub-parameters that jointly make up the token bucket, or b) in order 1713 to make coding more efficient when the length of each sub-parameter 1714 value is much less than a 32-bit word (as for example described in 1715 [RMD-QOSM]) and to avoid header overload. When a container is 1716 defined, the Parameter ID and the M, E, N, and R flags refer to the 1717 container. Examples of container parameters are , , , and , as specified below, and the 1719 PHR container parameter specified in [RMD-QOSM]. 1721 7.2 QSPEC-1 Parameter Coding 1723 7.2.1 Parameter 1725 0 1 2 3 1726 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 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 |1|E|0|R| 1 |r|r|r|r| 1 | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Excess Trtmnt | Remark Value | Reserved | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 1734 traffic, that is, traffic not covered by the parameter. 1735 The excess treatment parameter is set by the QNI. It is a read-only 1736 parameter. Allowed values are as follows: 1738 0: drop 1739 1: shape 1740 2: remark 1741 3: no metering or policing is permitted 1743 The default excess treatment in case that none is specified is that 1744 there are no guarantees to excess traffic, i.e. a QNE can do whatever 1745 it finds suitable. 1747 When excess treatment is set to 'drop', all marked traffic MUST be 1748 dropped by the QNE/RMF. 1750 When excess treatment is set to 'shape', it is expected that the 1751 QoS Desired object carries a token bucket parameter. Excess traffic 1752 is to be shaped to this token bucket. When the shaping causes 1753 unbounded queue growth at the shaper traffic can be dropped. 1755 When excess treatment is set to 'remark', the excess treatment 1756 parameter MUST carry the remark value, and the remark values and 1757 procedures MUST be specified in the QOSM specification document. 1758 For example, packets may be remarked to drop remarked to pertain to a 1759 particular QoS class". In the latter case, remarking relates to a 1760 DiffServ-type model, where packets arrive marked as belonging to a 1761 certain QoS class, and when they are identified as excess, they 1762 should then be remarked to a different QoS Class. 1764 If 'no metering or policing is permitted' is signaled, the QNE should 1765 accept the excess treatment parameter set by the sender with special 1766 care so that excess traffic should not cause a problem. To request 1767 the Null Meter [RFC3290] is especially strong, and should be used 1768 with caution. 1770 A NULL metering application [RFC2997] would not include the traffic 1771 profile, and conceptually it should be possible to support this with 1772 the QSPEC. A QSPEC without a traffic profile is not excluded by the 1773 current specification. However, note that the traffic profile is 1774 important even in those cases when the excess treatment is not 1775 specified, e.g., in negotiating bandwidth for the best effort 1776 aggregate. However, a "NULL Service QOSM" would need to be specified 1777 where the desired QNE Behavior and the corresponding QSPEC format are 1778 described. 1780 As an example behavior for a NULL metering, in the properly 1781 configured DiffServ router, the resources are shared between the 1782 aggregates by the scheduling disciplines. Thus, if the incoming rate 1783 increases, it will influence the state of a queue within that 1784 aggregate, while all the other aggregates will be provided sufficient 1785 bandwidth resources. NULL metering is useful for best effort and 1786 signaling data, where there is no need to meter and police this data 1787 as it will be policed implicitly by the allocated bandwidth and, 1788 possibly, active queue management mechanism. 1790 7.2.2 Parameter 1792 = [] [] 1794 = link bandwidth needed by flow [RFC2212, RFC2215] 1796 =

[RFC2210] 1798 The above notation means that either or 1799 sub-parameters can be populated in the parameter and that 1800 one and only one of them MUST be present. Note that an QSPEC-2 1801 second token bucket QSPEC parameter is specified 1802 below in Section 7.3.1. The references in the following sections 1803 point to the normative procedures for processing the and 1804 sub-parameters. 1806 The coding for the parameter is as follows: 1808 0 1 2 3 1809 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 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 |1|E|0|R| 2 |r|r|r|r| 6 | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | Bandwidth (32-bit IEEE floating point number) | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Token Bucket Rate-1 [r] (32-bit IEEE floating point number) | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Token Bucket Size-1 [b] (32-bit IEEE floating point number) | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Maximum Packet Size-1 [MTU] (32-bit unsigned integer) | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 Normally only one of these sub-parameters is populated in the 1827 parameter. If more than one sub-parameter is populated, 1828 the QOSM specification document MUST give procedures for processing 1829 multiple sub-parameters. The references in the following sections 1830 point to the normative procedures for processing the and 1831 sub-parameters. 1833 7.2.2.1 Sub-Parameter [RFC2212, RFC2215] 1835 The parameter MUST be nonnegative and is measured in 1836 bytes per second and has the same range and suggested representation 1837 as the bucket and peak rates of the . is 1838 represented using single-precision IEEE floating point. The 1839 representation MUST be able to express values ranging from 1 byte per 1840 second to 40 terabytes per second. For values of this parameter only 1841 valid non-negative floating point numbers are allowed. Negative 1842 numbers (including "negative zero"), infinities, and NAN's are not 1843 allowed. 1845 A QNE MAY export a local value of zero for this parameter. A network 1846 element or application receiving a composed value of zero for this 1847 parameter MUST assume that the actual bandwidth available is unknown. 1849 7.2.2.2 Sub-Parameters [RFC2215] 1851 The parameters are represented by three floating point 1852 numbers in single-precision IEEE floating point format followed by 1853 two 32-bit integers in network byte order. The first floating point 1854 value is the rate (r), the second floating point value is the bucket 1855 size (b), the third floating point is the peak rate (p), the first 1856 unsigned integer is the minimum policed unit (m), and the second 1857 unsigned integer is the maximum datagram size (MTU). 1859 Note that the two sets of parameters can be 1860 distinguished, as could be needed for example to support DiffServ 1861 applications. 1863 When r, b, and p terms are represented as IEEE floating point values, 1864 the sign bit MUST be zero (all values MUST be non-negative). 1865 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1866 than 162 (i.e., positive 35) are discouraged, except for specifying a 1867 peak rate of infinity. Infinity is represented with an exponent of 1868 all ones (255) and a sign bit and mantissa of all zeroes. 1870 7.2.3 Parameter 1872 = [] [] [] 1874 The above notation means that either , , 1875 or sub-parameters MAY be populated in the parameter. Normally only one of these sub-parameters is 1877 populated in . If more than one sub-parameter is 1878 populated, the QOSM specification document MUST give procedures for 1879 processing multiple sub-parameters. The references in the following 1880 sections point to the normative procedures for processing the , , and sub-parameters. 1883 The coding for the parameter is as follows: 1885 0 1 2 3 1886 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 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 |1|E|0|R| 3 |r|r|r|r| 3 | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | DSCP |0 0 0 0 0 0 0 0 0 0|DSTE Cls. Type |Y.1541 QoS Cls.| 1891 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1892 | QoS Class Parameters (Reserved) | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | QoS Class Parameters (Reserved) | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 7.2.3.1 Sub-Parameter [RFC3140] 1899 As prescribed in RFC 3140, the encoding for a single PHB is the 1900 recommended DSCP value for that PHB, left-justified in the 16 bit 1901 field, with bits 6 through 15 set to zero. 1903 The encoding for a set of PHBs is the numerically smallest of the set 1904 of encodings for the various PHBs in the set, with bit 14 set to 1. 1905 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 1906 bit 14 set to 1.) 1907 0 1 1908 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | DSCP |0 0 0 0 0 0 0 0 X 0| 1911 +---+---+---+---+---+---+---+---+ 1913 PHBs not defined by standards action, i.e., experimental or local use 1914 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 1915 identification code, assigned by the IANA, is placed left-justified 1916 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 1917 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 1919 0 1 1920 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | PHD ID CODE |0 0 X 0| 1923 +---+---+---+---+---+---+---+---+ 1925 Bits 12 and 13 are reserved either for expansion of the PHB 1926 identification code, or for other use, at some point in the future. 1928 In both cases, when a single PHBID is used to identify a set of PHBs 1929 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 1930 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 1931 intra-microflow traffic reordering when different PHBs from the set 1932 are applied to traffic in the same microflow). The set of AF1x PHBs 1933 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs 1934 that do not constitute a PHB Scheduling Class can be identified by 1935 using more than one PHBID. 1937 The registries needed to use RFC 3140 already exist, see 1938 [DSCP-REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs 1939 to be created for this purpose. 1941 7.2.3.2 Sub-Parameter [RFC4124] 1943 DSTE Class Type: Indicates the DSTE class type. Values currently 1944 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 1945 that the parameter is not used. 1947 7.2.3.3 Sub-Parameter [Y.1541] 1949 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 1950 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 1951 that the parameter is not used. 1953 Class 0: 1954 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1955 Real-time, highly interactive applications, sensitive to jitter. 1956 Application examples include VoIP, Video Teleconference. 1958 Class 1: 1959 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1960 Real-time, interactive applications, sensitive to jitter. 1961 Application examples include VoIP, Video Teleconference. 1963 Class 2: 1964 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 1965 10^-3. Highly interactive transaction data. Application examples 1966 include signaling. 1968 Class 3: 1969 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 1970 10^-3. Interactive transaction data. Application examples include 1971 signaling. 1973 Class 4: 1974 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 1975 10^-3. Low Loss Only applications. Application examples include 1976 short transactions, bulk data, video streaming. 1978 Class 5: 1979 Mean delay unspecified, delay variation unspecified, loss ratio 1980 unspecified. Unspecified applications. Application examples include 1981 traditional applications of default IP networks. 1983 Class 6: 1984 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1985 Applications that are highly sensitive to loss, such as television 1986 transport, high-capacity TCP transfers, and TDM circuit emulation. 1988 Class 7: 1989 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1990 Applications that are highly sensitive to loss, such as television 1991 transport, high-capacity TCP transfers, and TDM circuit emulation. 1993 7.2.4 Parameter 1995 = [] [] 1996 [] [] 1998 The above notation means that either , 1999 , , and/or 2000 sub-parameters MAY be populated in the parameter. Any or 2001 all of these sub-parameters may be populated in the 2002 parameter. The references in the following sections point to the 2003 normative procedures for processing the , 2004 , , and 2005 sub-parameters. 2007 The following cases are permissible (procedures specified in 2008 references): 2010 1 parameter: [Y.1571] 2011 2 parameters: , [RFC4412] 2012 2 parameters: , [RFC3181] 2013 3 parameters: , , 2014 [3GPP-1, 3GPP-2, 3GPP-3] 2015 4 parameers: , , 2016 , [3GPP-1, 3GPP-2, 2017 3GPP-3] 2019 It is permissible to have without , but not permissible to have without 2021 (alternatively is ignored in 2022 instances without ). 2024 eMLPP-like functionality (as defined in [3GPP-1, 3GPP-2]) specifies 2025 use of corresponding to the 'queuing allowed' 2026 part of eMLPP as well as 2027 corresponding to the 'preemption capable' and 'may be preempted' 2028 parts of eMLPP. 2030 The coding for the parameter is as follows: 2032 0 1 2 3 2033 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 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 |1|E|0|R| 4 |r|r|r|r| 4 | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Preemption Priority | Defending Priority | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 + Admis.Priority| RPH Namespace | RPH Priority | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Priority Parameters(Reserved) | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | Priority Parameters(Reserved) | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 7.2.4.1 & Sub-Parameters 2047 [RFC3181] 2049 Preemption Priority: The priority of the new flow compared with the 2050 defending priority of previously admitted flows. Higher values 2051 represent higher priority. 2053 Defending Priority: Once a flow is admitted, the preemption priority 2054 becomes irrelevant. Instead, its defending priority is used to 2055 compare with the preemption priority of new flows. 2057 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 2059 parameter is used. 2061 7.2.4.2 Sub-Parameter [Y.1571] 2063 High priority flows, normal priority flows, and best-effort priority 2064 flows can have access to resources depending on their admission 2065 priority value, as described in [Y.1571], as follows: 2067 Admission Priority: 2069 0 - best-effort priority flow 2070 1 - normal priority flow 2071 2 - high priority flow 2072 255 - not used 2074 A reservation without an sub-parameter (i.e., 2075 set to 255) MUST be treated as a reservation with an = 1. 2078 7.2.4.3 Sub-Parameter [RFC4412] 2080 [RFC4412] defines a resource priority header (RPH) with parameters 2081 "RPH Namespace" and "RPH Priority" combination, and if populated is 2082 applicable only to flows with high admission priority, as follows: 2084 RPH Namespace: 2086 0 - dsn 2087 1 - drsn 2088 2 - q735 2089 3 - ets 2090 4 - wps 2091 255 - not used 2093 RPH Priority: 2094 Each namespace has a finite list of relative priority-values. Each 2095 is listed here in the order of lowest priority to highest priority 2096 (note that dsn and drsn priority values are TBD): 2098 4 - q735.4 2099 3 - q735.3 2100 2 - q735.2 2101 1 - q735.1 2102 0 - q735.0 2104 4 - ets.4 2105 3 - ets.3 2106 2 - ets.2 2107 1 - ets.1 2108 0 - ets.0 2110 4 - wps.4 2111 3 - wps.3 2112 2 - wps.2 2113 1 - wps.1 2114 0 - wps.0 2116 Note that the parameter MAY be used in 2117 combination with the parameter, which depends on the 2118 supported QOSM. Furthermore, if more then one RPH namespace is 2119 supported by a QOSM, then the QOSM MUST specify how the mapping 2120 between the priorities belonging to the different RPH namespaces are 2121 mapped to each other. 2123 Note also that additional work is needed to communicate these flow 2124 priority values to bearer-level network elements 2125 [VERTICAL-INTERFACE]. 2127 7.3 QSPEC-2 Parameter Coding 2129 7.3.1 Parameter [RFC2215] 2131 A second, QSPEC-2 parameter is specified, as could 2132 be needed for example to support DiffServ applications [xxxx]. 2134 Parameter Values: 2136 0 1 2 3 2137 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 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 |0|E|N|R| 5 |r|r|r|r| 5 | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Token Bucket Rate-2 [r] (32-bit IEEE floating point number) | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | Token Bucket Size-2 [b] (32-bit IEEE floating point number) | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | Maximum Packet Size-2 [MTU] (32-bit unsigned integer) | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 When r, b, and p terms are represented as IEEE floating point values, 2153 the sign bit MUST be zero (all values MUST be non-negative). 2154 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 2155 than 162 (i.e., positive 35) are discouraged, except for specifying a 2156 peak rate of infinity. Infinity is represented with an exponent of 2157 all ones (255) and a sign bit and mantissa of all zeroes. 2159 7.3.2 Parameter [RFC2210, RFC2215] 2161 0 1 2 3 2162 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 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 |0|E|N|R| 6 |r|r|r|r| 1 | 2165 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2166 | Path Latency (32-bit integer) | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 The Path Latency is a single 32-bit integer in network byte order. 2170 The composition rule for the parameter is summation 2171 with a clamp of (2**32 - 1) on the maximum value. The latencies are 2172 average values reported in units of one microsecond. A system with 2173 resolution less than one microsecond MUST set unused digits to zero. 2174 An individual QNE can advertise a latency value between 1 and 2**28 2175 (somewhat over two minutes) and the total latency added across all 2176 QNEs can range as high as (2**32)-2. If the sum of the different 2177 elements delays exceeds (2**32)-2, the end-to-end advertised delay 2178 SHOULD be reported as indeterminate. A QNE that cannot accurately 2179 predict the latency of packets it is processing MUST raise the 2180 not-supported flagand either leave the value of Path Latency as is, 2181 or add its best estimate of its lower bound. A raised not-supported 2182 flagflag indicates the value of Path Latency is a lower bound of the 2183 real Path Latency. The distinguished value (2**32)-1 is taken to 2184 mean indeterminate latency because the composition function limits 2185 the composed sum to this value, it indicates the range of the 2186 composition calculation was exceeded. 2188 7.3.3 Parameter 2190 0 1 2 3 2191 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 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 |0|E|N|R| 7 |r|r|r|r| 4 | 2194 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2195 | Path Jitter STAT1(variance) (32-bit integer) | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | Path Jitter STAT4(Reserved) (32-bit integer) | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 The Path Jitter is a set of four 32-bit integers in network byte 2205 order. The Path Jitter parameter is the combination of four 2206 statistics describing the Jitter distribution with a clamp of 2207 (2**32 - 1) on the maximum of each value. The jitter STATs are 2208 reported in units of one microsecond. A system with resolution less 2209 than one microsecond MUST set unused digits to zero. An individual 2210 QNE can advertise jitter values between 1 and 2**28 (somewhat over 2211 two minutes) and the total jitter computed across all QNEs can range 2212 as high as (2**32)-2. If the combination of the different element 2213 values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be 2214 reported as indeterminate. A QNE that cannot accurately predict the 2215 jitter of packets it is processing MUST raise the not-supported flag 2216 and either leave the value of Path Jitter as is, or add its best 2217 estimate of its STAT values. A raised not-supported flag indicates 2218 the value of Path Jitter is a lower bound of the real Path Jitter. 2219 The distinguished value (2**32)-1 is taken to mean indeterminate 2220 jitter. A QNE that cannot accurately predict the jitter of packets 2221 it is processing SHOULD set its local parameter to this value. 2222 Because the composition function limits the total to this value, 2223 receipt of this value at a network element or application indicates 2224 that the true path jitter is not known. This MAY happen because one 2225 or more network elements could not supply a value, or because the 2226 range of the composition calculation was exceeded. 2228 NOTE: The Jitter composition function makes use of the 2229 parameter. Composition functions for loss, latency and jitter may be 2230 found in [Y.1541]. 2232 7.3.4 Parameter 2234 0 1 2 3 2235 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 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 |0|E|N|R| 8 |r|r|r|r| 1 | 2238 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2239 | Path Packet Loss Ratio (32-bit floating point) | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 The Path PLR is a single 32-bit single precision IEEE floating point 2243 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 2245 value. The PLRs are reported in units of 10^-11. A system with 2246 resolution less than one microsecond MUST set unused digits to zero. 2247 An individual QNE can advertise a PLR value between zero and 10^-2 2248 and the total PLR added across all QNEs can range as high as 10^-1. 2249 If the sum of the different elements values exceeds 10^-1, the 2250 end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE 2251 that cannot accurately predict the PLR of packets it is processing 2252 MUST raise the not-supported flag and either leave the value of Path 2253 PLR as is, or add its best estimate of its lower bound. A raised 2254 not-supported flag indicates the value of Path PLR is a lower bound 2255 of the real Path PLR. The distinguished value 10^-1 is taken to mean 2256 indeterminate PLR. A QNE which cannot accurately predict the PLR of 2257 packets it is processing SHOULD set its local parameter to this 2258 value. Because the composition function limits the composed sum to 2259 this value, receipt of this value at a network element or application 2260 indicates that the true path PLR is not known. This MAY happen 2261 because one or more network elements could not supply a value, or 2262 because the range of the composition calculation was exceeded. 2264 7.3.5 Parameter 2266 0 1 2 3 2267 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 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 |0|E|N|R| 9 |r|r|r|r| 1 | 2270 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2271 | Path Packet Error Ratio (32-bit floating point) | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 The Path PER is a single 32-bit single precision IEEE floating point 2275 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 2277 value. The PERs are reported in units of 10^-11. A system with 2278 resolution less than one microsecond MUST set unused digits to zero. 2279 An individual QNE can advertise a PER value between zero and 10^-2 2280 and the total PER added across all QNEs can range as high as 10^-1. 2281 If the sum of the different elements values exceeds 10^-1, the 2282 end-to-end advertised PER SHOULD be reported as indeterminate. A QNE 2283 that cannot accurately predict the PER of packets it is processing 2284 MUST raise the not-supported flag and either leave the value of Path 2285 PER as is, or add its best estimate of its lower bound. A raised 2286 not-supported flag indicates the value of Path PER is a lower bound 2287 of the real Path PER. The distinguished value 10^-1 is taken to mean 2288 indeterminate PER. A QNE which cannot accurately predict the PER of 2289 packets it is processing SHOULD set its local parameter to this 2290 value. Because the composition function limits the composed sum to 2291 this value, receipt of this value at a network element or application 2292 indicates that the true path PER is not known. This MAY happen 2293 because one or more network elements could not supply a value, or 2294 because the range of the composition calculation was exceeded. 2296 7.3.6 Parameters [RFC2210, RFC2212, 2297 RFC2215] 2299 0 1 2 3 2300 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 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 |0|E|N|R| 10 |r|r|r|r| 1 | 2303 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2304 | End-to-end composed value for C [Ctot] (32-bit integer) | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 0 1 2 3 2307 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 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 |0|E|N|R| 11 |r|r|r|r| 1 | 2310 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2311 | End-to-end composed value for D [Dtot] (32-bit integer) | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 0 1 2 3 2315 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 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 |0|E|N|R| 12 |r|r|r|r| 1 | 2318 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2319 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 0 1 2 3 2323 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 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 |0|E|N|R| 13 |r|r|r|r| 1 | 2326 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2327 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 The error term C is measured in units of bytes. An individual QNE 2331 can advertise a C value between 1 and 2**28 (a little over 250 2332 megabytes) and the total added over all QNEs can range as high as 2333 (2**32)-1. Should the sum of the different QNEs delay exceed 2334 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 2335 error term D is measured in units of one microsecond. An individual 2336 QNE can advertise a delay value between 1 and 2**28 (somewhat over 2337 two minutes) and the total delay added over all QNEs can range as 2338 high as (2**32)-1. Should the sum of the different QNEs delay 2339 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 2341 7.3.7 Parameter [RFC2212, RFC2215] 2343 0 1 2 3 2344 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 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 |0|E|N|R| 14 |r|r|r|r| 1 | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Slack Term [S] (32-bit integer) | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 Slack term S MUST be nonnegative and is measured in microseconds. 2352 The Slack term, S, is represented as a 32-bit integer. Its value 2353 can range from 0 to (2**32)-1 microseconds. 2355 8. Security Considerations 2357 The priority parameter raises possibilities for theft of service 2358 attacks because users could claim an emergency priority for their 2359 flows without real need, thereby effectively preventing serious 2360 emergency calls to get through. Several options exist for countering 2361 such attacks, for example 2363 - only some user groups (e.g. the police) are authorized to set the 2364 emergency priority bit 2366 - any user is authorized to employ the emergency priority bit for 2367 particular destination addresses (e.g. police) 2369 9. IANA Considerations 2371 This section defines the registries and initial codepoint assignments 2372 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 2373 It also defines the procedural requirements to be followed by IANA in 2374 allocating new codepoints. 2376 This specification creates the following registries with the 2377 structures as defined below: 2379 Object Types (12 bits): 2380 The following values are allocated by this specification: 2381 0-4: assigned as specified in Section 7: 2382 Object Type = 0: control information 2383 = 1: QoS Desired 2384 = 2: QoS Available 2385 = 3: QoS Reserved 2386 = 4: Minimum QoS 2387 The allocation policies for further values are as follows: 2388 5-63: Standards Action 2389 64-127: Private/Experimental Use 2390 128-4095: Reserved 2391 (Note: 'Reserved' just means 'do not give these out'.) 2393 QSPEC Version (4 bits): 2394 The following value is allocated by this specification: 2395 0: assigned to Version 0 QSPEC 2396 The allocation policies for further values are as follows: 2397 1-15: Standards Action 2398 A specification is required to depreciate, delete, or modify QSPEC 2399 versions. 2401 QOSM ID (12 bits): 2402 The allocation policies are as follows: 2403 0-63: Specification Required 2404 64-127: Private/Experimental Use 2405 128-4095: Reserved 2406 A specification is required to depreciate, delete, or modify QOSM 2407 IDs. 2409 QSPEC Procedure (8 bits): 2410 Broken down into 2411 Message Sequence (4 bits): 2412 The following values are allocated by this specification: 2413 0-2: assigned as specified in Section 7.1: 2414 Message Sequence 0: 2415 Semantic: QSPEC Procedure = Sender-Initiated Reservations 2416 (see Section 6.4.1) 2417 Message Sequence 1: 2418 Semantic: QSPEC Procedure = Receiver-Initiated Reservations 2419 (see Section 6.4.2) 2420 Message Sequence 2: 2421 Semantic: QSPEC Procedure = Resource Queries (see Section 6.4.3) 2422 The allocation policies for further values are as follows: 2423 3-15: Standards Action 2424 Object Combination (4 bits): 2425 The following values are allocated by this specification: 2426 The Object Combination field can take the values between 2427 1 and 3 indicated in the tables in Section 6: 2428 Message Sequence: 0 2429 Object Combination: 1, 2, 3 2430 Semantic: see table in Section 6.4.1 2431 Message Sequence: 1 2432 Object Combination: 1, 2, 3 2433 Semantic: see table in Section 6.4.2 2434 Message Sequence: 2 2435 Object Combination: 1, 2, 3 2436 Semantic: see table in Section 6.4.3 2437 The allocation policies for further values are as follows: 2438 3-15: Standards Action 2439 A specification is required to depreciate, delete, or modify QSPEC 2440 Procedures. 2442 Error Code (16 bits) 2443 The allocation policies are as follows: 2444 0-127: Specification Required 2445 128-255: Private/Experimental Use 2446 255-65535: Reserved 2447 A specification is required to depreciate, delete, or modify Error 2448 Codes. 2450 Parameter ID (12 bits): 2451 The following values are allocated by this specification: 2452 1-14: assigned as specified in Sections 7.2 and 7.3: 2453 Parameter ID 1: Parameter 2454 2: Parameter 2455 3: Parameter 2456 4: Parameter 2457 5: Parameter 2458 6: Parameter 2459 7: Parameter 2460 8: Parameter 2461 9: Parameter 2462 10: Parameter 2463 11: Parameter 2464 12: Parameter 2465 13: Parameters 2466 14: Parameter 2467 The allocation policies for further values are as follows: 2468 15-63: Standards Action (for QSPEC-1 parameters) 2469 64-127: Specification Required (for QSPEC-2 parameters) 2470 128-255: Private/Experimental Use 2471 255-4095: Reserved 2473 A specification is required to depreciate, delete, or modify 2474 Parameter IDs. Note that if additional QSPEC-1 parameters are 2475 defined in the future, this requires a standards action equivalent to 2476 reissuing this document as a QSPEC-bis. 2478 Excess Treatment Parameter (8 bits): 2479 The following values are allocated by this specification: 2480 0-3: assigned as specified in Section 7.2.1: 2481 Excess Treatment Parameter 0: drop 2482 1: shape 2483 2: remark 2484 3: no metering or policing is 2485 permitted 2486 The allocation policies for further values are as follows: 2487 4-63: Standards Action 2488 64-255: Reserved 2489 Remark Value (8 bits) 2490 The allocation policies are as follows: 2491 0-63: Specification Required 2492 64-127: Private/Experimental Use 2493 128-255: Reserved 2495 DSTE Class Type Sub-Parameter (8 bits): 2496 The following values are allocated by this specification: 2497 0-7: assigned as specified in Section 7.2.3: 2498 DSTE Class Type Sub-Parameter 0: DSTE Class Type 0 2499 1: DSTE Class Type 1 2500 2: DSTE Class Type 2 2501 3: DSTE Class Type 3 2502 4: DSTE Class Type 4 2503 5: DSTE Class Type 5 2504 6: DSTE Class Type 6 2505 7: DSTE Class Type 7 2506 The allocation policies for further values are as follows: 2507 8-63: Standards Action 2508 64-255: Reserved 2510 Y.1541 QoS Class Sub-Parameter (8 bits): 2511 The following values are allocated by this specification: 2512 0-7: assigned as specified in Section 7.2.3: 2513 Y.1541 QoS Class Sub-Parameter 0: Y.1541 QoS Class 0 2514 1: Y.1541 QoS Class 1 2515 2: Y.1541 QoS Class 2 2516 3: Y.1541 QoS Class 3 2517 4: Y.1541 QoS Class 4 2518 5: Y.1541 QoS Class 5 2519 6: Y.1541 QoS Class 6 2520 7: Y.1541 QoS Class 7 2521 The allocation policies for further values are as follows: 2522 8-63: Standards Action 2523 64-255: Reserved 2525 Admission Priority Parameter (8 bits): 2526 The following values are allocated by this specification: 2527 0-2: assigned as specified in Section 7.2.4: 2528 Admission Priority 0: best-effort priority flow 2529 1: normal priority flow 2530 2: high priority flow 2531 255: admission priority not used 2532 The allocation policies for further values are as follows: 2533 3-63: Standards Action 2534 64-254: Reserved 2536 RPH Namespace Parameter (16 bits): 2537 Note that [RFC4412] creates a registry for RPH Namespace and Priority 2538 values already (see Section 12.6 of [RFC4412]). A QSPEC registry is 2539 also created because the assigned values are being mapped to QSPEC 2540 parameter values. The following values are allocated by this 2541 specification: 2542 0-5: assigned as specified in Section 7.2.4: 2543 The allocation policies for further values are as follows: 2544 6-63: Standards Action 2545 64-65535: Reserved 2547 RPH Priority Parameter (8 bits): 2548 dsn namespace: 2549 The allocation policies are as follows: 2550 0-63: Standards Action 2551 64-255: Reserved 2552 drsn namespace: 2553 The allocation policies are as follows: 2554 0-63: Standards Action 2555 64-255: Reserved 2556 Q735 namespace: 2557 The following values are allocated by this specification: 2558 0-4: assigned as specified in Section 7.2.4: 2560 Q735 priority 4: q735.4 2561 3: q735.3 2562 2: q735.2 2563 1: q735.1 2564 0: q735.0 2565 The allocation policies for further values are as follows: 2566 5-63: Standards Action 2567 64-255: Reserved 2568 ets namespace: 2569 The following values are allocated by this specification: 2570 0-4: assigned as specified in Section 7.2.4: 2571 ETS priority 4: ets.4 2572 3: ets.3 2573 2: ets.2 2574 1: ets.1 2575 0: ets.0 2576 The allocation policies for further values are as follows: 2577 5-63: Standards Action 2578 64-255: Reserved 2579 wts namespace: 2580 The following values are allocated by this specification: 2581 0-4: assigned as specified in Section 7.2.4: 2582 WPS priority 4: wps.4 2583 3: wps.3 2584 2: wps.2 2585 1: wps.1 2586 0: wps.0 2587 The allocation policies for further values are as follows: 2588 5-63: Standards Action 2589 64-255: Reserved 2591 10. Acknowledgements 2593 The authors would like to thank (in alphabetical order) David Black, 2594 Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger 2595 Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, 2596 Chris Lang, Jukka Manner, An Nguyen, Dave Oran, Tom Phelan, James 2597 Polk, Alexander Sayenko, John Rosenberg, Bernd Schloer, Hannes 2598 Tschofenig, and Sven van den Bosch for their very helpful 2599 suggestions. 2601 11. Normative References 2603 [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd 2604 Generation Partnership Project; Technical Specification Group 2605 Services and System Aspects; enhanced Multi Level Precedence and 2606 Preemption service (eMLPP) - Stage 1 (Release 7). 2607 [3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd 2608 Generation Partnership Project; Technical Specification Group Core 2609 Network; enhanced Multi-Level Precedence and Preemption service 2610 (eMLPP) - Stage 2 (Release 7). 2612 [3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd 2613 Generation Partnership Project; Technical Specification Group Core 2614 Network; enhanced Multi-Level Precedence and Preemption service 2615 (eMLPP) - Stage 3 (Release 6). 2616 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 2617 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 2618 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 2619 Signaling Transport," work in progress. 2620 [QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service 2621 Signaling," work in progress. 2622 [RFC1832] Srinivasan, R., "XDR: External Data Representation 2623 Standard," RFC 1832, August 1995. 2624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2625 Requirement Levels", BCP 14, RFC 2119, March 1997. 2626 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2627 Services", RFC 2210, September 1997. 2628 [RFC2212] Shenker, S., et. al., "Specification of Guaranteed Quality 2629 of Service," September 1997. 2630 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 2631 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 2632 1997. 2633 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 2634 Services", RFC 2475, December 1998. 2635 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2636 Codes," June 2001. 2637 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element," 2638 RFC 3181, October 2001. 2639 [RFC3290] Bernet, Y., et. al., "An Informal Management Model for 2640 Diffserv Routers," RFC 3290, May 2002. 2641 [RFC4124] Le Faucheur, F., et. al., "Protocol Extensions for Support 2642 of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2005. 2643 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 2644 Priority for the Session Initiation Protocol(SIP)," RFC 4412, 2645 February 2006. 2646 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 2647 for IP-Based Services," May 2002. 2648 [Y.1571] ITU-T Recommendation Y.1571, "Admission Control Priority 2649 Levels in Next Generation Networks," July 2006. 2651 12. Informative References 2653 [DQOS] Cablelabs, "PacketCable Dynamic Quality of Service 2654 Specification," CableLabs Specification PKT-SP-DQOS-I12-050812, 2655 August 2005. 2656 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 2657 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 2658 754-1985, August 1985. 2659 [CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 2660 Controlled-Load Service with NSIS," work in progress. 2661 [NETWORK-BYTE-ORDER] Wikipedia, "Endianness," 2662 http://en.wikipedia.org/wiki/Endianness. 2664 [NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work 2665 in progress. 2666 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 2667 Protocol - Capability Set 3" Sep. 2003 2668 [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 2669 -- Version 1 Functional Specification," RFC 2205, September 1997. 2670 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 2671 IANA Considerations Section in RFCs," RFC 3181, October 1998. 2672 [RFC2474] Nichols, K., et. al., "Definition of the Differentiated 2673 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 2674 December 1998. 2675 [RFC2597] Heinanen, J., et. al., "Assured Forwarding PHB Group," RFC 2676 2597, June 1999. 2677 [RFC2997] Bernet, Y., et. al., "Specification of the Null Service 2678 Type," RFC 2997, November 2000. 2679 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2680 Codes," RFC 3140, June 2001. 2681 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 2682 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 2683 [RFC3564] Le Faucheur, F., et. al., Requirements for Support of 2684 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 2685 July 2003 2686 [RFC3726] Brunner, M., et. al., "Requirements for Signaling 2687 Protocols", RFC 3726, April 2004. 2688 [RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management 2689 in Diffserv QOS Model," work in progress. 2690 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 2691 on Associating of Control Signaling Messages with Media Priority 2692 Levels," T1S1.7 & PRQC, October 2004. 2693 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 2694 Communication Service - IP Packet Transfer and Availability 2695 Performance Parameters," December 2002. 2696 [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 2697 Networks Using Y.1541 QoS Classes," work in progress. 2699 13. Authors' Addresses 2701 Jerry Ash (Editor) 2702 AT&T 2703 Room MT D5-2A01 2704 200 Laurel Avenue 2705 Middletown, NJ 07748, USA 2706 Phone: +1-(732)-420-4578 2707 Fax: +1-(732)-368-8659 2708 Email: gash@att.com 2710 Attila Bader (Editor) 2711 Traffic Lab 2712 Ericsson Research 2713 Ericsson Hungary Ltd. 2714 Laborc u. 1 H-1037 2715 Budapest Hungary 2716 Email: Attila.Bader@ericsson.com 2718 Cornelia Kappler (Editor) 2719 Siemens AG 2720 Siemensdamm 62 2721 Berlin 13627 2722 Germany 2723 Email: cornelia.kappler@siemens.com 2725 Appendix A. Example of QSPEC Processing 2727 This appendix illustrates the operation and use of the QSPEC within 2728 the NSLP. The example configuration in shown in Figure 3. 2730 +----------+ /-------\ /--------\ /--------\ 2731 | Laptop | | Home | | Cable | | DiffServ | 2732 | Computer |-----| Network |-----| Network |-----| Network |----+ 2733 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 2734 \-------/ \--------/ \--------/ | 2735 | 2736 +-----------------------------------------------+ 2737 | 2738 | /--------\ +----------+ 2739 | | "X"G | | Handheld | 2740 +---| Wireless |-----| Device | 2741 | XG QOSM | +----------+ 2742 \--------/ 2744 Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC 2745 Operation 2747 In this configuration, a laptop computer and a handheld wireless 2748 device are the endpoints for some application that has QoS 2749 requirements. Assume initially that the two endpoints are stationary 2750 during the application session, later we consider mobile endpoints. 2751 For this session, the laptop computer is connected to a home network 2752 that has no QoS support. The home network is connected to a 2753 CableLabs-type cable access network with dynamic QoS (DQOS) support, 2754 such as specified in the 'CMS to CMS Signaling Specification' [DQOS] 2755 for cable access networks. That network is connected to a DiffServ 2756 core network that uses the RMD QOSM [RMD-QOSM]. On the other side of 2757 the DiffServ core is a wireless access network built on generation 2758 "X" technology with QoS support as defined by generation "X". And 2759 finally the handheld endpoint is connected to the wireless access 2760 network. 2762 We assume that the Laptop is the QNI and handheld device is the QNR. 2764 The QNI will signal an initiator QSPEC object to achieve the QoS 2765 desired on the path. As stated in Section 4, the QNI MUST support 2766 at least one QOSM, but it may not know the QOSM supported by the 2767 network. In any case, if the QNI supports only one QOSM, it would 2768 normally signal a reservation according to the requirements of that 2769 QOSM. Furthermore, the QNI would most likely support the QOSM that 2770 matches its functionality. For example, the default QOSM for mobile 2771 phones might be the XG-QOSM, while the CL-QOSM might be the 2772 default for workstations. 2774 Referring to Figure 3, the laptop computer may choose the 2775 CL-QOSM because it is connected to a wired network. If the 2776 handheld device acts as the QNI, it may choose the XG-QOSM because it 2777 is connected to the XG wireless network. On the other hand, a 2778 particular QOSM could be configured if a user/administrator knows 2779 that some particular QOSM is used. For example, if the laptop 2780 computer is connected to the XG network via the XG phone, which acts 2781 as a modem, then it reasonable to specify the XG-QOSM since resources 2782 are accessed through the XG network, 2784 In this example we consider two different ways to perform 2785 sender-initiated signaling for QoS: 2787 Case 1) The QNI sets , and possibly 2788 QSPEC objects in the initiator QSPEC, and initializes 2789 to . Since this is a reservation in a 2790 heterogenic network with different QOSMs supported in different 2791 domains, each QNE on the path reads and interprets those parameters 2792 in the initiator QSPEC that it needs to implement the QOSM within its 2793 domain (as described below). Each QNE along the path checks to see if 2794 resources can be reserved, and if not, the QNE 2795 reduces the respective parameter values in and 2796 reserves these values. The minimum parameter values are given in 2797 , if populated, otherwise zero if is not 2798 included. If one or more parameters in fails to 2799 satisfy the corresponding minimum values in Minimum QoS, the QNE 2800 generates a RESPONSE message to the QNI and the reservation is 2801 aborted. Otherwise, the QNR generates a RESPONSE to the QNI with the 2802 for the reservation. 2804 Case 2) The QNI signals the initiator QSPEC with . 2805 Since this is a reservation in a heterogenic network with different 2806 QOSMs supported in different domains, each QNE on the path reads and 2807 interprets those parameters in the initiator QSPEC that it needs to 2808 implement the QOSM within its domain (as described below). If a QNE 2809 cannot reserve resources, the reservation fails. 2811 In both cases, the QNI populates QSPEC-1 and QSPEC-2 to 2812 ensure correct treatment of its traffic in domains down the path. 2813 Since the QNI does not know the QOSM used in downstream domains, it 2814 includes values for those QSPEC-1 and QSPEC-2 parameters 2815 consistent with the QOSM it is signaling and any additional 2816 parameters it cares about. Let us assume the QNI wants to achieve 2817 IntServ-like QoS guarantees, and also is interested in what path 2818 latency it can achieve. The QNI therefore includes in the QSPEC the 2819 QOSM ID for IntServ Controlled Load Service. The QSPEC objects are 2820 signaled with all parameters necessary for IntServ Controlled Load 2821 and additionally the parameter to measure path latency, as follows: 2823 = 2824 = 2826 Additionally, to ensure correct treatment further down the path, the 2827 QNI may include in . 2829 In both cases, each QNE on the path reads and interprets those 2830 parameters in the initiator QSPEC that it needs to implement the QOSM 2831 within its domain. It may need additional parameters for its QOSM, 2832 which are not specified in the initiator QSPEC. If possible, these 2833 parameters must be inferred from those that are present, according to 2834 rules defined in the QOSM implemented by this QNE. 2836 There are three possibilities when a RESERVE message is received at a 2837 QNE at a domain border (we illustrate these possibilities in the 2838 example): 2840 - the QNE just leaves the QSPEC as-is. 2842 - the QNE can stack a local QSPEC on top of the initiator QSPEC (this 2843 is new in QoS NSLP, RSVP does not do this). 2845 - the QNE can tunnel the initiator RESERVE message through its domain 2846 and issue its own local RESERVE message. For this new local 2847 RESERVE message, the QNE acts as the QNI, and the QSPEC in the 2848 domain is an initiator QSPEC. This procedure is also used by RSVP 2849 in making aggregate reservations, in which case there is not a new 2850 intra-domain (aggregate) RESERVE for each newly arriving 2851 interdomain (per-flow) RESERVE, but the aggregate reservation is 2852 updated by the border QNE (QNI) as need be. This is also how RMD 2853 works [RMD-QOSM]. 2855 For example, at the RMD domain, a local RESERVE with its own RMD 2856 initiator QSPEC corresponding to the RMD-QOSM is generated based on 2857 the original initiator QSPEC according to the procedures described in 2858 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE 2859 to the RMD domain must map the QSPEC parameters contained in the 2860 original initiator QSPEC into the RMD QSPEC. The RMD QSPEC for 2861 example needs and . is generated 2862 from the parameter. Information on , 2863 however, is not provided. According to the rules laid out in the RMD 2864 QOSM, the ingress QNE infers from the fact that an IntServ Controlled 2865 Load QOSM was signaled that the EF PHB is appropriate to set the parameter. These RMD QSPEC parameters are populated in the 2867 RMD initiator QSPEC generated within the RMD domain. 2869 Furthermore, the node at the egress to the RMD domain updates on behalf of the entire RMD domain if it can. If it 2871 cannot, it raises the parameter-specific, 'not-supported' flag, 2872 warning the QNR that the final value of these parameters in QoS 2873 Available is imprecise. 2875 In the XG domain, the initiator QSPEC is translated into a local 2876 QSPEC using a similar procedure as described above. The local QSPEC 2877 becomes the current QSPEC used within the XG domain, that is, the 2878 it becomes the first QSPEC on the stack, and the initiator QSPEC is 2879 second. This saves the QNEs within the XG domain the trouble of 2880 re-translating the initiator QSPEC. At the egress edge of the XG 2881 domain, the translated local QSPEC is popped, and the initiator QSPEC 2882 returns to the number one position. 2884 If the reservation was successful, eventually the RESERVE request 2885 arrives at the QNR (otherwise the QNE at which the reservation failed 2886 would have aborted the RESERVE and sent an error RESPONSE back to the 2887 QNI). If the RII was included in the QoS NSLP message, the QNR 2888 generates a positive RESPONSE with QSPEC objects - and 2889 for case 1 - additionally . The parameters appearing 2890 in are the same as in , with values 2891 copied from in case 1, and with the original values 2892 from in case 2. That is, it is not necessary to 2893 transport the object back to the QNI since the QNI 2894 knows what it signaled originally, and the information is not useful 2895 for QNEs in the reverse direction. The object should 2896 transport all necessary information, although the and 2897 objects may end up transporting some of the same 2898 information. 2900 Hence, the QNR includes the following QSPEC objects in the RESPONSE: 2902 = 2903 = 2905 If the handheld device on the right of Figure 3 is mobile, and moves 2906 through different "XG" wireless networks, then the QoS might change 2907 on the path since different XG wireless networks might support 2908 different QOSMs. As a result, QoS NSLP/QSPEC processing will have to 2909 renegotiate the on the path. From a QSPEC 2910 perspective, this is like a new reservation on the new section of the 2911 path and is basically the same as any other rerouting event - to the 2912 QNEs on the new path it looks like a new reservation. That is, in 2913 this mobile scenario, the new segment may support a different QOSM 2914 than the old segment, and the QNI would now signal a new reservation 2915 (explicitly, or implicitly with the next refreshing RESERVE message) 2916 to account for the different QOSM in the XG wireless domain. Further 2917 details on rerouting are specified in [QoS-SIG]. 2919 For bit-level examples of QSPECs see the documents specifying QOSMs 2920 [CL-QOSM, Y.1541-QOSM, RMD-QOSM]. 2922 Appendix B. Mapping of QoS Desired, QoS Available and QoS Reserved of 2923 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 2925 The union of QoS Desired, QoS Available and QoS Reserved can provide 2926 all functionality of the objects specified in RSVP IntServ, however 2927 it is difficult to provide an exact mapping. 2929 In RSVP, the Sender TSpec specifies the traffic an application is 2930 going to send (e.g. token bucket). The AdSpec can collect path 2931 characteristics (e.g. delay). Both are issued by the sender. The 2932 receiver sends the FlowSpec which includes a Receiver TSpec 2933 describing the resources reserved using the same parameters as the 2934 Sender TSpec, as well as a RSpec which provides additional IntServ 2935 QoS Model specific parameters, e.g. Rate and Slack. 2937 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 2938 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 2939 knowledge of the authors it is not possible for the sender to specify 2940 a desired maximum delay except implicitly and mutably by seeding the 2941 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 2942 the receiver-issued RSVP RESERVE message. For this reason our 2943 discussion at this point leads us to a slightly different mapping of 2944 necessary functionality to objects, which should result in more 2945 flexible signaling models. 2947 Appendix C. Change History & Open Issues 2949 C.1 Change History (since Version -04) 2951 Version -05: 2953 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 2954 - discarded QSPEC parameter (Maximum packet size) since MTU 2955 discovery is expected to be handled by procedure currently defined 2956 by PMTUD WG 2957 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 2958 efficiency 2959 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 2960 - revised Section 6.2.2 on SIP priorities 2961 - added QSPEC procedures for "RSVP-style reservation", resource 2962 queries and bidirectional reservations in Sec. 7.1 2963 - reworked Section 7.2 2965 Version -06: 2967 - defined "not-supported flag" and "tunneled parameter flag" 2968 (subsumes "QSPEC-2 parameter flag") 2969 - defined "error flag" for error handling 2970 - updated bit error rate (BER) parameter to packet loss ratio (PLR) 2971 parameter 2972 - added packet error ratio (PER) parameter 2973 - coding checked by independent expert 2974 - coding updated to include RE flags in QSPEC objects and MENT flags 2975 in QSPEC parameters 2977 Version -07: 2979 - added text (from David Black) on DiffServ QSPEC example in Section 2980 6 2981 - re-numbered QSPEC parameter IDs to start with 0 (Section 7) 2982 - expanded IANA Considerations Section 9 2984 Version -08: 2986 - update to 'RSVP-style' reservation in Section 6.1.2 to mirror what 2987 is done in RSVP 2988 - modified text (from David Black) on DiffServ QSPEC example in 2989 Section 6.2 2990 - update to general QSPEC parameter formats in Section 7.1 (length 2991 restrictions, etc.) 2992 - re-numbered QSPEC parameter IDs in Section 7.2 2993 - modified parameter values in Section 7.2.2 2994 - update to reservation priority Section 7.2.7 2995 - specify the 3 "STATS" in the parameter, Section 2996 7.2.9.4 2997 - minor updates to IANA Considerations Section 9 2999 Version -09: 3001 - remove the DiffServ example in Section 6.2 (intent is use text as a 3002 basis for a separate DIFFSERV-QOSM I-D) 3003 - update wording in example in Section 4.3, to reflect use of default 3004 QOSM and QOSM selection by QNI 3005 - make minor changes to Section 7.2.7.2, per the exchange on the list 3006 - add comment on error codes, after the first paragraph in Section 3007 4.5.1 3009 Version -10: 3011 - rewrote Section 2.0 for clarity 3012 - added clarifications on QSPEC-1 parameters in Section 4.2; added 3013 discussion of forwarding options when a domain supports a different 3014 QOSM than the QNI 3015 - expanded Section 4.5 on error code handling, including redefined 3016 E-Flag and editorial changes to the N-Flag and T-Flag discussions 3017 - made some editorial clarifications in Section 4.6 on defining new 3018 mandatory (QSPEC-1) parameters, and also reference the 3019 [NSIS-EXTENSIBILITY] document 3020 - Section 4.7 added to identify what a QOSM specification document 3021 must include 3022 - clarified the requirements in Section 5.0 for defining a new QSPEC 3023 Version 3024 - made editorial changes to Section 6, and added procedures for 3025 handling preemption 3026 - removed QOSM ID assignments in Section 9.0; clarified procedures 3027 for defining new QSPEC-1 parameters; added registry of QOSM error 3028 codes 3030 Version -11: 3032 - 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter' 3033 - 'QSPEC-2 parameter' replaces 'optional QSPEC parameter' 3034 - R-flag ('remapped parameter flag') introduced to denote remapping, 3035 approximating, or otherwise not strictly interpreting a QSPEC 3036 parameter 3037 - T-flag ('tunneled parameter flag') eliminated and incorporated 3038 within the R-flag 3039 - Section 4 rewritten on QOSM concept, QSPEC processing, etc. to 3040 provide a more logical flow of information 3041 - read-write/read-only flag associated with QSPEC objects eliminated 3042 and object itself defined as rw or ro without a flag 3043 - parameter redefined as non-QOSM-hop Q-flag 3044 - Section 7 on QSPEC parameter definitions revised to clearly 3045 separate QSPEC-1 parameter coding from QSPEC-2 parameter coding 3046 - , , and QSPEC-1 parameters mapped 3047 to container parameters 3048 - references updated to include normative references defining 3049 procedures to 'strictly interpret' each QSPEC parameter 3050 - Section 7.2.1 on PHB class updated to specify additional RFC 3140 3051 cases 3052 - Section 7.2.1 on excess treatment updated to specify excess 3053 treatment behaviors 3055 Version -12: 3057 - Sections 4, 5, 6: Many editorial changes and rearrangements 3058 - Moved example of QSPEC processing to Appendix A 3059 - Section 7.2.2: Changed to fixed length 3060 Parameter 3061 - 3 open issues in version -11 resolved without change 3063 C.2 Open Issues 3065 None. 3067 Intellectual Property Statement 3069 The IETF takes no position regarding the validity or scope of any 3070 Intellectual Property Rights or other rights that might be claimed to 3071 pertain to the implementation or use of the technology described in 3072 this document or the extent to which any license under such rights 3073 might or might not be available; nor does it represent that it has 3074 made any independent effort to identify any such rights. Information 3075 on the procedures with respect to rights in RFC documents can be 3076 found in BCP 78 and BCP 79. 3078 Copies of IPR disclosures made to the IETF Secretariat and any 3079 assurances of licenses to be made available, or the result of an 3080 attempt made to obtain a general license or permission for the use of 3081 such proprietary rights by implementers or users of this 3082 specification can be obtained from the IETF on-line IPR repository at 3083 http://www.ietf.org/ipr. 3085 The IETF invites any interested party to bring to its attention any 3086 copyrights, patents or patent applications, or other proprietary 3087 rights that may cover technology that may be required to implement 3088 this standard. Please address the information to the IETF at 3089 ietf-ipr@ietf.org. 3091 Disclaimer of Validity 3093 This document and the information contained herein are provided on an 3094 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3095 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3096 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3097 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3098 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3099 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3101 Copyright Statement 3103 Copyright (C) The Internet Society (2006). This document is subject 3104 to the rights, licenses and restrictions contained in BCP 78, and 3105 except as set forth therein, the authors retain all their rights.