idnits 2.17.1 draft-ietf-nsis-qspec-13.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2599. 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 IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2006) is 6335 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: 'QOS-SIG' is mentioned on line 1251, but not defined == Missing Reference: 'S' is mentioned on line 1643, but not defined == Unused Reference: 'RFC1832' is defined on line 2243, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 2277, but no explicit reference was found in the text == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2282, but no explicit reference was found in the text == Unused Reference: 'RFC3564' is defined on line 2303, 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: 4 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft NSIS Working Group G. Ash 3 Internet Draft AT&T 4 A. Bader 5 Expiration Date: June 2007 Ericsson 6 C. Kappler 7 Siemens GmbH&Co KG 8 D. Oran 9 Cisco Systems, Inc. 11 December 2006 13 QoS NSLP QSPEC Template 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 21, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2006). 44 Abstract 46 The QoS NSLP protocol is used to signal QoS reservations and is 47 independent of a specific QoS model (QOSM) such as IntServ or 48 DiffServ. Rather, all information specific to a QOSM is encapsulated 49 in a separate object, the QSPEC. This document defines a template 50 for the QSPEC including a number of QSPEC parameters. The QSPEC 51 parameters provide a common language to be re-used in several QOSMs 52 and thereby aim to ensure the extensibility and interoperability of 53 QoS NSLP. The node initiating the NSIS signaling adds an initiator 54 QSPEC, which indicates the QSPEC parameters that must be interpreted 55 by the downstream nodes less the reservation fails, thereby ensuring 56 the intention of the NSIS initiator is preserved along the signaling 57 path. 59 Table of Contents 61 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. QSPEC Framework . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2 QSPEC Objects . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 10 68 4.3.1 Traffic Model Parameter . . . . . . . . . . . . . . . 10 69 4.3.2 Constraints Parameters . . . . . . . . . . . . . . . 11 70 4.3.3 Traffic Handling Directives . . . . . . . . . . . . . 13 71 4.3.4 Traffic Classifiers . . . . . . . . . . . . . . . . . 13 72 4.4 Example of QSPEC Processing . . . . . . . . . . . . . . . . 13 73 5. QSPEC Processing & Procedures . . . . . . . . . . . . . . . . . 16 74 5.1 Local QSPEC Definition & Processing . . . . . . . . . . . . 17 75 5.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 76 Notification . . . . . . . . . . . . . . . . . . . . . . . 18 77 5.2.1 Reservation Failure & Error E-Flag . . . . . . . . . 18 78 5.2.2 QSPEC Parameter Not Supported N-Flag . . . . . . . . 19 79 5.2.3 INFO_SPEC Coding of Reservation Outcome . . . . . . . 19 80 5.2.4 QNE Generation of a RESPONSE message . . . . . . . . 20 81 5.2.5 Special Case of Local QSPEC . . . . . . . . . . . . . 21 82 5.3 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 21 83 5.3.1 Sender-Initiated Reservations . . . . . . . . . . . . 22 84 5.3.2 Receiver-Initiated Reservations . . . . . . . . . . . 23 85 5.3.3 Resource Queries . . . . . . . . . . . . . . . . . . 25 86 5.3.4 Bidirectional Reservations . . . . . . . . . . . . . 25 87 5.3.5 Preemption . . . . . . . . . . . . . . . . . . . . . 25 88 5.4 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 26 89 6. QSPEC Functional Specification . . . . . . . . . . . . . . . . 26 90 6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 26 91 6.2 QSPEC Parameter Coding . . . . . . . . . . . . . . . . . . 29 92 6.2.1 Parameter . . . . . . . . . . . . . . . . . 29 93 6.2.2 Parameter . . . . . . . . . . . . . . . . . 30 94 6.2.3 Parameter . . . . . . . . . . . . . . 30 95 6.2.4 Parameter . . . . . . . . . . . . . . . 31 96 6.2.5 Parameter . . . . . . . . . . . . . . . . 32 97 6.2.6 Parameter . . . . . . . . . . . . . . . . 32 98 6.2.7 Parameter . . . . . . . . . . . . . . . 33 99 6.2.8 & 100 Parameters . . . . . . . . . . . . . . . . . . . . . 33 101 6.2.9 Parameter . . . . . . . . . . . 34 102 6.2.10 Parameter . . . . . . . . . . . . . . 34 103 6.2.11 Parameter . . . . . . . . . . . . 36 104 6.2.12 Parameter . . . . . . . . . . . . . . . 37 105 6.2.13 Parameter . . . . . . . . . . . . 38 106 6.2.14 Parameter . . . . . . . . . . . . 39 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 40 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 40 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 110 10. Normative References . . . . . . . . . . . . . . . . . . . . . 45 111 11. Informative References . . . . . . . . . . . . . . . . . . . . 46 112 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 113 Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved 114 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 47 115 Appendix B. Change History & Open Issues . . . . . . . . . . . . . 48 116 B.1 Change History (since Version -04) . . . . . . . . 48 117 B.2 Open Issues . . . . . . . . . . . . . . . . . . . 51 118 Intellectual Property Statement . . . . . . . . . . . . . . . . . 52 119 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 52 121 Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 1. Contributors 129 This document is the result of the NSIS Working Group effort. In 130 addition to the authors/editors listed in Section 12, the following 131 people contributed to the document: 133 Chuck Dvorak 134 AT&T 135 Room 2A37 136 180 Park Avenue, Building 2 137 Florham Park, NJ 07932 138 Phone: + 1 973-236-6700 139 Fax:+1 973-236-7453 140 Email: cdvorak@research.att.com 142 Yacine El Mghazli 143 Alcatel 144 Route de Nozay 145 91460 Marcoussis cedex 146 FRANCE 147 Phone: +33 1 69 63 41 87 148 Email: yacine.el_mghazli@alcatel.fr 150 Georgios Karagiannis 151 University of Twente 152 P.O. BOX 217 153 7500 AE Enschede 154 The Netherlands 155 Email: g.karagiannis@ewi.utwente.nl 157 Andrew McDonald 158 Siemens/Roke Manor Research 159 Roke Manor Research Ltd. 160 Romsey, Hants SO51 0ZN 161 UK 162 Email: andrew.mcdonald@roke.co.uk 164 Al Morton 165 AT&T 166 Room D3-3C06 167 200 S. Laurel Avenue 168 Middletown, NJ 07748 169 Phone: + 1 732 420-1571 170 Fax: +.1 732 368-1192 171 Email: acmorton@att.com 173 Percy Tarapore 174 AT&T 175 Room D1-33 176 200 S. Laurel Avenue 177 Middletown, NJ 07748 178 Phone: + 1 732 420-4172 179 Email: tarapore@.att.com 181 Lars Westberg 182 Ericsson Research 183 Torshamnsgatan 23 184 SE-164 80 Stockholm, Sweden 185 Email: Lars.Westberg@ericsson.com 187 2. Introduction 189 The QoS NSIS signaling layer protocol (NSLP) [QoS-SIG] establishes 190 and maintains state at nodes along the path of a data flow for the 191 purpose of providing forwarding resources (QoS) for that flow. The 192 design of QoS NSLP is conceptually similar to RSVP [RFC2205], and 193 meets the requirements of [RFC3726]. 195 A QoS-enabled domain supports a particular QoS model (QOSM), which is 196 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 197 provisioning methods and a QoS architecture. It defines the behavior 198 of the resource management function (RMF) defined in [QoS-SIG], 199 including inputs and outputs. Examples of QOSMs are IntServ, DiffServ 200 admission control, and those specified in [Y.1541-QOSM, CL-QOSM, 201 RMD-QOSM]. 203 The QoS NSLP protocol is used to signal QoS reservations and supports 204 signaling for different QOSMs. All information specific to a QOSM is 205 encapsulated in the QoS specification (QSPEC) object, and this 206 document defines a template for the QSPEC. 208 QSPEC parameters include, for example, a mandatory traffic model 209 (TMOD) parameter, constraints parameters, such as path latency and 210 path jitter, traffic handling directives, such as excess treatment, 211 and traffic classifiers such as PHB class. 213 QSPEC objects loosely correspond to the TSpec, RSpec and AdSpec 214 objects specified in RSVP and may contain, respectively, a 215 description of QoS desired, QoS reserved, and QoS available. 216 Going beyond RSVP functionality, the QSPEC also allows indicating 217 a range of acceptable QoS by defining a QSPEC object denoting 218 minimum QoS. Usage of these QSPEC objects is not bound to particular 219 message types thus allowing for flexibility. A QSPEC object 220 collecting information about available resources may travel in any 221 QoS NSLP message, for example a QUERY message or a RESERVE message. 222 The QSPEC travels in QoS NSLP messages but is opaque to the QoS NSLP, 223 and is only interpreted by the RMF. 225 Interoperability between QoS NSIS entities (QNEs) in different 226 domains is enhanced by the definition of a common set of QSPEC 227 parameters. A QoS NSIS initiator (QNI) initiating the QoS NSLP 228 signaling adds an initiator QSPEC object containing parameters 229 describing the desired QoS, normally based on the QOSM it supports. 230 QSPEC parameters flagged by the QNI must be interpreted by all QNEs 231 in the path, else the reservation fails. In contrast, QSPEC 232 parameters not flagged by the QNI may be skipped if not understood. 233 Additional QSPEC parameters can be defined by QOSM specification 234 documents, and thereby ensure the extensibility and flexibility of 235 QoS NSLP. 237 A local QSPEC can be defined in a local domain with the initiator 238 QSPEC encapsulated, which is functionally consistent with the 239 initiator QSPEC in terms of defined source traffic (TMOD parameter) 240 and other constraints. A local QSPEC, for example, can enable 241 simpler processing by QNEs within the local domain. 243 In Section 4.4 a worked example of QSPEC processing is provided. 245 3. Terminology 247 Initiator QSPEC: A QSPEC Type. The initiator QSPEC is included into 248 a QoS NSLP message by the QNI/QNR. It travels end-to-end to the 249 QNR/QNI and is never removed. 251 Local QSPEC: A QSPEC Type. A local QSPEC is used in a local domain 252 and is domain specific. It encapsulates the initiator QSPEC and is 253 removed at the egress of the local domain. 255 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 256 any QNE. Together with a description of QoS Desired or QoS 257 Available, it allows the QNI to specify a QoS range, i.e. an upper 258 and lower bound. If the QoS Desired cannot be reserved, QNEs are 259 going to decrease the reservation until the minimum QoS is hit. 261 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 263 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 265 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 267 QoS Available: QSPEC object containing parameters describing the 268 available resources. They are used to collect information along a 269 reservation path. 271 QoS Desired: QSPEC object containing parameters describing the 272 desired QoS for which the sender requests reservation. 274 QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., 275 IntServ Controlled Load; specifies what sub-set of QSPEC QoS 276 constraints & traffic handling directives a QNE implementing that 277 QOSM is capable of supporting & how resources will be managed by the 278 RMF. 280 QoS Reserved: QSPEC object containing parameters describing the 281 reserved resources and related QoS parameters. 283 QSPEC: QSPEC is the object of QoS NSLP containing all QoS-specific 284 information. 286 QSPEC parameter: Any parameter appearing in a QSPEC; for 287 example, traffic model (TMOD), path latency, and excess treatment 288 parameters. 290 QSPEC Object: Main building blocks containing a QSPEC parameter set 291 that is input or output of an RMF operation. 293 Resource Management Function (RMF): Functions that are related to 294 resource management and processing of QSPEC parameters. 296 4. QSPEC Framework 298 The overall framework for the QoS NSLP is that [QoS-SIG] defines QoS 299 signaling and semantics, the QSPEC template defines the container and 300 semantics for QoS parameters and objects, and QOSM specifications 301 define QoS methods and procedures for using QoS signaling and QSPEC 302 parameters/objects within specific QoS deployments. QoS NSLP is a 303 generic QoS signaling protocol that can signal for many QOSMs. 305 4.1 QoS Models 307 A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ 308 controlled load [CL-QOSM], resource management with DiffServ 309 [RMD-QOSM], and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM]. 310 A QOSM specifies a set of QSPEC parameters that describe the QoS 311 desired and how resources will be managed by the RMF. The RMF 312 implements functions that are related to resource management and 313 processes the QSPEC parameters. 315 QOSMs affect the operation of the RMF in NSIS-capable nodes, the 316 information carried in QSPEC objects, and may under some 317 circumstances (e.g. aggregation) cause a separate NSLP session to be 318 instantiated by having the RMF as a QNI. QOSMs all utilize the common 319 data, state machines, and APIs of the underlying NSIS protocols and 320 are not expected to re-define or extend these in any way. 322 The QOSM specification includes how the requested QoS resources will 323 be described and how they will be managed by the RMF. For this 324 purpose, the QOSM specification defines a set of QSPEC parameters it 325 uses to describe the desired QoS and resource control in the RMF, and 326 it may define additional QSPEC parameters. 328 When a QoS NSLP message travels through different domains, it may 329 encounter different QOSMs. Since QOSM use different QSPEC parameters 330 for describing resources, the QSPEC parameters included by the QNI 331 may not be understood in other domains. The QNI therefore can flag 332 those QSPEC parameters it considers vital with the M-flag. QSPEC 333 parameters with the M-flag set must be interpreted by the downstream 334 QNEs, or the reservation fails. QSPEC parameters without the M-flag 335 set should be interpreted by the downstream QNEs, but may be ignored 336 if not understood. 338 A QOSM specification MUST include the following: 340 - role of QNEs, e.g., location, frequency, statefulness, etc. 341 - QSPEC definition including QSPEC parameters 342 - QSPEC procedures applicable to this QOSM 343 - QNE processing rules describing how QSPEC information is treated 344 and interpreted in the RMF, e.g., 345 admission control, scheduling, policy control, QoS parameter 346 accumulation (e.g., delay). 347 - at least one bit-level QSPEC example 348 - QSPEC parameter behavior for new QSPEC parameters the QOSM 349 specification defines 350 - define what happens in case of preemption if the default QNI 351 behavior (tear down preempted reservation) is not followed (see 352 Section 5.3.5) 354 A QOSM specification MAY include the following: 356 - define additional QOSM-specific error codes, as discussed in 357 Section 5.2.3 358 - can state which QoS-NSLP options a QOSM wants to use, when 359 several options are available for a QOSM (e.g., local QSPEC to 360 either be a) tunneled or b) encapsulate initiator QSPEC). 362 4.2 QSPEC Objects 364 The QSPEC is the object of QoS NSLP containing QSPEC objects and 365 parameters. QSPEC objects are the main building blocks of the QSPEC 366 parameter set that is input or output of an RMF operation. QSPEC 367 parameters are the parameters appearing in a QSPEC, which must 368 include traffic (TMOD), and may optionally include constraints (e.g., 369 path latency), traffic handling directives (e.g., excess treatment), 370 and traffic classifiers (e.g., PHB class). The RMF implements 371 functions that are related to resource management and processes the 372 QSPEC parameters. 374 The QSPEC consists of a QSPEC version number and QSPEC objects. 375 Later QSPEC versions MUST be backward compatible with earlier QSPEC 376 versions. That is, a version n+1 device must support a version n 377 (or earlier) QSPEC parameters. A new QSPEC version MUST be defined 378 whenever this document is reissued, for example, whenever a new QSPEC 379 parameter is added. QSPEC parameters in a new QSPEC version MUST be 380 a superset of those in the previous QSPEC version. QSPEC version is 381 assigned by IANA. 383 This document provides a template for the QSPEC in order to promote 384 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 385 is composed of up to four QSPEC objects, namely QoS Desired, QoS 386 Available, QoS Reserved and Minimum QoS. Each of these QSPEC objects 387 consists of a number of QSPEC parameters. A given QSPEC may contain 388 only a subset of the QSPEC objects, e.g. QoS Desired. The QSPEC 389 objects QoS Desired, QoS Available and QoS Reserved MUST be supported 390 by QNEs. Minimum QoS MAY be supported. 392 +---------------------------------------+ 393 | QSPEC Objects | 394 +---------------------------------------+ 396 \________________ ______________________/ 397 V 398 +----------+----------+---------+-------+ 399 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| 400 +----------+----------+---------+-------+ 402 \____ ____/\___ _____/\___ ____/\__ ___/ 403 V V V V 405 +-------------+... +-------------+... 406 |QSPEC Para. 1| |QSPEC Para. n| 407 +-------------+... +-------------+... 409 Figure 1: Structure of the QSPEC 411 The QoS Desired Object describe the resources the QNI desires to 412 reserve and hence this is a read-only QSPEC object in that the QSPEC 413 parameters carried in the object may not be overwritten. QoS Desired 414 is always included in a RESERVE message. 416 The QoS Available Object travels in a RESERVE or QUERY message and 417 collects information on the resources currently available on the 418 path. Hence QoS Available in this case is a read-write object, which 419 means the QSPEC parameters contained in QoS Available may be updated, 420 but they cannot be deleted). Each 421 QNE MUST inspect all parameters of this QSPEC object, and if 422 resources available to this QNE are less than what a particular 423 parameter says currently, the QNE MUST adapt this parameter 424 accordingly. Hence when the message arrives at the recipient of the 425 message, reflects the bottleneck of the resources 426 currently available on a path. It can be used in a QUERY message, 427 for example, to collect the available resources along a data path. 429 When QoS Available travels in a RESPONSE message, it in fact just 430 transports the result of a previous measurement performed by a 431 RESERVE or QUERY message back to the initiator. Therefore in this 432 case, QoS Available is read-only. 434 QoS Reserved reflects the resources that were reserved. It is a 435 read-only object. 437 Minimum QoS does not have an equivalent in RSVP. It allows the QNI 438 to define a range of acceptable QoS levels by including both the 439 desired QoS value and the minimum acceptable QoS in the same message. 440 Parameters cannot be overwritten in this QSPEC object. The desired 441 QoS is included with a QoS Desired and/or a QoS Available QSPEC 442 object seeded to the desired QoS value. The minimum acceptable QoS 443 value MAY be coded in the Minimum QoS QSPEC object. As the message 444 travels towards the QNR, QoS Available is updated by QNEs on the 445 path. If its value drops below the value of Minimum QoS the 446 reservation fails and is aborted. When this method is employed, the 447 QNR SHOULD signal back to the QNI the value of QoS Available 448 attained in the end, because the reservation MAY need to be adapted 449 accordingly. 451 Note that the relationship of QSPEC objects to RSVP objects is 452 covered in Appendix A. 454 4.3 QSPEC Parameters 456 QSPEC parameters provide a common language for building QSPEC 457 objects. This document defines a number of QSPEC parameters, 458 additional parameters may be defined in separate QOSM specification 459 documents. For example, QSPEC parameters are defined in [RMD-QOSM] 460 and [Y.1541-QOSM]. 462 One QSPEC parameter, , is special. It provides a description 463 of the traffic for which resources are reserved. This parameter must 464 be included by the QNI and it must be interpreted by all QNEs. All 465 other QSPEC parameters are populated by a QNI if they are applicable 466 to the underlying QoS desired. For these QSPEC parameters, the QNI 467 sets the M-flag if they must be interpreted by downstream QNEs. If 468 QNEs cannot interpret the parameter the reservation fails. QSPEC 469 parameters populated by a QNI without the M-flag set should be 470 interpreted by downstream QNEs, but may be ignored if not understood. 472 In this document the term 'interpret' means, in relation to RMF 473 processing of QSPEC parameters, that the RMF processes the QSPEC 474 parameter according to the commonly accepted normative procedures 475 specified by references given for each QSPEC parameter. Note that a 476 QNE need only interpret a QSPEC parameter if it is populated in the 477 QSPEC object by the QNI; if not populated in the QSPEC, the QNE does 478 not interpret it of course. 480 Note that when an ingress QNE in a local domain defines a local QSPEC 481 and encapsulates the initiator QSPEC, the QNEs in the interior local 482 domain need only process the local QSPEC and can ignore the initiator 483 (encapsulated) QSPEC. However, edge QNEs in the local domain indeed 484 must interpret the QSPEC parameters populated in the initiator QSPEC 485 with the M-flag set and should interpret QSPEC parameters populated 486 in the initiator QSPEC without the M-flag set. 488 As described in the previous section, QoS parameters may be 489 overwritten depending on which QSPEC object, and which message, they 490 appear in. 492 4.3.1 Traffic Model Parameter 493 The (TMOD) parameter is mandatory for the QNI to 494 include in the initiator QSPEC and mandatory for downstream QNEs to 495 interpret. The traffic description specified by the TMOD parameter 496 is a container consisting of 4 sub-parameters: 498 o rate (r) 499 o bucket size (b) 500 o peak rate (p) 501 o minimum policed unit (m) 503 All 4 of the sub-parameters MUST be included in the TMOD parameter. 504 The TMOD parameter is a mathematically complete way to describe the 505 traffic source [WROCLAWSKI]. If, for example, TMOD is set to specify 506 bandwidth only, then set r = peak rate = p, b = large, m = large. As 507 another example if TMOD is set for TCP traffic, then set r = average 508 rate, b = large, p = large. 510 When the TMOD parameter in included in QoS Available, it provides 511 information, for example, about the TMOD resources available along 512 the path followed by a data flow. The value of TMOD at a QNE is an 513 estimate of the TMOD resources the QNE has available for packets 514 following the path up to the next QNE, including its outgoing link, 515 if this link exists. Furthermore, the QNI MUST account for the 516 resources of the ingress link, if this link exists. Computation of 517 the value of this parameter SHOULD take into account all information 518 available to the QNE about the path, taking into consideration 519 administrative and policy controls, as well as physical resources. 521 The composed value is the minimum of the QNE's value and the 522 previously composed value for r, b, and p, and the maximum of the 523 QNE's value and the previously composed value for m. This quantity, 524 when composed end-to-end, informs the QNR (or QNI in a RESPONSE 525 message) of the minimal TMOD resources along the path from QNI to 526 QNR. 528 4.3.2 Constraints Parameters 530 , , , and are QSPEC 531 parameters describing the desired path latency, path jitter and path 532 bit error rate respectively. Since these parameters are cumulative, 533 an individual QNE cannot decide whether the desired path latency, 534 etc., is available, and hence they cannot decide whether a 535 reservation fails. Rather, when these parameters are included in 536 , the QNI SHOULD also include corresponding parameters 537 in a QoS Available QSPEC object in order to facilitate collecting 538 this information. 540 The parameter accumulates the latency of the packet 541 forwarding process associated with each QNE, where the latency is 542 defined to be the mean packet delay added by each QNE. This delay 543 results from speed-of-light propagation delay, from packet processing 544 limitations, or both. The mean delay reflects the variable queuing 545 delay that may be present. Each QNE MUST add the propagation delay 546 of its outgoing link, if this link exists. Furthermore, the QNI MUST 547 add the propagation delay of the ingress link, if this link exists. 548 The composition rule for the parameter is summation 549 with a clamp of (2**32 - 1) on the maximum value. This quantity, 550 when composed end-to-end, informs the QNR (or QNI in a RESPONSE 551 message) of the minimal packet delay along the path from QNI to QNR. 552 The purpose of this parameter is to provide a minimum path latency 553 for use with services which provide estimates or bounds on additional 554 path delay [RFC2212]. 556 The parameter accumulates the jitter of the packet 557 forwarding process associated with each QNE, where the jitter is 558 defined to be the nominal jitter added by each QNE. IP packet 559 jitter, or delay variation, is defined in [RFC3393], Section 3.4 560 (Type-P-One-way-ipdv), and where the selection function includes the 561 packet with minimum delay such that the distribution is equivalent to 562 2-point delay variation in [Y.1540]. The suggested evaluation 563 interval is 1 minute. This jitter results from packet processing 564 limitations, and includes any variable queuing delay which may be 565 present. Each QNE MUST add the jitter of its outgoing link, if this 566 link exists. Furthermore, the QNI MUST add the jitter of the ingress 567 link, if this link exists. The composition method for the parameter is the combination of several statistics describing 569 the delay variation distribution with a clamp on the maximum value 570 (note that the methods of accumulation and estimation of nominal QNE 571 jitter are specified in clause 8 of [Y.1541]). This quantity, when 572 composed end-to-end, informs the QNR (or QNI in a RESPONSE message) 573 of the nominal packet jitter along the path from QNI to QNR. The 574 purpose of this parameter is to provide a nominal path jitter for use 575 with services that provide estimates or bounds on additional path 576 delay [RFC2212]. 578 The parameter accumulates the packet loss rate (PLR) of 579 the packet forwarding process associated with each QNE, where the PLR 580 is defined to be the PLR added by each QNE. Each QNE MUST add the 581 PLR of its outgoing link, if this link exists. Furthermore, the QNI 582 MUST add the PLR of the ingress link, if this link exists. The 583 composition rule for the parameter is summation with a 584 clamp on the maximum value (this assumes sufficiently low PLR values 585 such that summation error is not significant, however a more accurate 586 composition function is specified in clause 8 of [Y.1541]). This 587 quantity, when composed end-to-end, informs the QNR (or QNI in a 588 RESPONSE message) of the minimal packet PLR along the path from QNI 589 to QNR. 591 The parameter accumulates the packet error rate (PER) of 592 the packet forwarding process associated with each QNE, where the PER 593 is defined to be the PER added by each QNE. Each QNE MUST add the 594 PER of its outgoing link, if this link exists. Furthermore, the QNI 595 MUST add the PER of the ingress link, if this link exists. The 596 composition rule for the parameter is summation with a 597 clamp on the maximum value (this assumes sufficiently low PER values 598 such that summation error is not significant, however a more accurate 599 composition function is specified in clause 8 of [Y.1541]). This 600 quantity, when composed end-to-end, informs the QNR (or QNI in a 601 RESPONSE message) of the minimal packet PER along the path from QNI 602 to QNR. 604 The slack term parameter is the difference between desired delay and 605 delay obtained by using bandwidth reservation, and which is used to 606 reduce the resource reservation for a flow [RFC2212]. This is an 607 QSPEC parameter. 609 The parameter is the priority of the new flow 610 compared with the of previously admitted flows. 611 Once a flow is admitted, the preemption priority becomes irrelevant. 612 The parameter is used to compare with the 613 preemption priority of new flows. For any specific flow, its 614 preemption priority MUST always be less than or equal to the 615 defending priority. and provide 616 an essential way to differentiate flows for emergency services, ETS, 617 E911, etc., and assign them a higher admission priority than normal 618 priority flows and best-effort priority flows. 620 4.3.3 Traffic Handling Directives 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 cannot be overwritten. 627 4.3.4 Traffic Classifiers 629 An application MAY like to reserve resources for packets with a 630 particular DiffServ per-hop behavior (PHB) [RFC2475]. Note that PHB 631 class is normally set by a downstream QNE to tell the QNI how to mark 632 traffic to ensure treatment committed by admission control. An 633 application MAY like to reserve resources for packets with a 634 particular QoS class, e.g. Y.1541 QoS class [Y.1541] or 635 DiffServ-aware MPLS traffic engineering (DSTE) class type [RFC3564, 636 RFC4124]. These parameters are useful in various QOSMs, e.g., 637 [RMD-QOSM], [Y.1541-QOSM], and other QOSMs yet to be defined (e.g., 638 DSTE-QOSM). This is intended to provide guidelines to QOSMs on how 639 to encode these parameters; use of the PHB class parameter is 640 illustrated in the example in the following section. 642 4.4 Example of QSPEC Processing 644 This section illustrates the operation and use of the QSPEC within 645 the NSLP. The example configuration in shown in Figure 2. 647 +----------+ /-------\ /--------\ /--------\ 648 | Laptop | | Home | | Cable | | DiffServ | 649 | Computer |-----| Network |-----| Network |-----| Network |----+ 650 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 651 \-------/ \--------/ \--------/ | 652 | 653 +-----------------------------------------------+ 654 | 655 | /--------\ +----------+ 656 | | "X"G | | Handheld | 657 +---| Wireless |-----| Device | 658 | XG QOSM | +----------+ 659 \--------/ 661 Figure 2: Example Configuration to Illustrate QoS-NSLP/QSPEC 662 Operation 664 In this configuration, a laptop computer and a handheld wireless 665 device are the endpoints for some application that has QoS 666 requirements. Assume initially that the two endpoints are stationary 667 during the application session, later we consider mobile endpoints. 668 For this session, the laptop computer is connected to a home network 669 that has no QoS support. The home network is connected to a 670 CableLabs-type cable access network with dynamic QoS (DQOS) support, 671 such as specified in the [DQOS] for cable access networks. That 672 network is connected to a DiffServ core network that uses the RMD 673 QOSM [RMD-QOSM]. On the other side of the DiffServ core is a 674 wireless access network built on generation "X" technology with QoS 675 support as defined by generation "X". And finally the handheld 676 endpoint is connected to the wireless access network. 678 We assume that the Laptop is the QNI and handheld device is the QNR. 680 The QNI will signal an initiator QSPEC object to achieve the QoS 681 desired on the path. The QNI would normally signal a reservation 682 according to the requirements of its supported QOSM. Furthermore, 683 the QNI would most likely support the QOSM that matches its 684 functionality. For example, the default QOSM for mobile phones might 685 be the XG-QOSM, while the CL-QOSM might be the default for 686 workstations. 688 The QNI sets QoS Desired, QoS Available and possibly Minimum 689 QoS QSPEC objects in the initiator QSPEC, and initializes QoS 690 Available to QoS Desired. Each QNE on the path reads and 691 interprets those parameters in the initiator QSPEC and checks to see 692 if QoS Available resources can be reserved. If not, the QNE reduces 693 the respective parameter values in QoS Available and reserves these 694 values. The minimum parameter values are given in Minimum QoS, if 695 populated, otherwise zero if Minimum QoS is not included. If one or 696 more parameters in QoS Available fails to satisfy the corresponding 697 minimum values in Minimum QoS, the QNE generates a RESPONSE message 698 to the QNI and the reservation is aborted. Otherwise, the QNR 699 generates a RESPONSE to the QNI with the QoS Available for the 700 reservation. If a QNE cannot reserve QoS Desired resources, the 701 reservation fails. 703 The QNI populates QSPEC parameters to ensure correct treatment of its 704 traffic in domains down the path. Let us assume the QNI wants to 705 achieve IntServ-Controlled Load-like QoS guarantees, and also is 706 interested in what path latency it can achieve. Additionally, to 707 ensure correct treatment further down the path, the QNI includes in . The QNI therefore includes in the QSPEC 710 QoS Desired = 711 QoS Available = 713 Since and are not vital parameters from 714 the QNI's perspective, it does not raise their M-flags. 716 There are three possibilities when a RESERVE message is received at a 717 QNE at a domain border (we illustrate these possibilities in the 718 example): 720 - the QNE just leaves the QSPEC as-is. 722 - the QNE can add a local QSPEC and encapsulate the initiator QSPEC 723 (see discussion in Section 5.1; this is new in QoS NSLP, RSVP does 724 not do this). 726 - the QNE can tunnel the initiator RESERVE message through its domain 727 and issue its own local RESERVE message. For this new local 728 RESERVE message, the QNE acts as the QNI, and the QSPEC in the 729 domain is an initiator QSPEC. A similar procedure is also used by 730 RSVP in making aggregate reservations, in which case there is not a 731 new intra-domain (aggregate) RESERVE for each newly arriving 732 interdomain (per-flow) RESERVE, but the aggregate reservation is 733 updated by the border QNE (QNI) as need be. This is also how RMD 734 works [RMD-QOSM]. 736 For example, at the RMD domain, a local RESERVE with its own RMD 737 initiator QSPEC corresponding to the RMD-QOSM is generated based on 738 the original initiator QSPEC according to the procedures described in 739 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. For example, the ingress 740 QNE to the RMD domain maps the TMOD parameters contained in the 741 original initiator QSPEC into the equivalent TMOD parameter 742 representing only the peak bandwidth in the local QSPEC. The local 743 RMD QSPEC for example also needs , which in this case was 744 provided by the QNI. 746 Furthermore, the node at the egress to the RMD domain updates QoS 747 Available on behalf of the entire RMD domain if it can. If it 748 cannot (since the M-flag is not set for ) it raises the 749 parameter-specific, 'not-supported' flag, warning the QNR that the 750 final latency value in QoS Available is imprecise. 752 In the XG domain, the initiator QSPEC is translated into a local 753 QSPEC using a similar procedure as described above. The local QSPEC 754 becomes the current QSPEC used within the XG domain, that is, the 755 it becomes the first QSPEC on the stack, and the initiator QSPEC is 756 second. This saves the QNEs within the XG domain the trouble of 757 re-translating the initiator QSPEC, and simplifies processing in 758 the local domain. At the egress edge of the XG domain, the 759 translated local QSPEC is popped, and the initiator QSPEC returns to 760 the number one position. 762 If the reservation was successful, eventually the RESERVE request 763 arrives at the QNR (otherwise the QNE at which the reservation failed 764 would have aborted the RESERVE and sent an error RESPONSE back to the 765 QNI). If the RII was included in the QoS NSLP message, the QNR 766 generates a positive RESPONSE with QSPEC objects QoS Reserved and 767 QoS Available. The parameters appearing in QoS Reserved are the 768 same as in QoS Desired, with values copied from QoS Available. 769 Hence, the QNR includes the following QSPEC objects in the RESPONSE: 771 QoS Reserved = 772 QoS Available = 774 If the handheld device on the right of Figure 2 is mobile, and moves 775 through different "XG" wireless networks, then the QoS might change 776 on the path since different XG wireless networks might support 777 different QOSMs. As a result, QoS NSLP/QSPEC processing will have to 778 renegotiate the QoS Available on the path. From a QSPEC 779 perspective, this is like a new reservation on the new section of the 780 path and is basically the same as any other rerouting event - to the 781 QNEs on the new path it looks like a new reservation. That is, in 782 this mobile scenario, the new segment may support a different QOSM 783 than the old segment, and the QNI would now signal a new reservation 784 (explicitly, or implicitly with the next refreshing RESERVE message) 785 to account for the different QOSM in the XG wireless domain. Further 786 details on rerouting are specified in [QoS-SIG]. 788 For bit-level examples of QSPECs see the documents specifying QOSMs 789 [CL-QOSM, Y.1541-QOSM, RMD-QOSM]. 791 5. QSPEC Processing & Procedures 793 The QNI sets the M-flag for each QSPEC parameter it populates that 794 must be interpreted by downstream QNEs. If a QNE does not support 795 parameter it sets the N-flag and fails the reservation. If the QNE 796 supports the parameter but cannot meet the resources requested by the 797 parameter, it sets the E-flag and fails the reservation. 799 If the M-flag is not set, the downstream QNE SHOULD interpret the 800 parameter. If the QNE does not support the parameter it sets the 801 N-flag and forwards the reservation. If the QNE supports the 802 parameter but cannot meet the resources requested by the parameter, 803 it sets the E-flag and fails the reservation. 805 5.1 Local QSPEC Definition & Processing 807 A QNE at the edge of a local domain may either a) translate the 808 initiator QSPEC into a local QSPEC and encapsulate the initiator 809 QSPEC in the RESERVE message, or b) tunnel the initiator QSPEC 810 through the local domain and reserve resources by generating a new 811 RESERVE message through the local domain containing the local QSPEC. 812 In either case the initiator QSPEC parameters are interpreted at the 813 local domain edges. 815 A local QSPEC may allow a simpler control plane in a local domain. 816 The edge nodes in the local domain must interpret the initiator 817 QSPEC parameters. They can either initiate a parallel session with 818 local QSPEC or define a local QSPEC and encapsulate the initiator 819 QSPEC, as illustrated in Figure 3. As defined in Section 6, the 820 QSPEC type identifies where the QSPEC is an initiator QSPEC or a 821 local QSPEC. 823 +--------------------------------+ 824 | QSPEC Type = Local QSPEC | Common QSPEC Header 825 +================================+\ 826 | Local-QSPEC Parameter 1 | \ 827 +--------------------------------+ \ 828 | .... | Local-QSPEC Parameters 829 +--------------------------------+ / 830 | Local-QSPEC Parameter n | / 831 +--------------------------------+/ 832 | +----------------------------+ | 833 | |QSPEC Type = Initiator QSPEC| | 834 | +============================+ | 835 | | | | Encapsulated Initiator QSPEC 836 | | .... | | 837 | +----------------------------+ | 838 +--------------------------------+ 840 Figure 3. Defining a Local QSPEC 842 Here the QoS-NSLP only sees and passes one QSPEC up to the RMF. The 843 type of the QSPEC thus may change within a local domain. Hence 845 o the QNI signals its QoS requirements with the initiator QSPEC, 846 o the ingress edge QNE in the local domain translates the 847 initiator QSPEC parameters to equivalent parameters in the local 848 QSPEC, 849 o the QNEs in the local domain only interpret the local QSPEC 850 parameters 851 o the egress QNE in the local domain processes the local QSPEC and 852 also interprets the QSPEC parameters in the initiator QSPEC. 854 The local QSPEC MUST be consistent with the initiator QSPEC. That 855 is, it MUST NOT specify a lower level of resources than specified 856 by the initiator QSPEC. For example, RMD can define a local QSPEC 857 that contains TMOD = bandwidth (sets r=p, b/m to large). This 858 allows simple processing but may overprovision bandwidth. 860 5.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 861 Notification 863 A reservation may not be successful for several reasons: 865 - a reservation may fail because the desired resources are not 866 available. This is a reservation failure condition. 868 - a reservation may fail because the QSPEC is erroneous, or because 869 of a QNE fault. This is an error condition. 871 A reservation may be successful even though some parameters could not 872 be interpreted or updated properly: 874 - a QSPEC parameter cannot be interpreted because it is an unknown 875 QSPEC parameter type. This is a QSPEC parameter not supported 876 condition. The reservation however does not fail. The QNI can 877 still decide whether to keep or tear down the reservation depending 878 on the procedures specified by the QNI's QOSM. 880 The following sections describe the handling of unsuccessful 881 reservations and reservations where some parameters could not be met 882 in more detail, as follows: 884 - details on flags used inside the QSPEC to convey information on 885 success or failure of individual parameters. The formats and 886 semantics of all flags are given in Section 6. 887 - the content of the INFO_SPEC [QoS-SIG], which carries a code 888 indicating the outcome of reservations. 889 - the generation of a RESPONSE message to the QNI containing both 890 QSPEC and INFO_SPEC objects. 892 5.2.1 Reservation Failure & Error E-Flag 894 The QSPEC parameters each have a 'reservation failure error E-flag' 895 to indicate which (if any) parameters could not be satisfied. When a 896 resource cannot be satisfied for a particular parameter, the QNE 897 detecting the problem raises the E-flag in this parameter. Note that 898 all QSPEC parameters MUST be examined by the RMF and appropriately 899 flagged. Additionally, the E-flag in the corresponding QSPEC object 900 MUST be raised. If the reservation failure problem cannot be located 901 at the parameter level, only the E-flag in the QSPEC object is 902 raised. 904 When an RMF cannot interpret the QSPEC because the coding is 905 erroneous, it raises corresponding reservation failure E-flags in the 906 QSPEC. Normally all QSPEC parameters MUST be examined by the RMF 907 and the erroneous parameters appropriately flagged. In some cases, 908 however, an error condition may occur and the E-flag of the 909 error-causing QSPEC parameter is raised (if possible), but the 910 processing of further parameters may be aborted. 912 Note that if the QSPEC and/or any QSPEC parameter is found to be 913 erroneous, then any QSPEC parameters not satisfied are ignored and 914 the E-Flags in the QSPEC object MUST NOT be set for those parameters 915 (unless they are erroneous). 917 Whether E-flags denote reservation failure or error can be determined 918 by the corresponding error code in the INFO_SPEC in QoS NSLP, as 919 discussed below. 921 5.2.2 QSPEC Parameter Not Supported N-Flag 923 Each QSPEC parameter has an associated 'not supported N-flag'. If 924 the not supported N-flag is set, then at least one QNE along the data 925 transmission path between the QNI and QNR cannot interpret the 926 specified QSPEC parameter. A QNE MUST set the not supported N-flag 927 if it cannot interpret the QSPEC parameter. If the M-flag for the 928 parameter is not set, the message should continue to be forwarded but 929 with the N-flag set, and the QNI has the option of tearing the 930 reservation. 932 If a QNE in the path does not support a QSPEC parameter, e.g., 933 , and sets the N-flag, then downstream QNEs that 934 support the parameter SHOULD still update the parameter, even if the 935 N-flag is set. However, the presence of the N-flag will make the 936 cumulative value unreliable, and the QNI/QNR decides whether or not 937 to accept the reservation with the N-flag set. 939 5.2.3 INFO_SPEC Coding of Reservation Outcome 941 As prescribed by [QoS-SIG], the RESPONSE message always contains the 942 INFO_SPEC with an appropriate 'error' code. It usually also contains 943 a QSPEC with QSPEC objects, as described in Section 5.3 on QSPEC 944 Procedures. The RESPONSE message MAY omit the QSPEC in case of a 945 successful reservation. 947 The following guidelines are provided in setting the error codes in 948 the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of 949 [QoS-SIG]: 951 - INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success): 953 This code is set when all QSPEC parameters have been satisfied. In 954 this case no E-Flag is set, however one or more N-flags may be set. 956 - INFO_SPEC error class 0x04 (Transient Failure) / 0x08 (Reservation 957 Failure): 958 This code is set when at least one QSPEC parameter could not be 959 satisfied, or when a QSPEC parameter with M-flag could not be 960 interpreted. E-flags are set for the parameters that could not be 961 satisfied up to the QNE issuing the RESPONSE message. The N-flag is 962 set for those parameters that could not be interpreted by at least 963 one QNE. In this case QNEs receiving the RESPONSE message MUST 964 remove the corresponding reservation. 966 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0c (Malformed 967 QSPEC): 968 Some QSPEC parameters had associated errors, E-Flags are set for 969 parameters that had errors, and the QNE where the error was found 970 rejects the reservation. 972 - INFO_SPEC error class 0x06 (QoS Model Error): 973 QOSM error codes can be defined by QOSM specification documents. A 974 registry is defined in Section 8 IANA Considerations. 976 5.2.4 QNE Generation of a RESPONSE message 978 - Successful Reservation Condition 980 When a RESERVE message arrives at a QNR and no E-Flag is set, the 981 reservation is successful. A RESPONSE message may be generated with 982 INFO_SPEC code 'Reservation Success' as described above and in the 983 QSPEC Procedures described in Section 5.3. 985 - Reservation Failure Condition 987 When a QNE detects that a reservation failure occurs for at least one 988 parameter, the QNE sets the E-Flags for the QSPEC parameters and 989 QSPEC object that failed to be satisfied. According to [QoS-SIG], 990 the QNE behavior depends on whether it is stateful or not. When a 991 stateful QNE determines the reservation failed, it formulates a 992 RESPONSE message that includes an INFO_SPEC with the 'reservation 993 failure' error code and QSPEC object. The QSPEC in the RESPONSE 994 message includes the failed QSPEC parameters marked with the E-Flag 995 to clearly identify them. 997 The default action for a stateless QoS NSLP QNE that detects a 998 reservation failure condition is that it MUST continue to forward the 999 RESERVE message to the next stateful QNE, with the E-Flags 1000 appropriately set for each QSPEC parameter. The next stateful QNE 1001 then formulates the RESPONSE message as described above. 1003 - Malformed QSPEC Error Condition 1004 When a stateful QNE detects that one or more QSPEC parameters are 1005 erroneous, the QNE sets the error code 'malformed QSPEC' in the 1006 INFO_SPEC. In this case the QSPEC object with the E-Flags 1007 appropriately set for the erroneous parameters is returned within 1008 the INFO_SPEC object. The QSPEC object can be truncated or fully 1009 included within the INFO_SPEC. 1011 According to [QoS-SIG], the QNE behavior depends on whether it is 1012 stateful or not. When a stateful QNE determines a malformed QSPEC 1013 error condition, it formulates a RESPONSE message that includes an 1014 INFO_SPEC with the 'malformed QSPEC' error code and QSPEC object. 1015 The QSPEC in the RESPONSE message includes, if possible, only the 1016 erroneous QSPEC parameters and no others. The erroneous QSPEC 1017 parameter(s) are marked with the E-Flag to clearly identify them. If 1018 QSPEC parameters are returned in the INFO-SPEC that are not marked 1019 with the E-flag, then any values of these parameters are irrelevant 1020 and MUST be ignored by the QNI. 1022 The default action for a stateless QoS NSLP QNE that detects a 1023 Malformed QSPEC error condition is that it MUST continue to forward 1024 the RESERVE message to the next stateful QNE, with the E-Flags 1025 appropriately set for each QSPEC parameter. The next stateful QNE 1026 will then act as described in [QoS-SIG]. 1028 A 'malformed QSPEC' error code takes precedence over the 'reservation 1029 failure' error code, and therefore the case of reservation failure 1030 and QSPEC/RMF error conditions are disjoint and the same E-Flag can 1031 be used in both cases without ambiguity. 1033 5.2.5 Special Case of Local QSPEC 1035 When an unsuccessful reservation problem occurs inside a local domain 1036 where a local QSPEC is used, only the topmost (local) QSPEC is 1037 affected (e.g. E-flags are raised, etc.). The encapsulated 1038 initiator QSPEC is untouched. When the message (RESPONSE in case of 1039 stateful QNEs, RESERVE in case of stateless QNEs) however reaches the 1040 edge of the local domain, the local QSPEC is removed. The edge QNE 1041 must update the initiator QSPEC on behalf of the entire domain, 1042 reflecting the information received in the local QSPEC. This update 1043 concerns both parameter values and flags. 1045 5.3 QSPEC Procedures 1047 While the QSPEC template aims to put minimal restrictions on usage of 1048 QSPEC objects, interoperability between QNEs and between QOSMs must 1049 be ensured. We therefore give below an exhaustive list of QSPEC 1050 object combinations for the message sequences described in QoS NSLP 1051 [QoS-SIG]. A specific QOSM may prescribe that only a subset of the 1052 procedures listed below may be used. 1054 Note that QoS NSLP does not mandate the usage of a RESPONSE message. 1055 In fact, a RESPONSE message will only be generated if the QNI 1056 includes an RII (Request Identification Information) in the RESERVE 1057 message. Some of the QSPEC procedures below, however, are only 1058 meaningful when a RESPONSE message is possible. The QNI SHOULD in 1059 these cases include an RII. 1061 5.3.1 Sender-Initiated Reservations 1063 Here the QNI issues a RESERVE message, which may be replied to by a 1064 RESPONSE message. The following 3 cases for QSPEC object usage 1065 exist: 1067 ID | RESERVE | RESPONSE 1068 --------------------------------------------------------------- 1069 1 | QoS Desired | QoS Reserved 1070 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1071 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1073 Case 1: 1075 If only QoS Desired is included in the RESERVE message, the implicit 1076 assumption is that exactly these resources must be reserved. If this 1077 is not possible the reservation fails. The parameters in QoS 1078 Reserved are copied from the parameters in QoS Desired. If the 1079 reservation is successful, the RESPONSE message can be omitted in 1080 this case. If a RESPONSE message was requested by a QNE on the 1081 path, the QSPEC in the RESPONSE message can be omitted. 1083 Case 2: 1085 When QoS Available is included in the RESERVE message also, some 1086 parameters will appear only in QoS Available and not in QoS Desired. 1087 It is assumed that the value of these parameters is collected for 1088 informational purposes only (e.g. path latency). 1090 However, some parameters in QoS Available can be the same as in QoS 1091 Desired. For these parameters the implicit message is that the QNI 1092 would be satisfied by a reservation with lower parameter values than 1093 specified in QoS Desired. For these parameters, the QNI seeds the 1094 parameter values in QoS Available to those in QoS Desired (except for 1095 cumulative parameters such as ). 1097 Each QNE interprets the parameters in QoS 1098 Available according to its current capabilities. Reservations in 1099 each QNE are hence based on current parameter values in QoS Available 1100 (and additionally those parameters that only appear in QoS Desired). 1101 The drawback of this approach is that, if the resulting resource 1102 reservation becomes gradually smaller towards the QNR, QNEs close to 1103 the QNI have an oversized reservation, possibly resulting in 1104 unnecessary costs for the user. Of course, in the RESPONSE the QNI 1105 learns what the actual reservation is (from the QoS RESERVED object) 1106 and can immediately issue a properly sized refreshing RESERVE. The 1107 advantage of the approach is that the reservation is performed in 1108 half-a-roundtrip time. 1110 The QSPEC parameter IDs and values included in the QoS Reserved 1111 object in the RESPONSE message MUST be the same as those in the QoS 1112 Desired object in the RESERVE message. For those QSPEC parameters 1113 that were also included in the QoS Available object in the RESERVE 1114 message, their value is copied into the QoS Desired object. For the 1115 other QSPEC parameters, the value is copied from the QoS Desired 1116 object (the reservation would fail if the corresponding QoS could 1117 not be reserved). 1119 All parameters in the QoS Available object in the RESPONSE message 1120 are copied with their values from the QoS Available object in the 1121 RESERVE message (irrespective of whether they have also been copied 1122 into the QoS Desired object). Note that the parameters in the QoS 1123 Available object can be overwritten in the RESERVE message, whereas 1124 they cannot be overwritten in the RESPONSE message. 1126 In this case, the QNI SHOULD request a RESPONSE message since it will 1127 otherwise not learn what QoS is available. 1129 Case 3: 1131 This case is handled as case 2, except that the reservation fails 1132 when QoS Available becomes less than Minimum QoS for one parameter. 1133 If a parameter appears in the QoS Available object but not in the 1134 Minimum QoS object it is assumed that there is no minimum value for 1135 this parameter. 1137 5.3.2 Receiver-Initiated Reservations 1139 Here the QNR issues a QUERY message which is replied to by the QNI 1140 with a RESERVE message if the reservation was successful. The QNR in 1141 turn sends a RESPONSE message to the QNI. The following 3 cases for 1142 QSPEC object usage exist: 1144 ID| QUERY | RESERVE | RESPONSE 1145 --------------------------------------------------------------------- 1146 1 |QoS Des. | QoS Des. | QoS Res. 1147 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1148 3 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl. | QoS Res. 1150 Cases 1 and 2: 1152 The idea is that the sender (QNR in this scenario) needs to inform 1153 the receiver (QNI in this scenario) about the QoS it desires. To 1154 this end the sender sends a QUERY message to the receiver including a 1155 QoS Desired QSPEC object. If the QoS is negotiable it additionally 1156 includes a (possibly zero) Minimum QoS object, as in Case 2. 1158 The RESERVE message includes the QoS Available object if the sender 1159 signaled that QoS is negotiable (i.e. it included the Minimum QoS 1160 object). If the Minimum QoS object received from the sender is 1161 included in the QUERY message, the QNR also includes the Minimum QoS 1162 object in the RESERVE message. 1164 For a successful reservation, the RESPONSE message in case 1 is 1165 optional (as is the QSPEC inside). In case 2 however, the RESPONSE 1166 message is necessary in order for the QNI to learn about the QoS 1167 available. 1169 Case 4: 1171 This is the 'RSVP-style' scenario. The sender (QNR in this scenario) 1172 issues a QUERY message with a QoS Desired object informing the 1173 receiver (QNI in this scenario) about the QoS it desires as above. 1174 It also includes a QoS Available object to collect path properties. 1175 Note that here path properties are collected with the QUERY message, 1176 whereas in the previous case 2 path properties were collected in the 1177 RESERVE message. 1179 Some parameters in the QoS Available object may the same as in the 1180 QoS Desired object. For these parameters the implicit message is 1181 that the sender would be satisfied by a reservation with lower 1182 parameter values than specified in QoS Desired. 1184 It is possible for the QoS Available object to contain parameters 1185 that do not appear in the QoS Desired object. It is assumed that the 1186 value of these parameters is collected for informational purposes 1187 only (e.g. path latency). Parameter values in the QoS Available 1188 object are seeded according to the sender's capabilities. Each QNE 1189 remaps or approximately interprets the parameter values according to 1190 its current capabilities. 1192 The receiver (QNI in this scenario) signals the QoS Desired object as 1193 follows: For those parameters that appear in both the QoS Available 1194 object and QoS Desired object in the QUERY message, it takes the 1195 (possibly remapped) QSPEC parameter values from the QoS Available 1196 object. For those parameters that only appear in the QoS Desired 1197 object, it adopts the parameter values from the QoS Desired object. 1199 The parameters in the QoS Available QSPEC object in the RESERVE 1200 message are copied with their values from the QoS Available QSPEC 1201 object in the QUERY message. Note that the parameters in the QoS 1202 Available object can be overwritten in the QUERY message, whereas 1203 they are cannot be overwritten in the RESERVE message. 1205 The advantage of this model compared to the sender-initiated 1206 reservation is that the situation of over-reservation in QNEs close 1207 to the QNI as described above does not occur. On the other hand, the 1208 QUERY message may find, for example, a particular bandwidth is not 1209 available. When the actual reservation is performed, however, the 1210 desired bandwidth may meanwhile have become free. That is, the 'RSVP 1211 style' may result in a smaller reservation than necessary. 1213 The sender includes all QSPEC parameters it cares about in the QUERY 1214 message. Parameters that can be overwritten are updated by QNEs as 1215 the QUERY message travels towards the receiver. The receiver 1216 includes all QSPEC parameters arriving in the QUERY message also in 1217 the RESERVE message, with the value they had when arriving at the 1218 receiver. Again, QOSM-specific QSPEC parameters and procedures may 1219 be defined in QOSM specification documents. 1221 Also in this scenario, the QNI SHOULD request a RESPONSE message 1222 since it will otherwise not learn what QoS is available. 1224 5.3.3 Resource Queries 1226 Here the QNI issues a QUERY message in order to investigate what 1227 resources are currently available. The QNR replies with a RESPONSE 1228 message. 1230 ID | QUERY | RESPONSE 1231 -------------------------------------------- 1232 1 | QoS Available | QoS Available 1234 Note that the QoS Available object when traveling in the QUERY 1235 message can be overwritten, whereas in the RESPONSE message cannot be 1236 overwritten. 1238 5.3.4 Bidirectional Reservations 1240 On a QSPEC level, bidirectional reservations are no different from 1241 uni-directional reservations, since QSPECs for different directions 1242 never travel in the same message. 1244 5.3.5 Preemption 1246 A flow can be preempted by a QNE based on the values of the QSPEC 1247 Priority parameter (see Section 6.2.8). In this case the reservation 1248 state for this flow is torn down in this QNE, and the QNE sends a 1249 NOTIFY message to the QNI, as described in [QoS-SIG]. The NOTIFY 1250 message carries an INFO_SPEC with the error code as described in 1251 [QOS-SIG]. A QOSM specification document may specify whether a 1252 NOTIFY message also carries a QSPEC object. The QNI would normally 1253 tear down the preempted reservation by sending a RESERVE message with 1254 the TEAR flag set using the SII of the preempted reservation. 1255 However, the QNI can follow other procedures as specified in its QOSM 1256 specification document. 1258 5.4 QSPEC Extensibility 1260 The set of QSPEC parameters defined herein is at this point in time 1261 considered complete. Additional QSPEC parameters may be defined in 1262 the future. However, since this requires an update of all QNEs, this 1263 should be considered carefully. The definition of new QSPEC 1264 parameter requires standards action and an update of this document. 1265 Such an update also needs a new QSPEC version number. Furthermore, 1266 all QOSM definitions must be updated to include how the new QSPEC 1267 parameter is to be interpreted in the respective QOSM. 1269 Additional QSPEC parameters MAY need to be defined in the future 1270 and are defined in separate informational documents specific to a 1271 given QOSM. For example, QSPEC parameters are defined in 1272 [RMD-QOSM] and [Y.1541-QOSM]. 1274 Guidelines on the technical criteria to be followed in evaluating 1275 requests for new codepoint assignments for QSPEC objects and QSPEC 1276 parameters are given in Section 8 (IANA Considerations). 1278 Guidelines on the technical criteria to be followed in evaluating 1279 requests for new codepoint assignments beyond QSPEC objects and 1280 QSPEC parameters for the NSIS protocol suite are given in a separate 1281 NSIS extensibility document [NSIS-EXTENSIBILITY]. 1283 6. QSPEC Functional Specification 1285 This section defines the encodings of the QSPEC parameters. We first 1286 give the general QSPEC formats and then the formats of the QSPEC 1287 objects and parameters. 1289 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1290 well as 32-bit floating point numbers, are as specified in [RFC1832, 1291 IEEE754, NETWORK-BYTE-ORDER]. 1293 6.1 General QSPEC Formats 1295 The format of the QSPEC closely follows that used in GIST [GIST] and 1296 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1297 general format: 1299 o The overall format is Type-Length-Value (in that order). 1301 o Some parts of the type field are set aside for control flags. 1303 o Length has the units of 32-bit words, and measures the length of 1304 Value. If there is no Value, Length=0. The Object length 1305 excludes the header. 1307 o Value is a whole number of 32-bit words. If there is any padding 1308 required, the length and location MUST be defined by the 1309 object-specific format information; objects that contain variable 1310 length types may need to include additional length subfields to do 1311 so. 1313 o Any part of the object used for padding or defined as reserved("r") 1314 MUST be set to 0 on transmission and MUST be ignored on reception. 1316 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1318 o Duplicate objects, duplicate parameters, and/or multiple 1319 occurrences of a parameter MUST NOT be used. 1321 0 1 2 3 1322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Common QSPEC Header | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 // QSPEC Objects // 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 The Common QSPEC Header is a fixed 4-byte long object containing the 1330 QOSM ID and an identifier for the QSPEC Procedure (see Section 5.3): 1332 0 1 2 3 1333 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 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Vers. | QSPEC Type | QSPEC Proc. | Reserved | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 Note that a length field is not necessary since the overall length of 1339 the QSPEC is contained in the higher level QoS NSLP data object. 1341 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1343 QSPEC Type: Identifies the particular type of QSPEC, e.g., initiator 1344 QSPEC or local QSPEC. 1346 QSPEC Proc.: Identifies the QSPEC procedure and is composed of two 1347 times 4 bits. The first set of bits identifies the 1348 Message Sequence, the second set identifies the QSPEC 1349 Object Combination used for this particular message 1350 sequence: 1352 0 1 2 3 4 5 6 7 1353 +-+-+-+-+-+-+-+-+ 1354 |Mes.Sq |Obj.Cmb| 1355 +-+-+-+-+-+-+-+-+ 1357 The Message Sequence field can attain the following 1358 values: 1360 0: Sender-Initiated Reservations 1361 1: Receiver-Initiated Reservations 1362 2: Resource Queries 1364 The Object Combination field can take the values between 1365 1 and 3 indicated in the tables in Section 5.3: 1366 Message Sequence: 0 1367 Object Combination: 1, 2, 3 1368 Semantic: see table in Section 5.3.1 1369 Message Sequence: 1 1370 Object Combination: 1, 2, 3 1371 Semantic: see table in Section 5.3.2 1372 Message Sequence: 2 1373 Object Combination: 1, 2, 3 1374 Semantic: see table in Section 5.3.3 1376 The QSPEC Objects field is a collection of 1377 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1378 common format and each contain several parameters. 1380 QSPEC objects share a common header format: 1382 0 1 2 3 1383 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 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 |E|r|r|r| Object Type |r|r|r|r| Length | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 E Flag: Set if an error occurs on object level 1389 Object Type = 0: QoS Desired (parameters cannot be overwritten) 1390 = 1: QoS Available (parameters may be overwritten; see 1391 Section 4.3) 1392 = 2: QoS Reserved (parameters cannot be overwritten) 1393 = 3: Minimum QoS (parameters cannot be overwritten) 1395 The r bits are reserved. 1397 Each QSPEC or QSPEC parameter within an object is similarly 1398 encoded in TLV format using a similar parameter header: 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 |M|E|N|r| Parameter ID |r|r|r|r| Length | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 M Flag: When set indicates the subsequent parameter MUST be 1407 interpreted. Otherwise the parameter can be ignored if not 1408 understood. 1409 E Flag: When set indicates either a) a reservation failure where the 1410 QSPEC parameter is not met, or b) an error occurred when this 1411 parameter was being interpreted (see Section 5.2.1). 1412 N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2). 1413 For QSPEC parameters the value of this flag is always zero. 1414 Parameter ID: Assigned to each parameter (see below) 1416 Parameters are usually coded individually, for example, the parameter (Section 6.2.11). However, it is also possible 1418 to combine several sub-parameters into one parameter field, which is 1419 called 'container coding'. This coding is useful if either a) the 1420 sub-parameters always occur together, as for example the several 1421 sub-parameters that jointly make up the TMOD, or b) in order 1422 to make coding more efficient when the length of each sub-parameter 1423 value is much less than a 32-bit word (as for example described in 1424 [RMD-QOSM]) and to avoid header overload. When a container is 1425 defined, the Parameter ID and the M, E, and N flags refer to the 1426 container. Examples of container parameters are (specified 1427 below) and the PHR container parameter specified in [RMD-QOSM]. 1429 6.2 QSPEC Parameter Coding 1431 6.2.1 Parameter 1433 =

