idnits 2.17.1 draft-ietf-nsis-qspec-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 27, 2010) is 5200 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Internet Draft NSIS Working Group G. Ash 2 Internet Draft AT&T 3 Intended status: Experimental A. Bader 4 Ericsson 5 Expiration Date: July 2010 C. Kappler 6 deZem GmbH 7 D. Oran 8 Cisco Systems, Inc. 9 January 27, 2010 11 QoS NSLP QSPEC Template 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 27, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the BSD License. 51 Abstract 53 The QoS NSLP protocol is used to signal QoS reservations and is 54 independent of a specific QoS model (QOSM) such as IntServ or 55 DiffServ. Rather, all information specific to a QOSM is encapsulated 56 in a separate object, the QSPEC. This document defines a template 57 for the QSPEC including a number of QSPEC parameters. The QSPEC 58 parameters provide a common language to be re-used in several QOSMs 59 and thereby aim to ensure the extensibility and interoperability of 60 QoS NSLP. While the base protocol is QOSM-agnostic, the parameters 61 that can be carried in the QSPEC object are possibly closely coupled 62 to specific models. The node initiating the NSIS signaling adds an 63 initiator QSPEC, which indicates the QSPEC parameters that must be 64 interpreted by the downstream nodes less the reservation fails, 65 thereby ensuring the intention of the NSIS initiator is preserved 66 along the signaling path. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. QSPEC Framework . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.2 QSPEC Objects . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.3 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 9 76 3.3.1 Traffic Model Parameter . . . . . . . . . . . . . . . 10 77 3.3.2 Constraints Parameters . . . . . . . . . . . . . . . 12 78 3.3.3 Traffic Handling Directives . . . . . . . . . . . . . 14 79 3.3.4 Traffic Classifiers . . . . . . . . . . . . . . . . . 14 80 3.4 Example of QSPEC Processing . . . . . . . . . . . . . . . . 15 81 4. QSPEC Processing & Procedures . . . . . . . . . . . . . . . . . 17 82 4.1 Local QSPEC Definition & Processing . . . . . . . . . . . . 18 83 4.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 84 Notification . . . . . . . . . . . . . . . . . . . . . . . 20 85 4.2.1 Reservation Failure & Error E Flag . . . . . . . . . 21 86 4.2.2 QSPEC Parameter Not Supported N Flag . . . . . . . . 22 87 4.2.3 INFO_SPEC Coding of Reservation Outcome . . . . . . . 22 88 4.2.4 QNE Generation of a RESPONSE message . . . . . . . . 23 89 4.2.5 Special Case of Local QSPEC . . . . . . . . . . . . . 24 90 4.3 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 24 91 4.3.1 Two-Way Transactions . . . . . . . . . . . . . . . . 24 92 4.3.2 Three-Way Transactions . . . . . . . . . . . . . . . 26 93 4.3.3 Resource Queries . . . . . . . . . . . . . . . . . . 28 94 4.3.4 Bidirectional Reservations . . . . . . . . . . . . . 28 95 4.3.5 Preemption . . . . . . . . . . . . . . . . . . . . . 29 96 4.4 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 29 97 5. QSPEC Functional Specification . . . . . . . . . . . . . . . . 30 98 5.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 30 99 5.1.1 Common Header Format . . . . . . . . . . . . . . . . 30 100 5.1.2 QSPEC Object Header Format . . . . . . . . . . . . . 32 101 5.2 QSPEC Parameter Coding . . . . . . . . . . . . . . . . . . 33 102 5.2.1 Parameter . . . . . . . . . . . . . . . . . 33 103 5.2.2 Parameter . . . . . . . . . . . . . . . . . 34 104 5.2.3 Parameter . . . . . . . . . . . . . . 34 105 5.2.4 Parameter . . . . . . . . . . . . . . . 35 106 5.2.5 Parameter . . . . . . . . . . . . . . . . 36 107 5.2.6 Parameter . . . . . . . . . . . . . . . . 37 108 5.2.7 Parameter . . . . . . . . . . . . . . . 38 109 5.2.8 & Para. . 38 110 5.2.9 Parameter . . . . . . . . . . . 38 111 5.2.10 Parameter . . . . . . . . . . . . . . 39 112 5.2.11 Parameter . . . . . . . . . . . . 40 113 5.2.12 Parameter . . . . . . . . . . . . . . . 42 114 5.2.13 Parameter . . . . . . . . . . . . 43 115 5.2.14 Parameter . . . . . . . . . . . . 44 116 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 45 117 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 118 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 119 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49 120 10. Normative References . . . . . . . . . . . . . . . . . . . . . 50 121 11. Informative References . . . . . . . . . . . . . . . . . . . . 52 122 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54 123 Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved 124 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 54 125 Appendix B. Example of TMOD Parameter Encoding . . . . . . . . . . 55 127 Conventions Used in This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 1. Introduction 135 The QoS NSIS signaling layer protocol (NSLP) [QoS-NSLP] is used to 136 signal QoS reservations for a data flow, provide forwarding 137 resources (QoS) for that flow, and establish and maintain state at 138 nodes along the path of the flow. The design of QoS NSLP is 139 conceptually similar to the decoupling between RSVP [RFC2205] and 140 the IntServ architecture [RFC2210], where a distinction is made 141 between the operation of the signaling protocol and the information 142 required for the operation of the Resource Management Function (RMF). 143 [QoS-NSLP] describes the signaling protocol, while this document 144 describes the RMF-related information carried in the QSPEC (QoS 145 Specification) object carried in QoS NSLP messages. 147 [QoS-NSLP] defines four QoS NSLP messages - RESERVE, QUERY, RESPONSE, 148 and NOTIFY - each of which may carry the QSPEC object, while this 149 document describes a template for the QSPEC object. The QSPEC object 150 carries information on traffic descriptions, resources required, 151 resources available, and other information required by the RMF. 152 Therefore the QSPEC template described in this document is closely 153 tied to QoS NSLP and the reader should to be familiar with [QoS-NSLP] 154 to fully understand this document. 156 A QoS-enabled domain supports a particular QoS model (QOSM), which is 157 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 158 provisioning methods and a QoS architecture, and defines the behavior 159 of the RMF that reserves resources for each flow, including inputs 160 and outputs. The QoS NSLP protocol is able to signal QoS 161 reservations for different QOSMs, wherein all information specific to 162 a QOSM is encapsulated in the QSPEC object and only the RMF specific 163 to a given QOSM will need to interpret the QSPEC. Examples of QOSMs 164 are IntServ, DiffServ admission control, and those specified in 165 [Y.1541-QOSM, CL-QOSM, RMD-QOSM]. 167 QSPEC parameters include, for example, a mandatory traffic model 168 (TMOD) parameter, constraints parameters, such as path latency and 169 path jitter, traffic handling directives, such as excess treatment, 170 and traffic classifiers such as PHB class. While the base protocol 171 is QOSM-agnostic, the parameters that can be carried in the QSPEC 172 object are possibly closely coupled to specific models. 174 QSPEC objects loosely correspond to the TSpec, RSpec and AdSpec 175 objects specified in RSVP and may contain, respectively, a 176 description of QoS desired, QoS reserved, and QoS available. 177 Going beyond RSVP functionality, the QSPEC also allows indicating 178 a range of acceptable QoS by defining a QSPEC object denoting 179 minimum QoS. Usage of these QSPEC objects is not bound to particular 180 message types thus allowing for flexibility. A QSPEC object 181 collecting information about available resources may travel in any 182 QoS NSLP message, for example a QUERY message or a RESERVE message, 183 as defined in [QoS-NSLP]. The QSPEC travels in QoS NSLP messages but 184 is opaque to the QoS NSLP, and is only interpreted by the RMF. 186 Interoperability between QoS NSIS entities (QNEs) in different 187 domains is enhanced by the definition of a common set of QSPEC 188 parameters. A QoS NSIS initiator (QNI) initiating the QoS NSLP 189 signaling adds an initiator QSPEC object containing parameters 190 describing the desired QoS, normally based on the QOSM it supports. 191 QSPEC parameters flagged by the QNI must be interpreted by all QNEs 192 in the path, else the reservation fails. In contrast, QSPEC 193 parameters not flagged by the QNI may be skipped if not understood. 194 Additional QSPEC parameters can be defined by informational 195 specification documents, and thereby ensure the extensibility and 196 flexibility of QoS NSLP. 198 A local QSPEC can be defined in a local domain with the initiator 199 QSPEC encapsulated, where the local QSPEC must be functionally 200 consistent with the initiator QSPEC in terms of defined source 201 traffic and other constraints. That is, a domain specific local 202 QSPEC can be defined and processed in a local domain, which could, 203 for example, can enable simpler processing by QNEs within the local 204 domain. 206 In Section 3.4 an example of QSPEC processing is provided. 208 2. Terminology 210 Initiator QSPEC: The initiator QSPEC is included into 211 a QoS NSLP message by the QNI/QNR. It travels end-to-end to the 212 QNR/QNI and is never removed. 214 Local QSPEC: A local QSPEC is used in a local domain 215 and is domain specific. It encapsulates the initiator QSPEC and is 216 removed at the egress of the local domain. 218 Minimum QoS: QSPEC object that, together with a description of QoS 219 Desired or QoS Available, allows the QNI to specify a QoS range, 220 i.e. an upper and lower bound. If the QoS Desired cannot be 221 reserved, QNEs are going to decrease the reservation until the 222 minimum QoS is hit. Note that the term "minimum" is used 223 generically, since for some parameters, such as loss rate and 224 latency, what is specified is the maximum acceptable value. 226 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 228 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 230 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 232 QoS Available: QSPEC object containing parameters describing the 233 available resources. They are used to collect information along a 234 reservation path. 236 QoS Desired: QSPEC object containing parameters describing the 237 desired QoS for which the sender requests reservation. 239 QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., 240 IntServ Controlled Load; specifies what sub-set of QSPEC QoS 241 constraints & traffic handling directives a QNE implementing that 242 QOSM is capable of supporting & how resources will be managed by the 243 RMF. 245 QoS Reserved: QSPEC object containing parameters describing the 246 reserved resources and related QoS parameters. 248 QSPEC: QSPEC is the object of QoS NSLP containing all QoS-specific 249 information. 251 QSPEC parameter: Any parameter appearing in a QSPEC; for 252 example, traffic model (TMOD), path latency, and excess treatment 253 parameters. 255 QSPEC Object: Main building blocks containing a QSPEC parameter set 256 that is input or output of an RMF operation. 258 QSPEC Type: Identifies a particular QOSM used in the QSPEC 260 Resource Management Function (RMF): Functions that are related to 261 resource management and processing of QSPEC parameters. 263 3. QSPEC Framework 265 The overall framework for the QoS NSLP is that [QoS-NSLP] defines QoS 266 signaling and semantics, the QSPEC template defines the container and 267 semantics for QoS parameters and objects, and informational 268 specifications define QoS methods and procedures for using QoS 269 signaling and QSPEC parameters/objects within specific QoS 270 deployments. QoS NSLP is a generic QoS signaling protocol that can 271 signal for many QOSMs. 273 3.1 QoS Models 275 A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ 276 controlled load [CL-QOSM], resource management with DiffServ 277 [RMD-QOSM], and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM]. 278 A QOSM specifies a set of QSPEC parameters that describe the QoS 279 desired and how resources will be managed by the RMF. The RMF 280 implements functions that are related to resource management and 281 processes the QSPEC parameters. 283 QOSMs affect the operation of the RMF in NSIS-capable nodes, the 284 information carried in QSPEC objects, and may under some 285 circumstances (e.g. aggregation) cause a separate NSLP session to be 286 instantiated by having the RMF as a QNI. QOSM specifications may 287 define RMF triggers that cause the QoS NSLP to run semantics within 288 the underlying QoS NSLP signaling state and messaging processing 289 rules, as defined in Section 5.2 of [QoS-NSLP]. New QoS NSLP message 290 processing rules can only be defined in extensions to QoS NSLP. If a 291 QOSM specification defines triggers that deviate from existing QoS 292 NSLP processing rules, the fallback for QNEs not supporting that QOSM 293 are the QoS NSLP state transition/message processing rules. 295 The QOSM specification includes how the requested QoS resources will 296 be described and how they will be managed by the RMF. For this 297 purpose, the QOSM specification defines a set of QSPEC parameters it 298 uses to describe the desired QoS and resource control in the RMF, and 299 it may define additional QSPEC parameters. 301 When a QoS NSLP message travels through different domains, it may 302 encounter different QOSMs. Since QOSM use different QSPEC parameters 303 for describing resources, the QSPEC parameters included by the QNI 304 may not be understood in other domains. The QNI therefore can flag 305 those QSPEC parameters it considers vital with the M flag. QSPEC 306 parameters with the M flag set must be interpreted by the downstream 307 QNEs, or the reservation fails. QSPEC parameters without the M flag 308 set should be interpreted by the downstream QNEs, but may be ignored 309 if not understood. 311 A QOSM specification SHOULD include the following: 312 - role of QNEs, e.g., location, frequency, statefulness, etc. 313 - QSPEC definition including QSPEC parameters 314 - QSPEC procedures applicable to this QOSM 315 - QNE processing rules describing how QSPEC information is treated 316 and interpreted in the RMF, e.g., admission control, scheduling, 317 policy control, QoS parameter accumulation (e.g., delay). 318 - at least one bit-level QSPEC example 319 - QSPEC parameter behavior for new QSPEC parameters the QOSM 320 specification defines 321 - define what happens in case of preemption if the default QNI 322 behavior (tear down preempted reservation) is not followed (see 323 Section 4.3.5) 325 A QOSM specification MAY include the following: 327 - define additional QOSM-specific error codes, as discussed in 328 Section 4.2.3 329 - can state which QoS-NSLP options a QOSM wants to use, when 330 several options are available for a QOSM (e.g., local QSPEC to 331 either a) hide initiator QSPEC within a local domain message, or 332 b) encapsulate initiator QSPEC). 334 QOSMs are free, subject to IANA registration and review rules, to 335 extend QSPECs by adding parameters of any of the kinds supported by 336 the QSPEC. This includes traffic description parameters, 337 constraint parameters and traffic handling directives. QOSMs are not 338 permitted, however, to reinterpret or redefine the QSPEC 339 parameters specified in this document. Note that signaling 340 functionality is only defined by the QoS NSLP document [QoS-NSLP] and 341 not by this document or by QOSM specification documents 343 3.2 QSPEC Objects 345 The QSPEC is the object of QoS NSLP containing QSPEC objects and 346 parameters. QSPEC objects are the main building blocks of the QSPEC 347 parameter set that is input or output of an RMF operation. QSPEC 348 parameters are the parameters appearing in a QSPEC, which must 349 include the traffic model parameter (TMOD), and may optionally 350 include constraints (e.g., path latency), traffic handling directives 351 (e.g., excess treatment), and traffic classifiers (e.g., PHB class). 352 The RMF implements functions that are related to resource management 353 and processes the QSPEC parameters. 355 The QSPEC consists of a QSPEC version number and QSPEC objects. IANA 356 assigns a new QSPEC version number when the current version is 357 deprecated or deleted (as required by a specification). Note that a 358 new QSPEC version number is not needed when new QSPEC parameters are 359 specified. Later QSPEC versions MUST be backward compatible with 360 earlier QSPEC versions. That is, a version n+1 device must support 361 QSPEC version n (or earlier). On the other hand, if a QSPEC version 362 n (or earlier) device receives an NSLP message specifying QSPEC 363 version n+1, then the version n device responds with an 'Incompatible 364 QSPEC' error code (0x0f) response, as discussed in Section 4.2.3, 365 allowing the QNE that sent the NSLP message to retry with a lower 366 QSPEC version. 368 This document provides a template for the QSPEC in order to promote 369 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 370 is composed of up to four QSPEC objects, namely QoS Desired, QoS 371 Available, QoS Reserved and Minimum QoS. Each of these QSPEC objects 372 consists of a number of QSPEC parameters. A given QSPEC may contain 373 only a subset of the QSPEC objects, e.g. QoS Desired. The QSPEC 374 objects QoS Desired, QoS Available, QoS Reserved and Minimum QoS MUST 375 all be supported by QNEs and MAY appear in any QSPEC object carried 376 in any QoS NSLP message (RESERVE, QUERY, RESPONSE, NOTIFY). See 377 [QoS-NSLP] for descriptions of the QoS NSLP RESERVE, QUERY, RESPONSE, 378 and NOTIFY messages. 380 +---------------------------------------+ 381 | QSPEC Objects | 382 +---------------------------------------+ 384 \________________ ______________________/ 385 V 386 +----------+----------+---------+-------+ 387 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| 388 +----------+----------+---------+-------+ 390 \____ ____/\___ _____/\___ ____/\__ ___/ 391 V V V V 393 +-------------+... +-------------+... 394 |QSPEC Para. 1| |QSPEC Para. n| 395 +-------------+... +-------------+... 397 Figure 1: Structure of the QSPEC 399 Use of the 4 QSPEC objects QoS Desired, QoS Available, QoS Reserved 400 and Minimum QoS is described in Section 4.3 for 3 message sequences 401 and 7 object combinations. 403 The QoS Desired Object describe the resources the QNI desires to 404 reserve and hence this is a read-only QSPEC object in that the QSPEC 405 parameters carried in the object may not be overwritten. QoS Desired 406 is always included in a RESERVE message and sometimes included in the 407 QUERY message (see Section 4.3 for details). 409 As described in Section 4.3, the QoS Available Object may travel in a 410 RESERVE message, RESPONSE Message, or QUERY message and may collect 411 information on the resources currently available on the path. In 412 this case, QoS Available is a read-write object, which means the 413 QSPEC parameters contained in QoS Available may be updated, but they 414 cannot be deleted. As such, each QNE MUST inspect all parameters of 415 this QSPEC object, and if resources available to this QNE are less 416 than what a particular parameter says currently, the QNE MUST adapt 417 this parameter accordingly. Hence when the message arrives at the 418 recipient of the message, reflects the bottleneck of 419 the resources currently available on a path. It can be used in a 420 QUERY message, for example, to collect the available resources along 421 a data path. 423 When QoS Available travels in a RESPONSE message, it in fact just 424 transports the result of a previous measurement performed by a 425 RESERVE or QUERY message back to the initiator. Therefore in this 426 case, QoS Available is read-only. In one other instance described 427 in Section 4.3.2 (Case 3), QoS Available is sent by the QNI in a 428 RESERVE message as a read-only QSPEC object (see Section 4.3.2 for 429 details). 431 The QoS Reserved object reflects the resources that are being 432 reserved. It is a read-only object and is always included in a 433 RESPONSE message if QoS Desired is included in the RESERVE message 434 (see Section 4.3 for details). 436 Minimum QoS does not have an equivalent in RSVP. It allows the QNI 437 to define a range of acceptable QoS levels by including both the 438 desired QoS value and the minimum acceptable QoS in the same message. 439 Note that the term "minimum" is used generically, since for some 440 parameters, such as loss rate and latency, what is specified is the 441 maximum acceptable value. It is a read-only object, and may be 442 included in a RESERVE message, RESPONSE message, or QUERY message 443 (see Section 4.3 for details). The desired QoS is included with a 444 QoS Desired and/or a QoS Available QSPEC object seeded to the desired 445 QoS value. The minimum acceptable QoS value MAY be coded in the 446 Minimum QoS QSPEC object. As the message travels towards the QNR, 447 QoS Available is updated by QNEs on the path. If its value drops 448 below the value of Minimum QoS the reservation fails and is aborted. 449 When this method is employed, the QNR signals back to the QNI the 450 value of QoS Available attained in the end, because the reservation 451 may need to be adapted accordingly (see Section 4.3 for details). 453 Note that the relationship of QSPEC objects to RSVP objects is 454 covered in Appendix A. 456 3.3 QSPEC Parameters 458 QSPEC parameters provide a common language for building QSPEC 459 objects. This document defines a number of QSPEC parameters, 460 additional parameters may be defined in separate QOSM specification 461 documents. For example, QSPEC parameters are defined in [RMD-QOSM] 462 and [Y.1541-QOSM]. 464 One QSPEC parameter, , is special. It provides a description 465 of the traffic for which resources are reserved. This parameter must 466 be included by the QNI and it must be interpreted by all QNEs. All 467 other QSPEC parameters are populated by a QNI if they are applicable 468 to the underlying QoS desired. For these QSPEC parameters, the QNI 469 sets the M flag if they must be interpreted by downstream QNEs. If 470 QNEs cannot interpret the parameter the reservation fails. QSPEC 471 parameters populated by a QNI without the M flag set should be 472 interpreted by downstream QNEs, but may be ignored if not understood. 474 In this document the term 'interpret' means, in relation to RMF 475 processing of QSPEC parameters, that the RMF processes the QSPEC 476 parameter according to the commonly accepted normative procedures 477 specified by references given for each QSPEC parameter. Note that a 478 QNE need only interpret a QSPEC parameter if it is populated in the 479 QSPEC object by the QNI; if not populated in the QSPEC, the QNE does 480 not interpret it of course. 482 Note that when an ingress QNE in a local domain defines a local QSPEC 483 and encapsulates the initiator QSPEC, the QNEs in the interior local 484 domain need only process the local QSPEC and can ignore the initiator 485 (encapsulated) QSPEC. However, edge QNEs in the local domain indeed 486 must interpret the QSPEC parameters populated in the initiator QSPEC 487 with the M flag set and should interpret QSPEC parameters populated 488 in the initiator QSPEC without the M flag set 490 As described in the previous section, QoS parameters may be 491 overwritten depending on which QSPEC object, and which message, they 492 appear in. 494 3.3.1 Traffic Model Parameter 496 The (TMOD) parameter is mandatory for the QNI to 497 include in the initiator QSPEC and mandatory for downstream QNEs to 498 interpret. The traffic description specified by the TMOD parameter 499 is a container consisting of 4 sub-parameters [RFC2212]: 501 o rate (r) specified in octets per second 502 o bucket size (b) specified in octets 503 o peak rate (p) specified in octets per second 504 o minimum policed unit (m) specified in octets 505 o maximum packet size (MPS) specified in octets 507 The TMOD parameter takes the form of a token bucket of rate (r) and 508 bucket size (b), plus a peak rate (p), minimum policed unit (m), and 509 maximum packet size (MPS). 511 Both b and r MUST be positive. The rate, r, is measured in octets of 512 IP packets per second, and can range from 1 octet per second to as 513 large as 40 teraoctets per second. The bucket depth, b, is also 514 measured in octets and can range from 1 octet to 250 gigaoctets. The 515 peak rate, p, is measured in octets of IP packets per second and has 516 the same range and suggested representation as the bucket rate. 518 The peak rate is the maximum rate at which the source and any 519 reshaping (defined below) may inject bursts of traffic into the 520 network. More precisely, it is a requirement that for all time 521 periods the amount of data sent cannot exceed MPS+pT where MPS is the 522 maximum packet size and T is the length of the time period. 523 Furthermore, p MUST be greater than or equal to the token bucket 524 rate, r. If the peak rate is unknown or unspecified, then p MUST be 525 set to infinity. 527 The minimum policed unit, m, is an integer measured in octets. All 528 IP packets less than size m will be counted, when policed and tested 529 for conformance to the TMOD, as being of size m. 531 The maximum packet size, MPS, is the biggest packet that will conform 532 to the traffic specification; it is also measured in octets. The 533 flow MUST be rejected if the requested maximum packet size is larger 534 than the MTU of the link. Both m and MPS MUST be positive, and m 535 MUST be less than or equal to MPS. 537 Policing compares arriving traffic against the TMOD parameters at the 538 edge of the network. Traffic is policed to ensure it conforms to the 539 token bucket. Reshaping attempts to restore (possibly distorted) 540 traffic's shape to conform to the TMOD parameters, and the fact that 541 traffic is in violation of the TMOD is discovered because the 542 reshaping fails (the reshaping buffer overflows). 544 The token bucket and peak rate parameters require that traffic MUST 545 obey the rule that over all time periods, the amount of data sent 546 cannot exceed MPS+min[pT, rT+b-MPS], where r and b are the token 547 bucket parameters, MPS is the maximum packet size, and T is the 548 length of the time period (note that when p is infinite this 549 reduces to the standard token bucket requirement). For the 550 purposes of this accounting, links MUST count packets that are 551 smaller than the minimum policing unit to be of size m. Packets 552 that arrive at an element and cause a violation of the the 553 MPS+min[pT, rT+b-MPS] bound are considered non-conformant. 555 All 5 of the sub-parameters MUST be included in the TMOD parameter. 556 The TMOD parameter can be set to describe the traffic source. If, 557 for example, TMOD is set to specify bandwidth only, then set r = peak 558 rate = p, b = large, m = large. As another example if TMOD is set 559 for TCP traffic, then set r = average rate, b = large, p = large. 561 When the 5 TMOD sub-parameters are included in QoS Available, they 562 provide information, for example, about the TMOD resources available 563 along the path followed by a data flow. The value of TMOD at a QNE 564 is an estimate of the TMOD resources the QNE has available for 565 packets following the path up to the next QNE, including its outgoing 566 link, if this link exists. Furthermore, the QNI MUST account for the 567 resources of the ingress link, if this link exists. Computation of 568 the value of this parameter SHOULD take into account all information 569 available to the QNE about the path, taking into consideration 570 administrative and policy controls, as well as physical resources. 572 The output composed value is the minimum of the QNE's value and the 573 input composed value for r, b, p, and MPS, and the maximum of the 574 QNE's value and the input composed value for m. This quantity, 575 when composed end-to-end, informs the QNR (or QNI in a RESPONSE 576 message) of the minimal TMOD resources along the path from QNI to 577 QNR. 579 Two TMOD parameters are defined in Section 5, and , 580 where the second () parameter is specified as could be needed 581 to support some DiffServ applications. For example, it is typically 582 assumed that DiffServ EF traffic is shaped at the ingress by a single 583 rate token bucket. Therefore, a single TMOD parameter is sufficient 584 to signal DiffServ EF traffic. However, for DiffServ AF traffic two 585 sets of token bucket parameters are needed, one token bucket for the 586 average traffic and one token bucket for the burst traffic. 587 [RFC2697] defines a Single Rate Three Color Marker (srTCM), which 588 meters a traffic stream and marks its packets according to three 589 traffic parameters, Committed Information Rate (CIR), Committed Burst 590 Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, 591 or red. A packet is marked green if it does not exceed the CBS, 592 yellow if it does exceed the CBS, but not the EBS, and red otherwise. 593 [RFC2697] defines specific procedures using two token buckets that 594 run at the same rate. Therefore 2 TMOD parameters are sufficient to 595 distinguish among 3 levels of drop precedence. An example is also 596 described in the Appendix to [RFC2597]. 598 3.3.2 Constraints Parameters 600 , , , and are QSPEC 601 parameters describing the desired path latency, path jitter, packet 602 loss ratio, and path bit error rate respectively. Since these 603 parameters are cumulative, an individual QNE cannot decide whether 604 the desired path latency, etc., is available, and hence they cannot 605 decide whether a reservation fails. Rather, when these parameters 606 are included in , the QNI SHOULD also include 607 corresponding parameters in a QoS Available QSPEC object in order to 608 facilitate collecting this information. 610 The parameter accumulates the latency of the packet 611 forwarding process associated with each QNE, where the latency is 612 defined to be the mean packet delay, measured in microseconds, added 613 by each QNE. This delay results from the combination of link 614 propagation delay, packet processing, and queueing. Each QNE MUST 615 add the propagation delay of its outgoing link, if this link exists. 616 Furthermore, the QNI SHOULD add the propagation delay of the ingress 617 link, if this link exists. The composition rule for the parameter is summation with a clamp of (2**32) - 1 on the 619 maximum value. This quantity, when composed end-to-end, informs the 620 QNR (or QNI in a RESPONSE message) of the minimal packet delay along 621 the path from QNI to QNR. The purpose of this parameter is to 622 provide a minimum path latency for use with services which provide 623 estimates or bounds on additional path delay [RFC2212]. 625 The parameter accumulates the jitter of the packet 626 forwarding process associated with each QNE, where the jitter is 627 defined to be the nominal jitter, measured in microseconds, added by 628 each QNE. IP packet jitter, or delay variation, is defined in 629 [RFC3393], Section 3.4 (Type-P-One-way-ipdv), and where the selection 630 function includes the packet with minimum delay such that the 631 distribution is equivalent to 2-point delay variation in [Y.1540]. 632 The suggested evaluation interval is 1 minute. This jitter results 633 from packet processing limitations, and includes any variable queuing 634 delay which may be present. Each QNE MUST add the jitter of its 635 outgoing link, if this link exists. Furthermore, the QNI SHOULD add 636 the jitter of the ingress link, if this link exists. The composition 637 method for the parameter is the combination of several 638 statistics describing the delay variation distribution with a clamp 639 on the maximum value (note that the methods of accumulation and 640 estimation of nominal QNE jitter are specified in clause 8 of 641 [Y.1541]). This quantity, when composed end-to-end, informs the QNR 642 (or QNI in a RESPONSE message) of the nominal packet jitter along the 643 path from QNI to QNR. The purpose of this parameter is to provide a 644 nominal path jitter for use with services that provide estimates or 645 bounds on additional path delay [RFC2212]. 647 The parameter is the unit-less ratio of total lost IP 648 packets to total transmitted IP packets. accumulates the 649 packet loss ratio (PLR) of the packet forwarding process associated 650 with each QNE, where the PLR is defined to be the PLR added by each 651 QNE. Each QNE MUST add the PLR of its outgoing link, if this link 652 exists. Furthermore, the QNI MUST add the PLR of the ingress link, 653 if this link exists. The composition rule for the 654 parameter is summation with a clamp on the maximum value (this 655 assumes sufficiently low PLR values such that summation error is not 656 significant, however a more accurate composition function is 657 specified in clause 8 of [Y.1541]). This quantity, when composed 658 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 659 minimal packet PLR along the path from QNI to QNR. 661 Packet error ratio [Y.1540, Y.1541] is the unit-less ratio of total 662 errored IP packet outcomes to the total of successful IP packet 663 transfer outcomes plus errored IP packet outcomes in a population of 664 interest, with a resolution of at least 10^-9. If lesser resolution 665 is available in a value, the unused digits MUST be set to zero. Note 666 that the number of errored packets observed is directly related to 667 the confidence in the result. The parameter accumulates 668 the packet error ratio (PER) of the packet forwarding process 669 associated with each QNE, where the PER is defined to be the PER 670 added by each QNE. Each QNE MUST add the PER of its outgoing link, 671 if this link exists. Furthermore, the QNI SHOULD add the PER of the 672 ingress link, if this link exists. The composition rule for the 673 parameter is summation with a clamp on the maximum value 674 (this assumes sufficiently low PER values such that summation error 675 is not significant, however a more accurate composition function is 676 specified in clause 8 of [Y.1541]). This quantity, when composed 677 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 678 minimal packet PER along the path from QNI to QNR. 680 The slack term parameter is the difference between desired delay and 681 delay obtained by using bandwidth reservation, and which is used to 682 reduce the resource reservation for a flow [RFC2212]. 684 3.3.3 Traffic Handling Directives 686 An application MAY like to reserve resources for packets and also 687 specify a specific traffic handling behavior, such as . In addition, as discussed in Section 3.1, an application 689 MAY like to define RMF triggers that cause the QoS NSLP to run 690 semantics within the underlying QoS NSLP signaling state / messaging 691 processing rules, as defined in Section 5.2 of [QoS-NSLP]. Note, 692 however, that new QoS NSLP message processing rules can only be 693 defined in extensions to the QoS NSLP. As with constraints 694 parameters and other QSPEC parameters, traffic-handling-directives 695 parameters may be defined in QOSM specifications in order to provide 696 support for QOSM-specific resource management functions. Such 697 QOSM-specific parameters are already defined, for example, in 698 [RMD-QOSM], [CL-QOSM] and [Y.1541-QOSM]. Generally, a 699 traffic-handling-directives parameters is expected to be set by the 700 QNI in , and to not be included in . 701 If such a parameter is included in , QNEs may change 702 their value. 704 The parameter is the priority of the new flow 705 compared with the of previously admitted flows. 706 Once a flow is admitted, the preemption priority becomes irrelevant. 707 The parameter is used to compare with the 708 preemption priority of new flows. For any specific flow, its 709 preemption priority MUST always be less than or equal to the 710 defending priority. and provide 711 an essential way to differentiate flows for emergency services, ETS, 712 E911, etc., and assign them a higher admission priority than normal 713 priority flows and best-effort priority flows. 715 The parameter describes how the QNE will process 716 out-of-profile traffic. Excess traffic MAY be dropped, shaped and/or 717 remarked 719 3.3.4 Traffic Classifiers 721 An application MAY like to reserve resources for packets with a 722 particular DiffServ per-hop behavior (PHB) [RFC2475]. Note that PHB 723 class is normally set by a downstream QNE to tell the QNI how to mark 724 traffic to ensure treatment committed by admission control, however, 725 setting of the parameter by the QNI is not precluded. An application 726 MAY like to reserve resources for packets with a particular QoS 727 class, e.g. Y.1541 QoS class [Y.1541] or DiffServ-aware MPLS traffic 728 engineering (DSTE) class type [RFC3564, RFC4124]. These parameters 729 are useful in various QOSMs, e.g., [RMD-QOSM], [Y.1541-QOSM], and 730 other QOSMs yet to be defined (e.g., DSTE-QOSM). This is intended to 731 provide guidelines to QOSMs on how to encode these parameters; use of 732 the PHB class parameter is illustrated in the example in the 733 following section. 735 3.4 Example of QSPEC Processing 737 This section illustrates the operation and use of the QSPEC within 738 the NSLP. The example configuration in shown in Figure 2. 740 +----------+ /-------\ /--------\ /--------\ 741 | Laptop | | Home | | Cable | | DiffServ | 742 | Computer |-----| Network |-----| Network |-----| Network |----+ 743 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 744 \-------/ \--------/ \--------/ | 745 | 746 +-----------------------------------------------+ 747 | 748 | /--------\ +----------+ 749 | | "X"G | | Handheld | 750 +---| Wireless |-----| Device | 751 | XG QOSM | +----------+ 752 \--------/ 754 Figure 2: Example Configuration to Illustrate QoS-NSLP/QSPEC 755 Operation 757 In this configuration, a laptop computer and a handheld wireless 758 device are the endpoints for some application that has QoS 759 requirements. Assume initially that the two endpoints are stationary 760 during the application session, later we consider mobile endpoints. 761 For this session, the laptop computer is connected to a home network 762 that has no QoS support. The home network is connected to a 763 CableLabs-type cable access network with dynamic QoS (DQOS) support, 764 such as specified in the [DQOS] for cable access networks. That 765 network is connected to a DiffServ core network that uses the RMD 766 QOSM [RMD-QOSM]. On the other side of the DiffServ core is a 767 wireless access network built on generation "X" technology with QoS 768 support as defined by generation "X". And finally the handheld 769 endpoint is connected to the wireless access network. 771 We assume that the Laptop is the QNI and handheld device is the QNR. 772 The QNI will signal an initiator QSPEC object to achieve the QoS 773 desired on the path. 775 The QNI sets QoS Desired, QoS Available and possibly Minimum 776 QoS QSPEC objects in the initiator QSPEC, and initializes QoS 777 Available to QoS Desired. Each QNE on the path reads and 778 interprets those parameters in the initiator QSPEC and checks to see 779 if QoS Available resources can be reserved. If not, the QNE reduces 780 the respective parameter values in QoS Available and reserves these 781 values. The minimum parameter values are given in Minimum QoS, if 782 populated, otherwise zero if Minimum QoS is not included. If one or 783 more parameters in QoS Available fails to satisfy the corresponding 784 minimum values in Minimum QoS, the QNE generates a RESPONSE message 785 to the QNI and the reservation is aborted. Otherwise, the QNR 786 generates a RESPONSE to the QNI with the QoS Available for the 787 reservation. If a QNE cannot reserve QoS Desired resources, the 788 reservation fails. 790 The QNI populates QSPEC parameters to ensure correct treatment of its 791 traffic in domains down the path. Let us assume the QNI wants to 792 achieve IntServ-Controlled Load-like QoS guarantees, and also is 793 interested in what path latency it can achieve. Additionally, to 794 ensure correct treatment further down the path, the QNI includes in . The QNI therefore includes in the QSPEC 797 QoS Desired = 798 QoS Available = 800 Since and are not vital parameters from 801 the QNI's perspective, it does not raise their M flags. 803 There are three possibilities when a RESERVE message is received at a 804 QNE at a domain border (we illustrate these possibilities in the 805 example): 807 - the QNE just leaves the QSPEC as-is. 809 - the QNE can add a local QSPEC and encapsulate the initiator QSPEC 810 (see discussion in Section 4.1; this is new in QoS NSLP, RSVP does 811 not do this). 813 - the QNE can 'hide' the initiator RESERVE message so that only the 814 edge QNE processes the initiator RESERVE message, which then 815 bypasses intermediate nodes between the edges of the domain, and 816 issues its own local RESERVE message (see Section 3.3.1 of 817 [QoS-NSLP]). For this new local RESERVE message, the QNE acts as 818 the QNI, and the QSPEC in the domain is an initiator QSPEC. A 819 similar procedure is also used by RSVP in making aggregate 820 reservations, in which case there is not a new intra-domain 821 (aggregate) RESERVE for each newly arriving interdomain (per-flow) 822 RESERVE, but the aggregate reservation is updated by the border 823 QNE (QNI) as need be. This is also how RMD works [RMD-QOSM]. 825 For example, at the RMD domain, a local RESERVE with its own RMD 826 initiator QSPEC corresponding to the RMD-QOSM is generated based on 827 the original initiator QSPEC according to the procedures described in 828 Section 4.5 of [QoS-NSLP] and in [RMD-QOSM]. The ingress QNE to the 829 RMD domain maps the TMOD parameters contained in the original 830 initiator QSPEC into the equivalent TMOD parameter representing only 831 the peak bandwidth in the local QSPEC. The local RMD QSPEC for 832 example also needs , which in this case was provided by 833 the QNI. 835 Furthermore, the node at the egress to the RMD domain updates QoS 836 Available on behalf of the entire RMD domain if it can. If it 837 cannot (since the M flag is not set for ) it raises the 838 parameter-specific, 'not-supported' flag, warning the QNR that the 839 final latency value in QoS Available is imprecise. 841 In the XG domain, the initiator QSPEC is translated into a local 842 QSPEC using a similar procedure as described above. The local QSPEC 843 becomes the current QSPEC used within the XG domain, and the 844 initiator QSPEC is encapsulated. This saves the QNEs within the XG 845 domain the trouble of re-translating the initiator QSPEC, and 846 simplifies processing in the local domain. At the egress edge of the 847 XG domain, the translated local QSPEC is removed, and the initiator 848 QSPEC returns to the number one position. 850 If the reservation was successful, eventually the RESERVE request 851 arrives at the QNR (otherwise the QNE at which the reservation failed 852 would have aborted the RESERVE and sent an error RESPONSE back to the 853 QNI). If the RII was included in the QoS NSLP message, the QNR 854 generates a positive RESPONSE with QSPEC objects QoS Reserved and 855 QoS Available. The parameters appearing in QoS Reserved are the 856 same as in QoS Desired, with values copied from QoS Available. 857 Hence, the QNR includes the following QSPEC objects in the RESPONSE: 859 QoS Reserved = 860 QoS Available = 862 If the handheld device on the right of Figure 2 is mobile, and moves 863 through different "XG" wireless networks, then the QoS might change 864 on the path since different XG wireless networks might support 865 different QOSMs. As a result, QoS NSLP/QSPEC processing will have to 866 renegotiate the QoS Available on the path. From a QSPEC 867 perspective, this is like a new reservation on the new section of the 868 path and is basically the same as any other rerouting event - to the 869 QNEs on the new path it looks like a new reservation. That is, in 870 this mobile scenario, the new segment may support a different QOSM 872 than the old segment, and the QNI would now signal a new reservation 873 (explicitly, or implicitly with the next refreshing RESERVE message) 874 to account for the different QOSM in the XG wireless domain. Further 875 details on rerouting are specified in [QoS-NSLP]. 877 For bit-level examples of QSPECs see the documents specifying QOSMs 878 [CL-QOSM, Y.1541-QOSM, RMD-QOSM]. 880 4. QSPEC Processing & Procedures 882 Three flags are used in QSPEC processing, the M flag, E flag, and N 883 flag, which are explained in this section. The QNI sets the M flag 884 for each QSPEC parameter it populates that MUST be interpreted by 885 downstream QNEs. If a QNE does not support parameter it sets the N 886 flag and fails the reservation. If the QNE supports the parameter 887 but cannot meet the resources requested by the parameter, it sets the 888 E flag and fails the reservation. 890 If the M flag is not set, the downstream QNE SHOULD interpret the 891 parameter. If the QNE does not support the parameter it sets the 892 N flag and forwards the reservation. If the QNE supports the 893 parameter but cannot meet the resources requested by the parameter, 894 it sets the E flag and fails the reservation. 896 4.1 Local QSPEC Definition & Processing 898 A QNE at the edge of a local domain may either a) translate the 899 initiator QSPEC into a local QSPEC and encapsulate the initiator 900 QSPEC in the RESERVE message, or b) 'hiding' the initiator QSPEC 901 through the local domain and reserve resources by generating a new 902 RESERVE message through the local domain containing the local QSPEC. 903 In either case the initiator QSPEC parameters are interpreted at the 904 local domain edges. 906 A local QSPEC may allow a simpler control plane in a local domain. 907 The edge nodes in the local domain must interpret the initiator 908 QSPEC parameters. They can either initiate a parallel session with 909 local QSPEC or define a local QSPEC and encapsulate the initiator 910 QSPEC, as illustrated in Figure 3. The Initiator/Local QSPEC bit 911 identifies whether the QSPEC is an initiator QSPEC or a local QSPEC. 912 The QSPEC Type indicates, for example, that the initiator of local 913 QSPEC uses to a certain QOSM, e.g., CL-QSPEC Type. It may be 914 useful for the QNI to signal a QSPEC Type based on some QOSM (which 915 will necessarily entail populating certain QOSM-related parameters) 916 so that a downstream QNE can chose amongst various QOSM-related 917 processes it might have. That is, the QNI populates the QSPEC Type, 918 e.g., CL-QSPEC Type and sets the Initiator/Local QSPEC bit to 919 'Initiator'. A local QNE can decide, for whatever reasons, to 920 insert a local QSPEC Type, e.g., RMD-QSPEC Type, and set the local 921 QSPEC Type = RMD-QSPEC and set the Initiator/Local QSPEC bit to 922 'Local' (and encapsulate the Initiator QSPEC in the RESERVE or 923 whatever NSLP message). 925 +--------------------------------+\ 926 | QSPEC Type, QSPEC Procedure | \ 927 +--------------------------------+ / Common QQSPEC Header 928 | Init./Local QSPEC bit=Local |/ 929 +================================+\ 930 | Local-QSPEC Parameter 1 | \ 931 +--------------------------------+ \ 932 | .... | Local-QSPEC Parameters 933 +--------------------------------+ / 934 | Local-QSPEC Parameter n | / 935 +--------------------------------+/ 936 | +----------------------------+ | 937 | | QSPEC Type, QSPEC Procedure| | 938 | +----------------------------+ | 939 | | Init./Local QSPEC bit=Init.| | 940 | +============================+ | 941 | | | | Encapsulated Initiator QSPEC 942 | | .... | | 943 | +----------------------------+ | 944 +--------------------------------+ 946 Figure 3. Defining a Local QSPEC 948 Here the QoS-NSLP only sees and passes one QSPEC up to the RMF. The 949 type of the QSPEC thus may change within a local domain. Hence 951 o the QNI signals its QoS requirements with the initiator QSPEC, 952 o the ingress edge QNE in the local domain translates the 953 initiator QSPEC parameters to equivalent parameters in the local 954 QSPEC, 955 o the QNEs in the local domain only interpret the local QSPEC 956 parameters 957 o the egress QNE in the local domain processes the local QSPEC and 958 also interprets the QSPEC parameters in the initiator QSPEC. 960 The local QSPEC MUST be consistent with the initiator QSPEC. That 961 is, it MUST NOT specify a lower level of resources than specified 962 by the initiator QSPEC. For example, in RMD the TMOD parameters 963 contained in the original initiator QSPEC are mapped into the 964 equivalent TMOD parameter representing only the peak bandwidth in the 965 local QSPEC. 967 Note that it is possible to use both a) hiding a QSPEC through a 968 local domain by initiating a new RESERVE at the domain edge, and 969 b) defining a local QSPEC and encapsulating the initiator QSPEC, as 970 defined above. However, it is not expected that both the hiding and 971 encapsulating functions would be use at the same time for the same 972 flow. 974 The support of local QSPECs is illustrated in Figure 4 for a single 975 flow to show where the initiator and local QSPECs are used. The QNI 976 initiates an end-to-end, inter-domain QoS NSLP RESERVE message 977 containing the Initiator QSPEC for the Y.1541 QOSM. As illustrated 978 in Figure 4, the RESERVE message crosses multiple domains supporting 979 different QOSMs. In this illustration, the initiator QSPEC arrives 980 in an QoS NSLP RESERVE message at the ingress node of the 981 local-QOSM domain. At the ingress edge node of the local-QOSM 982 domain, the end-to-end, inter-domain QoS-NSLP message triggers the 983 generation of a local QSPEC, and the initiator QSPEC is encapsulated 984 within the messages signaled through the local domain. The local 985 QSPEC is used for QoS processing in the local-QOSM domain, and the 986 initiator QSPEC is used for QoS processing outside the local domain. 988 In this example the QNI sets , , objects to include objectives for the , , and parameters. The QNE/local domain sets the 991 cumulative parameters, e.g., , that can be 992 achieved in the object (but not less than specified 993 in ). If the fails to satisfy one or 994 more of the objectives, the QNE/local domain notifies 995 the QNI and the reservation is aborted. If any QNE cannot meet the 996 requirements designated by the initiator QSPEC to support a QSPEC 997 parameter with the M bit set to zero, the QNE sets the N flag for 998 that parameter to one. Otherwise, the QNR notifies the QNI of the 999 for the reservation. 1001 |------| |------| |------| |------| 1002 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 1003 | QOSM | | QOSM | | QOSM | | QOSM | 1004 | | |------| |-------| |-------| |------| | | 1005 | NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | 1006 |Y.1541| |local | |local | |local | |local | |Y.1541| 1007 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 1008 |------| |------| |-------| |-------| |------| |------| 1009 ----------------------------------------------------------------- 1010 |------| |------| |-------| |-------| |------| |------| 1011 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 1012 |------| |------| |-------| |-------| |------| |------| 1013 QNI QNE QNE QNE QNE QNR 1014 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 1016 Figure 4. Example of Initiator & Local Domain QOSM Operation 1018 4.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 1019 Notification 1021 A reservation may not be successful for several reasons: 1023 - a reservation may fail because the desired resources are not 1024 available. This is a reservation failure condition. 1026 - a reservation may fail because the QSPEC is erroneous, or because 1027 of a QNE fault. This is an error condition. 1029 A reservation may be successful even though some parameters could not 1030 be interpreted or updated properly: 1032 - a QSPEC parameter cannot be interpreted because it is an unknown 1033 QSPEC parameter type. This is a QSPEC parameter not supported 1034 condition. The reservation however does not fail. The QNI can 1035 still decide whether to keep or tear down the reservation depending 1036 on the procedures specified by the QNI's QOSM. 1038 The following sections describe the handling of unsuccessful 1039 reservations and reservations where some parameters could not be met 1040 in more detail, as follows: 1042 - details on flags used inside the QSPEC to convey information on 1043 success or failure of individual parameters. The formats and 1044 semantics of all flags are given in Section 5. 1045 - the content of the INFO_SPEC [QoS-NSLP], which carries a code 1046 indicating the outcome of reservations. 1047 - the generation of a RESPONSE message to the QNI containing both 1048 QSPEC and INFO_SPEC objects. 1050 Note that when there are routers along the path between the QNI and 1051 QNR where QoS cannot be provided, then the QoS-NSLP generic flag 1052 BREAK (B) is set. The BREAK flag is discussed in Section 3.3.5 of 1053 [QoS-NSLP]. 1055 4.2.1 Reservation Failure & Error E Flag 1057 The QSPEC parameters each have a 'reservation failure error E flag' 1058 to indicate which (if any) parameters could not be satisfied. When a 1059 resource cannot be satisfied for a particular parameter, the QNE 1060 detecting the problem raises the E flag in this parameter. Note that 1061 the TMOD parameter and all QSPEC parameters with the M flag set MUST 1062 be examined by the RMF, and all QSPEC parameters with the M flag not 1063 set SHOULD be examined by the RMF, and the E flag set to indicate 1064 whether the parameter could or could not be satisfied. Additionally, 1065 the E flag in the corresponding QSPEC object MUST be raised when a 1066 resource cannot be satisfied for this parameter. If the reservation 1067 failure problem cannot be located at the parameter level, only the E 1068 flag in the QSPEC object is raised. 1070 When an RMF cannot interpret the QSPEC because the coding is 1071 erroneous, it raises corresponding reservation failure E flags in the 1072 QSPEC. Normally all QSPEC parameters MUST be examined by the RMF 1073 and the erroneous parameters appropriately flagged. In some cases, 1074 however, an error condition may occur and the E flag of the 1075 error-causing QSPEC parameter is raised (if possible), but the 1076 processing of further parameters may be aborted. 1078 Note that if the QSPEC and/or any QSPEC parameter is found to be 1079 erroneous, then any QSPEC parameters not satisfied are ignored and 1080 the E Flags in the QSPEC object MUST NOT be set for those parameters 1081 (unless they are erroneous). 1083 Whether E flags denote reservation failure or error can be determined 1084 by the corresponding error code in the INFO_SPEC in QoS NSLP, as 1085 discussed below. 1087 4.2.2 QSPEC Parameter Not Supported N Flag 1089 Each QSPEC parameter has an associated 'not supported N flag'. If 1090 the not supported N flag is set, then at least one QNE along the data 1091 transmission path between the QNI and QNR cannot interpret the 1092 specified QSPEC parameter. A QNE MUST set the not supported N flag 1093 if it cannot interpret the QSPEC parameter. If the M flag for the 1094 parameter is not set, the message should continue to be forwarded but 1095 with the N flag set, and the QNI has the option of tearing the 1096 reservation. 1098 If a QNE in the path does not support a QSPEC parameter, e.g., 1099 , and sets the N flag, then downstream QNEs that 1100 support the parameter SHOULD still update the parameter, even if the 1101 N flag is set. However, the presence of the N flag will indicates 1102 that the cumulative value only provides a bound, and the QNI/QNR 1103 decides whether or not to accept the reservation with the N flag set. 1105 4.2.3 INFO_SPEC Coding of Reservation Outcome 1107 As prescribed by [QoS-NSLP], the RESPONSE message always contains the 1108 INFO_SPEC with an appropriate 'error' code. It usually also contains 1109 a QSPEC with QSPEC objects, as described in Section 4.3 on QSPEC 1110 Procedures. The RESPONSE message MAY omit the QSPEC in case of a 1111 successful reservation. 1113 The following guidelines are provided in setting the error codes in 1114 the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of 1115 [QoS-NSLP]: 1117 - INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success): 1118 This code is set when all QSPEC parameters have been satisfied. In 1119 this case no E Flag is set, however one or more N flags may be set 1121 - INFO_SPEC error class 0x04 (Transient Failure) / 0x07 (Reservation 1122 Failure): 1123 This code is set when at least one QSPEC parameter could not be 1124 satisfied, or when a QSPEC parameter with M flag set could not be 1125 interpreted. E flags are set for the parameters that could not be 1126 satisfied up to the QNE issuing the RESPONSE message. The N flag is 1127 set for those parameters that could not be interpreted by at least 1128 one QNE. In this case QNEs receiving the RESPONSE message MUST 1129 remove the corresponding reservation. 1131 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0c (Malformed 1132 QSPEC): 1134 Some QSPEC parameters had associated errors, E Flags are set for 1135 parameters that had errors, and the QNE where the error was found 1136 rejects the reservation. 1138 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0f (Incompatible 1139 QSPEC): 1140 A higher version QSPEC is signaled and not support by the QNE. 1142 - INFO_SPEC error class 0x06 (QoS Model Error): 1143 QOSM error codes can be defined by QOSM specification documents. A 1144 registry is defined in Section 7 IANA Considerations. 1146 4.2.4 QNE Generation of a RESPONSE message 1148 - Successful Reservation Condition 1150 When a RESERVE message arrives at a QNR and no E Flag is set, the 1151 reservation is successful. A RESPONSE message may be generated with 1152 INFO_SPEC code 'Reservation Success' as described above and in the 1153 QSPEC Procedures described in Section 4.3. 1155 - Reservation Failure Condition 1157 When a QNE detects that a reservation failure occurs for at least one 1158 parameter, the QNE sets the E Flags for the QSPEC parameters and 1159 QSPEC object that failed to be satisfied. According to [QoS-NSLP], 1160 the QNE behavior depends on whether it is stateful or not. When a 1161 stateful QNE determines the reservation failed, it formulates a 1162 RESPONSE message that includes an INFO_SPEC with the 'reservation 1163 failure' error code and QSPEC object. The QSPEC in the RESPONSE 1164 message includes the failed QSPEC parameters marked with the E Flag 1165 to clearly identify them. 1167 The default action for a stateless QoS NSLP QNE that detects a 1168 reservation failure condition is that it MUST continue to forward the 1169 RESERVE message to the next stateful QNE, with the E Flags 1170 appropriately set for each QSPEC parameter. The next stateful QNE 1171 then formulates the RESPONSE message as described above. 1173 - Malformed QSPEC Error Condition 1175 When a stateful QNE detects that one or more QSPEC parameters are 1176 erroneous, the QNE sets the error code 'malformed QSPEC' in the 1177 INFO_SPEC. In this case the QSPEC object with the E Flags 1178 appropriately set for the erroneous parameters is returned within 1179 the INFO_SPEC object. The QSPEC object can be truncated or fully 1180 included within the INFO_SPEC. 1182 According to [QoS-NSLP], the QNE behavior depends on whether it is 1183 stateful or not. When a stateful QNE determines a malformed QSPEC 1184 error condition, it formulates a RESPONSE message that includes an 1185 INFO_SPEC with the 'malformed QSPEC' error code and QSPEC object. 1187 The QSPEC in the RESPONSE message includes, if possible, only the 1188 erroneous QSPEC parameters and no others. The erroneous QSPEC 1189 parameter(s) are marked with the E Flag to clearly identify them. If 1190 QSPEC parameters are returned in the INFO-SPEC that are not marked 1191 with the E flag, then any values of these parameters are irrelevant 1192 and MUST be ignored by the QNI. 1194 The default action for a stateless QoS NSLP QNE that detects a 1195 Malformed QSPEC error condition is that it MUST continue to forward 1196 the RESERVE message to the next stateful QNE, with the E Flags 1197 appropriately set for each QSPEC parameter. The next stateful QNE 1198 will then act as described in [QoS-NSLP]. 1200 A 'malformed QSPEC' error code takes precedence over the 'reservation 1201 failure' error code, and therefore the case of reservation failure 1202 and QSPEC/RMF error conditions are disjoint and the same E Flag can 1203 be used in both cases without ambiguity. 1205 4.2.5 Special Case of Local QSPEC 1207 When an unsuccessful reservation problem occurs inside a local domain 1208 where a local QSPEC is used, only the topmost (local) QSPEC is 1209 affected (e.g. E flags are raised, etc.). The encapsulated 1210 initiator QSPEC is untouched. When the message (RESPONSE in case of 1211 stateful QNEs, RESERVE in case of stateless QNEs) however reaches the 1212 edge of the local domain, the local QSPEC is removed. The edge QNE 1213 must update the initiator QSPEC on behalf of the entire domain, 1214 reflecting the information received in the local QSPEC. This update 1215 concerns both parameter values and flags. Note that some 1216 intelligence is needed in mapping the E flags, etc. from the local 1217 QSPEC to the initiator QSPEC. For example, there may be no direct 1218 match between the parameters in the local and initiator QSPECs, but 1219 that does not mean that no E flags should be raised in the latter. 1221 4.3 QSPEC Procedures 1223 While the QSPEC template aims to put minimal restrictions on usage of 1224 QSPEC objects, interoperability between QNEs and between QOSMs must 1225 be ensured. We therefore give below an exhaustive list of QSPEC 1226 object combinations for the message sequences described in QoS NSLP 1227 [QoS-NSLP]. A specific QOSM may prescribe that only a subset of the 1228 procedures listed below may be used. 1230 Note that QoS NSLP does not mandate the usage of a RESPONSE message. 1231 A positive RESPONSE message will only be generated if the QNE 1232 includes an RII (Request Identification Information) in the RESERVE 1233 message, and a negative RESPONSE message is always generated in case 1234 of an error or failure. Some of the QSPEC procedures below, 1235 however, are only meaningful when a RESPONSE message is possible. 1236 The QNI SHOULD in these cases include an RII. 1238 4.3.1 Two-Way Transactions 1239 Here the QNI issues a RESERVE message, which may be replied to by a 1240 RESPONSE message. The following 3 cases for QSPEC object usage 1241 exist: 1243 MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED 1244 SEQUENCE | COMBINATION | IN RESERVE MESSAGE | IN RESPONSE MESSAGE 1245 ----------------------------------------------------------------- 1246 0 | 0 | QoS Desired | QoS Reserved 1247 | | | 1248 0 | 1 | QoS Desired | QoS Reserved 1249 | | QoS Available | QoS Available 1250 | | | 1251 0 | 2 | QoS Desired | QoS Reserved 1252 | | QoS Available | QoS Available 1253 | | Minimum QoS | 1255 Table 1. Message Sequence 0: Two-Way Transactions 1256 Defining Object Combinations 0, 1, and 2 1258 Case 1: 1260 If only QoS Desired is included in the RESERVE message, the implicit 1261 assumption is that exactly these resources must be reserved. If this 1262 is not possible the reservation fails. The parameters in QoS 1263 Reserved are copied from the parameters in QoS Desired. If the 1264 reservation is successful, the RESPONSE message can be omitted in 1265 this case. If a RESPONSE message was requested by a QNE on the 1266 path, the QSPEC in the RESPONSE message can be omitted. 1268 Case 2: 1270 When QoS Available is included in the RESERVE message also, some 1271 parameters will appear only in QoS Available and not in QoS Desired. 1272 It is assumed that the value of these parameters is collected for 1273 informational purposes only (e.g. path latency). 1275 However, some parameters in QoS Available can be the same as in QoS 1276 Desired. For these parameters the implicit message is that the QNI 1277 would be satisfied by a reservation with lower parameter values than 1278 specified in QoS Desired. For these parameters, the QNI seeds the 1279 parameter values in QoS Available to those in QoS Desired (except for 1280 cumulative parameters such as ). 1282 Each QNE interprets the parameters in QoS Available according to its 1283 current capabilities. Reservations in each QNE are hence based on 1284 current parameter values in QoS Available (and additionally those 1285 parameters that only appear in QoS Desired). The drawback of this 1286 approach is that, if the resulting resource reservation becomes 1287 gradually smaller towards the QNR, QNEs close to the QNI have an 1288 oversized reservation, possibly resulting in unnecessary costs for 1289 the user. Of course, in the RESPONSE the QNI learns what the actual 1290 reservation is (from the QoS RESERVED object) and can immediately 1291 issue a properly sized refreshing RESERVE. The advantage of the 1292 approach is that the reservation is performed in half-a-roundtrip 1293 time. 1295 The QSPEC parameter IDs and values included in the QoS Reserved 1296 object in the RESPONSE message MUST be the same as those in the QoS 1297 Desired object in the RESERVE message. For those QSPEC parameters 1298 that were also included in the QoS Available object in the RESERVE 1299 message, their value is copied from the QoS Available object (in 1300 RESERVE) into the QoS Reserved object (in RESPONSE). For the 1301 other QSPEC parameters, the value is copied from the QoS Desired 1302 object (the reservation would fail if the corresponding QoS could 1303 not be reserved). 1305 All parameters in the QoS Available object in the RESPONSE message 1306 are copied with their values from the QoS Available object in the 1307 RESERVE message (irrespective of whether they have also been copied 1308 into the QoS Desired object). Note that the parameters in the QoS 1309 Available object can be overwritten in the RESERVE message, whereas 1310 they cannot be overwritten in the RESPONSE message. 1312 In this case, the QNI SHOULD request a RESPONSE message since it will 1313 otherwise not learn what QoS is available. 1315 Case 3: 1317 This case is handled as case 2, except that the reservation fails 1318 when QoS Available becomes less than Minimum QoS for one parameter. 1319 If a parameter appears in the QoS Available object but not in the 1320 Minimum QoS object it is assumed that there is no minimum value for 1321 this parameter. 1323 Regarding , the default rule is that all 1324 QSPEC parameters that have been included in the RESERVE message by 1325 the QNI are also included in the RESPONSE message by the QNR with the 1326 value they had when arriving at the QNR. When traveling in the 1327 RESPONSE message, all parameters are 1328 read-only. Note that a QOSM specification may define its own 1329 parameters and processing rules. 1331 4.3.2 Three-Way Transactions 1333 Here the QNR issues a QUERY message which is replied to by the QNI 1334 with a RESERVE message if the reservation was successful. The QNR in 1335 turn sends a RESPONSE message to the QNI. The following 3 cases for 1336 QSPEC object usage exist: 1338 MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED 1339 SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE 1340 ------------------------------------------------------------------- 1341 1 |0 |QoS Desired |QoS Desired |QoS Reserved 1342 | | | | 1343 1 |1 |QoS Desired |QoS Desired |QoS Reserved 1344 | |Minimum QoS |QoS Available |QoS Available 1345 | | |(Minimum QoS) | 1346 | | | | 1347 1 |2 |QoS Desired |QoS Desired |QoS Reserved 1348 | |QoS Available |QoS Available | 1350 Table 2. Message Sequence 1: Three-Way Transactions 1351 Defining Object Combinations 0, 1, and 2 1353 Cases 1 and 2: 1355 The idea is that the sender (QNR in this scenario) needs to inform 1356 the receiver (QNI in this scenario) about the QoS it desires. To 1357 this end the sender sends a QUERY message to the receiver including a 1358 QoS Desired QSPEC object. If the QoS is negotiable it additionally 1359 includes a (possibly zero) Minimum QoS object, as in Case 2. 1361 The RESERVE message includes the QoS Available object if the sender 1362 signaled that QoS is negotiable (i.e. it included the Minimum QoS 1363 object). If the Minimum QoS object received from the sender is 1364 included in the QUERY message, the QNI also includes the Minimum QoS 1365 object in the RESERVE message. 1367 For a successful reservation, the RESPONSE message in case 1 is 1368 optional (as is the QSPEC inside). In case 2 however, the RESPONSE 1369 message is necessary in order for the QNI to learn about the QoS 1370 available. 1372 Case 3: 1374 This is the 'RSVP-style' scenario. The sender (QNR in this scenario) 1375 issues a QUERY message with a QoS Desired object informing the 1376 receiver (QNI in this scenario) about the QoS it desires as above. 1377 It also includes a QoS Available object to collect path properties. 1378 Note that here path properties are collected with the QUERY message, 1379 whereas in the previous case 2 path properties were collected in the 1380 RESERVE message. 1382 Some parameters in the QoS Available object may the same as in the 1383 QoS Desired object. For these parameters the implicit message is 1384 that the sender would be satisfied by a reservation with lower 1385 parameter values than specified in QoS Desired. 1387 It is possible for the QoS Available object to contain parameters 1388 that do not appear in the QoS Desired object. It is assumed that the 1389 value of these parameters is collected for informational purposes 1390 only (e.g. path latency). Parameter values in the QoS Available 1391 object are seeded according to the sender's capabilities. Each QNE 1392 remaps or approximately interprets the parameter values according to 1393 its current capabilities. 1395 The receiver (QNI in this scenario) signals the QoS Desired object as 1396 follows: For those parameters that appear in both the QoS Available 1397 object and QoS Desired object in the QUERY message, it takes the 1398 (possibly remapped) QSPEC parameter values from the QoS Available 1399 object. For those parameters that only appear in the QoS Desired 1400 object, it adopts the parameter values from the QoS Desired object. 1402 The parameters in the QoS Available QSPEC object in the RESERVE 1403 message are copied with their values from the QoS Available QSPEC 1404 object in the QUERY message. Note that the parameters in the QoS 1405 Available object can be overwritten in the QUERY message, whereas 1406 they are cannot be overwritten in the RESERVE message. 1408 The advantage of this model compared to the sender-initiated 1409 reservation is that the situation of over-reservation in QNEs close 1410 to the QNI as described above does not occur. On the other hand, the 1411 QUERY message may find, for example, a particular bandwidth is not 1412 available. When the actual reservation is performed, however, the 1413 desired bandwidth may meanwhile have become free. That is, the 'RSVP 1414 style' may result in a smaller reservation than necessary. 1416 The sender includes all QSPEC parameters it cares about in the QUERY 1417 message. Parameters that can be overwritten are updated by QNEs as 1418 the QUERY message travels towards the receiver. The receiver 1419 includes all QSPEC parameters arriving in the QUERY message also in 1420 the RESERVE message, with the value they had when arriving at the 1421 receiver. Again, QOSM-specific QSPEC parameters and procedures may 1422 be defined in QOSM specification documents. 1424 Also in this scenario, the QNI SHOULD request a RESPONSE message 1425 since it will otherwise not learn what QoS is available. 1427 Regarding , the default rule is that all 1428 QSPEC parameters that have been included in the RESERVE message by 1429 the QNI are also included in the RESPONSE message by the QNR with the 1430 value they had when arriving at the QNR. When traveling in the 1431 RESPONSE message, all parameters are 1432 read-only. Note that a QOSM specification may define its own 1433 parameters and processing rules. 1435 4.3.3 Resource Queries 1437 Here the QNI issues a QUERY message in order to investigate what 1438 resources are currently available. The QNR replies with a RESPONSE 1439 message. 1441 MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED 1442 SEQUENCE | COMBINATION | IN QUERY MESSAGE | IN RESPONSE MESSAGE 1443 ----------------------------------------------------------------- 1444 2 | 0 | QoS Available | QoS Available 1446 Table 3. Message Sequence 2: Resource Queries 1447 Defining Object Combination 0 1449 Note that the QoS Available object when traveling in the QUERY 1450 message can be overwritten, whereas in the RESPONSE message cannot be 1451 overwritten. 1453 Regarding , the default rule is that all 1454 QSPEC parameters that have been included in the RESERVE message by 1455 the QNI are also included in the RESPONSE message by the QNR with the 1456 value they had when arriving at the QNR. When traveling in the 1457 RESPONSE message, all parameters are 1458 read-only. Note that a QOSM specification may define its own 1459 parameters and processing rules. 1461 4.3.4 Bidirectional Reservations 1463 On a QSPEC level, bidirectional reservations are no different from 1464 uni-directional reservations, since QSPECs for different directions 1465 never travel in the same message. 1467 4.3.5 Preemption 1469 A flow can be preempted by a QNE based on QNE policy, where a 1470 decision to preempt a flow may account for various factors such as, 1471 for example, the values of the QSPEC preemption priority and 1472 defending priority parameters as described in Section 5.2.8. In 1473 this case the reservation state for this flow is torn down in this 1474 QNE, and the QNE sends a NOTIFY message to the QNI, as described in 1475 [QoS-NSLP]. The NOTIFY message carries an INFO_SPEC with the error 1476 code as described in [QoS-NSLP]. A QOSM specification document may 1477 specify whether a NOTIFY message also carries a QSPEC object. The 1478 QNI would normally tear down the preempted reservation by sending a 1479 RESERVE message with the TEAR flag set using the SII of the preempted 1480 reservation. However, the QNI can follow other procedures as 1481 specified in its QOSM specification document. 1483 4.4 QSPEC Extensibility 1485 Additional QSPEC parameters MAY need to be defined in the future 1486 and are defined in separate informational documents. For example, 1487 QSPEC parameters are defined in [RMD-QOSM] and [Y.1541-QOSM]. 1489 Guidelines on the technical criteria to be followed in evaluating 1490 requests for new codepoint assignments for QSPEC objects and QSPEC 1491 parameters are given in Section 7 (IANA Considerations). 1493 5. QSPEC Functional Specification 1495 This section defines the encodings of the QSPEC parameters. We first 1496 give the general QSPEC formats and then the formats of the QSPEC 1497 objects and parameters. 1499 Network octet order ('big-endian') for all 16- and 32-bit integers, 1500 as well as 32-bit floating point numbers, are as specified in 1501 [RFC4506, IEEE754, NETWORK-OCTET-ORDER]. 1503 5.1 General QSPEC Formats 1505 The format of the QSPEC closely follows that used in GIST [GIST] and 1506 QoS NSLP [QoS-NSLP]. Every object (and parameter) has the following 1507 general format: 1509 o The overall format is Type-Length-Value (in that order). 1511 o Some parts of the type field are set aside for control flags. 1513 o Length has the units of 32-bit words, and measures the length of 1514 Value. If there is no Value, Length=0. The Object length 1515 excludes the header. 1517 o Value is a whole number of 32-bit words. If there is any padding 1518 required, the length and location MUST be defined by the 1519 object-specific format information; objects that contain variable 1520 length types may need to include additional length subfields to do 1521 so. 1523 o Any part of the object used for padding or defined as reserved("r") 1524 MUST be set to 0 on transmission and MUST be ignored on reception. 1526 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1528 o Duplicate objects, duplicate parameters, and/or multiple 1529 occurrences of a parameter MUST NOT be used. 1531 0 1 2 3 1532 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 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Common QSPEC Header | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 // QSPEC Objects // 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 5.1.1 Common Header Format 1541 The Common QSPEC Header is a fixed 4-octet long object containing the 1542 QSPEC Version, QSPEC Type, an identifier for the QSPEC Procedure (see 1543 Section 4.3), and an Initiator/Local QSPEC bit: 1545 0 1 2 3 1546 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 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Vers.|I|QSPECType|r|r| QSPEC Proc. | Length | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 Vers.: Identifies the QSPEC version number. QSPEC Version 0 is 1552 assigned by this specification in Section 7 (IANA 1553 Considerations). 1555 QSPEC Type: Identifies the particular type of QSPEC, e.g., a QSPEC 1556 Type corresponding to a particular QOSM. QSPEC Type 0 1557 (default) is assigned by this specification in Section 7 1558 (IANA Considerations). 1560 QSPEC Proc.: Identifies the QSPEC procedure and is composed of two 1561 times 4 bits. The first field identifies the Message 1562 Sequence, the second field identifies the QSPEC 1563 Object Combination used for this particular message 1564 sequence: 1566 0 1 2 3 4 5 6 7 1567 +-+-+-+-+-+-+-+-+ 1568 |Mes.Sq |Obj.Cmb| 1569 +-+-+-+-+-+-+-+-+ 1571 The Message Sequence field can attain the following 1572 values: 1574 0: Sender-Initiated Reservations 1575 1: Receiver-Initiated Reservations 1576 2: Resource Queries 1578 The Object Combination field can take the values between 1579 1 and 3 indicated in the tables in Section 4.3: 1580 Message Sequence: 0 1581 Object Combination: 0, 1, 2 1582 Semantic: see Table 1 in Section 4.3.1 1583 Message Sequence: 1 1584 Object Combination: 0, 1, 2 1585 Semantic: see Table 2 in Section 4.3.2 1586 Message Sequence: 2 1587 Object Combination: 0 1588 Semantic: see Table 3 in Section 4.3.3 1590 I: Initiator/Local QSPEC bit identifies whether the QSPEC is an 1591 initiator QSPEC or a local QSPEC, and is set to the following 1592 values: 1594 0: Initiator QSPEC 1595 1: Local QSPEC 1597 Length: The total length of the QSPEC (in 32-bit words) excluding the 1598 common header 1599 The QSPEC Objects field is a collection of 1600 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1601 common format and each contain several parameters. 1603 5.1.2 QSPEC Object Header Format 1605 QSPEC objects share a common header format: 1607 0 1 2 3 1608 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 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 |E|r|r|r| Object Type |r|r|r|r| Length | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 E Flag: Set if an error occurs on object level 1614 Object Type = 0: QoS Desired (parameters cannot be overwritten) 1615 = 1: QoS Available (parameters may be overwritten; see 1616 Section 3.2) 1617 = 2: QoS Reserved (parameters cannot be overwritten) 1618 = 3: Minimum QoS (parameters cannot be overwritten) 1620 The r bits are reserved. 1622 Each QSPEC or QSPEC parameter within an object is similarly 1623 encoded in TLV format using a similar parameter header: 1625 0 1 2 3 1626 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 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 |M|E|N|r| Parameter ID |r|r|r|r| Length | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 M Flag: When set indicates the subsequent parameter MUST be 1632 interpreted. Otherwise the parameter can be ignored if not 1633 understood. 1634 E Flag: When set indicates either a) a reservation failure where the 1635 QSPEC parameter is not met, or b) an error occurred when this 1636 parameter was being interpreted (see Section 4.2.1). 1637 N Flag: Not-supported QSPEC parameter flag (see Section 4.2.2). 1638 Parameter ID: Assigned consecutively to each QSPEC parameter 1639 (parameter ID's are assigned to each QSPEC parameter 1640 defined in this document in Section 5.2 below and in 1641 Section 7/IANA Considerations). 1643 Parameters are usually coded individually, for example, the parameter (Section 5.2.11). However, it is also possible 1645 to combine several sub-parameters into one parameter field, which is 1646 called 'container coding'. This coding is useful if either a) the 1647 sub-parameters always occur together, as for example the 5 1648 sub-parameters that jointly make up the TMOD, or b) in order 1649 to make coding more efficient when the length of each sub-parameter 1650 value is much less than a 32-bit word (as for example described in 1651 [RMD-QOSM]) and to avoid header overload. When a container is 1652 defined, the Parameter ID and the M, E, and N flags refer to the 1653 container. Examples of container parameters are (specified 1654 below) and the PHR container parameter specified in [RMD-QOSM]. 1656 5.2 QSPEC Parameter Coding 1658 The references in the following sections point to the normative 1659 procedures for processing the QSPEC parameters and 1660 sub-parameters. 1662 5.2.1 Parameter 1664 The parameter consists of the , ,

, , and 1665 sub-parameters [RFC2212], which all must be populated in the 1666 parameter. Note that a second TMOD QSPEC parameter is 1667 specified below in Section 5.2.2. 1669 The coding for the parameter is as follows: 1671 0 1 2 3 1672 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 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 |1|E|0|r| 1 |r|r|r|r| 5 | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 The parameters are represented by three floating point 1688 numbers in single-precision IEEE floating point format [IEEE754] 1689 followed by two 32-bit integers in network octet order. The first 1690 floating point value is the rate (r), the second floating point value 1691 is the bucket size (b), the third floating point is the peak rate 1692 (p), the first unsigned integer is the minimum policed unit (m), and 1693 the second unsigned integer is the maximum packet size (MPS). The 1694 values of r and p are measured in octets/second, b, m, and MPS are 1695 measured in octets. When r, b, and p terms are represented as IEEE 1696 floating point values, the sign bit MUST be zero (all values MUST be 1697 non-negative). Exponents less than 127 (i.e., 0) are prohibited. 1698 Exponents greater than 162 (i.e., positive 35) are discouraged, 1699 except for specifying a peak rate of infinity. Infinity is 1700 represented with an exponent of all ones (255) and a sign bit and 1701 mantissa of all zeroes. 1703 5.2.2 Parameter 1705 A second QSPEC parameter is specified as could be needed for 1706 example to support some DiffServ applications. 1708 The coding for the parameter is as follows: 1710 0 1 2 3 1711 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 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 |M|E|N|r| 2 |r|r|r|r| 5 | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | TMOD Rate-2 (r) (32-bit IEEE floating point number) | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | TMOD Size-2 (b) (32-bit IEEE floating point number) | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | Peak Data Rate-2 (p) (32-bit IEEE floating point number) | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | Minimum Policed Unit-2 (m) (32-bit unsigned integer) | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | Maximum Packet Size-2 (MPS) (32-bit unsigned integer) | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 The parameters are represented by three floating point 1727 numbers in single-precision IEEE floating point format [IEEE754] 1728 followed by two 32-bit integers in network octet order. The first 1729 floating point value is the rate (r), the second floating point value 1730 is the bucket size (b), the third floating point is the peak rate 1731 (p), the first unsigned integer is the minimum policed unit (m), and 1732 the second unsigned integer is the maximum packet size (MPS). The 1733 values of r and p are measured in octets/second, b, m, and MPS are 1734 measured in octets. When r, b, and p terms are represented as IEEE 1735 floating point values, the sign bit MUST be zero (all values MUST be 1736 non-negative). Exponents less than 127 (i.e., 0) are prohibited. 1737 Exponents greater than 162 (i.e., positive 35) are discouraged, 1738 except for specifying a peak rate of infinity. Infinity is 1739 represented with an exponent of all ones (255) and a sign bit and 1740 mantissa of all zeroes. 1742 5.2.3 Parameter 1744 0 1 2 3 1745 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 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 |M|E|N|r| 3 |r|r|r|r| 1 | 1748 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1749 | Path Latency (32-bit unsigned integer) | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 The Path Latency [RFC2215] is a single 32-bit unsigned integer in 1753 network octet order. The intention of the Path Latency parameter is 1754 the same as the Minimal Path Latency parameter defined in Section 3.4 1755 of [RFC2215]. The purpose of this parameter is to provide a baseline 1756 minimum path latency for use with services which provide estimates or 1757 bounds on additional path delay, such as in [RFC2212]. Together with 1758 the queuing delay bound offered by [RFC2212] and similar services, 1759 this parameter gives the application knowledge of both the minimum 1760 and maximum packet delivery delay. 1762 The composition rule for the parameter is summation 1763 with a clamp of (2**32) - 1 on the maximum value. The latencies are 1764 average values reported in units of one microsecond. A system with 1765 resolution less than one microsecond MUST set unused digits to zero. 1766 An individual QNE can add a latency value between 1 and 2**28 1767 (somewhat over two minutes) and the total latency added across all 1768 QNEs can range as high as (2**32)-2. If the sum of the different 1769 elements delays exceeds (2**32)-2, the end-to-end cumulative delay 1770 SHOULD be reported as indeterminate = (2**32)-1. A QNE that cannot 1771 accurately predict the latency of packets it is processing MUST raise 1772 the not-supported flag and either leave the value of Path Latency as 1773 is, or add its best estimate of its lower bound. A raised 1774 not-supported flag indicates the value of Path Latency is a lower 1775 bound of the real Path Latency. The distinguished value (2**32)-1 is 1776 taken to mean indeterminate latency because the composition function 1777 limits the composed sum to this value, it indicates the range of the 1778 composition calculation was exceeded. 1780 5.2.4 Parameter 1782 0 1 2 3 1783 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 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 |M|E|N|r| 4 |r|r|r|r| 4 | 1786 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1787 | Path Jitter STAT1(variance) (32-bit unsigned integer) | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer) | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Path Jitter STAT3(minimum Latency) (32-bit unsigned integer) | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Path Jitter STAT4(Reserved) (32-bit unsigned integer) | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 The Path Jitter is a set of four 32-bit unsigned integers in network 1797 octet order [RFC3393, Y.1540, Y.1541]. As noted in Section 3.3.2, the 1798 Path Jitter parameter is called "IP Delay Variation" in [RFC3393]. 1799 The Path Jitter parameter is the combination of four statistics 1800 describing the Jitter distribution with a clamp of (2**32) - 1 on the 1801 maximum of each value. The jitter STATs are reported in units of one 1802 microsecond. A system with resolution less than one microsecond MUST 1803 set unused digits to zero. An individual QNE can add jitter values 1804 between 1 and 2**28 (somewhat over two minutes) and the total jitter 1805 computed across all QNEs can range as high as (2**32)-2. If the 1806 combination of the different element values exceeds (2**32)-2, the 1807 end-to-end cumulative jitter SHOULD be reported as indeterminate. A 1808 QNE that cannot accurately predict the jitter of packets it is 1809 processing MUST raise the not-supported flag and either leave the 1810 value of Path Jitter as is, or add its best estimate of its STAT 1811 values. A raised not-supported flag indicates the value of Path 1812 Jitter is a lower bound of the real Path Jitter. The distinguished 1813 value (2**32)-1 is taken to mean indeterminate jitter. A QNE that 1814 cannot accurately predict the jitter of packets it is processing 1815 SHOULD set its local path jitter parameter to this value. Because 1816 the composition function limits the total to this value, receipt of 1817 this value at a network element or application indicates that the 1818 true path jitter is not known. This MAY happen because one or more 1819 network elements could not supply a value, or because the range of 1820 the composition calculation was exceeded. 1822 NOTE: The Jitter composition function makes use of the 1823 parameter. Composition functions for loss, latency and jitter may be 1824 found in [Y.1541]. Development continues on methods to combine jitter 1825 values to estimate the value of the complete path, and additional 1826 statistics may be needed to support new methods (the methods are 1827 standardized in [RFC5481, COMPOSITION]). 1829 5.2.5 Parameter 1831 0 1 2 3 1832 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 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 |M|E|N|r| 5 |r|r|r|r| 1 | 1835 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1836 | Path Packet Loss Ratio (32-bit floating point) | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 The Path PLR is a single 32-bit single precision IEEE floating point 1840 number in network octet order [Y.1541]. As defined in [Y.1540], Path 1841 PLR is the ratio of total lost IP packets to total transmitted IP 1842 packets. An evaluation interval of 1 minute is suggested in 1843 [Y.1541], in which the number of losses observed is directly related 1844 to the confidence in the result. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1846 value. The PLRs are reported in units of 10^-11. A system with 1847 resolution less than 10^-11 MUST set unused digits to zero. An 1848 individual QNE adds its local PLR value (up to a maximum of 10^-2) to 1849 the total Path PLR value (up to a maximum of 10^-1) , where the 1850 acceptability of the total Path PLR value added across all QNEs is 1851 determined based on the QOSM being used. The maximum limit of 10^-2 1852 on a QNE's local PLR value and the maximum limit (clamp value) of 1853 10^-1 on accumulated end-to-end Path PLR value are used to preserve 1854 the accuracy of the simple additive accumulation function specified 1855 and to avoid more complex accumulation functions. Furthermore, if 1856 these maximums are exceeded, then the path would likely not meet the 1857 QoS objectives. If the sum of the different elements values exceeds 1858 10^-1, the end-to-end cumulative PLR SHOULD be reported as 1859 indeterminate. A QNE that cannot accurately predict the PLR of 1860 packets it is processing MUST raise the not-supported flag and either 1861 leave the value of Path PLR as is, or add its best estimate of its 1862 lower bound. A raised not-supported flag indicates the value of Path 1863 PLR is a lower bound of the real Path PLR. The distinguished value 1864 10^-1 is taken to mean indeterminate PLR. A QNE which cannot 1865 accurately predict the PLR of packets it is processing SHOULD set its 1866 local path PLR parameter to this value. Because the composition 1867 function limits the composed sum to this value, receipt of this value 1868 at a network element or application indicates that the true path PLR 1869 is not known. This MAY happen because one or more network elements 1870 could not supply a value, or because the range of the composition 1871 calculation was exceeded. 1873 5.2.6 Parameter 1875 0 1 2 3 1876 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 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 |M|E|N|r| 6 |r|r|r|r| 1 | 1879 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1880 | Path Packet Error Ratio (32-bit floating point) | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 The Path PER is a single 32-bit single precision IEEE floating point 1884 number in network octet order [Y.1541. As defined in [Y.1540], Path 1885 PER is the ratio of total errored IP packets to the total of 1886 successful IP Packets plus errored IP packets, in which the number of 1887 errored packets observed is directly related to the confidence in 1888 the result. The composition rule for the parameter is 1889 summation with a clamp of 10^-1 on the maximum value. The PERs are 1890 reported in units of 10^-11. A system with resolution less than 1891 10^-11 MUST set unused digits to zero. An individual QNE adds its 1892 local PER value (up to a maximum of 10^-2) to the total Path PER 1893 value (up to a maximum of 10^-1) , where the acceptability of the 1894 total Path PER value added across all QNEs is determined based on the 1895 QOSM being used. The maximum limit of 10^-2 on a QNE's local PER 1896 value and the maximum limit (clamp value) of 10^-1 on accumulated 1897 end-to-end Path PER value are used to preserve the accuracy of the 1898 simple additive accumulation function specified and to avoid more 1899 complex accumulation functions. Furthermore, if these maximums are 1900 exceeded, then the path would likely not meet the QoS objectives. 1901 If the sum of the different elements values exceeds 10^-1, the 1902 end-to-end cumulative PER SHOULD be reported as indeterminate. A QNE 1903 that cannot accurately predict the PER of packets it is processing 1904 MUST raise the not-supported flag and either leave the value of Path 1905 PER as is, or add its best estimate of its lower bound. A raised 1906 not-supported flag indicates the value of Path PER is a lower bound 1907 of the real Path PER. The distinguished value 10^-1 is taken to mean 1908 indeterminate PER. A QNE which cannot accurately predict the PER of 1909 packets it is processing SHOULD set its local path PER parameter to 1910 this value. Because the composition function limits the composed sum 1911 to this value, receipt of this value at a network element or 1912 application indicates that the true path PER is not known. This MAY 1913 happen because one or more network elements could not supply a value, 1914 or because the range of the composition calculation was exceeded. 1916 5.2.7 Parameter 1918 0 1 2 3 1919 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 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 |M|E|N|r| 7 |r|r|r|r| 1 | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Slack Term (S) (32-bit unsigned integer) | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 Slack term S MUST be nonnegative and is measured in microseconds 1927 [RFC2212]. The Slack term, S, is represented as a 32-bit unsigned 1928 integer. Its value can range from 0 to (2**32)-1 microseconds. 1930 5.2.8 & Parameters 1932 The coding for the & 1933 sub-parameters is as follows RFC3181]: 1935 0 1 2 3 1936 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 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 |M|E|N|r| 8 |r|r|r|r| 1 | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Preemption Priority | Defending Priority | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 Preemption Priority: The priority of the new flow compared with the 1944 defending priority of previously admitted flows. Higher values 1945 represent higher priority. 1947 Defending Priority: Once a flow is admitted, the preemption priority 1948 becomes irrelevant. Instead, its defending priority is used to 1949 compare with the preemption priority of new flows. 1951 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 1953 parameter is used. 1955 5.2.9 Parameter 1957 The coding for the parameter is as follows: 1959 0 1 2 3 1960 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 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 |M|E|N|r| 9 |r|r|r|r| 1 | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 |Y.2171 Adm Pri.|Admis. Priority| (Reserved) | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 Two fields are provided for the parameter and 1968 are populated according to the following rules. 1970 values are globally significant on an 1971 end-to-end basis. High priority flows, normal priority flows, and 1972 best-effort priority flows can have access to resources depending on 1973 their admission priority value, as described in [Y.2171], as follows: 1975 : 1977 0 - best-effort priority flow 1978 1 - normal priority flow 1979 2 - high priority flow 1981 If the QNI signals , it populates both 1982 the and fields with 1983 the same value. Downstream QNEs MUST NOT change the value in the 1984 field so that end-to-end consistency is 1985 maintained and MUST treat the flow priority according to the value 1986 populated. A QNE in a local domain MAY reset a different value of 1987 in a local QSPEC, but as specified in Section 1988 4.1 the local QSPEC MUST be consistent with the initiator QSPEC. 1989 That is, the local domain MUST specify an in the 1990 local QSPEC functionally equivalent to the specified by the QNI in the initiator QSPEC. 1993 If the QNI signals admission priority according to [EMERGENCY-RSVP], 1994 it populates a locally significant value in the 1995 field and places all 1's in the field. 1996 In this case the functional significance of the 1997 value is specified by the local network administrator. Higher 1998 values indicate higher priority. Downstream QNEs and RSVP nodes MAY 1999 reset the value according to the local rules 2000 specified by the local network administrator, but MUST NOT reset the 2001 value of the field. 2003 A reservation without an parameter MUST 2004 be treated as a reservation with an = 1. 2006 5.2.10 Parameter 2008 The coding for the parameter is as follows: 2010 0 1 2 3 2011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 |M|E|N|r| 10 |r|r|r|r| 1 | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | RPH Namespace | RPH Priority | (Reserved) | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 [RFC4412] defines a resource priority header (RPH) with parameters 2019 "RPH Namespace" and "RPH Priority", and if populated is applicable 2020 only to flows with high admission priority. A registry is created 2021 in [RFC4412] and extended in [EMERGENCY-RSVP] for IANA to assign 2022 the RPH priority parameter. In the extended registry, "Namespace 2023 Numerical Values" are assigned by IANA to RPH Namespaces and 2024 "Priority Numerical Values" are assigned to the RPH Priority. 2026 Note that the parameter MAY be used in 2027 combination with the parameter, which depends on the 2028 supported QOSM. Furthermore, if more than one RPH namespace is 2029 supported by a QOSM, then the QOSM MUST specify how the mapping 2030 between the priorities belonging to the different RPH namespaces are 2031 mapped to each other. 2033 Note also that additional work is needed to communicate these flow 2034 priority values to bearer-level network elements 2035 [VERTICAL-INTERFACE]. 2037 For the 4 priority parameters, the following cases are permissible 2038 (procedures specified in references): 2040 1 parameter: [Y.2171] 2041 2 parameters: , [RFC4412] 2042 2 parameters: , [RFC3181] 2043 3 parameters: , , 2044 [3GPP-1, 3GPP-2, 3GPP-3] 2045 4 parameters: , , 2046 , [3GPP-1, 3GPP-2, 2047 3GPP-3] 2049 It is permissible to have without , but not permissible to have without 2051 (alternatively is ignored in 2052 instances without ). 2054 eMLPP-like functionality (as defined in [3GPP-1, 3GPP-2]) specifies 2055 use of corresponding to the 'queuing allowed' 2056 part of eMLPP as well as 2057 corresponding to the 'preemption capable' and 'may be preempted' 2058 parts of eMLPP. 2060 5.2.11 Parameter 2061 0 1 2 3 2062 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 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 |M|E|N|r| 11 |r|r|r|r| 1 | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | Excess Trtmnt |Remark Value | Reserved | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 2070 traffic, that is, traffic not covered by the parameter. 2071 The excess treatment parameter is set by the QNI. Allowed values are 2072 as follows: 2074 0: drop 2075 1: shape 2076 2: remark 2077 3: no metering or policing is permitted 2079 The default excess treatment in case that no Excess Treatment 2080 Parameter is specified is that there are no guarantees to excess 2081 traffic, i.e. a QNE can do whatever it finds suitable. 2083 When excess treatment is set to 'drop', all marked traffic MUST be 2084 dropped by the QNE/RMF. 2086 When excess treatment is set to 'shape', it is expected that the QoS 2087 Desired object carries a TMOD parameter and excess traffic is shaped 2088 to this TMOD. The bucket size in the TMOD parameter for excess 2089 traffic specifies the queuing behavior, and when the shaping causes 2090 unbounded queue growth at the shaper, any traffic in excess of the 2091 TMOD for excess traffic SHOULD be dropped. If excess treatment is 2092 set to 'shape' and no TMOD parameter is given, the E flag is set for 2093 the parameter and the reservation fails. If excess treatment is set 2094 to 'shape' and two TMOD parameters are specified, then the QOSM 2095 specification dictates how excess traffic should be shaped in that 2096 case. 2098 When excess treatment is set to 'remark', the excess treatment 2099 parameter MUST carry the remark value, and the remark values and 2100 procedures MUST be specified in the QOSM specification document. For 2101 example, packets may be remarked to pertain to a particular QoS class 2102 (DSCP value). In the latter case, remarking relates to a DiffServ 2103 model where packets arrive marked as belonging to a certain QoS 2104 class/DSCP, and when they are identified as excess, they should then 2105 be remarked to a different QoS Class (DSCP value) indicated in the 2106 'Remark Value', as follows: 2108 Remark Value (6 bits): indicates DSCP value [RFC2474] to remark 2109 packets to when identified as excess 2111 If 'no metering or policing is permitted' is signaled, the QNE should 2112 accept the excess treatment parameter set by the sender with special 2113 care so that excess traffic should not cause a problem. To request 2114 the Null Meter [RFC3290] is especially strong, and should be used 2115 with caution. 2117 A NULL metering application [RFC2997] would not include the traffic 2118 profile, and conceptually it should be possible to support this with 2119 the QSPEC. A QSPEC without a traffic profile is not excluded by the 2120 current specification. However, note that the traffic profile is 2121 important even in those cases when the excess treatment is not 2122 specified, e.g., in negotiating bandwidth for the best effort 2123 aggregate. However, a "NULL Service QOSM" would need to be specified 2124 where the desired QNE Behavior and the corresponding QSPEC format are 2125 described. 2127 As an example behavior for a NULL metering, in the properly 2128 configured DiffServ router, the resources are shared between the 2129 aggregates by the scheduling disciplines. Thus, if the incoming rate 2130 increases, it will influence the state of a queue within that 2131 aggregate, while all the other aggregates will be provided sufficient 2132 bandwidth resources. NULL metering is useful for best effort and 2133 signaling data, where there is no need to meter and police this data 2134 as it will be policed implicitly by the allocated bandwidth and, 2135 possibly, active queue management mechanism. 2137 5.2.12 Parameter 2139 The coding for the parameter is as follows [RFC3140]: 2141 0 1 2 3 2142 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 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 |M|E|N|r| 12 |r|r|r|r| 1 | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | PHB Field | (Reserved) | 2147 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2149 The above encoding is consistent with [RFC3140], and the following 2150 Four figures show four possible formats based on the value of the PHB 2151 Field. 2153 Single PHB: 2155 0 1 2156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | DSCP |0 0 0 0 0 0 0 0 0 0| 2159 +---+---+---+---+---+---+---+---+ 2161 Set of PHBs: 2163 0 1 2164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | DSCP |0 0 0 0 0 0 0 0 1 0| 2167 +---+---+---+---+---+---+---+---+ 2169 PHBs not defined by standards action, i.e., experimental or local use 2170 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 2171 identification code, assigned by the IANA, is placed left-justified 2172 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 2173 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 2175 Single non-standard PHB (experimental or local): 2177 0 1 2178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | PHB ID CODE |0 0 0 1| 2181 +---+---+---+---+---+---+---+---+ 2183 Set of non-standard PHBs (experimental or local): 2185 0 1 2186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | PHB ID CODE |0 0 1 1| 2189 +---+---+---+---+---+---+---+---+ 2191 Bits 12 and 13 are reserved either for expansion of the PHB 2192 identification code, or for other use, at some point in the future. 2194 In both cases, when a single PHBID is used to identify a set of PHBs 2195 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 2196 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 2197 intra-microflow traffic reordering when different PHBs from the set 2198 are applied to traffic in the same microflow). The set of AF1x PHBs 2199 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs 2200 that do not constitute a PHB Scheduling Class can be identified by 2201 using more than one PHBID. 2203 The registries needed to use RFC 3140 already exist, see 2204 [DSCP-REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs 2205 to be created for this purpose. 2207 5.2.13 Parameter 2209 A description of the semantic of the parameter values can be found in 2210 [RFC4124]. The coding for the parameter is as 2211 follows: 2213 0 1 2 3 2214 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 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 |M|E|N|r| 13 |r|r|r|r| 1 | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 |DSTE Cls. Type | (Reserved) | 2219 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2221 DSTE Class Type: Indicates the DSTE class type. Values currently 2222 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 2224 5.2.14 Parameter 2226 The coding for the parameter [Y.1541] is as 2227 follows: 2229 0 1 2 3 2230 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 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 |M|E|N|r| 14 |r|r|r|r| 1 | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 |Y.1541 QoS Cls.| (Reserved) | 2235 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2237 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 2238 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 2240 Class 0: 2241 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 2242 Real-time, highly interactive applications, sensitive to jitter. 2243 Application examples include VoIP, Video Teleconference. 2245 Class 1: 2246 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 2247 Real-time, interactive applications, sensitive to jitter. 2248 Application examples include VoIP, Video Teleconference. 2250 Class 2: 2251 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 2252 10^-3. Highly interactive transaction data. Application examples 2253 include signaling. 2255 Class 3: 2256 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 2258 10^-3. Interactive transaction data. Application examples include 2259 signaling. 2261 Class 4: 2262 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 2263 10^-3. Low Loss Only applications. Application examples include 2264 short transactions, bulk data, video streaming. 2266 Class 5: 2267 Mean delay unspecified, delay variation unspecified, loss ratio 2268 unspecified. Unspecified applications. Application examples include 2269 traditional applications of default IP networks. 2271 Class 6: 2272 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 2273 Applications that are highly sensitive to loss, such as television 2274 transport, high-capacity TCP transfers, and TDM circuit emulation. 2276 Class 7: 2277 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 2278 Applications that are highly sensitive to loss, such as television 2279 transport, high-capacity TCP transfers, and TDM circuit emulation. 2281 6. Security Considerations 2283 QSPEC security is directly tied to QoS NSLP security, and the QoS 2284 NSLP document [QoS-NSLP] has a very detailed security discussion in 2285 Section 7. All the considerations detailed in Section 7 of 2286 [QoS-NSLP] apply to QSPEC. 2288 The priority parameter raises possibilities for theft of service 2289 attacks because users could claim an emergency priority for their 2290 flows without real need, thereby effectively preventing serious 2291 emergency calls to get through. Several options exist for countering 2292 such attacks, for example 2294 - only some user groups (e.g. the police) are authorized to set the 2295 emergency priority bit 2297 - any user is authorized to employ the emergency priority bit for 2298 particular destination addresses (e.g. police) 2300 7. IANA Considerations 2302 This section defines the registries and initial codepoint assignments 2303 for the QSPEC template, in accordance with BCP 26 RFC 5226 [RFC5226]. 2304 It also defines the procedural requirements to be followed by IANA in 2305 allocating new codepoints. 2307 This specification creates the following registries with the 2308 structures as defined below: 2310 Object Types (12 bits): 2311 The following values are allocated as specified in Section 5: 2312 0: QoS Desired 2313 1: QoS Available 2314 2: QoS Reserved 2315 3: Minimum QoS 2316 The allocation policies for further values are as follows: 2318 4-63: Specification Required 2319 64-67: Private/Experimental Use 2320 68-4095: Reserved 2321 (Note: 'Reserved' just means 'do not give these out'.) 2323 QSPEC Version (4 bits): 2324 The following value is allocated by this specification: 2325 0: assigned to Version 0 QSPEC 2326 The allocation policies for further values are as follows: 2327 1-15: Specification Required 2328 A specification is required to depreciate, delete, or modify QSPEC 2329 versions. 2331 QSPEC Type (5 bits): 2332 The following values are allocated by this specification: 2333 0: Default 2334 1: Y.1541-QOSM [Y.1541-QOSM] 2335 2: RMD-QOSM [RMD-QOSM] 2336 The allocation policies for further values are as follows: 2337 3-12: Specification Required 2338 13-16: Local/Experimental Use 2339 17-31: Reserved 2341 QSPEC Procedure (8 bits): 2342 The QSPEC Procedure object consists of the Message Sequence 2343 parameter (4 bits) and the Object Combination parameter (4 bits), as 2344 discussed in Section 4.3. Message Sequences 0 (Two-Way 2345 Transactions), 1 (Three-Way Transactions), and 2 (Resource Queries) 2346 are explained in Sections 4.3.1, 4.3.2, and 4.3.3, respectively. 2347 Tables 1, 2, and 3 in Section 4.3 assign the Object Combination # to 2348 Message Sequences 0, 1, and, 2, respectively. The values assigned by 2349 this specification for the Message Sequence parameter and the Object 2350 Combination parameter are summarized here: 2352 MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED 2353 SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE 2354 ------------------------------------------------------------------- 2355 0 |0 |N/A |QoS Desired |QoS Reserved 2356 | | | | 2357 0 |1 |N/A |QoS Desired |QoS Reserved 2358 | |N/A |QoS Available |QoS Available 2359 | | | | 2360 0 |2 |N/A |QoS Desired |QoS Reserved 2361 | |N/A |QoS Available |QoS Available 2362 | |N/A |Minimum QoS | 2363 | | | | 2364 1 |0 |QoS Desired |QoS Desired |QoS Reserved 2365 | | | | 2366 1 |1 |QoS Desired |QoS Desired |QoS Reserved 2367 | |Minimum QoS |QoS Available |QoS Available 2368 | | |(Minimum QoS) | 2369 | | | | 2370 1 |2 |QoS Desired |QoS Desired |QoS Reserved 2371 | |QoS Available |QoS Available | 2372 | | | | 2373 2 |0 |QoS Available |N/A |QoS Available 2375 The allocation policies for further values of the Message Sequence 2376 parameter (4 bits) are as follows: 2377 3-15: Specification Required 2378 The allocation policies for further values of the Object Combination 2379 parameter (4 bits) are as follows: 2380 3-15: Specification Required (Message Sequence 0) 2381 2-15: Specification Required (Message Sequence 1) 2382 1-15: Specification Required (Message Sequence 2) 2383 0-15: Specification Required (Message Sequence 3-15) 2385 A specification is required to depreciate, delete, or modify QSPEC 2386 Procedures. 2388 Error Code (8 bits) 2389 Error Codes may be defined for INFO_SPEC error class 0x06 (QoS Model 2390 Error), as described in Section 6.4 of [QoS-NSLP]. 2391 The allocation policies are as follows: 2392 0-63: Specification Required 2393 64-67: Private/Experimental Use 2394 68-255: Reserved 2396 A specification is required to depreciate, delete, or modify Error 2397 Codes. 2399 Parameter ID (12 bits): 2400 The following values are allocated by this specification: 2401 1-14: assigned as specified in Section 5.2: 2402 Parameter ID 1: 2403 2: 2404 3: 2405 4: 2406 5: 2407 6: 2408 7: 2409 8: & 2410 9: 2411 10: 2412 11: 2413 12: 2414 13: 2415 14: 2417 The allocation policies for further values are as follows: 2418 15-255: Specification Required 2419 256-259: Private/Experimental Use 2420 260-4095: Reserved 2422 A specification is required to depreciate, delete, or modify 2423 Parameter IDs. 2425 Y.2171 Admission Priority Parameter (8 bits): 2426 The following values are allocated by this specification: 2427 0-2: assigned as specified in Section 5.2.9: 2428 Y.2171 Admission Priority 0: best-effort priority flow 2429 1: normal priority flow 2430 2: high priority flow 2431 The allocation policies for further values are as follows: 2432 3-63: Specification Required 2433 64-255: Reserved 2434 RPH Namespace Parameter (16 bits): 2435 Note that [RFC4412] creates a registry for RPH Namespace and Priority 2436 values already (see Section 12.6 of [RFC4412]), and an extension to 2437 this registry is created in [EMERGENCY-RSVP], which will also be used 2438 for the QSPEC RPH parameter. In the extended registry, "Namespace 2439 Numerical Values" are assigned by IANA to RPH Namespaces and 2440 "Priority Numerical Values" are assigned to the RPH Priority. There 2441 are no additional IANA requirements made by this specification for 2442 the RPH Namespace Parameter. 2444 Excess Treatment Parameter (8 bits): 2445 The following values are allocated by this specification: 2446 0-3: assigned as specified in Section 5.2.11: 2447 Excess Treatment Parameter 0: drop 2448 1: shape 2449 2: remark 2450 3: no metering or policing is 2451 permitted 2452 The allocation policies for further values are as follows: 2453 4-63: Specification Required 2454 64-255: Reserved 2455 Y.1541 QoS Class Parameter (8 bits): 2456 The following values are allocated by this specification: 2457 0-7: assigned as specified in Section 5.2.14: 2458 Y.1541 QoS Class Parameter 0: Y.1541 QoS Class 0 2459 1: Y.1541 QoS Class 1 2460 2: Y.1541 QoS Class 2 2461 3: Y.1541 QoS Class 3 2462 4: Y.1541 QoS Class 4 2463 5: Y.1541 QoS Class 5 2464 6: Y.1541 QoS Class 6 2465 7: Y.1541 QoS Class 7 2466 The allocation policies for further values are as follows: 2467 8-63: Specification Required 2468 64-255: Reserved 2470 8. Acknowledgements 2472 The authors would like to thank (in alphabetical order) David Black, 2473 Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger 2474 Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, 2475 Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Tom Phelan, 2476 James Polk, Alexander Sayenko, John Rosenberg, Hannes Tschofenig, and 2477 Sven van den Bosch for their very helpful suggestions. 2479 9. Contributors 2481 This document is the result of the NSIS Working Group effort. In 2482 addition to the authors/editors listed in Section 12, the following 2483 people contributed to the document: 2485 Roland Bless 2486 Institute of Telematics, Universitaet Karlsruhe (TH) 2487 Zirkel 2 2488 Karlsruhe 76131 2489 Germany 2490 Phone: +49 721 608 6413 2491 Email: bless@tm.uka.de 2492 URI: http://www.tm.uka.de/~bless 2494 Chuck Dvorak 2495 AT&T 2496 Room 2A37 2497 180 Park Avenue, Building 2 2498 Florham Park, NJ 07932 2499 Phone: + 1 973-236-6700 2500 Fax:+1 973-236-7453 2501 Email: cdvorak@research.att.com 2503 Yacine El Mghazli 2504 Alcatel 2505 Route de Nozay 2506 91460 Marcoussis cedex 2507 FRANCE 2508 Phone: +33 1 69 63 41 87 2509 Email: yacine.el_mghazli@alcatel.fr 2511 Georgios Karagiannis 2512 University of Twente 2513 P.O. BOX 217 2514 7500 AE Enschede 2515 The Netherlands 2516 Email: g.karagiannis@ewi.utwente.nl 2518 Andrew McDonald 2519 Siemens/Roke Manor Research 2520 Roke Manor Research Ltd. 2521 Romsey, Hants SO51 0ZN 2522 UK 2523 Email: andrew.mcdonald@roke.co.uk 2525 Al Morton 2526 AT&T 2527 Room D3-3C06 2528 200 S. Laurel Avenue 2529 Middletown, NJ 07748 2530 Phone: + 1 732 420-1571 2531 Fax: +.1 732 368-1192 2532 Email: acmorton@att.com 2534 Bernd Schloer 2535 University of Goettingen 2536 Email: bschloer@cs.uni-goettingen.de 2538 Percy Tarapore 2539 AT&T 2540 Room D1-33 2541 200 S. Laurel Avenue 2542 Middletown, NJ 07748 2543 Phone: + 1 732 420-4172 2544 Email: tarapore@.att.com 2546 Lars Westberg 2547 Ericsson Research 2548 Torshamnsgatan 23 2549 SE-164 80 Stockholm, Sweden 2550 Email: Lars.Westberg@ericsson.com 2552 10. Normative References 2554 [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 2555 3rd Generation Partnership Project; Technical Specification 2556 Group Services and System Aspects; enhanced Multi Level 2557 Precedence and Preemption service (eMLPP) - Stage 1 2558 (Release 7). 2560 [3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 2561 3rd Generation Partnership Project; Technical Specification 2562 Group Core Network; enhanced Multi-Level Precedence and 2563 Preemption service (eMLPP) - Stage 2 (Release 7). 2565 [3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 2566 3rd Generation Partnership Project; Technical Specification 2567 Group Core Network; enhanced Multi-Level Precedence and 2568 Preemption service (eMLPP) - Stage 3 (Release 6). 2570 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 2571 Signaling Transport," work in progress. 2573 [QoS-NSLP] Manner, J., et al., "NSLP for Quality-of-Service 2574 Signaling," work in progress. 2576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2577 Requirement Levels", BCP 14, RFC 2119, March 1997. 2579 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2580 Services", RFC 2210, September 1997. 2582 [RFC2212] Shenker, S., et al., "Specification of Guaranteed Quality 2583 of Service," September 1997. 2585 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 2586 Parameters for Integrated Service Network Elements", RFC 2587 2215, Sept. 1997. 2589 [RFC3140] Black, D., et al., "Per Hop Behavior Identification 2590 Codes," June 2001. 2592 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element," 2593 RFC 3181, October 2001. 2595 [RFC4124] Le Faucheur, F., et al., "Protocol Extensions for Support 2596 of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2597 2005. 2599 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 2600 Priority for the Session Initiation Protocol(SIP)," RFC 2601 4412, February 2006. 2603 [RFC4506] Eisler, M., "XDR: External Data Representation Standard," 2604 RFC 4506, May 2006. 2606 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 2607 Objectives for IP-Based Services," February 2006. 2609 [Y.2171] ITU-T Recommendation Y.2171, "Admission Control Priority 2610 Levels in Next Generation Networks," September 2006. 2612 11. Informative References 2614 [COMPOSITION] Morton, A.,Stephan, E., "Spacial Composition of 2615 Metrics," work in progress. 2617 [DQOS] Cablelabs, "PacketCable Dynamic Quality of Service 2618 Specification," CableLabs Specification 2619 PKT-SP-DQOS-I12-050812, August 2005. 2621 [EMERGENCY-RSVP] Le Faucheur, F., et. al., "Resource ReSerVation 2622 Protocol (RSVP) Extensions for Emergency Services," work in 2623 progress. 2625 [G.711] ITU-T Recommendation G.711, "Pulse code modulation (PCM) of 2626 voice frequencies," November 1988. 2628 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 2629 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE 2630 Standard 754-1985, August 1985. 2632 [CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 2633 Controlled-Load Service with NSIS," work in progress. 2635 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry. 2637 [NETWORK-OCTET-ORDER] Wikipedia, "Endianness," 2638 http://en.wikipedia.org/wiki/Endianness. 2640 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes. 2642 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 2643 Protocol - Capability Set 3," September 2003. 2645 [RFC1701] Hanks, S., et. al., "Generic Routing Encapsulation (GRE)," 2646 RFC 1701, October 1994. 2648 [RFC1702] Hanks, S., et. al., "Generic Routing Encapsulation over 2649 IPv4 Networks," RFC 1702, October 1994. 2651 [RFC2003] Perkins, C., "IP Encapsulation within IP," RFC 2003, 2652 October 1996. 2654 [RFC2004] Perkins, C., "Minimal Encapsulation within IP," RFC 2004, 2655 October 1996. 2657 [RFC2205] Braden, B., et al., "Resource ReSerVation Protocol (RSVP) 2658 -- Version 1 Functional Specification," RFC 2205, September 2659 1997. 2661 [RFC2473] Conta, A., Deering, S., "Generic Packet Tunneling in IPv6 2662 Specification," RFC 2473, December 1998. 2664 [RFC2474] Nichols, K., et al., "Definition of the Differentiated 2665 Services Field (DS Field) in the IPv4 and IPv6 Headers," 2666 RFC 2474, December 1998. 2668 [RFC2475] Blake, S., et al., "An Architecture for Differentiated 2669 Services", RFC 2475, December 1998. 2671 [RFC2597] Heinanen, J., et al., "Assured Forwarding PHB Group," RFC 2672 2597, June 1999. 2674 [RFC2697] Heinanen, J., et al., "A Single Rate Three Color Marker," 2675 RFC 2697, September 1999. 2677 [RFC2997] Bernet, Y., et al., "Specification of the Null Service 2678 Type," RFC 2997, November 2000. 2680 [RFC3290] Bernet, Y., et al., "An Informal Management Model for 2681 Diffserv Routers," RFC 3290, May 2002. 2683 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 2684 Metric for IP Performance Metrics (IPPM), RFC 3393, 2685 November 2002. 2687 [RFC3550] Schulzrinne, H., et. al., "RTP: A Transport Protocol for 2688 Real-Time Applications," RFC 3550, July 2003. 2690 [RFC3564] Le Faucheur, F., et al., "Requirements for Support of 2691 Differentiated Services-aware MPLS Traffic Engineering," 2692 RFC 3564, July 2003. 2694 [RFC4213] Nordmark, E., Gilligan, R., "Basic Transition Mechanisms 2695 for IPv6 Hosts and Routers," RFC 4213, October 2005. 2697 [RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet 2698 Protocol," RFC 4301, December 2005. 2700 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)," RFC 2701 4303, December 2005. 2703 [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an 2704 IANA Considerations Section in RFCs," RFC 5226, May 2008. 2706 [RFC5481] Morton, A., Claise, B., "Packet Delay Variation 2707 Applicability Statement," RFC 5481, March 2009. 2709 [RMD-QOSM] Bader, A., et al., "RMD-QOSM - The Resource Management 2710 in Diffserv QOS Model," work in progress. 2712 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 2713 on Associating of Control Signaling Messages with Media 2715 Priority Levels," T1S1.7 & PRQC, October 2004. 2717 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 2718 Communication Service - IP Packet Transfer and Availability 2719 Performance Parameters," December 2002. 2721 [Y.1541-QOSM] Ash, J., et al., "Y.1541-QOSM -- Y.1541 QoS Model for 2722 Networks Using Y.1541 QoS Classes," work in progress. 2724 12. Authors' Addresses 2726 Gerald Ash (Editor) 2727 AT&T 2728 Email: gash5107@yahoo.com 2730 Attila Bader (Editor) 2731 Traffic Lab 2732 Ericsson Research 2733 Ericsson Hungary Ltd. 2734 Laborc u. 1 H-1037 2735 Budapest Hungary 2736 Email: Attila.Bader@ericsson.com 2738 Cornelia Kappler (Editor) 2739 deZem GmbH 2740 Knesebeckstr. 86/87 2741 10623 Berlin 2742 Germany 2743 Email: cornelia.kappler@googlemail.com 2745 David R. Oran (Editor) 2746 Cisco Systems, Inc. 2747 7 Ladyslipper Lane 2748 Acton, MA 01720, USA 2749 Email: oran@cisco.com 2751 Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved of 2752 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 2754 The union of QoS Desired, QoS Available and QoS Reserved can provide 2755 all functionality of the objects specified in RSVP IntServ, however 2756 it is difficult to provide an exact mapping. 2758 In RSVP, the Sender TSpec specifies the traffic an application is 2759 going to send (e.g. TMOD). The AdSpec can collect path 2760 characteristics (e.g. delay). Both are issued by the sender. The 2761 receiver sends the FlowSpec which includes a Receiver TSpec 2762 describing the resources reserved using the same parameters as the 2763 Sender TSpec, as well as a RSpec which provides additional IntServ 2764 QoS Model specific parameters, e.g. Rate and Slack. 2766 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 2767 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 2768 knowledge of the authors it is not possible for the sender to specify 2769 a desired maximum delay except implicitly and mutably by seeding the 2770 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 2771 the receiver-issued RSVP RESERVE message. For this reason our 2772 discussion at this point leads us to a slightly different mapping of 2773 necessary functionality to objects, which should result in more 2774 flexible signaling models. 2776 Appendix B. Example of TMOD Parameter Encoding 2778 An example VoIP application that uses RTP [RFC3550] and the G.711 2779 Codec [G.711] the TMOD-1 parameter could be set as follows: 2781 In the simplest case the Minimum Policed Unit m is the sum of the 2782 IP-, UDP- and RTP- headers + payload. The IP header in the IPv4 case 2783 has a size of 20 octets (40 octets if IPv6 is used). The UDP header 2784 has a size of 8 octets and RTP uses a 12 octet header. The G.711 2785 Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming 2786 RTP transmits voice datagrams every 20ms, the payload for one 2787 datagram is 8000 octets/s * 0.02 s = 160 octets. 2789 IPv4+UDP+RTP+payload: m=20+8+12+160 octets = 200 octets 2790 IPv6+UDP+RTP+payload: m=40+8+12+160 octets = 220 octets 2792 The Rate r specifies the amount of octets per second. 50 datagrams 2793 Are sent per second. 2795 IPv4: r = 50 1/s * m = 10,000 octets/s 2796 IPv6: r = 50 1/s * m = 11,000 octets/s 2798 The bucket size b specifies the maximum burst. In this example a 2799 burst of 10 packets is used. 2801 IPv4: b = 10 * m = 2000 octets 2802 IPv6: b = 10 * m = 2200 octets 2804 A number of extra headers (e.g. for encapsulation) may be included 2805 into the datagram. A non exhaustive list is given below. For 2806 additional headers m, r and b have to be set accordingly. 2808 Protocol Header Size 2809 --------------------------+----------- 2810 GRE [RFC1701] | 8 octets 2811 GREIP4 [RFC1702] | 4-8 octets 2812 IP4INIP4 [RFC2003] | 20 octets 2813 MINENC [RFC2004] | 8-12 octets 2814 IP6GEN [RFC2473] | 40 octets 2815 IP6INIP4 [RFC4213] | 20 octets 2816 IPSec [RFC4301, RFC4303] | variable 2817 --------------------------+----------- 2819 Appendix C. Change History & Open Issues 2821 This appendix should be removed by the RFC editor before publication. 2823 C.1 Change History (since Version -14) 2825 Version -14: 2827 - Section 4.3.3 added text that QOSM specifications SHOULD NOT define 2828 new RMF functions 2829 - Section 5.1 added text that both mechanisms can be used 2830 simultaneously: a) tunneling a QSPEC through a local domain and b) 2831 defining a local QSPEC and encapsulating the initiator QSPEC 2832 - Section 4.1 added text that signaling functionality is only defined 2833 by the QoS NSLP document 2834 - Section 4.1 added text that QOSMs are free to extend QSPECs by 2835 adding parameters but are not permitted to reinterpret or redefine 2836 the standard QSPEC parameters specified in this document 2838 Version -15: 2840 - editorial revisions made to Sections 4.1, 4.3.3, 5.3.1, 5.3.2, and 2841 5.3.3 according to agreements on NSIS discussion list archive. 2843 Version -16: 2845 - QSPEC Types: additional QSPEC Types can be defined per IANA 2846 Considerations Section (already in place); QSPEC Type = 0 is 2847 default 2848 - Initiator/Local QSPEC bit added 2849 - various editorial fixes: DSCP parameter encoding; various edits 2850 carry over from QSPEC-1 parameter removal; QSPEC version number 2851 edits & additional error code 2853 Version -17: 2854 - QSPEC Header format: added Length field 2856 Version -18: 2857 - clarified handling of Traffic Handling Directives in QoS Available 2858 in Sec. 4.3.3 2859 - classified Priority Parameters as Traffic Handling Directives 2860 (Previously and erroneously were classified as Constraint 2861 Parameters) 2862 - added units to TMOD parameter in 6.2.1 2863 - fixed error in possible object combination for Resource Queries in 2864 Sec 6.1 2865 - streamlined usage of QSPEC Type and added terminology 2867 Version -19: 2868 - changes made per NSIS chair review (as specified on list) 2869 Version -20: 2870 - changes made to Section 5.2.9 (Admission Priority) as specified on 2871 List 2873 Version -21: 2874 - added example of TMOD parameter encoding (Appendix B) 2875 - eliminated IANA registry for DSTE class types 2877 Version -22: 2878 - incorporated responses to AD review comments (see 2879 http://www.ietf.org/mail-archive/web/nsis/current/msg08601.html) 2881 Version -23: 2882 - incorporated responses to Gen-Art and IANA review comments (see 2883 http://www.ietf.org/mail-archive/web/nsis/current/msg08616.html) 2885 Version -24: 2886 - incorporated responses to IESG review comments 2888 C.2 Open Issues 2890 None.