[RFC2210, RFC2215] 1435 The above notation means that the 4 sub-parameters must all 1436 be populated in the parameter. Note that a second TMOD 1437 QSPEC parameter is specified below in Section 6.2.2. The 1438 references in the following sections point to the normative 1439 procedures for processing the sub-parameters. 1441 The coding for the parameter is as follows: 1443 0 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 |1|E|0|r| 1 |r|r|r|r| 4 | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 The parameters are represented by three floating point 1458 numbers in single-precision IEEE floating point format followed by 1459 one 32-bit integer in network byte order. The first floating point 1460 value is the rate (r), the second floating point value is the bucket 1461 size (b), the third floating point is the peak rate (p), and the 1462 first unsigned integer is the minimum policed unit (m). 1464 When r, b, and p terms are represented as IEEE floating point values, 1465 the sign bit MUST be zero (all values MUST be non-negative). 1466 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1467 than 162 (i.e., positive 35) are discouraged, except for specifying a 1468 peak rate of infinity. Infinity is represented with an exponent of 1469 all ones (255) and a sign bit and mantissa of all zeroes. 1471 6.2.2 Parameter [RFC2215] 1473 A second, QSPEC parameter is specified, as could be needed 1474 for example to support DiffServ applications. 1476 Parameter Values: 1478 0 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 |M|E|N|r| 2 |r|r|r|r| 4 | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | TMOD Rate-2 [r] (32-bit IEEE floating point number) | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | TMOD Size-2 [b] (32-bit IEEE floating point number) | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 When r, b, and p terms are represented as IEEE floating point values, 1493 the sign bit MUST be zero (all values MUST be non-negative). 1494 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1495 than 162 (i.e., positive 35) are discouraged, except for specifying a 1496 peak rate of infinity. Infinity is represented with an exponent of 1497 all ones (255) and a sign bit and mantissa of all zeroes. 1499 6.2.3 Parameter [RFC2210, RFC2215] 1501 0 1 2 3 1502 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 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 |M|E|N|r| 3 |r|r|r|r| 1 | 1505 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1506 | Path Latency (32-bit integer) | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 The Path Latency is a single 32-bit integer in network byte order. 1510 The composition rule for the parameter is summation 1511 with a clamp of (2**32 - 1) on the maximum value. The latencies are 1512 average values reported in units of one microsecond. A system with 1513 resolution less than one microsecond MUST set unused digits to zero. 1514 An individual QNE can advertise a latency value between 1 and 2**28 1515 (somewhat over two minutes) and the total latency added across all 1516 QNEs can range as high as (2**32)-2. If the sum of the different 1517 elements delays exceeds (2**32)-2, the end-to-end advertised delay 1518 SHOULD be reported as indeterminate. A QNE that cannot accurately 1519 predict the latency of packets it is processing MUST raise the 1520 not-supported flagand either leave the value of Path Latency as is, 1521 or add its best estimate of its lower bound. A raised not-supported 1522 flagflag indicates the value of Path Latency is a lower bound of the 1523 real Path Latency. The distinguished value (2**32)-1 is taken to 1524 mean indeterminate latency because the composition function limits 1525 the composed sum to this value, it indicates the range of the 1526 composition calculation was exceeded. 1528 6.2.4 Parameter 1530 0 1 2 3 1531 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 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 |M|E|N|r| 4 |r|r|r|r| 4 | 1534 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1535 | Path Jitter STAT1(variance) (32-bit integer) | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Path Jitter STAT4(Reserved) (32-bit integer) | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 The Path Jitter is a set of four 32-bit integers in network byte 1545 order. The Path Jitter parameter is the combination of four 1546 statistics describing the Jitter distribution with a clamp of 1547 (2**32 - 1) on the maximum of each value. The jitter STATs are 1548 reported in units of one microsecond. A system with resolution less 1549 than one microsecond MUST set unused digits to zero. An individual 1550 QNE can advertise jitter values between 1 and 2**28 (somewhat over 1551 two minutes) and the total jitter computed across all QNEs can range 1552 as high as (2**32)-2. If the combination of the different element 1553 values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be 1554 reported as indeterminate. A QNE that cannot accurately predict the 1555 jitter of packets it is processing MUST raise the not-supported flag 1556 and either leave the value of Path Jitter as is, or add its best 1557 estimate of its STAT values. A raised not-supported flag indicates 1558 the value of Path Jitter is a lower bound of the real Path Jitter. 1559 The distinguished value (2**32)-1 is taken to mean indeterminate 1560 jitter. A QNE that cannot accurately predict the jitter of packets 1561 it is processing SHOULD set its local path jitter parameter to this 1562 value. Because the composition function limits the total to this 1563 value, receipt of this value at a network element or application 1564 indicates that the true path jitter is not known. This MAY happen 1565 because one or more network elements could not supply a value, or 1566 because the range of the composition calculation was exceeded. 1568 NOTE: The Jitter composition function makes use of the 1569 parameter. Composition functions for loss, latency and jitter may be 1570 found in [Y.1541]. 1572 6.2.5 Parameter 1574 0 1 2 3 1575 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 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 |M|E|N|r| 5 |r|r|r|r| 1 | 1578 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1579 | Path Packet Loss Ratio (32-bit floating point) | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 The Path PLR is a single 32-bit single precision IEEE floating point 1583 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1585 value. The PLRs are reported in units of 10^-11. A system with 1586 resolution less than one microsecond MUST set unused digits to zero. 1587 An individual QNE can advertise a PLR value between zero and 10^-2 1588 and the total PLR added across all QNEs can range as high as 10^-1. 1589 If the sum of the different elements values exceeds 10^-1, the 1590 end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE 1591 that cannot accurately predict the PLR of packets it is processing 1592 MUST raise the not-supported flag and either leave the value of Path 1593 PLR as is, or add its best estimate of its lower bound. A raised 1594 not-supported flag indicates the value of Path PLR is a lower bound 1595 of the real Path PLR. The distinguished value 10^-1 is taken to mean 1596 indeterminate PLR. A QNE which cannot accurately predict the PLR of 1597 packets it is processing SHOULD set its local path PLR parameter to 1598 this value. Because the composition function limits the composed sum 1599 to this value, receipt of this value at a network element or 1600 application indicates that the true path PLR is not known. This MAY 1601 happen because one or more network elements could not supply a value, 1602 or because the range of the composition calculation was exceeded. 1604 6.2.6 Parameter 1606 0 1 2 3 1607 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 |M|E|N|r| 6 |r|r|r|r| 1 | 1610 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1611 | Path Packet Error Ratio (32-bit floating point) | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 The Path PER is a single 32-bit single precision IEEE floating point 1615 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1617 value. The PERs are reported in units of 10^-11. A system with 1618 resolution less than one microsecond MUST set unused digits to zero. 1619 An individual QNE can advertise a PER value between zero and 10^-2 1620 and the total PER added across all QNEs can range as high as 10^-1. 1621 If the sum of the different elements values exceeds 10^-1, the 1622 end-to-end advertised PER SHOULD be reported as indeterminate. A QNE 1623 that cannot accurately predict the PER of packets it is processing 1624 MUST raise the not-supported flag and either leave the value of Path 1625 PER as is, or add its best estimate of its lower bound. A raised 1626 not-supported flag indicates the value of Path PER is a lower bound 1627 of the real Path PER. The distinguished value 10^-1 is taken to mean 1628 indeterminate PER. A QNE which cannot accurately predict the PER of 1629 packets it is processing SHOULD set its local path PER parameter to 1630 this value. Because the composition function limits the composed sum 1631 to this value, receipt of this value at a network element or 1632 application indicates that the true path PER is not known. This MAY 1633 happen because one or more network elements could not supply a value, 1634 or because the range of the composition calculation was exceeded. 1636 6.2.7 Parameter [RFC2212, RFC2215] 1638 0 1 2 3 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 |M|E|N|r| 7 |r|r|r|r| 1 | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Slack Term [S] (32-bit integer) | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 Slack term S MUST be nonnegative and is measured in microseconds. 1647 The Slack term, S, is represented as a 32-bit integer. Its value 1648 can range from 0 to (2**32)-1 microseconds. 1650 6.2.8 & Parameters 1651 [RFC3181] 1653 The coding for the & 1654 sub-parameters is as follows: 1656 0 1 2 3 1657 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 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 |M|E|0|r| 8 |r|r|r|r| 1 | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Preemption Priority | Defending Priority | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 Preemption Priority: The priority of the new flow compared with the 1665 defending priority of previously admitted flows. Higher values 1666 represent higher priority. 1668 Defending Priority: Once a flow is admitted, the preemption priority 1669 becomes irrelevant. Instead, its defending priority is used to 1670 compare with the preemption priority of new flows. 1672 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 1674 parameter is used. 1676 6.2.9 Parameter [Y.1571] 1678 The coding for the parameter is as follows: 1680 0 1 2 3 1681 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 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 |M|E|0|r| 9 |r|r|r|r| 1 | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | Admis.Priority| (Reserved) | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 High priority flows, normal priority flows, and best-effort priority 1689 flows can have access to resources depending on their admission 1690 priority value, as described in [Y.1571], as follows: 1692 Admission Priority: 1694 0 - best-effort priority flow 1695 1 - normal priority flow 1696 2 - high priority flow 1697 255 - not used 1699 A reservation without an parameter (i.e., 1700 set to 255) MUST be treated as a reservation with an = 1. 1703 6.2.10 Parameter [RFC4412] 1705 The coding for the parameter is as follows: 1707 0 1 2 3 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 |M|E|0|r| 10 |r|r|r|r| 1 | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | RPH Namespace | RPH Priority | (Reserved) | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 [RFC4412] defines a resource priority header (RPH) with parameters 1716 "RPH Namespace" and "RPH Priority" combination, and if populated is 1717 applicable only to flows with high admission priority, as follows: 1719 RPH Namespace: 1721 0 - dsn 1722 1 - drsn 1723 2 - q735 1724 3 - ets 1725 4 - wps 1726 255 - not used 1728 RPH Priority: 1729 Each namespace has a finite list of relative priority-values. Each 1730 is listed here in the order of lowest priority to highest priority 1731 (note that dsn and drsn priority values are TBD): 1733 4 - q735.4 1734 3 - q735.3 1735 2 - q735.2 1736 1 - q735.1 1737 0 - q735.0 1739 4 - ets.4 1740 3 - ets.3 1741 2 - ets.2 1742 1 - ets.1 1743 0 - ets.0 1745 4 - wps.4 1746 3 - wps.3 1747 2 - wps.2 1748 1 - wps.1 1749 0 - wps.0 1751 Note that the parameter MAY be used in 1752 combination with the parameter, which depends on the 1753 supported QOSM. Furthermore, if more then one RPH namespace is 1754 supported by a QOSM, then the QOSM MUST specify how the mapping 1755 between the priorities belonging to the different RPH namespaces are 1756 mapped to each other. 1758 Note also that additional work is needed to communicate these flow 1759 priority values to bearer-level network elements 1760 [VERTICAL-INTERFACE]. 1762 For the 4 priority parameters, the following cases are permissible 1763 (procedures specified in references): 1765 1 parameter: [Y.1571] 1766 2 parameters: , [RFC4412] 1767 2 parameters: , [RFC3181] 1768 3 parameters: , , 1769 [3GPP-1, 3GPP-2, 3GPP-3] 1770 4 parameters: , , 1771 , [3GPP-1, 3GPP-2, 1772 3GPP-3] 1774 It is permissible to have without , but not permissible to have without 1776 (alternatively is ignored in 1777 instances without ). 1779 eMLPP-like functionality (as defined in [3GPP-1, 3GPP-2]) specifies 1780 use of corresponding to the 'queuing allowed' 1781 part of eMLPP as well as 1782 corresponding to the 'preemption capable' and 'may be preempted' 1783 parts of eMLPP. 1785 6.2.11 Parameter 1787 0 1 2 3 1788 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 |M|E|0|r| 11 |r|r|r|r| 1 | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Excess Trtmnt | Remark Value | Reserved | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 1796 traffic, that is, traffic not covered by the parameter. 1797 The excess treatment parameter is set by the QNI. It cannot be 1798 overwritten. Allowed values are as follows: 1800 0: drop 1801 1: shape 1802 2: remark 1803 3: no metering or policing is permitted 1805 The default excess treatment in case that none is specified is that 1806 there are no guarantees to excess traffic, i.e. a QNE can do whatever 1807 it finds suitable. 1809 When excess treatment is set to 'drop', all marked traffic MUST be 1810 dropped by the QNE/RMF. 1812 When excess treatment is set to 'shape', it is expected that the 1813 QoS Desired object carries a TMOD parameter. Excess traffic 1814 is to be shaped to this TMOD. When the shaping causes 1815 unbounded queue growth at the shaper traffic can be dropped. 1817 When excess treatment is set to 'remark', the excess treatment 1818 parameter MUST carry the remark value, and the remark values and 1819 procedures MUST be specified in the QOSM specification document. 1820 For example, packets may be remarked to drop remarked to pertain to a 1821 particular QoS class". In the latter case, remarking relates to a 1822 DiffServ-type model, where packets arrive marked as belonging to a 1823 certain QoS class, and when they are identified as excess, they 1824 should then be remarked to a different QoS Class. 1826 If 'no metering or policing is permitted' is signaled, the QNE should 1827 accept the excess treatment parameter set by the sender with special 1828 care so that excess traffic should not cause a problem. To request 1829 the Null Meter [RFC3290] is especially strong, and should be used 1830 with caution. 1832 A NULL metering application [RFC2997] would not include the traffic 1833 profile, and conceptually it should be possible to support this with 1834 the QSPEC. A QSPEC without a traffic profile is not excluded by the 1835 current specification. However, note that the traffic profile is 1836 important even in those cases when the excess treatment is not 1837 specified, e.g., in negotiating bandwidth for the best effort 1838 aggregate. However, a "NULL Service QOSM" would need to be specified 1839 where the desired QNE Behavior and the corresponding QSPEC format are 1840 described. 1842 As an example behavior for a NULL metering, in the properly 1843 configured DiffServ router, the resources are shared between the 1844 aggregates by the scheduling disciplines. Thus, if the incoming rate 1845 increases, it will influence the state of a queue within that 1846 aggregate, while all the other aggregates will be provided sufficient 1847 bandwidth resources. NULL metering is useful for best effort and 1848 signaling data, where there is no need to meter and police this data 1849 as it will be policed implicitly by the allocated bandwidth and, 1850 possibly, active queue management mechanism. 1852 6.2.12 Parameter [RFC3140] 1854 The coding for the parameter is as follows: 1856 0 1 2 3 1857 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 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 |M|E|0|r| 12 |r|r|r|r| 1 | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 1862 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1864 As prescribed in RFC 3140, the encoding for a single PHB is the 1865 recommended DSCP value for that PHB, left-justified in the 16 bit 1866 field, with bits 6 through 15 set to zero. 1868 The encoding for a set of PHBs is the numerically smallest of the set 1869 of encodings for the various PHBs in the set, with bit 14 set to 1. 1870 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 1871 bit 14 set to 1.) 1873 0 1 1874 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | DSCP |0 0 0 0 0 0 0 0 X 0| 1877 +---+---+---+---+---+---+---+---+ 1879 PHBs not defined by standards action, i.e., experimental or local use 1880 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 1881 identification code, assigned by the IANA, is placed left-justified 1882 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 1883 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 1885 0 1 1886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | PHD ID CODE |0 0 X 0| 1889 +---+---+---+---+---+---+---+---+ 1891 Bits 12 and 13 are reserved either for expansion of the PHB 1892 identification code, or for other use, at some point in the future. 1894 In both cases, when a single PHBID is used to identify a set of PHBs 1895 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 1896 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 1897 intra-microflow traffic reordering when different PHBs from the set 1898 are applied to traffic in the same microflow). The set of AF1x PHBs 1899 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs 1900 that do not constitute a PHB Scheduling Class can be identified by 1901 using more than one PHBID. 1903 The registries needed to use RFC 3140 already exist, see 1904 [DSCP-REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs 1905 to be created for this purpose. 1907 6.2.13 Parameter [RFC4124] 1909 The coding for the parameter is as follows: 1911 0 1 2 3 1912 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 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 |M|E|0|r| 13 |r|r|r|r| 1 | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 |DSTE Cls. Type | (Reserved) | 1917 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1918 DSTE Class Type: Indicates the DSTE class type. Values currently 1919 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 1920 that the parameter is not used. 1922 6.2.14 Parameter [Y.1541] 1924 The coding for the parameter is as follows: 1926 0 1 2 3 1927 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 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 |M|E|0|r| 14 |r|r|r|r| 1 | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 |Y.1541 QoS Cls.| (Reserved) | 1932 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1934 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 1935 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 1936 that the parameter is not used. 1938 Class 0: 1939 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1940 Real-time, highly interactive applications, sensitive to jitter. 1941 Application examples include VoIP, Video Teleconference. 1943 Class 1: 1944 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1945 Real-time, interactive applications, sensitive to jitter. 1946 Application examples include VoIP, Video Teleconference. 1948 Class 2: 1949 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 1950 10^-3. Highly interactive transaction data. Application examples 1951 include signaling. 1953 Class 3: 1954 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 1955 10^-3. Interactive transaction data. Application examples include 1956 signaling. 1958 Class 4: 1959 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 1960 10^-3. Low Loss Only applications. Application examples include 1961 short transactions, bulk data, video streaming. 1963 Class 5: 1964 Mean delay unspecified, delay variation unspecified, loss ratio 1965 unspecified. Unspecified applications. Application examples include 1966 traditional applications of default IP networks. 1968 Class 6: 1970 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1971 Applications that are highly sensitive to loss, such as television 1972 transport, high-capacity TCP transfers, and TDM circuit emulation. 1974 Class 7: 1975 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1976 Applications that are highly sensitive to loss, such as television 1977 transport, high-capacity TCP transfers, and TDM circuit emulation. 1979 7. Security Considerations 1981 The priority parameter raises possibilities for theft of service 1982 attacks because users could claim an emergency priority for their 1983 flows without real need, thereby effectively preventing serious 1984 emergency calls to get through. Several options exist for countering 1985 such attacks, for example 1987 - only some user groups (e.g. the police) are authorized to set the 1988 emergency priority bit 1990 - any user is authorized to employ the emergency priority bit for 1991 particular destination addresses (e.g. police) 1993 8. IANA Considerations 1995 This section defines the registries and initial codepoint assignments 1996 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 1997 It also defines the procedural requirements to be followed by IANA in 1998 allocating new codepoints. 2000 This specification creates the following registries with the 2001 structures as defined below: 2003 Object Types (12 bits): 2004 The following values are allocated by this specification: 2005 0-4: assigned as specified in Section 6: 2006 Object Type = 0: QoS Desired 2007 = 1: QoS Available 2008 = 2: QoS Reserved 2009 = 3: Minimum QoS 2010 The allocation policies for further values are as follows: 2011 5-63: Standards Action 2012 64-127: Private/Experimental Use 2013 128-4095: Reserved 2014 (Note: 'Reserved' just means 'do not give these out'.) 2016 QSPEC Version (4 bits): 2017 The following value is allocated by this specification: 2018 0: assigned to Version 0 QSPEC 2019 The allocation policies for further values are as follows: 2020 1-15: Standards Action 2021 A specification is required to depreciate, delete, or modify QSPEC 2022 versions. 2024 QSPEC Type (8 bits): 2025 The following values are allocated by this specification: 2026 0: Initiator QSPEC 2027 1: Local QSPEC 2028 The allocation policies for further values are as follows: 2029 2-63: Standards Action 2030 64-255: Reserved 2032 QSPEC Procedure (8 bits): 2033 Broken down into 2034 Message Sequence (4 bits): 2035 The following values are allocated by this specification: 2036 0-2: assigned as specified in Section 6.1: 2037 Message Sequence 0: 2038 Semantic: QSPEC Procedure = Sender-Initiated Reservations 2039 (see Section 5.3.1) 2040 Message Sequence 1: 2041 Semantic: QSPEC Procedure = Receiver-Initiated Reservations 2042 (see Section 5.3.2) 2043 Message Sequence 2: 2044 Semantic: QSPEC Procedure = Resource Queries (see Section 6.4.3) 2045 The allocation policies for further values are as follows: 2046 3-15: Standards Action 2047 Object Combination (4 bits): 2048 The following values are allocated by this specification: 2049 The Object Combination field can take the values between 2050 1 and 3 indicated in the tables in Section 6: 2051 Message Sequence: 0 2052 Object Combination: 1, 2, 3 2053 Semantic: see table in Section 5.3.1 2054 Message Sequence: 1 2055 Object Combination: 1, 2, 3 2056 Semantic: see table in Section 5.3.2 2057 Message Sequence: 2 2058 Object Combination: 1, 2, 3 2059 Semantic: see table in Section 5.3.3 2060 The allocation policies for further values are as follows: 2061 3-15: Standards Action 2062 A specification is required to depreciate, delete, or modify QSPEC 2063 Procedures. 2065 Error Code (16 bits) 2066 The allocation policies are as follows: 2067 0-127: Specification Required 2068 128-255: Private/Experimental Use 2069 255-65535: Reserved 2070 A specification is required to depreciate, delete, or modify Error 2071 Codes. 2073 Parameter ID (12 bits): 2074 The following values are allocated by this specification: 2075 1-14: assigned as specified in Section 6.2: 2076 Parameter ID 1: 2077 2: 2078 3: 2079 4: 2080 5: 2081 6: 2082 7: 2083 8: & 2084 9: 2085 10: 2086 11: 2087 12: 2088 13: 2089 14: 2091 The allocation policies for further values are as follows: 2092 15-63: Standards Action (for QSPEC parameters) 2093 64-127: Specification Required (for QSPEC parameters) 2094 128-255: Private/Experimental Use 2095 255-4095: Reserved 2097 A specification is required to depreciate, delete, or modify 2098 Parameter IDs. Note that if additional QSPEC parameters are 2099 defined in the future, this requires a standards action equivalent to 2100 reissuing this document as a QSPEC-bis. 2102 Admission Priority Parameter (8 bits): 2103 The following values are allocated by this specification: 2104 0-2: assigned as specified in Section 6.2.9: 2105 Admission Priority 0: best-effort priority flow 2106 1: normal priority flow 2107 2: high priority flow 2108 255: admission priority not used 2109 The allocation policies for further values are as follows: 2110 3-63: Standards Action 2111 64-254: Reserved 2113 RPH Namespace Parameter (16 bits): 2114 Note that [RFC4412] creates a registry for RPH Namespace and Priority 2115 values already (see Section 12.6 of [RFC4412]). A QSPEC registry is 2116 also created because the assigned values are being mapped to QSPEC 2117 parameter values. The following values are allocated by this 2118 specification: 2119 0-5: assigned as specified in Section 6.2.10: 2120 The allocation policies for further values are as follows: 2121 6-63: Standards Action 2122 64-65535: Reserved 2123 RPH Priority Parameter (8 bits): 2124 dsn namespace: 2125 The allocation policies are as follows: 2126 0-63: Standards Action 2127 64-255: Reserved 2128 drsn namespace: 2129 The allocation policies are as follows: 2130 0-63: Standards Action 2131 64-255: Reserved 2132 Q735 namespace: 2133 The following values are allocated by this specification: 2134 0-4: assigned as specified in Section 6.2.10: 2135 Q735 priority 4: q735.4 2136 3: q735.3 2137 2: q735.2 2138 1: q735.1 2139 0: q735.0 2140 The allocation policies for further values are as follows: 2141 5-63: Standards Action 2142 64-255: Reserved 2143 ets namespace: 2144 The following values are allocated by this specification: 2145 0-4: assigned as specified in Section 6.2.10: 2146 ETS priority 4: ets.4 2147 3: ets.3 2148 2: ets.2 2149 1: ets.1 2150 0: ets.0 2151 The allocation policies for further values are as follows: 2152 5-63: Standards Action 2153 64-255: Reserved 2154 wts namespace: 2155 The following values are allocated by this specification: 2156 0-4: assigned as specified in Section 6.2.10: 2157 WPS priority 4: wps.4 2158 3: wps.3 2159 2: wps.2 2160 1: wps.1 2161 0: wps.0 2162 The allocation policies for further values are as follows: 2163 5-63: Standards Action 2164 64-255: Reserved 2166 Excess Treatment Parameter (8 bits): 2167 The following values are allocated by this specification: 2168 0-3: assigned as specified in Section 6.2.11: 2169 Excess Treatment Parameter 0: drop 2170 1: shape 2171 2: remark 2172 3: no metering or policing is 2173 permitted 2174 The allocation policies for further values are as follows: 2175 4-63: Standards Action 2176 64-255: Reserved 2177 Remark Value (8 bits) 2178 The allocation policies are as follows: 2179 0-63: Specification Required 2180 64-127: Private/Experimental Use 2181 128-255: Reserved 2183 DSTE Class Type Parameter (8 bits): 2184 The following values are allocated by this specification: 2185 0-7: assigned as specified in Section 6.2.13: 2186 DSTE Class Type Parameter 0: DSTE Class Type 0 2187 1: DSTE Class Type 1 2188 2: DSTE Class Type 2 2189 3: DSTE Class Type 3 2190 4: DSTE Class Type 4 2191 5: DSTE Class Type 5 2192 6: DSTE Class Type 6 2193 7: DSTE Class Type 7 2194 The allocation policies for further values are as follows: 2195 8-63: Standards Action 2196 64-255: Reserved 2198 Y.1541 QoS Class Parameter (8 bits): 2199 The following values are allocated by this specification: 2200 0-7: assigned as specified in Section 6.2.14: 2201 Y.1541 QoS Class Parameter 0: Y.1541 QoS Class 0 2202 1: Y.1541 QoS Class 1 2203 2: Y.1541 QoS Class 2 2204 3: Y.1541 QoS Class 3 2205 4: Y.1541 QoS Class 4 2206 5: Y.1541 QoS Class 5 2207 6: Y.1541 QoS Class 6 2208 7: Y.1541 QoS Class 7 2209 The allocation policies for further values are as follows: 2210 8-63: Standards Action 2211 64-255: Reserved 2213 9. Acknowledgements 2215 The authors would like to thank (in alphabetical order) David Black, 2216 Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger 2217 Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, 2218 Chris Lang, Jukka Manner, An Nguyen, Dave Oran, Tom Phelan, James 2219 Polk, Alexander Sayenko, John Rosenberg, Bernd Schloer, Hannes 2220 Tschofenig, and Sven van den Bosch for their very helpful 2221 suggestions. 2223 10. Normative References 2225 [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd 2226 Generation Partnership Project; Technical Specification Group 2227 Services and System Aspects; enhanced Multi Level Precedence and 2228 Preemption service (eMLPP) - Stage 1 (Release 7). 2229 [3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd 2230 Generation Partnership Project; Technical Specification Group Core 2231 Network; enhanced Multi-Level Precedence and Preemption service 2232 (eMLPP) - Stage 2 (Release 7). 2233 [3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd 2234 Generation Partnership Project; Technical Specification Group Core 2235 Network; enhanced Multi-Level Precedence and Preemption service 2236 (eMLPP) - Stage 3 (Release 6). 2237 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 2238 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 2239 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 2240 Signaling Transport," work in progress. 2241 [QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service 2242 Signaling," work in progress. 2243 [RFC1832] Srinivasan, R., "XDR: External Data Representation 2244 Standard," RFC 1832, August 1995. 2245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2246 Requirement Levels", BCP 14, RFC 2119, March 1997. 2247 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2248 Services", RFC 2210, September 1997. 2249 [RFC2212] Shenker, S., et. al., "Specification of Guaranteed Quality 2250 of Service," September 1997. 2251 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 2252 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 2253 1997. 2254 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 2255 Services", RFC 2475, December 1998. 2256 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2257 Codes," June 2001. 2258 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element," 2259 RFC 3181, October 2001. 2260 [RFC3290] Bernet, Y., et. al., "An Informal Management Model for 2261 Diffserv Routers," RFC 3290, May 2002. 2262 [RFC4124] Le Faucheur, F., et. al., "Protocol Extensions for Support 2263 of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2005. 2264 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 2265 Priority for the Session Initiation Protocol(SIP)," RFC 4412, 2266 February 2006. 2267 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 2268 for IP-Based Services," February 2006. 2269 [Y.1571] ITU-T Recommendation Y.1571, "Admission Control Priority 2270 Levels in Next Generation Networks," July 2006. 2272 11. Informative References 2274 [DQOS] Cablelabs, "PacketCable Dynamic Quality of Service 2275 Specification," CableLabs Specification PKT-SP-DQOS-I12-050812, 2276 August 2005. 2277 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 2278 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 2279 754-1985, August 1985. 2280 [CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 2281 Controlled-Load Service with NSIS," work in progress. 2282 [NETWORK-BYTE-ORDER] Wikipedia, "Endianness," 2283 http://en.wikipedia.org/wiki/Endianness. 2284 [NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work 2285 in progress. 2286 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 2287 Protocol - Capability Set 3" Sep. 2003 2288 [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 2289 -- Version 1 Functional Specification," RFC 2205, September 1997. 2290 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 2291 IANA Considerations Section in RFCs," RFC 3181, October 1998. 2292 [RFC2474] Nichols, K., et. al., "Definition of the Differentiated 2293 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 2294 December 1998. 2295 [RFC2597] Heinanen, J., et. al., "Assured Forwarding PHB Group," RFC 2296 2597, June 1999. 2297 [RFC2997] Bernet, Y., et. al., "Specification of the Null Service 2298 Type," RFC 2997, November 2000. 2299 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2300 Codes," RFC 3140, June 2001. 2301 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 2302 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 2303 [RFC3564] Le Faucheur, F., et. al., Requirements for Support of 2304 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 2305 July 2003 2306 [RFC3726] Brunner, M., et. al., "Requirements for Signaling 2307 Protocols", RFC 3726, April 2004. 2308 [RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management 2309 in Diffserv QOS Model," work in progress. 2310 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 2311 on Associating of Control Signaling Messages with Media Priority 2312 Levels," T1S1.7 & PRQC, October 2004. 2313 [WROCLAWSKI] Wroclawski, J., TBD. 2314 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 2315 Communication Service - IP Packet Transfer and Availability 2316 Performance Parameters," December 2002. 2317 [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 2318 Networks Using Y.1541 QoS Classes," work in progress. 2320 12. Authors' Addresses 2322 Gerald Ash (Editor) 2323 AT&T 2324 Room MT D5-2A01 2325 200 Laurel Avenue 2326 Middletown, NJ 07748, USA 2327 Phone: +1-(732)-420-4578 2328 Fax: +1-(732)-368-8659 2329 Email: gash@att.com 2331 Attila Bader (Editor) 2332 Traffic Lab 2333 Ericsson Research 2334 Ericsson Hungary Ltd. 2335 Laborc u. 1 H-1037 2336 Budapest Hungary 2337 Email: Attila.Bader@ericsson.com 2339 Cornelia Kappler (Editor) 2340 Siemens GmbH&Co KG 2341 Siemensdamm 62 2342 Berlin 13627 2343 Germany 2344 Email: cornelia.kappler@siemens.com 2346 David R. Oran (Editor) 2347 Cisco Systems, Inc. 2348 7 Ladyslipper Lane 2349 Acton, MA 01720, USA 2350 Email: oran@cisco.com 2352 Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved of 2353 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 2355 The union of QoS Desired, QoS Available and QoS Reserved can provide 2356 all functionality of the objects specified in RSVP IntServ, however 2357 it is difficult to provide an exact mapping. 2359 In RSVP, the Sender TSpec specifies the traffic an application is 2360 going to send (e.g. TMOD). The AdSpec can collect path 2361 characteristics (e.g. delay). Both are issued by the sender. The 2362 receiver sends the FlowSpec which includes a Receiver TSpec 2363 describing the resources reserved using the same parameters as the 2364 Sender TSpec, as well as a RSpec which provides additional IntServ 2365 QoS Model specific parameters, e.g. Rate and Slack. 2367 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 2368 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 2369 knowledge of the authors it is not possible for the sender to specify 2370 a desired maximum delay except implicitly and mutably by seeding the 2371 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 2372 the receiver-issued RSVP RESERVE message. For this reason our 2373 discussion at this point leads us to a slightly different mapping of 2374 necessary functionality to objects, which should result in more 2375 flexible signaling models. 2377 Appendix B. Change History & Open Issues 2379 B.1 Change History (since Version -04) 2381 Version -05: 2383 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 2384 - discarded QSPEC parameter (Maximum packet size) since MTU 2385 discovery is expected to be handled by procedure currently defined 2386 by PMTUD WG 2387 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 2388 efficiency 2389 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 2390 - revised Section 6.2.2 on SIP priorities 2391 - added QSPEC procedures for "RSVP-style reservation", resource 2392 queries and bidirectional reservations in Sec. 7.1 2393 - reworked Section 7.2 2395 Version -06: 2397 - defined "not-supported flag" and "tunneled parameter flag" 2398 (subsumes "QSPEC parameter flag") 2399 - defined "error flag" for error handling 2400 - updated bit error rate (BER) parameter to packet loss ratio (PLR) 2401 parameter 2402 - added packet error ratio (PER) parameter 2403 - coding checked by independent expert 2404 - coding updated to include RE flags in QSPEC objects and MENT flags 2405 in QSPEC parameters 2407 Version -07: 2409 - added text (from David Black) on DiffServ QSPEC example in Section 2410 6 2411 - re-numbered QSPEC parameter IDs to start with 0 (Section 7) 2412 - expanded IANA Considerations Section 9 2414 Version -08: 2416 - update to 'RSVP-style' reservation in Section 6.1.2 to mirror what 2417 is done in RSVP 2418 - modified text (from David Black) on DiffServ QSPEC example in 2419 Section 6.2 2420 - update to general QSPEC parameter formats in Section 7.1 (length 2421 restrictions, etc.) 2422 - re-numbered QSPEC parameter IDs in Section 7.2 2423 - modified parameter values in Section 7.2.2 2424 - update to reservation priority Section 7.2.7 2425 - specify the 3 "STATS" in the parameter, Section 2426 7.2.9.4 2427 - minor updates to IANA Considerations Section 9 2429 Version -09: 2431 - remove the DiffServ example in Section 6.2 (intent is use text as a 2432 basis for a separate DIFFSERV-QOSM I-D) 2433 - update wording in example in Section 4.3, to reflect use of default 2434 QOSM and QOSM selection by QNI 2435 - make minor changes to Section 7.2.7.2, per the exchange on the list 2436 - add comment on error codes, after the first paragraph in Section 2437 4.5.1 2439 Version -10: 2441 - rewrote Section 2.0 for clarity 2442 - added clarifications on QSPEC parameters in Section 4.2; added 2443 discussion of forwarding options when a domain supports a different 2444 QOSM than the QNI 2445 - expanded Section 4.5 on error code handling, including redefined 2446 E-Flag and editorial changes to the N-Flag and T-Flag discussions 2447 - made some editorial clarifications in Section 4.6 on defining new 2448 mandatory (QSPEC) parameters, and also reference the 2449 [NSIS-EXTENSIBILITY] document 2450 - Section 4.7 added to identify what a QOSM specification document 2451 must include 2452 - clarified the requirements in Section 5.0 for defining a new QSPEC 2453 Version 2454 - made editorial changes to Section 6, and added procedures for 2455 handling preemption 2456 - removed QOSM ID assignments in Section 9.0; clarified procedures 2457 for defining new QSPEC parameters; added registry of QOSM error 2458 codes 2460 Version -11: 2462 - 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter' 2463 - 'QSPEC-2 parameter' replaces 'optional QSPEC parameter' 2464 - R-flag ('remapped parameter flag') introduced to denote remapping, 2465 approximating, or otherwise not strictly interpreting a QSPEC 2466 parameter 2467 - T-flag ('tunneled parameter flag') eliminated and incorporated 2468 within the R-flag 2469 - Section 4 rewritten on QOSM concept, QSPEC processing, etc. to 2470 provide a more logical flow of information 2471 - read-write/read-only flag associated with QSPEC objects eliminated 2472 and object itself defined as rw or ro without a flag 2473 - parameter redefined as non-QOSM-hop Q-flag 2474 - Section 7 on QSPEC parameter definitions revised to clearly 2475 separate QSPEC parameter coding from QSPEC parameter coding 2477 - , , and QSPEC parameters mapped 2478 to container parameters 2479 - references updated to include normative references defining 2480 procedures to 'strictly interpret' each QSPEC parameter 2481 - Section 7.2.1 on PHB class updated to specify additional RFC 3140 2482 cases 2483 - Section 7.2.1 on excess treatment updated to specify excess 2484 treatment behaviors 2486 Version -12: 2488 - Sections 4, 5, 6: Many editorial changes and rearrangements 2489 - Moved example of QSPEC processing to Appendix A 2490 - Section 7.2.2: Changed from a variable 2491 length to a fixed length parameter 2493 Version -13: 2495 - notion of QOSMs played down 2496 o language e.g. 'QNSLP/QSPEC can signal for different QOSMs across 2497 multiple domains' replaced by notion that 'QNSLP/QSPEC allows 2498 QNEs on the path to implement different data plane QoS mechanisms 2499 that meet QSPEC constraints' 2500 o a QOSM describes common capabilities among QNEs to act 2501 consistently when requested to admit traffic & in treating 2502 admitted traffic 2503 o a QOSM ID need not be defined or signaled 2504 o a QNE need not support any particular QOSM although a QNI 2505 normally includes a QSPEC corresponding to a particular QOSM 2506 - a 'QOSM specification' 2507 o still provides a rigorous specification of a QOSM & what it does 2508 o documents how a QNE interprets & treats various elements in QSPEC 2509 o can define additional QSPEC parameters 2510 - updated QOSM definition: 2511 a method to achieve QoS for a traffic flow, e.g., IntServ 2512 Controlled Load; specifies what sub-set of QSPEC QoS constraints & 2513 traffic handling directives a QNE implementing that QOSM is capable 2514 of supporting & how resources will be managed by the RMF 2515 - QSPEC1/QSPEC2 semantics replaced with following semantics: 2516 o source traffic description (mandatory to include by QNI & 2517 mandatory to interpret by downstream QNEs) 2518 > specified by traffic model (TMOD-1) parameter consisting of 2519 rate (r), bucket size (b), peak rate (p), minimum policed unit 2520 (m) (mathematically complete way to describe traffic source) 2521 > bandwidth only set r=p; b/m to large values (separate 2522 bandwidth parameter not needed) 2523 > TMOD-2 (optional to include) 2524 o constraints (optional to include): 2525 > Path Latency 2526 > Path Jitter 2527 > Path PLR 2528 > Path PER 2529 > Slack Term 2530 > Priority (Preemption, Defending, Admission, RPH Priority) 2531 o handling directives (optional to include): 2532 > Excess Treatment 2533 o traffic classifiers (optional to include): 2534 > PHB Class (PHB class set by downstream QNE to tell QNI how to 2535 mark traffic to ensure treatment committed by admission 2536 control) 2537 > DSTE Class Type 2538 > Y.1541 QoS class 2539 o eliminated: 2540 > Bandwidth 2541 > Ctot, Dtot, Csum, Dsum 2542 - concept of remapping QSPEC parameters eliminated 2543 - redefine 'interpret' a QSPEC parameter to mean 'must conform to 2544 RFCs defining parameter & procedures (formerly called 'strictly 2545 interpret') 2546 - concept of local QSPECs retained 2547 o allows simpler control plane in a local domain 2548 o edge nodes 2549 > must interpret initiator QSPEC parameters 2550 > can either initiate parallel session with local QSPEC or 2551 define a local QSPEC with encapsulated initiator QSPEC 2552 o local QSPEC interpreted by local domain QNEs 2553 o local QSPEC must be consistent with initiator QSPEC 2554 > e.g., RMD can initiate a local QSPEC that contains TMOD = 2555 bandwidth (sets r=p, b/m to large) 2556 - QSPEC flags modified as follows: 2557 o QNI sets M flag for each QSPEC parameter it populates that must 2558 be interpreted or reservation fails 2559 o if M flag set 2560 > downstream QNE MUST interpret parameter or reservation fails 2561 > if QNE does not support parameter it sets N flag & rejects 2562 reservation 2563 > if QNE supports parameter but cannot meet parameter, it sets E 2564 flag & rejects reservation 2565 o if M flag not set 2566 > downstream QNE SHOULD interpret parameter 2567 > if QNE does not support parameter it sets the N flag & 2568 optionally accepts or rejects reservation 2569 > if QNE supports parameter but cannot meet parameter, it sets E 2570 flag & optionally accepts or rejects reservation 2571 o R (remapped parameter) flag & Q (non QOSM) flag eliminated 2573 B.2 Open Issues 2575 None. 2577 Intellectual Property Statement 2579 The IETF takes no position regarding the validity or scope of any 2580 Intellectual Property Rights or other rights that might be claimed to 2581 pertain to the implementation or use of the technology described in 2582 this document or the extent to which any license under such rights 2583 might or might not be available; nor does it represent that it has 2584 made any independent effort to identify any such rights. Information 2585 on the procedures with respect to rights in RFC documents can be 2586 found in BCP 78 and BCP 79. 2588 Copies of IPR disclosures made to the IETF Secretariat and any 2589 assurances of licenses to be made available, or the result of an 2590 attempt made to obtain a general license or permission for the use of 2591 such proprietary rights by implementers or users of this 2592 specification can be obtained from the IETF on-line IPR repository at 2593 http://www.ietf.org/ipr. 2595 The IETF invites any interested party to bring to its attention any 2596 copyrights, patents or patent applications, or other proprietary 2597 rights that may cover technology that may be required to implement 2598 this standard. Please address the information to the IETF at 2599 ietf-ipr@ietf.org. 2601 Full Copyright Statement 2603 Copyright (C) The IETF Trust (2006). 2605 This document is subject to the rights, licenses and restrictions 2606 contained in BCP 78, and except as set forth therein, the authors 2607 retain all their rights. 2609 This document and the information contained herein are provided on an 2610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2612 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2613 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2614 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.