idnits 2.17.1 draft-ietf-nsis-qspec-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2809. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 3, 2008) is 5860 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NSIS-EXTENSIBILITY' is mentioned on line 2612, but not defined == Unused Reference: 'RFC4506' is defined on line 2426, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 2441, but no explicit reference was found in the text == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2447, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 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: Informational A. Bader 4 Ericsson 5 Expiration Date: October 2008 C. Kappler 6 deZem GmbH 7 D. Oran 8 Cisco Systems, Inc. 9 April 3, 2008 11 QoS NSLP QSPEC Template 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 3, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The QoS NSLP protocol is used to signal QoS reservations and is 45 independent of a specific QoS model (QOSM) such as IntServ or 46 DiffServ. Rather, all information specific to a QOSM is encapsulated 47 in a separate object, the QSPEC. This document defines a template 48 for the QSPEC including a number of QSPEC parameters. The QSPEC 49 parameters provide a common language to be re-used in several QOSMs 50 and thereby aim to ensure the extensibility and interoperability of 51 QoS NSLP. The node initiating the NSIS signaling adds an initiator 52 QSPEC, which indicates the QSPEC parameters that must be interpreted 53 by the downstream nodes less the reservation fails, thereby ensuring 54 the intention of the NSIS initiator is preserved along the signaling 55 path. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. QSPEC Framework . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2 QSPEC Objects . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.3 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 9 65 3.3.1 Traffic Model Parameter . . . . . . . . . . . . . . . 10 66 3.3.2 Constraints Parameters . . . . . . . . . . . . . . . 11 67 3.3.3 Traffic Handling Directives . . . . . . . . . . . . . 12 68 3.3.4 Traffic Classifiers . . . . . . . . . . . . . . . . . 13 69 3.4 Example of QSPEC Processing . . . . . . . . . . . . . . . . 13 70 4. QSPEC Processing & Procedures . . . . . . . . . . . . . . . . . 16 71 4.1 Local QSPEC Definition & Processing . . . . . . . . . . . . 16 72 4.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 73 Notification . . . . . . . . . . . . . . . . . . . . . . . 19 74 4.2.1 Reservation Failure & Error E Flag . . . . . . . . . 19 75 4.2.2 QSPEC Parameter Not Supported N Flag . . . . . . . . 20 76 4.2.3 INFO_SPEC Coding of Reservation Outcome . . . . . . . 20 77 4.2.4 QNE Generation of a RESPONSE message . . . . . . . . 21 78 4.2.5 Special Case of Local QSPEC . . . . . . . . . . . . . 22 79 4.3 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 23 80 4.3.1 Two-Way Transactions . . . . . . . . . . . . . . . . 23 81 4.3.2 Three-Way Transactions . . . . . . . . . . . . . . . 25 82 4.3.3 Resource Queries . . . . . . . . . . . . . . . . . . 26 83 4.3.4 Bidirectional Reservations . . . . . . . . . . . . . 27 84 4.3.5 Preemption . . . . . . . . . . . . . . . . . . . . . 27 85 4.4 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 27 86 5. QSPEC Functional Specification . . . . . . . . . . . . . . . . 28 87 5.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 28 88 5.1.1 Common Header Format . . . . . . . . . . . . . . . . 28 89 5.1.2 QSPEC Object Header Format . . . . . . . . . . . . . 30 90 5.2 QSPEC Parameter Coding . . . . . . . . . . . . . . . . . . 31 91 5.2.1 Parameter . . . . . . . . . . . . . . . . . 31 92 5.2.2 Parameter . . . . . . . . . . . . . . . . . 31 93 5.2.3 Parameter . . . . . . . . . . . . . . 32 94 5.2.4 Parameter . . . . . . . . . . . . . . . 33 95 5.2.5 Parameter . . . . . . . . . . . . . . . . 34 96 5.2.6 Parameter . . . . . . . . . . . . . . . . 34 97 5.2.7 Parameter . . . . . . . . . . . . . . . 35 98 5.2.8 & 99 Parameters . . . . . . . . . . . . . . . . . . . . . 35 100 5.2.9 Parameter . . . . . . . . . . . 36 101 5.2.10 Parameter . . . . . . . . . . . . . . 36 102 5.2.11 Parameter . . . . . . . . . . . . 37 103 5.2.12 Parameter . . . . . . . . . . . . . . . 39 104 5.2.13 Parameter . . . . . . . . . . . . 40 105 5.2.14 Parameter . . . . . . . . . . . . 40 106 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 41 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42 108 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 109 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45 110 10. Normative References . . . . . . . . . . . . . . . . . . . . . 46 111 11. Informative References . . . . . . . . . . . . . . . . . . . . 47 112 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 48 113 Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved 114 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 48 115 Appendix B. Change History & Open Issues . . . . . . . . . . . . . 49 116 B.1 Change History (since Version -04) . . . . . . . . 49 117 B.2 Open Issues . . . . . . . . . . . . . . . . . . . 54 118 Intellectual Property Statement . . . . . . . . . . . . . . . . . 54 119 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55 121 Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 1. Introduction 129 The QoS NSIS signaling layer protocol (NSLP) [QoS-SIG] is used to 130 signal QoS reservations for a data flow, provide forwarding 131 resources (QoS) for that flow, and establish and maintain state at 132 nodes along the path of the flow. The design of QoS NSLP is 133 conceptually similar to the decoupling between RSVP [RFC2205] and 134 the IntServ architecture [RFC2210], where a distinction is made 135 between the operation of the signaling protocol and the information 136 required for the operation of the Resource Management Function (RMF). 137 [QoS-SIG] describes the signaling protocol, while this document 138 describes the RMF-related information carried in the QSPEC (QoS 139 Specification) object carried in QoS NSLP messages. 141 [QoS-SIG] defines four QoS NSLP messages - RESERVE, QUERY, RESPONSE, 142 and NOTIFY - each of which may carry the QSPEC object, while this 143 document describes a template for the QSPEC object. The QSPEC object 144 carries information on traffic descriptions, resources required, 145 resources available, and other information required by the RMF. 146 Therefore the QSPEC template described in this document is closely 147 tied to QoS NSLP and the reader should to be familiar with [QoS-SIG] 148 to fully understand this document. 150 A QoS-enabled domain supports a particular QoS model (QOSM), which is 151 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 152 provisioning methods and a QoS architecture, and defines the behavior 153 of the RMF that reserves resources for each flow, including inputs 154 and outputs. The QoS NSLP protocol is able to signal QoS 155 reservations for different QOSMs, wherein all information specific to 156 a QOSM is encapsulated in the QSPEC object and only the RMF specific 157 to a given QOSM will need to interpret the QSPEC. Examples of QOSMs 158 are IntServ, DiffServ admission control, and those specified in 160 [Y.1541-QOSM, CL-QOSM, RMD-QOSM]. 162 QSPEC parameters include, for example, a mandatory traffic model 163 (TMOD) parameter, constraints parameters, such as path latency and 164 path jitter, traffic handling directives, such as excess treatment, 165 and traffic classifiers such as PHB class. 167 QSPEC objects loosely correspond to the TSpec, RSpec and AdSpec 168 objects specified in RSVP and may contain, respectively, a 169 description of QoS desired, QoS reserved, and QoS available. 170 Going beyond RSVP functionality, the QSPEC also allows indicating 171 a range of acceptable QoS by defining a QSPEC object denoting 172 minimum QoS. Usage of these QSPEC objects is not bound to particular 173 message types thus allowing for flexibility. A QSPEC object 174 collecting information about available resources may travel in any 175 QoS NSLP message, for example a QUERY message or a RESERVE message, 176 as defined in [QoS-SIG]. The QSPEC travels in QoS NSLP messages but 177 is opaque to the QoS NSLP, and is only interpreted by the RMF. 179 Interoperability between QoS NSIS entities (QNEs) in different 180 domains is enhanced by the definition of a common set of QSPEC 181 parameters. A QoS NSIS initiator (QNI) initiating the QoS NSLP 182 signaling adds an initiator QSPEC object containing parameters 183 describing the desired QoS, normally based on the QOSM it supports. 184 QSPEC parameters flagged by the QNI must be interpreted by all QNEs 185 in the path, else the reservation fails. In contrast, QSPEC 186 parameters not flagged by the QNI may be skipped if not understood. 187 Additional QSPEC parameters can be defined by informational 188 specification documents, and thereby ensure the extensibility and 189 flexibility of QoS NSLP. 191 A local QSPEC can be defined in a local domain with the initiator 192 QSPEC encapsulated, where the local QSPEC must be functionally 193 consistent with the initiator QSPEC in terms of defined source 194 traffic and other constraints. That is, a domain specific local 195 QSPEC can be defined and processed in a local domain, which could, 196 for example, can enable simpler processing by QNEs within the local 197 domain. 199 In Section 3.4 a worked example of QSPEC processing is provided. 201 2. Terminology 203 Initiator QSPEC: The initiator QSPEC is included into 204 a QoS NSLP message by the QNI/QNR. It travels end-to-end to the 205 QNR/QNI and is never removed. 207 Local QSPEC: A local QSPEC is used in a local domain 208 and is domain specific. It encapsulates the initiator QSPEC and is 209 removed at the egress of the local domain. 210 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 211 any QNE. Together with a description of QoS Desired or QoS 212 Available, it allows the QNI to specify a QoS range, i.e. an upper 213 and lower bound. If the QoS Desired cannot be reserved, QNEs are 214 going to decrease the reservation until the minimum QoS is hit. 216 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 218 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 220 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 222 QoS Available: QSPEC object containing parameters describing the 223 available resources. They are used to collect information along a 224 reservation path. 226 QoS Desired: QSPEC object containing parameters describing the 227 desired QoS for which the sender requests reservation. 229 QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., 230 IntServ Controlled Load; specifies what sub-set of QSPEC QoS 231 constraints & traffic handling directives a QNE implementing that 232 QOSM is capable of supporting & how resources will be managed by the 233 RMF. 235 QoS Reserved: QSPEC object containing parameters describing the 236 reserved resources and related QoS parameters. 238 QSPEC: QSPEC is the object of QoS NSLP containing all QoS-specific 239 information. 241 QSPEC parameter: Any parameter appearing in a QSPEC; for 242 example, traffic model (TMOD), path latency, and excess treatment 243 parameters. 245 QSPEC Object: Main building blocks containing a QSPEC parameter set 246 that is input or output of an RMF operation. 248 QSPEC Type: Identifies a particular QOSM used in the QSPEC 250 Resource Management Function (RMF): Functions that are related to 251 resource management and processing of QSPEC parameters. 253 3. QSPEC Framework 255 The overall framework for the QoS NSLP is that [QoS-SIG] defines QoS 256 signaling and semantics, the QSPEC template defines the container and 257 semantics for QoS parameters and objects, and informational 258 specifications define QoS methods and procedures for using QoS 259 signaling and QSPEC parameters/objects within specific QoS 260 deployments. QoS NSLP is a generic QoS signaling protocol that can 261 signal for many QOSMs. 263 3.1 QoS Models 265 A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ 266 controlled load [CL-QOSM], resource management with DiffServ 267 [RMD-QOSM], and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM]. 268 A QOSM specifies a set of QSPEC parameters that describe the QoS 269 desired and how resources will be managed by the RMF. The RMF 270 implements functions that are related to resource management and 271 processes the QSPEC parameters. 273 QOSMs affect the operation of the RMF in NSIS-capable nodes, the 274 information carried in QSPEC objects, and may under some 275 circumstances (e.g. aggregation) cause a separate NSLP session to be 276 instantiated by having the RMF as a QNI. QOSM specifications may 277 define RMF triggers that cause the QoS NSLP to run semantics within 278 the underlying QoS NSLP signaling state and messaging processing 279 rules, as defined in Section 5.2 of [QoS-SIG]. New QoS NSLP message 280 processing rules can only be defined in Standards Track extensions to 281 QoS NSLP. If a QOSM specification defines triggers that deviate 282 from existing standard QoS NSLP processing rules (must be standards 283 track in that case), the fallback for QNEs not supporting that QOSM 284 are the standard QoS NSLP state transition/message processing rules. 286 The QOSM specification includes how the requested QoS resources will 287 be described and how they will be managed by the RMF. For this 288 purpose, the QOSM specification defines a set of QSPEC parameters it 289 uses to describe the desired QoS and resource control in the RMF, and 290 it may define additional QSPEC parameters. 292 When a QoS NSLP message travels through different domains, it may 293 encounter different QOSMs. Since QOSM use different QSPEC parameters 294 for describing resources, the QSPEC parameters included by the QNI 295 may not be understood in other domains. The QNI therefore can flag 296 those QSPEC parameters it considers vital with the M flag. QSPEC 297 parameters with the M flag set must be interpreted by the downstream 298 QNEs, or the reservation fails. QSPEC parameters without the M flag 299 set should be interpreted by the downstream QNEs, but may be ignored 300 if not understood. 302 A QOSM specification MUST include the following: 303 - role of QNEs, e.g., location, frequency, statefulness, etc. 304 - QSPEC definition including QSPEC parameters 305 - QSPEC procedures applicable to this QOSM 306 - QNE processing rules describing how QSPEC information is treated 307 and interpreted in the RMF, e.g., 308 admission control, scheduling, policy control, QoS parameter 309 accumulation (e.g., delay). 310 - at least one bit-level QSPEC example 311 - QSPEC parameter behavior for new QSPEC parameters the QOSM 312 specification defines 313 - define what happens in case of preemption if the default QNI 314 behavior (tear down preempted reservation) is not followed (see 315 Section 4.3.5) 317 A QOSM specification MAY include the following: 319 - define additional QOSM-specific error codes, as discussed in 320 Section 4.2.3 321 - can state which QoS-NSLP options a QOSM wants to use, when 322 several options are available for a QOSM (e.g., local QSPEC to 323 either a) hide initiator QSPEC within a local domain message, or 324 b) encapsulate initiator QSPEC). 326 QOSMs are free, subject to IANA registration and review rules, to 327 extend QSPECs by adding parameters of any of the kinds supported by 328 the standard QSPEC. This includes traffic description parameters, 329 constraint parameters and traffic handling directives. QOSMs are not 330 permitted, however, to reinterpret or redefine the standard QSPEC 331 parameters specified in this document. Note that signaling 332 functionality is only defined by the QoS NSLP document [QoS-SIG] and 333 not by this document or by QOSM specification documents. 335 3.2 QSPEC Objects 337 The QSPEC is the object of QoS NSLP containing QSPEC objects and 338 parameters. QSPEC objects are the main building blocks of the QSPEC 339 parameter set that is input or output of an RMF operation. QSPEC 340 parameters are the parameters appearing in a QSPEC, which must 341 include traffic (TMOD), and may optionally include constraints (e.g., 342 path latency), traffic handling directives (e.g., excess treatment), 343 and traffic classifiers (e.g., PHB class). The RMF implements 344 functions that are related to resource management and processes the 345 QSPEC parameters. 347 The QSPEC consists of a QSPEC version number and QSPEC objects. IANA 348 assigns a new QSPEC version number when changes that are not 349 backwards compatible are made to the QSPEC and this document is 350 reissued. Note that a new QSPEC version number is not needed when 351 new QSPEC parameters are specified. Later QSPEC versions MUST be 352 backward compatible with earlier QSPEC versions. That is, a version 353 n+1 device must support QSPEC version n (or earlier). On the other 354 hand, if a QSPEC version n (or earlier) device receives an NSLP 355 message specifying QSPEC version n+1, then the version n device 356 responds with an 'Incompatible QSPEC' error code (0x0f) response, as 357 discussed in Section 4.2.3, allowing the QNE that sent the NSLP 358 message to retry with a lower QSPEC version. 360 This document provides a template for the QSPEC in order to promote 361 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 362 is composed of up to four QSPEC objects, namely QoS Desired, QoS 363 Available, QoS Reserved and Minimum QoS. Each of these QSPEC objects 364 consists of a number of QSPEC parameters. A given QSPEC may contain 365 only a subset of the QSPEC objects, e.g. QoS Desired. The QSPEC 366 objects QoS Desired, QoS Available and QoS Reserved MUST be supported 367 by QNEs. Minimum QoS MAY be supported. 369 +---------------------------------------+ 370 | QSPEC Objects | 371 +---------------------------------------+ 373 \________________ ______________________/ 374 V 375 +----------+----------+---------+-------+ 376 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| 377 +----------+----------+---------+-------+ 379 \____ ____/\___ _____/\___ ____/\__ ___/ 380 V V V V 382 +-------------+... +-------------+... 383 |QSPEC Para. 1| |QSPEC Para. n| 384 +-------------+... +-------------+... 386 Figure 1: Structure of the QSPEC 388 The QoS Desired Object describe the resources the QNI desires to 389 reserve and hence this is a read-only QSPEC object in that the QSPEC 390 parameters carried in the object may not be overwritten. QoS Desired 391 is always included in a RESERVE message (see [QoS-SIG] for 392 descriptions of the QoS NSLP RESERVE, QUERY, RESPONSE, and NOTIFY 393 messages). 395 The QoS Available Object travels in a RESERVE or QUERY message and 396 collects information on the resources currently available on the 397 path. Hence QoS Available in this case is a read-write object, which 398 means the QSPEC parameters contained in QoS Available may be updated, 399 but they cannot be deleted). Each QNE MUST inspect all parameters of 400 this QSPEC object, and if resources available to this QNE are less 401 than what a particular parameter says currently, the QNE MUST adapt 402 this parameter accordingly. Hence when the message arrives at the 403 recipient of the message, reflects the bottleneck of 404 the resources currently available on a path. It can be used in a 405 QUERY message, for example, to collect the available resources along 406 a data path. 408 When QoS Available travels in a RESPONSE message, it in fact just 409 transports the result of a previous measurement performed by a 410 RESERVE or QUERY message back to the initiator. Therefore in this 411 case, QoS Available is read-only. 413 QoS Reserved reflects the resources that were reserved. It is a 414 read-only object. 416 Minimum QoS does not have an equivalent in RSVP. It allows the QNI 417 to define a range of acceptable QoS levels by including both the 418 desired QoS value and the minimum acceptable QoS in the same message. 420 Parameters cannot be overwritten in this QSPEC object. The desired 421 QoS is included with a QoS Desired and/or a QoS Available QSPEC 422 object seeded to the desired QoS value. The minimum acceptable QoS 423 value MAY be coded in the Minimum QoS QSPEC object. As the message 424 travels towards the QNR, QoS Available is updated by QNEs on the 425 path. If its value drops below the value of Minimum QoS the 426 reservation fails and is aborted. When this method is employed, the 427 QNR SHOULD signal back to the QNI the value of QoS Available 428 attained in the end, because the reservation MAY need to be adapted 429 accordingly. 431 Note that the relationship of QSPEC objects to RSVP objects is 432 covered in Appendix A. 434 3.3 QSPEC Parameters 436 QSPEC parameters provide a common language for building QSPEC 437 objects. This document defines a number of QSPEC parameters, 438 additional parameters may be defined in separate QOSM specification 439 documents. For example, QSPEC parameters are defined in [RMD-QOSM] 440 and [Y.1541-QOSM]. 442 One QSPEC parameter, , is special. It provides a description 443 of the traffic for which resources are reserved. This parameter must 444 be included by the QNI and it must be interpreted by all QNEs. All 445 other QSPEC parameters are populated by a QNI if they are applicable 446 to the underlying QoS desired. For these QSPEC parameters, the QNI 447 sets the M flag if they must be interpreted by downstream QNEs. If 448 QNEs cannot interpret the parameter the reservation fails. QSPEC 449 parameters populated by a QNI without the M flag set should be 450 interpreted by downstream QNEs, but may be ignored if not understood. 452 In this document the term 'interpret' means, in relation to RMF 453 processing of QSPEC parameters, that the RMF processes the QSPEC 454 parameter according to the commonly accepted normative procedures 455 specified by references given for each QSPEC parameter. Note that a 456 QNE need only interpret a QSPEC parameter if it is populated in the 457 QSPEC object by the QNI; if not populated in the QSPEC, the QNE does 458 not interpret it of course. 460 Note that when an ingress QNE in a local domain defines a local QSPEC 461 and encapsulates the initiator QSPEC, the QNEs in the interior local 462 domain need only process the local QSPEC and can ignore the initiator 463 (encapsulated) QSPEC. However, edge QNEs in the local domain indeed 464 must interpret the QSPEC parameters populated in the initiator QSPEC 465 with the M flag set and should interpret QSPEC parameters populated 466 in the initiator QSPEC without the M flag set 468 As described in the previous section, QoS parameters may be 469 overwritten depending on which QSPEC object, and which message, they 470 appear in. 472 3.3.1 Traffic Model Parameter 474 The (TMOD) parameter is mandatory for the QNI to 475 include in the initiator QSPEC and mandatory for downstream QNEs to 476 interpret The traffic description specified by the TMOD parameter 477 is a container consisting of 4 sub-parameters: 479 o rate (r) 480 o bucket size (b) 481 o peak rate (p) 482 o minimum policed unit (m) 484 All 4 of the sub-parameters MUST be included in the TMOD parameter. 485 The TMOD parameter can be set to describe the traffic source. If, 486 for example, TMOD is set to specify bandwidth only, then set r = peak 487 rate = p, b = large, m = large. As another example if TMOD is set 488 for TCP traffic, then set r = average rate, b = large, p = large. 490 When the 4 TMOD sub-parameters are included in QoS Available, they 491 provide information, for example, about the TMOD resources available 492 along the path followed by a data flow. The value of TMOD at a QNE 493 is an estimate of the TMOD resources the QNE has available for 494 packets following the path up to the next QNE, including its outgoing 495 link, if this link exists. Furthermore, the QNI MUST account for the 496 resources of the ingress link, if this link exists. Computation of 497 the value of this parameter SHOULD take into account all information 498 available to the QNE about the path, taking into consideration 499 administrative and policy controls, as well as physical resources. 501 The output composed value is the minimum of the QNE's value and the 502 input composed value for r, b, and p, and the maximum of the 503 QNE's value and the input composed value for m. This quantity, 504 when composed end-to-end, informs the QNR (or QNI in a RESPONSE 505 message) of the minimal TMOD resources along the path from QNI to 506 QNR. 508 Two TMOD parameters are defined in Section 5, and , 509 where the second () parameter is specified as could be needed 510 to support some DiffServ applications. For example, it is typically 511 assumed that DiffServ EF traffic is shaped at the ingress by a single 512 rate token bucket. Therefore, a single TMOD parameter is sufficient 513 to signal DiffServ EF traffic. However, for DiffServ AF traffic two 514 sets of token bucket parameters are needed, one token bucket for the 515 average traffic and one token bucket for the burst traffic. 516 [RFC2697] defines a Single Rate Three Color Marker (srTCM), which 517 meters a traffic stream and marks its packets according to three 518 traffic parameters, Committed Information Rate (CIR), Committed Burst 519 Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, 520 or red. A packet is marked green if it does not exceed the CBS, 521 yellow if it does exceed the CBS, but not the EBS, and red otherwise. 522 [RFC2697] defines specific procedures using two token buckets that 523 run at the same rate. Therefore 2 TMOD parameters are sufficient to 524 distinguish among 3 levels of drop precedence. An example is also 525 described in the Appendix to [RFC2597]. 527 3.3.2 Constraints Parameters 529 , , , and are QSPEC 530 parameters describing the desired path latency, path jitter and path 531 bit error rate respectively. Since these parameters are cumulative, 532 an individual QNE cannot decide whether the desired path latency, 533 etc., is available, and hence they cannot decide whether a 534 reservation fails. Rather, when these parameters are included in 535 , the QNI SHOULD also include corresponding parameters 536 in a QoS Available QSPEC object in order to facilitate collecting 537 this information. 539 The parameter accumulates the latency of the packet 540 forwarding process associated with each QNE, where the latency is 541 defined to be the mean packet delay added by each QNE. This delay 542 results from the combination of speed-of-light propagation delay, 543 packet processing, and queueing. Each QNE MUST add the propagation 544 delay of its outgoing link, if this link exists. Furthermore, the 545 QNI MUST add the propagation delay of the ingress link, if this link 546 exists. The composition rule for the parameter is 547 summation with a clamp of (2**32) - 1 on the maximum value. This 548 quantity, when composed end-to-end, informs the QNR (or QNI in a 549 RESPONSE message) of the minimal packet delay along the path from QNI 550 to QNR. The purpose of this parameter is to provide a minimum path 551 latency for use with services which provide estimates or bounds on 552 additional path delay [RFC2212]. 554 The parameter accumulates the jitter of the packet 555 forwarding process associated with each QNE, where the jitter is 556 defined to be the nominal jitter added by each QNE. IP packet 557 jitter, or delay variation, is defined in [RFC3393], Section 3.4 558 (Type-P-One-way-ipdv), and where the selection function includes the 559 packet with minimum delay such that the distribution is equivalent to 560 2-point delay variation in [Y.1540]. The suggested evaluation 561 interval is 1 minute. This jitter results from packet processing 562 limitations, and includes any variable queuing delay which may be 563 present. Each QNE MUST add the jitter of its outgoing link, if this 564 link exists. Furthermore, the QNI MUST add the jitter of the ingress 565 link, if this link exists. The composition method for the parameter is the combination of several statistics describing 567 the delay variation distribution with a clamp on the maximum value 568 (note that the methods of accumulation and estimation of nominal QNE 569 jitter are specified in clause 8 of [Y.1541]). This quantity, when 570 composed end-to-end, informs the QNR (or QNI in a RESPONSE message) 571 of the nominal packet jitter along the path from QNI to QNR. The 572 purpose of this parameter is to provide a nominal path jitter for use 573 with services that provide estimates or bounds on additional path 574 delay [RFC2212]. 576 The parameter accumulates the packet loss ratio (PLR) of 577 the packet forwarding process associated with each QNE, where the PLR 578 is defined to be the PLR added by each QNE. Each QNE MUST add the 579 PLR of its outgoing link, if this link exists. Furthermore, the QNI 580 MUST add the PLR of the ingress link, if this link exists. The 581 composition rule for the parameter is summation with a 582 clamp on the maximum value (this assumes sufficiently low PLR values 583 such that summation error is not significant, however a more accurate 584 composition function is specified in clause 8 of [Y.1541]). This 585 quantity, when composed end-to-end, informs the QNR (or QNI in a 586 RESPONSE message) of the minimal packet PLR along the path from QNI 587 to QNR. 589 The parameter accumulates the packet error ratio (PER) of 590 the packet forwarding process associated with each QNE, where the PER 591 is defined to be the PER added by each QNE. Each QNE MUST add the 592 PER of its outgoing link, if this link exists. Furthermore, the QNI 593 MUST add the PER of the ingress link, if this link exists. The 594 composition rule for the parameter is summation with a 595 clamp on the maximum value (this assumes sufficiently low PER values 596 such that summation error is not significant, however a more accurate 597 composition function is specified in clause 8 of [Y.1541]). This 598 quantity, when composed end-to-end, informs the QNR (or QNI in a 599 RESPONSE message) of the minimal packet PER along the path from QNI 600 to QNR. 602 The slack term parameter is the difference between desired delay and 603 delay obtained by using bandwidth reservation, and which is used to 604 reduce the resource reservation for a flow [RFC2212]. 606 3.3.3 Traffic Handling Directives 608 An application MAY like to reserve resources for packets and also 609 specify a specific traffic handling behavior, such as . In addition, as discussed in Section 3.1, an application 611 MAY like to define RMF triggers that cause the QoS NSLP to run 612 semantics within the underlying QoS NSLP signaling state / messaging 613 processing rules, as defined in Section 5.2 of [QoS-SIG]. Note, 614 however, that new QoS NSLP message processing rules can only be 615 defined in Standards Track extensions to the QoS NSLP. 616 As with constraints parameters and other QSPEC parameters, 617 traffic-handling-directives parameters may be defined in QOSM 618 specifications in order to provide support for QOSM-specific resource 619 management functions. Such QOSM-specific parameters are already 620 defined, for example, in [RMD-QOSM], [CL-QOSM] and [Y.1541-QOSM]. 622 Generally, a traffic-handling-directives parameters is expected to be 623 set by the QNI in , and to not be included in 624 . If such a parameter is included in , 625 QNEs may change their value. 627 The parameter is the priority of the new flow 628 compared with the of previously admitted flows. 629 Once a flow is admitted, the preemption priority becomes irrelevant. 630 The parameter is used to compare with the 631 preemption priority of new flows. For any specific flow, its 632 preemption priority MUST always be less than or equal to the 633 defending priority. and provide 634 an essential way to differentiate flows for emergency services, ETS, 635 E911, etc., and assign them a higher admission priority than normal 636 priority flows and best-effort priority flows. 638 The parameter describes how the QNE will process 639 out-of-profile traffic. Excess traffic MAY be dropped, shaped and/or 640 remarked. 642 3.3.4 Traffic Classifiers 644 An application MAY like to reserve resources for packets with a 645 particular DiffServ per-hop behavior (PHB) [RFC2475]. Note that PHB 646 class is normally set by a downstream QNE to tell the QNI how to mark 647 traffic to ensure treatment committed by admission control, however, 648 setting of the parameter by the QNI is not precluded. An application 649 MAY like to reserve resources for packets with a particular QoS 650 class, e.g. Y.1541 QoS class [Y.1541] or DiffServ-aware MPLS traffic 651 engineering (DSTE) class type [RFC3564, RFC4124]. These parameters 652 are useful in various QOSMs, e.g., [RMD-QOSM], [Y.1541-QOSM], and 653 other QOSMs yet to be defined (e.g., DSTE-QOSM). This is intended to 654 provide guidelines to QOSMs on how to encode these parameters; use of 655 the PHB class parameter is illustrated in the example in the 656 following section. 658 3.4 Example of QSPEC Processing 660 This section illustrates the operation and use of the QSPEC within 661 the NSLP. The example configuration in shown in Figure 2. 663 +----------+ /-------\ /--------\ /--------\ 664 | Laptop | | Home | | Cable | | DiffServ | 665 | Computer |-----| Network |-----| Network |-----| Network |----+ 666 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 667 \-------/ \--------/ \--------/ | 668 | 669 +-----------------------------------------------+ 670 | 671 | /--------\ +----------+ 672 | | "X"G | | Handheld | 673 +---| Wireless |-----| Device | 674 | XG QOSM | +----------+ 675 \--------/ 677 Figure 2: Example Configuration to Illustrate QoS-NSLP/QSPEC 678 Operation 680 In this configuration, a laptop computer and a handheld wireless 681 device are the endpoints for some application that has QoS 682 requirements. Assume initially that the two endpoints are stationary 683 during the application session, later we consider mobile endpoints. 684 For this session, the laptop computer is connected to a home network 685 that has no QoS support. The home network is connected to a 686 CableLabs-type cable access network with dynamic QoS (DQOS) support, 687 such as specified in the [DQOS] for cable access networks. That 688 network is connected to a DiffServ core network that uses the RMD 689 QOSM [RMD-QOSM]. On the other side of the DiffServ core is a 690 wireless access network built on generation "X" technology with QoS 691 support as defined by generation "X". And finally the handheld 692 endpoint is connected to the wireless access network. 694 We assume that the Laptop is the QNI and handheld device is the QNR. 695 The QNI will signal an initiator QSPEC object to achieve the QoS 696 desired on the path. 698 The QNI sets QoS Desired, QoS Available and possibly Minimum 699 QoS QSPEC objects in the initiator QSPEC, and initializes QoS 700 Available to QoS Desired. Each QNE on the path reads and 701 interprets those parameters in the initiator QSPEC and checks to see 702 if QoS Available resources can be reserved. If not, the QNE reduces 703 the respective parameter values in QoS Available and reserves these 704 values. The minimum parameter values are given in Minimum QoS, if 705 populated, otherwise zero if Minimum QoS is not included. If one or 706 more parameters in QoS Available fails to satisfy the corresponding 707 minimum values in Minimum QoS, the QNE generates a RESPONSE message 708 to the QNI and the reservation is aborted. Otherwise, the QNR 709 generates a RESPONSE to the QNI with the QoS Available for the 710 reservation. If a QNE cannot reserve QoS Desired resources, the 711 reservation fails. 713 The QNI populates QSPEC parameters to ensure correct treatment of its 714 traffic in domains down the path. Let us assume the QNI wants to 715 achieve IntServ-Controlled Load-like QoS guarantees, and also is 716 interested in what path latency it can achieve. Additionally, to 717 ensure correct treatment further down the path, the QNI includes in . The QNI therefore includes in the QSPEC 720 QoS Desired = 721 QoS Available = 723 Since and are not vital parameters from 724 the QNI's perspective, it does not raise their M flags. 726 There are three possibilities when a RESERVE message is received at a 727 QNE at a domain border (we illustrate these possibilities in the 728 example): 730 - the QNE just leaves the QSPEC as-is. 732 - the QNE can add a local QSPEC and encapsulate the initiator QSPEC 733 (see discussion in Section 4.1; this is new in QoS NSLP, RSVP does 734 not do this). 736 - the QNE can 'hide' the initiator RESERVE message so that only the 737 edge QNE processes the initiator RESERVE message, which then 738 bypasses intermediate nodes between the edges of the domain, and 739 issues its own local RESERVE message (see Section 3.3.1 of 740 [QoS-SIG]). For this new local RESERVE message, the QNE acts as 741 the QNI, and the QSPEC in the domain is an initiator QSPEC. A 742 similar procedure is also used by RSVP in making aggregate 743 reservations, in which case there is not a new intra-domain 744 (aggregate) RESERVE for each newly arriving interdomain (per-flow) 745 RESERVE, but the aggregate reservation is updated by the border 746 QNE (QNI) as need be. This is also how RMD works [RMD-QOSM]. 748 For example, at the RMD domain, a local RESERVE with its own RMD 749 initiator QSPEC corresponding to the RMD-QOSM is generated based on 750 the original initiator QSPEC according to the procedures described in 751 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. The ingress QNE to the 752 RMD domain maps the TMOD parameters contained in the original 753 initiator QSPEC into the equivalent TMOD parameter representing only 754 the peak bandwidth in the local QSPEC. The local RMD QSPEC for 755 example also needs , which in this case was provided by 756 the QNI. 758 Furthermore, the node at the egress to the RMD domain updates QoS 759 Available on behalf of the entire RMD domain if it can. If it 760 cannot (since the M flag is not set for ) it raises the 761 parameter-specific, 'not-supported' flag, warning the QNR that the 762 final latency value in QoS Available is imprecise. 764 In the XG domain, the initiator QSPEC is translated into a local 765 QSPEC using a similar procedure as described above. The local QSPEC 766 becomes the current QSPEC used within the XG domain, and the 767 initiator QSPEC is encapsulated. This saves the QNEs within the XG 768 domain the trouble of re-translating the initiator QSPEC, and 769 simplifies processing in the local domain. At the egress edge of the 770 XG domain, the translated local QSPEC is removed, and the initiator 771 QSPEC returns to the number one position. 773 If the reservation was successful, eventually the RESERVE request 774 arrives at the QNR (otherwise the QNE at which the reservation failed 775 would have aborted the RESERVE and sent an error RESPONSE back to the 776 QNI). If the RII was included in the QoS NSLP message, the QNR 777 generates a positive RESPONSE with QSPEC objects QoS Reserved and 778 QoS Available. The parameters appearing in QoS Reserved are the 779 same as in QoS Desired, with values copied from QoS Available. 780 Hence, the QNR includes the following QSPEC objects in the RESPONSE: 782 QoS Reserved = 783 QoS Available = 785 If the handheld device on the right of Figure 2 is mobile, and moves 786 through different "XG" wireless networks, then the QoS might change 787 on the path since different XG wireless networks might support 788 different QOSMs. As a result, QoS NSLP/QSPEC processing will have to 789 renegotiate the QoS Available on the path. From a QSPEC 790 perspective, this is like a new reservation on the new section of the 791 path and is basically the same as any other rerouting event - to the 792 QNEs on the new path it looks like a new reservation. That is, in 793 this mobile scenario, the new segment may support a different QOSM 794 than the old segment, and the QNI would now signal a new reservation 795 (explicitly, or implicitly with the next refreshing RESERVE message) 796 to account for the different QOSM in the XG wireless domain. Further 797 details on rerouting are specified in [QoS-SIG]. 799 For bit-level examples of QSPECs see the documents specifying QOSMs 800 [CL-QOSM, Y.1541-QOSM, RMD-QOSM]. 802 4. QSPEC Processing & Procedures 804 Three flags are used in QSPEC processing, the M flag, E flag, and N 805 flag, which are explained in this section. The QNI sets the M flag 806 for each QSPEC parameter it populates that must be interpreted by 807 downstream QNEs. If a QNE does not support parameter it sets the N 808 flag and fails the reservation. If the QNE supports the parameter 809 but cannot meet the resources requested by the parameter, it sets the 810 E flag and fails the reservation. 812 If the M flag is not set, the downstream QNE SHOULD interpret the 813 parameter. If the QNE does not support the parameter it sets the 814 N flag and forwards the reservation. If the QNE supports the 815 parameter but cannot meet the resources requested by the parameter, 816 it sets the E flag and fails the reservation. 818 4.1 Local QSPEC Definition & Processing 819 A QNE at the edge of a local domain may either a) translate the 820 initiator QSPEC into a local QSPEC and encapsulate the initiator 821 QSPEC in the RESERVE message, or b) 'hiding' the initiator QSPEC 822 through the local domain and reserve resources by generating a new 823 RESERVE message through the local domain containing the local QSPEC. 824 In either case the initiator QSPEC parameters are interpreted at the 825 local domain edges. 827 A local QSPEC may allow a simpler control plane in a local domain. 828 The edge nodes in the local domain must interpret the initiator 829 QSPEC parameters. They can either initiate a parallel session with 830 local QSPEC or define a local QSPEC and encapsulate the initiator 831 QSPEC, as illustrated in Figure 3. The Initiator/Local QSPEC bit 832 identifies whether the QSPEC is an initiator QSPEC or a local QSPEC. 833 The QSPEC Type indicates, for example, that the initiator of local 834 QSPEC uses to a certain QOSM, e.g., CL-QSPEC Type. It may be 835 useful for the QNI to signal a QSPEC Type based on some QOSM (which 836 will necessarily entail populating certain QOSM-related parameters) 837 so that a downstream QNE can chose amongst various QOSM-related 838 processes it might have. That is, the QNI populates the QSPEC Type, 839 e.g., CL-QSPEC Type and sets the Initiator/Local QSPEC bit to 840 'Initiator'. A local QNE can decide, for whatever reasons, to 841 insert a local QSPEC Type, e.g., RMD-QSPEC Type, and set the local 842 QSPEC Type = RMD-QSPEC and set the Initiator/Local QSPEC bit to 843 'Local' (and encapsulate the Initiator QSPEC in the RESERVE or 844 whatever NSLP message). 846 +--------------------------------+\ 847 | QSPEC Type, QSPEC Procedure | \ 848 +--------------------------------+ / Common QQSPEC Header 849 | Init./Local QSPEC bit=Local |/ 850 +================================+\ 851 | Local-QSPEC Parameter 1 | \ 852 +--------------------------------+ \ 853 | .... | Local-QSPEC Parameters 854 +--------------------------------+ / 855 | Local-QSPEC Parameter n | / 856 +--------------------------------+/ 857 | +----------------------------+ | 858 | | QSPEC Type, QSPEC Procedure| | 859 | +----------------------------+ | 860 | | Init./Local QSPEC bit=Init.| | 861 | +============================+ | 862 | | | | Encapsulated Initiator QSPEC 863 | | .... | | 864 | +----------------------------+ | 865 +--------------------------------+ 867 Figure 3. Defining a Local QSPEC 869 Here the QoS-NSLP only sees and passes one QSPEC up to the RMF. The 870 type of the QSPEC thus may change within a local domain. Hence 871 o the QNI signals its QoS requirements with the initiator QSPEC, 872 o the ingress edge QNE in the local domain translates the 873 initiator QSPEC parameters to equivalent parameters in the local 874 QSPEC, 875 o the QNEs in the local domain only interpret the local QSPEC 876 parameters 877 o the egress QNE in the local domain processes the local QSPEC and 878 also interprets the QSPEC parameters in the initiator QSPEC. 880 The local QSPEC MUST be consistent with the initiator QSPEC. That 881 is, it MUST NOT specify a lower level of resources than specified 882 by the initiator QSPEC. For example, in RMD the TMOD parameters 883 contained in the original initiator QSPEC are mapped into the 884 equivalent TMOD parameter representing only the peak bandwidth in the 885 local QSPEC. 887 Note that it is possible to use both a) hiding a QSPEC through a 888 local domain by initiating a new RESERVE at the domain edge, and 889 b) defining a local QSPEC and encapsulating the initiator QSPEC, as 890 defined above. However, it is not expected that both the hiding and 891 encapsulating functions would be use at the same time for the same 892 flow. 894 The support of local QSPECs is a new and quite powerful capability, 895 which is illustrated in Figure 4 for a single flow to show where the 896 initiator and local QSPECs are used. The QNI initiates an 897 end-to-end, inter-domain QoS NSLP RESERVE message containing the 898 Initiator QSPEC for the Y.1541 QOSM. As illustrated in Figure 4, the 899 RESERVE message crosses multiple domains supporting different QOSMs. 900 In this illustration, the initiator QSPEC arrives in an QoS NSLP 901 RESERVE message at the ingress node of the local-QOSM domain. At the 902 ingress edge node of the local-QOSM domain, the end-to-end, inter- 903 domain QoS-NSLP message triggers the generation of a local QSPEC, and 904 the initiator QSPEC is encapsulated within the messages signaled 905 through the local domain. The local QSPEC is used for QoS processing 906 in the local-QOSM domain, and the initiator QSPEC is used for QoS 907 processing outside the local domain. 909 In this example the QNI sets , , objects to include objectives for the , , and parameters. The QNE/local domain sets the 912 cumulative parameters, e.g., , that can be 913 achieved in the object (but not less than specified 914 in ). If the fails to satisfy one or 915 more of the objectives, the QNE/local domain notifies 916 the QNI and the reservation is aborted. If any QNE cannot meet the 917 requirements designated by the initiator QSPEC to support a QSPEC 918 parameter with the M bit set to zero, the QNE sets the N flag for 919 that parameter to one. Otherwise, the QNR notifies the QNI of the 920 for the reservation. 922 |------| |------| |------| |------| 923 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 924 | QOSM | | QOSM | | QOSM | | QOSM | 925 | | |------| |-------| |-------| |------| | | 926 | NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | 927 |Y.1541| |local | |local | |local | |local | |Y.1541| 928 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 929 |------| |------| |-------| |-------| |------| |------| 930 ----------------------------------------------------------------- 931 |------| |------| |-------| |-------| |------| |------| 932 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 933 |------| |------| |-------| |-------| |------| |------| 934 QNI QNE QNE QNE QNE QNR 935 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 937 Figure 4. Example of Initiator & Local Domain QOSM Operation 939 4.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 940 Notification 942 A reservation may not be successful for several reasons: 944 - a reservation may fail because the desired resources are not 945 available. This is a reservation failure condition. 947 - a reservation may fail because the QSPEC is erroneous, or because 948 of a QNE fault. This is an error condition. 950 A reservation may be successful even though some parameters could not 951 be interpreted or updated properly: 953 - a QSPEC parameter cannot be interpreted because it is an unknown 954 QSPEC parameter type. This is a QSPEC parameter not supported 955 condition. The reservation however does not fail. The QNI can 956 still decide whether to keep or tear down the reservation depending 957 on the procedures specified by the QNI's QOSM. 959 The following sections describe the handling of unsuccessful 960 reservations and reservations where some parameters could not be met 961 in more detail, as follows: 963 - details on flags used inside the QSPEC to convey information on 964 success or failure of individual parameters. The formats and 965 semantics of all flags are given in Section 5. 966 - the content of the INFO_SPEC [QoS-SIG], which carries a code 967 indicating the outcome of reservations. 968 - the generation of a RESPONSE message to the QNI containing both 969 QSPEC and INFO_SPEC objects. 971 4.2.1 Reservation Failure & Error E Flag 973 The QSPEC parameters each have a 'reservation failure error E flag' 974 to indicate which (if any) parameters could not be satisfied. When a 975 resource cannot be satisfied for a particular parameter, the QNE 976 detecting the problem raises the E flag in this parameter. Note that 977 the TMOD parameter and all QSPEC parameters with the M flag set MUST 978 be examined by the RMF, and all QSPEC parameters with the M flag not 979 set SHOULD be examined by the RMF, and appropriately flagged. 980 Additionally, the E flag in the corresponding QSPEC object MUST be 981 raised when a resource cannot be satisfied for this parameter. If 982 the reservation failure problem cannot be located at the parameter 983 level, only the E flag in the QSPEC object is raised. 985 When an RMF cannot interpret the QSPEC because the coding is 986 erroneous, it raises corresponding reservation failure E flags in the 987 QSPEC. Normally all QSPEC parameters MUST be examined by the RMF 988 and the erroneous parameters appropriately flagged. In some cases, 989 however, an error condition may occur and the E flag of the 990 error-causing QSPEC parameter is raised (if possible), but the 991 processing of further parameters may be aborted. 993 Note that if the QSPEC and/or any QSPEC parameter is found to be 994 erroneous, then any QSPEC parameters not satisfied are ignored and 995 the E Flags in the QSPEC object MUST NOT be set for those parameters 996 (unless they are erroneous). 998 Whether E flags denote reservation failure or error can be determined 999 by the corresponding error code in the INFO_SPEC in QoS NSLP, as 1000 discussed below. 1002 4.2.2 QSPEC Parameter Not Supported N Flag 1004 Each QSPEC parameter has an associated 'not supported N flag'. If 1005 the not supported N flag is set, then at least one QNE along the data 1006 transmission path between the QNI and QNR cannot interpret the 1007 specified QSPEC parameter. A QNE MUST set the not supported N flag 1008 if it cannot interpret the QSPEC parameter. If the M flag for the 1009 parameter is not set, the message should continue to be forwarded but 1010 with the N flag set, and the QNI has the option of tearing the 1011 reservation. 1013 If a QNE in the path does not support a QSPEC parameter, e.g., 1014 , and sets the N flag, then downstream QNEs that 1015 support the parameter SHOULD still update the parameter, even if the 1016 N flag is set. However, the presence of the N flag will indicates 1017 that the cumulative value only provides a bound, and the QNI/QNR 1018 decides whether or not to accept the reservation with the N flag set. 1020 4.2.3 INFO_SPEC Coding of Reservation Outcome 1022 As prescribed by [QoS-SIG], the RESPONSE message always contains the 1023 INFO_SPEC with an appropriate 'error' code. It usually also contains 1024 a QSPEC with QSPEC objects, as described in Section 4.3 on QSPEC 1025 Procedures. The RESPONSE message MAY omit the QSPEC in case of a 1026 successful reservation. 1028 The following guidelines are provided in setting the error codes in 1029 the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of 1030 [QoS-SIG]: 1032 - INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success): 1033 This code is set when all QSPEC parameters have been satisfied. In 1034 this case no E Flag is set, however one or more N flags may be set 1036 - INFO_SPEC error class 0x04 (Transient Failure) / 0x07 (Reservation 1037 Failure): 1038 This code is set when at least one QSPEC parameter could not be 1039 satisfied, or when a QSPEC parameter with M flag set could not be 1040 interpreted. E flags are set for the parameters that could not be 1041 satisfied up to the QNE issuing the RESPONSE message. The N flag is 1042 set for those parameters that could not be interpreted by at least 1043 one QNE. In this case QNEs receiving the RESPONSE message MUST 1044 remove the corresponding reservation. 1046 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0c (Malformed 1047 QSPEC): 1048 Some QSPEC parameters had associated errors, E Flags are set for 1049 parameters that had errors, and the QNE where the error was found 1050 rejects the reservation. 1052 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0f (Incompatible 1053 QSPEC): 1054 A higher version QSPEC is signaled and not support by the QNE. 1056 - INFO_SPEC error class 0x06 (QoS Model Error): 1057 QOSM error codes can be defined by QOSM specification documents. A 1058 registry is defined in Section 7 IANA Considerations. 1060 4.2.4 QNE Generation of a RESPONSE message 1062 - Successful Reservation Condition 1064 When a RESERVE message arrives at a QNR and no E Flag is set, the 1065 reservation is successful. A RESPONSE message may be generated with 1066 INFO_SPEC code 'Reservation Success' as described above and in the 1067 QSPEC Procedures described in Section 4.3. 1069 - Reservation Failure Condition 1071 When a QNE detects that a reservation failure occurs for at least one 1072 parameter, the QNE sets the E Flags for the QSPEC parameters and 1073 QSPEC object that failed to be satisfied. According to [QoS-SIG], 1074 the QNE behavior depends on whether it is stateful or not. When a 1075 stateful QNE determines the reservation failed, it formulates a 1076 RESPONSE message that includes an INFO_SPEC with the 'reservation 1077 failure' error code and QSPEC object. The QSPEC in the RESPONSE 1078 message includes the failed QSPEC parameters marked with the E Flag 1079 to clearly identify them. 1081 The default action for a stateless QoS NSLP QNE that detects a 1082 reservation failure condition is that it MUST continue to forward the 1083 RESERVE message to the next stateful QNE, with the E Flags 1084 appropriately set for each QSPEC parameter. The next stateful QNE 1085 then formulates the RESPONSE message as described above. 1087 - Malformed QSPEC Error Condition 1089 When a stateful QNE detects that one or more QSPEC parameters are 1090 erroneous, the QNE sets the error code 'malformed QSPEC' in the 1091 INFO_SPEC. In this case the QSPEC object with the E Flags 1092 appropriately set for the erroneous parameters is returned within 1093 the INFO_SPEC object. The QSPEC object can be truncated or fully 1094 included within the INFO_SPEC. 1096 According to [QoS-SIG], the QNE behavior depends on whether it is 1097 stateful or not. When a stateful QNE determines a malformed QSPEC 1098 error condition, it formulates a RESPONSE message that includes an 1099 INFO_SPEC with the 'malformed QSPEC' error code and QSPEC object. 1100 The QSPEC in the RESPONSE message includes, if possible, only the 1101 erroneous QSPEC parameters and no others. The erroneous QSPEC 1102 parameter(s) are marked with the E Flag to clearly identify them. If 1103 QSPEC parameters are returned in the INFO-SPEC that are not marked 1104 with the E flag, then any values of these parameters are irrelevant 1105 and MUST be ignored by the QNI. 1107 The default action for a stateless QoS NSLP QNE that detects a 1108 Malformed QSPEC error condition is that it MUST continue to forward 1109 the RESERVE message to the next stateful QNE, with the E Flags 1110 appropriately set for each QSPEC parameter. The next stateful QNE 1111 will then act as described in [QoS-SIG]. 1113 A 'malformed QSPEC' error code takes precedence over the 'reservation 1114 failure' error code, and therefore the case of reservation failure 1115 and QSPEC/RMF error conditions are disjoint and the same E Flag can 1116 be used in both cases without ambiguity. 1118 4.2.5 Special Case of Local QSPEC 1120 When an unsuccessful reservation problem occurs inside a local domain 1121 where a local QSPEC is used, only the topmost (local) QSPEC is 1122 affected (e.g. E flags are raised, etc.). The encapsulated 1123 initiator QSPEC is untouched. When the message (RESPONSE in case of 1124 stateful QNEs, RESERVE in case of stateless QNEs) however reaches the 1125 edge of the local domain, the local QSPEC is removed. The edge QNE 1126 must update the initiator QSPEC on behalf of the entire domain, 1127 reflecting the information received in the local QSPEC. This update 1128 concerns both parameter values and flags. Note that some 1129 intelligence is needed in mapping the E flags, etc. from the local 1130 QSPEC to the initiator QSPEC. For example, there may be no direct 1131 match between the parameters in the local and initiator QSPECs, but 1132 that does not mean that no E flags should be raised in the latter. 1134 4.3 QSPEC Procedures 1136 While the QSPEC template aims to put minimal restrictions on usage of 1137 QSPEC objects, interoperability between QNEs and between QOSMs must 1138 be ensured. We therefore give below an exhaustive list of QSPEC 1139 object combinations for the message sequences described in QoS NSLP 1140 [QoS-SIG]. A specific QOSM may prescribe that only a subset of the 1141 procedures listed below may be used. 1143 Note that QoS NSLP does not mandate the usage of a RESPONSE message. 1144 A positive RESPONSE message will only be generated if the QNE 1145 includes an RII (Request Identification Information) in the RESERVE 1146 message, and a negative RESPONSE message is always generated in case 1147 of an error or failure. Some of the QSPEC procedures below, 1148 however, are only meaningful when a RESPONSE message is possible. 1149 The QNI SHOULD in these cases include an RII. 1151 4.3.1 Two-Way Transactions 1153 Here the QNI issues a RESERVE message, which may be replied to by a 1154 RESPONSE message. The following 3 cases for QSPEC object usage 1155 exist: 1157 ID | RESERVE | RESPONSE 1158 --------------------------------------------------------------- 1159 1 | QoS Desired | QoS Reserved 1160 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1161 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1163 Table 1. Three Cases for Two-Way Transactions 1165 Case 1: 1167 If only QoS Desired is included in the RESERVE message, the implicit 1168 assumption is that exactly these resources must be reserved. If this 1169 is not possible the reservation fails. The parameters in QoS 1170 Reserved are copied from the parameters in QoS Desired. If the 1171 reservation is successful, the RESPONSE message can be omitted in 1172 this case. If a RESPONSE message was requested by a QNE on the 1173 path, the QSPEC in the RESPONSE message can be omitted. 1175 Case 2: 1177 When QoS Available is included in the RESERVE message also, some 1178 parameters will appear only in QoS Available and not in QoS Desired. 1179 It is assumed that the value of these parameters is collected for 1180 informational purposes only (e.g. path latency). 1182 However, some parameters in QoS Available can be the same as in QoS 1183 Desired. For these parameters the implicit message is that the QNI 1184 would be satisfied by a reservation with lower parameter values than 1185 specified in QoS Desired. For these parameters, the QNI seeds the 1186 parameter values in QoS Available to those in QoS Desired (except for 1187 cumulative parameters such as ). 1189 Each QNE interprets the parameters in QoS 1190 Available according to its current capabilities. Reservations in 1191 each QNE are hence based on current parameter values in QoS Available 1192 (and additionally those parameters that only appear in QoS Desired). 1193 The drawback of this approach is that, if the resulting resource 1194 reservation becomes gradually smaller towards the QNR, QNEs close to 1195 the QNI have an oversized reservation, possibly resulting in 1196 unnecessary costs for the user. Of course, in the RESPONSE the QNI 1197 learns what the actual reservation is (from the QoS RESERVED object) 1198 and can immediately issue a properly sized refreshing RESERVE. The 1199 advantage of the approach is that the reservation is performed in 1200 half-a-roundtrip time. 1202 The QSPEC parameter IDs and values included in the QoS Reserved 1203 object in the RESPONSE message MUST be the same as those in the QoS 1204 Desired object in the RESERVE message. For those QSPEC parameters 1205 that were also included in the QoS Available object in the RESERVE 1206 message, their value is copied from the QoS Available object (in 1207 RESERVE) into the QoS Reserved object (in RESPONSE). For the 1208 other QSPEC parameters, the value is copied from the QoS Desired 1209 object (the reservation would fail if the corresponding QoS could 1210 not be reserved). 1212 All parameters in the QoS Available object in the RESPONSE message 1213 are copied with their values from the QoS Available object in the 1214 RESERVE message (irrespective of whether they have also been copied 1215 into the QoS Desired object). Note that the parameters in the QoS 1216 Available object can be overwritten in the RESERVE message, whereas 1217 they cannot be overwritten in the RESPONSE message. 1219 In this case, the QNI SHOULD request a RESPONSE message since it will 1220 otherwise not learn what QoS is available. 1222 Case 3: 1224 This case is handled as case 2, except that the reservation fails 1225 when QoS Available becomes less than Minimum QoS for one parameter. 1226 If a parameter appears in the QoS Available object but not in the 1227 Minimum QoS object it is assumed that there is no minimum value for 1228 this parameter. 1230 Regarding , the default rule is that all 1231 QSPEC parameters that have been included in the RESERVE message by 1232 the QNI are also included in the RESPONSE message by the QNR with the 1233 value they had when arriving at the QNR. When traveling in the 1234 RESPONSE message, all parameters are 1235 read-only. Note that a QOSM specification may define its own 1236 parameters and processing rules. 1238 4.3.2 Three-Way Transactions 1240 Here the QNR issues a QUERY message which is replied to by the QNI 1241 with a RESERVE message if the reservation was successful. The QNR in 1242 turn sends a RESPONSE message to the QNI. The following 3 cases for 1243 QSPEC object usage exist: 1245 ID| QUERY | RESERVE | RESPONSE 1246 --------------------------------------------------------------------- 1247 1 |QoS Des. | QoS Des. | QoS Res. 1248 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1249 3 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl. | QoS Res. 1251 Table 2. Three Cases for Three-Way Transactions 1253 Cases 1 and 2: 1255 The idea is that the sender (QNR in this scenario) needs to inform 1256 the receiver (QNI in this scenario) about the QoS it desires. To 1257 this end the sender sends a QUERY message to the receiver including a 1258 QoS Desired QSPEC object. If the QoS is negotiable it additionally 1259 includes a (possibly zero) Minimum QoS object, as in Case 2. 1261 The RESERVE message includes the QoS Available object if the sender 1262 signaled that QoS is negotiable (i.e. it included the Minimum QoS 1263 object). If the Minimum QoS object received from the sender is 1264 included in the QUERY message, the QNI also includes the Minimum QoS 1265 object in the RESERVE message. 1267 For a successful reservation, the RESPONSE message in case 1 is 1268 optional (as is the QSPEC inside). In case 2 however, the RESPONSE 1269 message is necessary in order for the QNI to learn about the QoS 1270 available. 1272 Case 3: 1274 This is the 'RSVP-style' scenario. The sender (QNR in this scenario) 1275 issues a QUERY message with a QoS Desired object informing the 1276 receiver (QNI in this scenario) about the QoS it desires as above. 1277 It also includes a QoS Available object to collect path properties. 1278 Note that here path properties are collected with the QUERY message, 1279 whereas in the previous case 2 path properties were collected in the 1280 RESERVE message. 1282 Some parameters in the QoS Available object may the same as in the 1283 QoS Desired object. For these parameters the implicit message is 1284 that the sender would be satisfied by a reservation with lower 1285 parameter values than specified in QoS Desired. 1287 It is possible for the QoS Available object to contain parameters 1288 that do not appear in the QoS Desired object. It is assumed that the 1289 value of these parameters is collected for informational purposes 1290 only (e.g. path latency). Parameter values in the QoS Available 1291 object are seeded according to the sender's capabilities. Each QNE 1292 remaps or approximately interprets the parameter values according to 1293 its current capabilities. 1295 The receiver (QNI in this scenario) signals the QoS Desired object as 1296 follows: For those parameters that appear in both the QoS Available 1297 object and QoS Desired object in the QUERY message, it takes the 1298 (possibly remapped) QSPEC parameter values from the QoS Available 1299 object. For those parameters that only appear in the QoS Desired 1300 object, it adopts the parameter values from the QoS Desired object. 1302 The parameters in the QoS Available QSPEC object in the RESERVE 1303 message are copied with their values from the QoS Available QSPEC 1304 object in the QUERY message. Note that the parameters in the QoS 1305 Available object can be overwritten in the QUERY message, whereas 1306 they are cannot be overwritten in the RESERVE message. 1308 The advantage of this model compared to the sender-initiated 1309 reservation is that the situation of over-reservation in QNEs close 1310 to the QNI as described above does not occur. On the other hand, the 1311 QUERY message may find, for example, a particular bandwidth is not 1312 available. When the actual reservation is performed, however, the 1313 desired bandwidth may meanwhile have become free. That is, the 'RSVP 1314 style' may result in a smaller reservation than necessary. 1316 The sender includes all QSPEC parameters it cares about in the QUERY 1317 message. Parameters that can be overwritten are updated by QNEs as 1318 the QUERY message travels towards the receiver. The receiver 1319 includes all QSPEC parameters arriving in the QUERY message also in 1320 the RESERVE message, with the value they had when arriving at the 1321 receiver. Again, QOSM-specific QSPEC parameters and procedures may 1322 be defined in QOSM specification documents. 1324 Also in this scenario, the QNI SHOULD request a RESPONSE message 1325 since it will otherwise not learn what QoS is available. 1327 Regarding , the default rule is that all 1328 QSPEC parameters that have been included in the RESERVE message by 1329 the QNI are also included in the RESPONSE message by the QNR with the 1330 value they had when arriving at the QNR. When traveling in the 1331 RESPONSE message, all parameters are 1332 read-only. Note that a QOSM specification may define its own 1333 parameters and processing rules. 1335 4.3.3 Resource Queries 1337 Here the QNI issues a QUERY message in order to investigate what 1338 resources are currently available. The QNR replies with a RESPONSE 1339 message. 1341 ID | QUERY | RESPONSE 1342 -------------------------------------------- 1343 1 | QoS Available | QoS Available 1345 Table 3. One Case for Two-Way Transactions 1347 Note that the QoS Available object when traveling in the QUERY 1348 message can be overwritten, whereas in the RESPONSE message cannot be 1349 overwritten. 1351 Regarding , the default rule is that all 1352 QSPEC parameters that have been included in the RESERVE message by 1353 the QNI are also included in the RESPONSE message by the QNR with the 1354 value they had when arriving at the QNR. When traveling in the 1355 RESPONSE message, all parameters are 1356 read-only. Note that a QOSM specification may define its own 1357 parameters and processing rules. 1359 4.3.4 Bidirectional Reservations 1361 On a QSPEC level, bidirectional reservations are no different from 1362 uni-directional reservations, since QSPECs for different directions 1363 never travel in the same message. 1365 4.3.5 Preemption 1367 A flow can be preempted by a QNE based on QNE policy, where a 1368 decision to preempt a flow may account for various factors such as, 1369 for example, the values of the QSPEC preemption priority and 1370 defending priority parameters as described in Section 5.2.8. In 1371 this case the reservation state for this flow is torn down in this 1372 QNE, and the QNE sends a NOTIFY message to the QNI, as described in 1373 [QoS-SIG]. The NOTIFY message carries an INFO_SPEC with the error 1374 code as described in [QoS-SIG]. A QOSM specification document may 1375 specify whether a NOTIFY message also carries a QSPEC object. The 1376 QNI would normally tear down the preempted reservation by sending a 1377 RESERVE message with the TEAR flag set using the SII of the preempted 1378 reservation. However, the QNI can follow other procedures as 1379 specified in its QOSM specification document. 1381 4.4 QSPEC Extensibility 1383 Additional QSPEC parameters MAY need to be defined in the future 1384 and are defined in separate informational documents. For example, 1385 QSPEC parameters are defined in [RMD-QOSM] and [Y.1541-QOSM]. 1387 Guidelines on the technical criteria to be followed in evaluating 1388 requests for new codepoint assignments for QSPEC objects and QSPEC 1389 parameters are given in Section 7 (IANA Considerations). 1391 5. QSPEC Functional Specification 1393 This section defines the encodings of the QSPEC parameters. We first 1394 give the general QSPEC formats and then the formats of the QSPEC 1395 objects and parameters. 1397 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1398 well as 32-bit floating point numbers, are as specified in [RFC4506, 1399 IEEE754, NETWORK-BYTE-ORDER]. 1401 5.1 General QSPEC Formats 1403 The format of the QSPEC closely follows that used in GIST [GIST] and 1404 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1405 general format: 1407 o The overall format is Type-Length-Value (in that order). 1409 o Some parts of the type field are set aside for control flags. 1411 o Length has the units of 32-bit words, and measures the length of 1412 Value. If there is no Value, Length=0. The Object length 1413 excludes the header. 1415 o Value is a whole number of 32-bit words. If there is any padding 1416 required, the length and location MUST be defined by the 1417 object-specific format information; objects that contain variable 1418 length types may need to include additional length subfields to do 1419 so. 1421 o Any part of the object used for padding or defined as reserved("r") 1422 MUST be set to 0 on transmission and MUST be ignored on reception. 1424 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1426 o Duplicate objects, duplicate parameters, and/or multiple 1427 occurrences of a parameter MUST NOT be used. 1429 0 1 2 3 1430 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 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Common QSPEC Header | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 // QSPEC Objects // 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 5.1.1 Common Header Format 1439 The Common QSPEC Header is a fixed 4-byte long object containing the 1440 QSPEC Version, QSPEC Type, an identifier for the QSPEC Procedure (see 1441 Section 4.3), and an Initiator/Local QSPEC bit: 1443 0 1 2 3 1444 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1451 QSPEC Type: Identifies the particular type of QSPEC, e.g., a QSPEC 1452 Type corresponding to a particular QOSM. 1454 QSPEC Proc.: Identifies the QSPEC procedure and is composed of two 1455 times 4 bits. The first field identifies the Message 1456 Sequence, the second field identifies the QSPEC 1457 Object Combination used for this particular message 1458 sequence: 1460 0 1 2 3 4 5 6 7 1461 +-+-+-+-+-+-+-+-+ 1462 |Mes.Sq |Obj.Cmb| 1463 +-+-+-+-+-+-+-+-+ 1465 The Message Sequence field can attain the following 1466 values: 1468 0: Sender-Initiated Reservations 1469 1: Receiver-Initiated Reservations 1470 2: Resource Queries 1472 The Object Combination field can take the values between 1473 1 and 3 indicated in the tables in Section 4.3: 1474 Message Sequence: 0 1475 Object Combination: 1, 2, 3 1476 Semantic: see Table 1 in Section 4.3.1 1477 Message Sequence: 1 1478 Object Combination: 1, 2, 3 1479 Semantic: see Table 2 in Section 4.3.2 1480 Message Sequence: 2 1481 Object Combination: 1 1482 Semantic: see Table 3 in Section 4.3.3 1484 I: Initiator/Local QSPEC bit identifies whether the QSPEC is an 1485 initiator QSPEC or a local QSPEC, and is set to the following 1486 values: 1488 0: Initiator QSPEC 1489 1: Local QSPEC 1491 Length: The total length of the QSPEC excluding the common header 1492 The QSPEC Objects field is a collection of 1493 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1494 common format and each contain several parameters. 1496 5.1.2 QSPEC Object Header Format 1498 QSPEC objects share a common header format: 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 |E|r|r|r| Object Type |r|r|r|r| Length | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 E Flag: Set if an error occurs on object level 1507 Object Type = 0: QoS Desired (parameters cannot be overwritten) 1508 = 1: QoS Available (parameters may be overwritten; see 1509 Section 3.3) 1510 = 2: QoS Reserved (parameters cannot be overwritten) 1511 = 3: Minimum QoS (parameters cannot be overwritten) 1513 The r bits are reserved. 1515 Each QSPEC or QSPEC parameter within an object is similarly 1516 encoded in TLV format using a similar parameter header: 1518 0 1 2 3 1519 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 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 |M|E|N|r| Parameter ID |r|r|r|r| Length | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 M Flag: When set indicates the subsequent parameter MUST be 1525 interpreted. Otherwise the parameter can be ignored if not 1526 understood. 1527 E Flag: When set indicates either a) a reservation failure where the 1528 QSPEC parameter is not met, or b) an error occurred when this 1529 parameter was being interpreted (see Section 4.2.1). 1530 N Flag: Not-supported QSPEC parameter flag (see Section 4.2.2). 1531 Parameter ID: Assigned to each parameter (see below) 1533 Parameters are usually coded individually, for example, the parameter (Section 5.2.11). However, it is also possible 1535 to combine several sub-parameters into one parameter field, which is 1536 called 'container coding'. This coding is useful if either a) the 1537 sub-parameters always occur together, as for example the several 1538 sub-parameters that jointly make up the TMOD, or b) in order 1539 to make coding more efficient when the length of each sub-parameter 1540 value is much less than a 32-bit word (as for example described in 1541 [RMD-QOSM]) and to avoid header overload. When a container is 1542 defined, the Parameter ID and the M, E, and N flags refer to the 1543 container. Examples of container parameters are (specified 1544 below) and the PHR container parameter specified in [RMD-QOSM]. 1546 5.2 QSPEC Parameter Coding 1548 The references in the following sections point to the normative 1549 procedures for processing the QSPEC parameters and 1550 sub-parameters. 1552 5.2.1 Parameter [RFC2210, RFC2215] 1554 The parameter consists of the , ,

, and 1555 sub-parameters, which all must be populated in the 1556 parameter. Note that a second TMOD QSPEC parameter is 1557 specified below in Section 5.2.2. 1559 The coding for the parameter is as follows: 1561 0 1 2 3 1562 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 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 |1|E|0|r| 1 |r|r|r|r| 4 | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 The parameters are represented by three floating point 1576 numbers in single-precision IEEE floating point format followed by 1577 one 32-bit integer in network byte order. The first floating point 1578 value is the rate (r), the second floating point value is the bucket 1579 size (b), the third floating point is the peak rate (p), and the 1580 first unsigned integer is the minimum policed unit (m). The values of 1581 r and p are measured in bytes/second, b and m are measured in bytes. 1582 When r, b, and p terms are represented as IEEE floating point values, 1583 the sign bit MUST be zero (all values MUST be non-negative). 1584 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1585 than 162 (i.e., positive 35) are discouraged, except for specifying a 1586 peak rate of infinity. Infinity is represented with an exponent of 1587 all ones (255) and a sign bit and mantissa of all zeroes. 1589 5.2.2 Parameter [RFC2215] 1591 A second QSPEC parameter is specified as could be needed 1592 for example to support some DiffServ applications. 1594 Parameter Values: 1596 0 1 2 3 1597 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 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 |M|E|N|r| 2 |r|r|r|r| 4 | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | TMOD Rate-2 [r] (32-bit IEEE floating point number) | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | TMOD Size-2 [b] (32-bit IEEE floating point number) | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 When r, b, and p terms are represented as IEEE floating point values, 1611 the sign bit MUST be zero (all values MUST be non-negative). 1612 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1613 than 162 (i.e., positive 35) are discouraged, except for specifying a 1614 peak rate of infinity. Infinity is represented with an exponent of 1615 all ones (255) and a sign bit and mantissa of all zeroes. 1617 5.2.3 Parameter [RFC2210, RFC2215] 1619 0 1 2 3 1620 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 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 |M|E|N|r| 3 |r|r|r|r| 1 | 1623 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1624 | Path Latency (32-bit unsigned integer) | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 The Path Latency is a single 32-bit unsigned integer in network byte 1628 order. The composition rule for the parameter is 1629 summation with a clamp of (2**32) - 1 on the maximum value. The 1630 latencies are average values reported in units of one microsecond. A 1631 system with resolution less than one microsecond MUST set unused 1632 digits to zero. An individual QNE can advertise a latency value 1633 between 1 and 2**28 (somewhat over two minutes) and the total latency 1634 added across all QNEs can range as high as (2**32)-2. If the sum of 1635 the different elements delays exceeds (2**32)-2, the end-to-end 1636 advertised delay SHOULD be reported as indeterminate = (2**32)-1. A 1637 QNE that cannot accurately predict the latency of packets it is 1638 processing MUST raise the not-supported flag and either leave the 1639 value of Path Latency as is, or add its best estimate of its lower 1640 bound. A raised not-supported flag indicates the value of Path 1641 Latency is a lower bound of the real Path Latency. The distinguished 1642 value (2**32)-1 is taken to mean indeterminate latency because the 1643 composition function limits the composed sum to this value, it 1644 indicates the range of the composition calculation was exceeded. 1646 5.2.4 Parameter 1648 0 1 2 3 1649 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 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 |M|E|N|r| 4 |r|r|r|r| 4 | 1652 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1653 | Path Jitter STAT1(variance) (32-bit unsigned integer) | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer) | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Path Jitter STAT3(minimum Latency) (32-bit unsigned integer) | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | Path Jitter STAT4(Reserved) (32-bit unsigned integer) | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 The Path Jitter is a set of four 32-bit unsigned integers in network 1663 byte order. The Path Jitter parameter is the combination of four 1664 statistics describing the Jitter distribution with a clamp of 1665 (2**32) - 1 on the maximum of each value. The jitter STATs are 1666 reported in units of one microsecond. A system with resolution less 1667 than one microsecond MUST set unused digits to zero. An individual 1668 QNE can advertise jitter values between 1 and 2**28 (somewhat over 1669 two minutes) and the total jitter computed across all QNEs can range 1670 as high as (2**32)-2. If the combination of the different element 1671 values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be 1672 reported as indeterminate. A QNE that cannot accurately predict the 1673 jitter of packets it is processing MUST raise the not-supported flag 1674 and either leave the value of Path Jitter as is, or add its best 1675 estimate of its STAT values. A raised not-supported flag indicates 1676 the value of Path Jitter is a lower bound of the real Path Jitter. 1677 The distinguished value (2**32)-1 is taken to mean indeterminate 1678 jitter. A QNE that cannot accurately predict the jitter of packets 1679 it is processing SHOULD set its local path jitter parameter to this 1680 value. Because the composition function limits the total to this 1681 value, receipt of this value at a network element or application 1682 indicates that the true path jitter is not known. This MAY happen 1683 because one or more network elements could not supply a value, or 1684 because the range of the composition calculation was exceeded. 1686 NOTE: The Jitter composition function makes use of the 1687 parameter. Composition functions for loss, latency and jitter may be 1688 found in [Y.1541]. 1690 5.2.5 Parameter 1692 0 1 2 3 1693 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 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 |M|E|N|r| 5 |r|r|r|r| 1 | 1696 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1697 | Path Packet Loss Ratio (32-bit floating point) | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 The Path PLR is a single 32-bit single precision IEEE floating point 1701 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1703 value. The PLRs are reported in units of 10^-11. A system with 1704 resolution less than 10^-11 MUST set unused digits to zero. An 1705 individual QNE can advertise a PLR value between zero and 10^-2 1706 and the total PLR added across all QNEs can range as high as 10^-1. 1707 If the sum of the different elements values exceeds 10^-1, the 1708 end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE 1709 that cannot accurately predict the PLR of packets it is processing 1710 MUST raise the not-supported flag and either leave the value of Path 1711 PLR as is, or add its best estimate of its lower bound. A raised 1712 not-supported flag indicates the value of Path PLR is a lower bound 1713 of the real Path PLR. The distinguished value 10^-1 is taken to mean 1714 indeterminate PLR. A QNE which cannot accurately predict the PLR of 1715 packets it is processing SHOULD set its local path PLR parameter to 1716 this value. Because the composition function limits the composed sum 1717 to this value, receipt of this value at a network element or 1718 application indicates that the true path PLR is not known. This MAY 1719 happen because one or more network elements could not supply a value, 1720 or because the range of the composition calculation was exceeded. 1722 5.2.6 Parameter 1724 0 1 2 3 1725 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 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 |M|E|N|r| 6 |r|r|r|r| 1 | 1728 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1729 | Path Packet Error Ratio (32-bit floating point) | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 The Path PER is a single 32-bit single precision IEEE floating point 1733 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 1735 value. The PERs are reported in units of 10^-11. A system with 1736 resolution less than 10^-11 MUST set unused digits to zero. An 1737 individual QNE can advertise a PER value between zero and 10^-2 1738 and the total PER added across all QNEs can range as high as 10^-1. 1739 If the sum of the different elements values exceeds 10^-1, the 1740 end-to-end advertised PER SHOULD be reported as indeterminate. A QNE 1741 that cannot accurately predict the PER of packets it is processing 1742 MUST raise the not-supported flag and either leave the value of Path 1743 PER as is, or add its best estimate of its lower bound. A raised 1744 not-supported flag indicates the value of Path PER is a lower bound 1745 of the real Path PER. The distinguished value 10^-1 is taken to mean 1746 indeterminate PER. A QNE which cannot accurately predict the PER of 1747 packets it is processing SHOULD set its local path PER parameter to 1748 this value. Because the composition function limits the composed sum 1749 to this value, receipt of this value at a network element or 1750 application indicates that the true path PER is not known. This MAY 1751 happen because one or more network elements could not supply a value, 1752 or because the range of the composition calculation was exceeded. 1754 5.2.7 Parameter [RFC2212, RFC2215] 1756 0 1 2 3 1757 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 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 |M|E|N|r| 7 |r|r|r|r| 1 | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | Slack Term (S) (32-bit unsigned integer) | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 Slack term S MUST be nonnegative and is measured in microseconds. 1765 The Slack term, S, is represented as a 32-bit unsigned integer. Its 1766 value can range from 0 to (2**32)-1 microseconds. 1768 5.2.8 & Parameters 1769 [RFC3181] 1771 The coding for the & 1772 sub-parameters is as follows: 1774 0 1 2 3 1775 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 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 |M|E|N|r| 8 |r|r|r|r| 1 | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Preemption Priority | Defending Priority | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 Preemption Priority: The priority of the new flow compared with the 1783 defending priority of previously admitted flows. Higher values 1784 represent higher priority. 1786 Defending Priority: Once a flow is admitted, the preemption priority 1787 becomes irrelevant. Instead, its defending priority is used to 1788 compare with the preemption priority of new flows. 1790 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 1792 parameter is used. 1794 5.2.9 Parameter 1796 The coding for the parameter is as follows: 1798 0 1 2 3 1799 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 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 |M|E|N|r| 9 |r|r|r|r| 1 | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 |Y.2171 Adm Pri.|Admis. Priority| (Reserved) | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 Two fields are provided for the parameter and 1807 are populated according to the following rules. 1809 values are globally significant on an 1810 end-to-end basis. High priority flows, normal priority flows, and 1811 best-effort priority flows can have access to resources depending on 1812 their admission priority value, as described in [Y.2171], as follows: 1814 : 1816 0 - best-effort priority flow 1817 1 - normal priority flow 1818 2 - high priority flow 1820 If the QNI signals , it populates both 1821 the and fields with 1822 the same value. Downstream QNEs MUST NOT change the value in the 1823 field so that end-to-end consistency is 1824 maintained and MUST treat the flow priority according to the value 1825 populated. A QNE in a local domain MAY reset a different value of 1826 in a local QSPEC, but as specified in Section 1827 4.1 the local QSPEC MUST be consistent with the initiator QSPEC. 1828 That is, the local domain MUST specify an in the 1829 local QSPEC functionally equivalent to the specified by the QNI in the initiator QSPEC. 1832 If the QNI signals admission priority according to [EMERGENCY-RSVP], 1833 it populates a locally significant value in the 1834 field and places all 1's in the field. 1835 In this case the functional significance of the 1836 value is specified by the local network administrator. Higher 1837 values indicate higher priority. Downstream QNEs and RSVP nodes MAY 1838 reset the value according to the local rules 1839 specified by the local network administrator, but MUST NOT reset the 1840 value of the field. 1842 A reservation without an parameter MUST 1843 be treated as a reservation with an = 1. 1845 5.2.10 Parameter [RFC4412] 1847 The coding for the parameter is as follows: 1849 0 1 2 3 1850 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 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 |M|E|N|r| 10 |r|r|r|r| 1 | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | RPH Namespace | RPH Priority | (Reserved) | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 [RFC4412] defines a resource priority header (RPH) with parameters 1858 "RPH Namespace" and "RPH Priority", and if populated is applicable 1859 only to flows with high admission priority. A registry is created 1860 in [RFC4412] and extended in [EMERGENCY-RSVP] for IANA to assign 1861 the RPH priority parameter. In the extended registry, "Namespace 1862 Numerical Values" are assigned by IANA to RPH Namespaces and 1863 "Priority Numerical Values" are assigned to the RPH Priority. 1865 Note that the parameter MAY be used in 1866 combination with the parameter, which depends on the 1867 supported QOSM. Furthermore, if more than one RPH namespace is 1868 supported by a QOSM, then the QOSM MUST specify how the mapping 1869 between the priorities belonging to the different RPH namespaces are 1870 mapped to each other. 1872 Note also that additional work is needed to communicate these flow 1873 priority values to bearer-level network elements 1874 [VERTICAL-INTERFACE]. 1876 For the 4 priority parameters, the following cases are permissible 1877 (procedures specified in references): 1879 1 parameter: [Y.2171] 1880 2 parameters: , [RFC4412] 1881 2 parameters: , [RFC3181] 1882 3 parameters: , , 1883 [3GPP-1, 3GPP-2, 3GPP-3] 1884 4 parameters: , , 1885 , [3GPP-1, 3GPP-2, 1886 3GPP-3] 1888 It is permissible to have without , but not permissible to have without 1890 (alternatively is ignored in 1891 instances without ). 1893 eMLPP-like functionality (as defined in [3GPP-1, 3GPP-2]) specifies 1894 use of corresponding to the 'queuing allowed' 1895 part of eMLPP as well as 1896 corresponding to the 'preemption capable' and 'may be preempted' 1897 parts of eMLPP. 1899 5.2.11 Parameter 1901 0 1 2 3 1902 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 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 |M|E|N|r| 11 |r|r|r|r| 1 | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Excess Trtmnt |Remark Value | Reserved | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 1910 traffic, that is, traffic not covered by the parameter. 1911 The excess treatment parameter is set by the QNI. Allowed values are 1912 as follows: 1914 0: drop 1915 1: shape 1916 2: remark 1917 3: no metering or policing is permitted 1919 The default excess treatment in case that none is specified is that 1920 there are no guarantees to excess traffic, i.e. a QNE can do whatever 1921 it finds suitable. 1923 When excess treatment is set to 'drop', all marked traffic MUST be 1924 dropped by the QNE/RMF. 1926 When excess treatment is set to 'shape', it is expected that the 1927 QoS Desired object carries a TMOD parameter. Excess traffic 1928 is to be shaped to this TMOD. When the shaping causes 1929 unbounded queue growth at the shaper traffic can be dropped. If 1930 excess treatment is set to 'shape' and no TMOD parameter is given, 1931 the E flag is set for the parameter and the reservation fails. 1933 When excess treatment is set to 'remark', the excess treatment 1934 parameter MUST carry the remark value, and the remark values and 1935 procedures MUST be specified in the QOSM specification document. For 1936 example, packets may be remarked to drop or remarked to pertain to a 1937 particular QoS class (DSCP value). In the latter case, remarking 1938 relates to a DiffServ model where packets arrive marked as belonging 1939 to a certain QoS class/DSCP, and when they are identified as excess, 1940 they should then be remarked to a different QoS Class (DSCP value) 1941 indicated in the 'Remark Value', as follows: 1943 Remark Value (6 bits): indicates either drop (set to 0) or DSCP 1944 value to remark packets to when identified as 1945 excess 1947 If 'no metering or policing is permitted' is signaled, the QNE should 1948 accept the excess treatment parameter set by the sender with special 1949 care so that excess traffic should not cause a problem. To request 1950 the Null Meter [RFC3290] is especially strong, and should be used 1951 with caution. 1953 A NULL metering application [RFC2997] would not include the traffic 1954 profile, and conceptually it should be possible to support this with 1955 the QSPEC. A QSPEC without a traffic profile is not excluded by the 1956 current specification. However, note that the traffic profile is 1957 important even in those cases when the excess treatment is not 1958 specified, e.g., in negotiating bandwidth for the best effort 1959 aggregate. However, a "NULL Service QOSM" would need to be specified 1960 where the desired QNE Behavior and the corresponding QSPEC format are 1961 described. 1963 As an example behavior for a NULL metering, in the properly 1964 configured DiffServ router, the resources are shared between the 1965 aggregates by the scheduling disciplines. Thus, if the incoming rate 1966 increases, it will influence the state of a queue within that 1967 aggregate, while all the other aggregates will be provided sufficient 1968 bandwidth resources. NULL metering is useful for best effort and 1969 signaling data, where there is no need to meter and police this data 1970 as it will be policed implicitly by the allocated bandwidth and, 1971 possibly, active queue management mechanism. 1973 5.2.12 Parameter [RFC3140] 1975 The coding for the parameter is as follows: 1977 0 1 2 3 1978 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 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 |M|E|N|r| 12 |r|r|r|r| 1 | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 1983 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1985 As prescribed in RFC 3140, the encoding for a single PHB is the 1986 recommended DSCP value for that PHB, left-justified in the 16 bit 1987 field, with bits 6 through 15 set to zero. 1989 The encoding for a set of PHBs is the numerically smallest of the set 1990 of encodings for the various PHBs in the set, with bit 14 set to 1. 1991 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 1992 bit 14 set to 1.) 1994 Single PHB: 1996 0 1 1997 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | DSCP |0 0 0 0 0 0 0 0 0 0| 2000 +---+---+---+---+---+---+---+---+ 2002 Set of PHBs: 2004 0 1 2005 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | DSCP |0 0 0 0 0 0 0 0 1 0| 2008 +---+---+---+---+---+---+---+---+ 2010 PHBs not defined by standards action, i.e., experimental or local use 2011 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 2012 identification code, assigned by the IANA, is placed left-justified 2013 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 2014 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 2016 Single non-standard PHB (experimental or local): 2018 0 1 2019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | PHD ID CODE |0 0 0 1| 2022 +---+---+---+---+---+---+---+---+ 2024 Set of non-standard PHBs (experimental or local): 2026 0 1 2027 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | PHD ID CODE |0 0 1 1| 2030 +---+---+---+---+---+---+---+---+ 2032 Bits 12 and 13 are reserved either for expansion of the PHB 2033 identification code, or for other use, at some point in the future. 2035 In both cases, when a single PHBID is used to identify a set of PHBs 2036 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 2037 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 2038 intra-microflow traffic reordering when different PHBs from the set 2039 are applied to traffic in the same microflow). The set of AF1x PHBs 2040 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs 2041 that do not constitute a PHB Scheduling Class can be identified by 2042 using more than one PHBID. 2044 The registries needed to use RFC 3140 already exist, see 2045 [DSCP-REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs 2046 to be created for this purpose. 2048 5.2.13 Parameter [RFC4124] 2050 The coding for the parameter is as follows: 2052 0 1 2 3 2053 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 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 |M|E|N|r| 13 |r|r|r|r| 1 | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 |DSTE Cls. Type | (Reserved) | 2058 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2060 DSTE Class Type: Indicates the DSTE class type. Values currently 2061 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 2063 5.2.14 Parameter [Y.1541] 2065 The coding for the parameter is as follows: 2067 0 1 2 3 2068 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 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 |M|E|N|r| 14 |r|r|r|r| 1 | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 |Y.1541 QoS Cls.| (Reserved) | 2073 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2075 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 2076 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 2078 Class 0: 2079 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 2080 Real-time, highly interactive applications, sensitive to jitter. 2081 Application examples include VoIP, Video Teleconference. 2083 Class 1: 2084 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 2085 Real-time, interactive applications, sensitive to jitter. 2086 Application examples include VoIP, Video Teleconference. 2088 Class 2: 2089 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 2090 10^-3. Highly interactive transaction data. Application examples 2091 include signaling. 2093 Class 3: 2094 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 2095 10^-3. Interactive transaction data. Application examples include 2096 signaling. 2098 Class 4: 2099 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 2100 10^-3. Low Loss Only applications. Application examples include 2101 short transactions, bulk data, video streaming. 2103 Class 5: 2104 Mean delay unspecified, delay variation unspecified, loss ratio 2105 unspecified. Unspecified applications. Application examples include 2106 traditional applications of default IP networks. 2108 Class 6: 2109 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 2110 Applications that are highly sensitive to loss, such as television 2111 transport, high-capacity TCP transfers, and TDM circuit emulation. 2113 Class 7: 2114 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 2115 Applications that are highly sensitive to loss, such as television 2116 transport, high-capacity TCP transfers, and TDM circuit emulation. 2118 6. Security Considerations 2120 QSPEC security is directly tied to QoS NSLP security, and the QoS 2121 NSLP document [QoS-SIG] has a very detailed security discussion in 2122 Section 7. All the considerations detailed in Section 7 of [QoS-SIG] 2123 apply to QSPEC. 2125 The priority parameter raises possibilities for theft of service 2126 attacks because users could claim an emergency priority for their 2127 flows without real need, thereby effectively preventing serious 2128 emergency calls to get through. Several options exist for countering 2129 such attacks, for example 2131 - only some user groups (e.g. the police) are authorized to set the 2132 emergency priority bit 2134 - any user is authorized to employ the emergency priority bit for 2135 particular destination addresses (e.g. police) 2137 7. IANA Considerations 2139 This section defines the registries and initial codepoint assignments 2140 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 2141 It also defines the procedural requirements to be followed by IANA in 2142 allocating new codepoints. 2144 This specification creates the following registries with the 2145 structures as defined below: 2147 Object Types (12 bits): 2148 The following values are allocated by this specification: 2149 0-4: assigned as specified in Section 5: 2151 Object Type = 0: QoS Desired 2152 = 1: QoS Available 2153 = 2: QoS Reserved 2154 = 3: Minimum QoS 2156 The allocation policies for further values are as follows: 2157 5-63: Standards Action 2158 64-127: Private/Experimental Use 2159 128-4095: Reserved 2160 (Note: 'Reserved' just means 'do not give these out'.) 2162 QSPEC Version (4 bits): 2163 The following value is allocated by this specification: 2164 0: assigned to Version 0 QSPEC 2165 The allocation policies for further values are as follows: 2166 1-15: Standards Action 2167 A specification is required to depreciate, delete, or modify QSPEC 2168 versions. 2170 QSPEC Type (4 bits): 2171 The following value is allocated by this specification: 2172 0: Default 2173 The allocation policies for further values are as follows: 2174 1-63: Specification Required 2175 64-255: Reserved 2177 QSPEC Procedure (8 bits): 2178 Broken down into 2179 Message Sequence (4 bits): 2180 The following values are allocated by this specification: 2181 0-2: assigned as specified in Section 4.3: 2182 Message Sequence 0: 2183 Semantic: QSPEC Procedure = Two-Way Transaction 2184 (see Section 4.3.1) 2185 Message Sequence 1: 2186 Semantic: QSPEC Procedure = Three-Way Transaction 2187 (see Section 4.3.2) 2188 Message Sequence 2: 2189 Semantic: QSPEC Procedure = Resource Queries (see Section 4.3.3) 2190 The allocation policies for further values are as follows: 2191 3-15: Standards Action 2192 Object Combination (4 bits): 2193 The following values are allocated by this specification: 2194 The Object Combination field can take the values between 2195 1 and 3 indicated in the tables in Section 4.3: 2196 Message Sequence: 0 2197 Object Combination: 1, 2, 3 2198 Semantic: see Table 1 in Section 4.3.1 2199 Message Sequence: 1 2200 Object Combination: 1, 2, 3 2201 Semantic: see Table 2 in Section 4.3.2 2202 Message Sequence: 2 2203 Object Combination: 1, 2, 3 2204 Semantic: see Table 3 in Section 4.3.3 2205 The allocation policies for further values are as follows: 2206 3-15: Standards Action 2208 A specification is required to depreciate, delete, or modify QSPEC 2209 Procedures. 2211 Error Code (16 bits) 2212 The allocation policies are as follows: 2213 0-127: Specification Required 2214 128-255: Private/Experimental Use 2215 255-65535: Reserved 2216 A specification is required to depreciate, delete, or modify Error 2217 Codes. 2219 Parameter ID (12 bits): 2220 The following values are allocated by this specification: 2221 1-14: assigned as specified in Section 5.2: 2222 Parameter ID 1: 2223 2: 2224 3: 2225 4: 2226 5: 2227 6: 2228 7: 2229 8: & 2230 9: 2231 10: 2232 11: 2233 12: 2234 13: 2235 14: 2237 The allocation policies for further values are as follows: 2238 15-255: Specification Required 2239 256-1024: Private/Experimental Use 2240 1025-4095: Reserved 2242 A specification is required to depreciate, delete, or modify 2243 Parameter IDs. 2245 Y.2171 Admission Priority Parameter (8 bits): 2246 The following values are allocated by this specification: 2247 0-2: assigned as specified in Section 5.2.9: 2248 Y.2171 Admission Priority 0: best-effort priority flow 2249 1: normal priority flow 2250 2: high priority flow 2251 The allocation policies for further values are as follows: 2252 3-63: Standards Action 2253 64-255: Reserved 2254 RPH Namespace Parameter (16 bits): 2255 Note that [RFC4412] creates a registry for RPH Namespace and Priority 2256 values already (see Section 12.6 of [RFC4412]), and an extension to 2257 this registry is created in [EMERGENCY-RSVP], which will also be used 2258 for the QSPEC RPH parameter. In the extended registry, "Namespace 2259 Numerical Values" are assigned by IANA to RPH Namespaces and 2260 "Priority Numerical Values" are assigned to the RPH Priority. 2262 Excess Treatment Parameter (8 bits): 2263 The following values are allocated by this specification: 2264 0-3: assigned as specified in Section 5.2.11: 2265 Excess Treatment Parameter 0: drop 2266 1: shape 2267 2: remark 2268 3: no metering or policing is 2269 permitted 2270 The allocation policies for further values are as follows: 2271 4-63: Standards Action 2272 64-255: Reserved 2273 Remark Value (8 bits) 2274 The allocation policies are as follows: 2275 0-63: Specification Required 2276 64-127: Private/Experimental Use 2277 128-255: Reserved 2279 DSTE Class Type Parameter (8 bits): 2280 The following values are allocated by this specification: 2281 0-7: assigned as specified in Section 5.2.13: 2282 DSTE Class Type Parameter 0: DSTE Class Type 0 2283 1: DSTE Class Type 1 2284 2: DSTE Class Type 2 2285 3: DSTE Class Type 3 2286 4: DSTE Class Type 4 2287 5: DSTE Class Type 5 2288 6: DSTE Class Type 6 2289 7: DSTE Class Type 7 2290 The allocation policies for further values are as follows: 2291 8-63: Standards Action 2292 64-255: Reserved 2294 Y.1541 QoS Class Parameter (8 bits): 2295 The following values are allocated by this specification: 2296 0-7: assigned as specified in Section 5.2.14: 2298 Y.1541 QoS Class Parameter 0: Y.1541 QoS Class 0 2299 1: Y.1541 QoS Class 1 2300 2: Y.1541 QoS Class 2 2301 3: Y.1541 QoS Class 3 2302 4: Y.1541 QoS Class 4 2303 5: Y.1541 QoS Class 5 2304 6: Y.1541 QoS Class 6 2305 7: Y.1541 QoS Class 7 2307 The allocation policies for further values are as follows: 2308 8-63: Standards Action 2309 64-255: Reserved 2311 8. Acknowledgements 2313 The authors would like to thank (in alphabetical order) David Black, 2314 Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger 2315 Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, 2316 Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Tom Phelan, 2317 James Polk, Alexander Sayenko, John Rosenberg, Bernd Schloer, Hannes 2318 Tschofenig, and Sven van den Bosch for their very helpful 2319 suggestions. 2321 9. Contributors 2323 This document is the result of the NSIS Working Group effort. In 2324 addition to the authors/editors listed in Section 12, the following 2325 people contributed to the document: 2327 Roland Bless 2328 Institute of Telematics, Universitaet Karlsruhe (TH) 2329 Zirkel 2 2330 Karlsruhe 76131 2331 Germany 2332 Phone: +49 721 608 6413 2333 Email: bless@tm.uka.de 2334 URI: http://www.tm.uka.de/~bless 2336 Chuck Dvorak 2337 AT&T 2338 Room 2A37 2339 180 Park Avenue, Building 2 2340 Florham Park, NJ 07932 2341 Phone: + 1 973-236-6700 2342 Fax:+1 973-236-7453 2343 Email: cdvorak@research.att.com 2345 Yacine El Mghazli 2346 Alcatel 2347 Route de Nozay 2348 91460 Marcoussis cedex 2349 FRANCE 2350 Phone: +33 1 69 63 41 87 2351 Email: yacine.el_mghazli@alcatel.fr 2353 Georgios Karagiannis 2354 University of Twente 2355 P.O. BOX 217 2356 7500 AE Enschede 2357 The Netherlands 2358 Email: g.karagiannis@ewi.utwente.nl 2359 Andrew McDonald 2360 Siemens/Roke Manor Research 2361 Roke Manor Research Ltd. 2362 Romsey, Hants SO51 0ZN 2363 UK 2364 Email: andrew.mcdonald@roke.co.uk 2366 Al Morton 2367 AT&T 2368 Room D3-3C06 2369 200 S. Laurel Avenue 2370 Middletown, NJ 07748 2371 Phone: + 1 732 420-1571 2372 Fax: +.1 732 368-1192 2373 Email: acmorton@att.com 2375 Percy Tarapore 2376 AT&T 2377 Room D1-33 2378 200 S. Laurel Avenue 2379 Middletown, NJ 07748 2380 Phone: + 1 732 420-4172 2381 Email: tarapore@.att.com 2383 Lars Westberg 2384 Ericsson Research 2385 Torshamnsgatan 23 2386 SE-164 80 Stockholm, Sweden 2387 Email: Lars.Westberg@ericsson.com 2389 10. Normative References 2391 [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd 2392 Generation Partnership Project; Technical Specification Group 2393 Services and System Aspects; enhanced Multi Level Precedence and 2394 Preemption service (eMLPP) - Stage 1 (Release 7). 2395 [3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd 2396 Generation Partnership Project; Technical Specification Group Core 2397 Network; enhanced Multi-Level Precedence and Preemption service 2398 (eMLPP) - Stage 2 (Release 7). 2399 [3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd 2400 Generation Partnership Project; Technical Specification Group Core 2401 Network; enhanced Multi-Level Precedence and Preemption service 2402 (eMLPP) - Stage 3 (Release 6). 2403 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 2404 Signaling Transport," work in progress. 2405 [QoS-SIG] Manner, J., et al., "NSLP for Quality-of-Service 2406 Signaling," work in progress. 2407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2408 Requirement Levels", BCP 14, RFC 2119, March 1997. 2409 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2410 Services", RFC 2210, September 1997. 2412 [RFC2212] Shenker, S., et al., "Specification of Guaranteed Quality 2413 of Service," September 1997. 2414 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 2415 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 2416 1997. 2417 [RFC3140] Black, D., et al., "Per Hop Behavior Identification 2418 Codes," June 2001. 2419 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element," 2420 RFC 3181, October 2001. 2421 [RFC4124] Le Faucheur, F., et al., "Protocol Extensions for Support 2422 of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2005. 2423 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 2424 Priority for the Session Initiation Protocol(SIP)," RFC 4412, 2425 February 2006. 2426 [RFC4506] Eisler, M., "XDR: External Data Representation Standard," 2427 RFC 4506, May 2006. 2428 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 2429 for IP-Based Services," February 2006. 2430 [Y.2171] ITU-T Recommendation Y.2171, "Admission Control Priority 2431 Levels in Next Generation Networks," September 2006. 2433 11. Informative References 2435 [DQOS] Cablelabs, "PacketCable Dynamic Quality of Service 2436 Specification," CableLabs Specification PKT-SP-DQOS-I12-050812, 2437 August 2005. 2438 [EMERGENCY-RSVP] Le Faucheur, F., et. al., "Resource ReSerVation 2439 Protocol (RSVP) Extensions for Emergency Services," work in 2440 progress. 2441 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 2442 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 2443 754-1985, August 1985. 2444 [CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 2445 Controlled-Load Service with NSIS," work in progress. 2446 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 2447 [NETWORK-BYTE-ORDER] Wikipedia, "Endianness," 2448 http://en.wikipedia.org/wiki/Endianness. 2449 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 2450 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 2451 Protocol - Capability Set 3" Sep. 2003 2452 [RFC2205] Braden, B., et al., "Resource ReSerVation Protocol (RSVP) 2453 -- Version 1 Functional Specification," RFC 2205, September 1997. 2454 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 2455 IANA Considerations Section in RFCs," RFC 2434, October 1998. 2456 [RFC2474] Nichols, K., et al., "Definition of the Differentiated 2457 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 2458 December 1998. 2459 [RFC2475] Blake, S., et al., "An Architecture for Differentiated 2460 Services", RFC 2475, December 1998. 2461 [RFC2597] Heinanen, J., et al., "Assured Forwarding PHB Group," RFC 2462 2597, June 1999. 2463 [RFC2697] Heinanen, J., et al., "A Single Rate Three Color Marker," 2464 RFC 2697, September 1999. 2465 [RFC2997] Bernet, Y., et al., "Specification of the Null Service 2466 Type," RFC 2997, November 2000. 2467 [RFC3140] Black, D., et al., "Per Hop Behavior Identification 2468 Codes," RFC 3140, June 2001. 2469 [RFC3290] Bernet, Y., et al., "An Informal Management Model for 2470 Diffserv Routers," RFC 3290, May 2002. 2471 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 2472 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 2473 [RFC3564] Le Faucheur, F., et al., Requirements for Support of 2474 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 2475 July 2003 2476 [RMD-QOSM] Bader, A., et al., "RMD-QOSM - The Resource Management 2477 in Diffserv QOS Model," work in progress. 2478 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 2479 on Associating of Control Signaling Messages with Media Priority 2480 Levels," T1S1.7 & PRQC, October 2004. 2481 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 2482 Communication Service - IP Packet Transfer and Availability 2483 Performance Parameters," December 2002. 2484 [Y.1541-QOSM] Ash, J., et al., "Y.1541-QOSM -- Y.1541 QoS Model for 2485 Networks Using Y.1541 QoS Classes," work in progress. 2487 12. Authors' Addresses 2489 Gerald Ash (Editor) 2490 AT&T 2491 Email: gash5107@yahoo.com 2493 Attila Bader (Editor) 2494 Traffic Lab 2495 Ericsson Research 2496 Ericsson Hungary Ltd. 2497 Laborc u. 1 H-1037 2498 Budapest Hungary 2499 Email: Attila.Bader@ericsson.com 2501 Cornelia Kappler (Editor) 2502 deZem GmbH 2503 Knesebeckstr. 86/87 2504 10623 Berlin 2505 Germany 2506 Email: cornelia.kappler@googlemail.com 2508 David R. Oran (Editor) 2509 Cisco Systems, Inc. 2510 7 Ladyslipper Lane 2511 Acton, MA 01720, USA 2512 Email: oran@cisco.com 2514 Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved of 2515 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 2516 The union of QoS Desired, QoS Available and QoS Reserved can provide 2517 all functionality of the objects specified in RSVP IntServ, however 2518 it is difficult to provide an exact mapping. 2520 In RSVP, the Sender TSpec specifies the traffic an application is 2521 going to send (e.g. TMOD). The AdSpec can collect path 2522 characteristics (e.g. delay). Both are issued by the sender. The 2523 receiver sends the FlowSpec which includes a Receiver TSpec 2524 describing the resources reserved using the same parameters as the 2525 Sender TSpec, as well as a RSpec which provides additional IntServ 2526 QoS Model specific parameters, e.g. Rate and Slack. 2528 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 2529 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 2530 knowledge of the authors it is not possible for the sender to specify 2531 a desired maximum delay except implicitly and mutably by seeding the 2532 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 2533 the receiver-issued RSVP RESERVE message. For this reason our 2534 discussion at this point leads us to a slightly different mapping of 2535 necessary functionality to objects, which should result in more 2536 flexible signaling models. 2538 Appendix B. Change History & Open Issues 2540 This appendix should be removed by the RFC editor before publication. 2542 B.1 Change History (since Version -04) 2544 Version -05: 2546 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 2547 - discarded QSPEC parameter (Maximum packet size) since MTU 2548 discovery is expected to be handled by procedure currently defined 2549 by PMTUD WG 2550 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 2551 efficiency 2552 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 2553 - revised Section 6.2.2 on SIP priorities 2554 - added QSPEC procedures for "RSVP-style reservation", resource 2555 queries and bidirectional reservations in Sec. 7.1 2556 - reworked Section 7.2 2558 Version -06: 2560 - defined "not-supported flag" and "tunneled parameter flag" 2561 (subsumes "QSPEC parameter flag") 2562 - defined "error flag" for error handling 2563 - updated bit error rate (BER) parameter to packet loss ratio (PLR) 2564 parameter 2565 - added packet error ratio (PER) parameter 2566 - coding checked by independent expert 2567 - coding updated to include RE flags in QSPEC objects and MENT flags 2568 in QSPEC parameters 2570 Version -07: 2572 - added text (from David Black) on DiffServ QSPEC example in Section 2573 6 2574 - re-numbered QSPEC parameter IDs to start with 0 (Section 7) 2575 - expanded IANA Considerations Section 9 2577 Version -08: 2579 - update to 'RSVP-style' reservation in Section 6.1.2 to mirror what 2580 is done in RSVP 2581 - modified text (from David Black) on DiffServ QSPEC example in 2582 Section 6.2 2583 - update to general QSPEC parameter formats in Section 7.1 (length 2584 restrictions, etc.) 2585 - re-numbered QSPEC parameter IDs in Section 7.2 2586 - modified parameter values in Section 7.2.2 2587 - update to reservation priority Section 7.2.7 2588 - specify the 3 "STATS" in the parameter, Section 2589 7.2.9.4 2590 - minor updates to IANA Considerations Section 9 2592 Version -09: 2594 - remove the DiffServ example in Section 6.2 (intent is use text as a 2595 basis for a separate DIFFSERV-QOSM I-D) 2596 - update wording in example in Section 4.3, to reflect use of default 2597 QOSM and QOSM selection by QNI 2598 - make minor changes to Section 7.2.7.2, per the exchange on the list 2599 - add comment on error codes, after the first paragraph in Section 2600 4.5.1 2602 Version -10: 2604 - rewrote Section 2.0 for clarity 2605 - added clarifications on QSPEC parameters in Section 4.2; added 2606 discussion of forwarding options when a domain supports a different 2607 QOSM than the QNI 2608 - expanded Section 4.5 on error code handling, including redefined 2609 E Flag and editorial changes to the N Flag and T-Flag discussions 2610 - made some editorial clarifications in Section 4.6 on defining new 2611 mandatory (QSPEC) parameters, and also reference the 2612 [NSIS-EXTENSIBILITY] document 2613 - Section 4.7 added to identify what a QOSM specification document 2614 must include 2615 - clarified the requirements in Section 5.0 for defining a new QSPEC 2616 Version 2617 - made editorial changes to Section 6, and added procedures for 2618 handling preemption 2620 - removed QOSM ID assignments in Section 9.0; clarified procedures 2621 for defining new QSPEC parameters; added registry of QOSM error 2622 codes 2624 Version -11: 2626 - 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter' 2627 - 'QSPEC-2 parameter' replaces 'optional QSPEC parameter' 2628 - R-flag ('remapped parameter flag') introduced to denote remapping, 2629 approximating, or otherwise not strictly interpreting a QSPEC 2630 parameter 2631 - T-flag ('tunneled parameter flag') eliminated and incorporated 2632 within the R-flag 2633 - Section 4 rewritten on QOSM concept, QSPEC processing, etc. to 2634 provide a more logical flow of information 2635 - read-write/read-only flag associated with QSPEC objects eliminated 2636 and object itself defined as rw or ro without a flag 2637 - parameter redefined as non-QOSM-hop Q-flag 2638 - Section 7 on QSPEC parameter definitions revised to clearly 2639 separate QSPEC parameter coding from QSPEC parameter coding 2640 - , , and QSPEC parameters mapped 2641 to container parameters 2642 - references updated to include normative references defining 2643 procedures to 'strictly interpret' each QSPEC parameter 2644 - Section 7.2.1 on PHB class updated to specify additional RFC 3140 2645 cases 2646 - Section 7.2.1 on excess treatment updated to specify excess 2647 treatment behaviors 2649 Version -12: 2651 - Sections 4, 5, 6: Many editorial changes and rearrangements 2652 - Moved example of QSPEC processing to Appendix A 2653 - Section 7.2.2: Changed from a variable 2654 length to a fixed length parameter 2656 Version -13: 2658 - notion of QOSMs played down 2659 o language e.g. 'QNSLP/QSPEC can signal for different QOSMs across 2660 multiple domains' replaced by notion that 'QNSLP/QSPEC allows 2661 QNEs on the path to implement different data plane QoS mechanisms 2662 that meet QSPEC constraints' 2663 o a QOSM describes common capabilities among QNEs to act 2664 consistently when requested to admit traffic & in treating 2665 admitted traffic 2666 o a QOSM ID need not be defined or signaled 2667 o a QNE need not support any particular QOSM although a QNI 2668 normally includes a QSPEC corresponding to a particular QOSM 2669 - a 'QOSM specification' 2670 o still provides a rigorous specification of a QOSM & what it does 2671 o documents how a QNE interprets & treats various elements in QSPEC 2672 o can define additional QSPEC parameters 2673 - updated QOSM definition: 2674 a method to achieve QoS for a traffic flow, e.g., IntServ 2675 Controlled Load; specifies what sub-set of QSPEC QoS constraints & 2676 traffic handling directives a QNE implementing that QOSM is capable 2677 of supporting & how resources will be managed by the RMF 2678 - QSPEC1/QSPEC2 semantics replaced with following semantics: 2679 o source traffic description (mandatory to include by QNI & 2680 mandatory to interpret by downstream QNEs) 2681 > specified by traffic model (TMOD-1) parameter consisting of 2682 rate (r), bucket size (b), peak rate (p), minimum policed unit 2683 (m) (mathematically complete way to describe traffic source) 2684 > bandwidth only set r=p; b/m to large values (separate 2685 bandwidth parameter not needed) 2686 > TMOD-2 (optional to include) 2687 o constraints (optional to include): 2688 > Path Latency 2689 > Path Jitter 2690 > Path PLR 2691 > Path PER 2692 > Slack Term 2693 > Priority (Preemption, Defending, Admission, RPH Priority) 2694 o handling directives (optional to include): 2695 > Excess Treatment 2696 o traffic classifiers (optional to include): 2697 > PHB Class (PHB class set by downstream QNE to tell QNI how to 2698 mark traffic to ensure treatment committed by admission 2699 control) 2700 > DSTE Class Type 2701 > Y.1541 QoS class 2702 o eliminated: 2703 > Bandwidth 2704 > Ctot, Dtot, Csum, Dsum 2705 - concept of remapping QSPEC parameters eliminated 2706 - redefine 'interpret' a QSPEC parameter to mean 'must conform to 2707 RFCs defining parameter & procedures (formerly called 'strictly 2708 interpret') 2709 - concept of local QSPECs retained 2710 o allows simpler control plane in a local domain 2711 o edge nodes 2712 > must interpret initiator QSPEC parameters 2713 > can either initiate parallel session with local QSPEC or 2714 define a local QSPEC with encapsulated initiator QSPEC 2715 o local QSPEC interpreted by local domain QNEs 2716 o local QSPEC must be consistent with initiator QSPEC 2717 > e.g., RMD can initiate a local QSPEC that contains TMOD = 2718 bandwidth (sets r=p, b/m to large) 2719 - QSPEC flags modified as follows: 2720 o QNI sets M flag for each QSPEC parameter it populates that must 2721 be interpreted or reservation fails 2722 o if M flag set 2723 > downstream QNE MUST interpret parameter or reservation fails 2724 > if QNE does not support parameter it sets N flag & rejects 2725 reservation 2726 > if QNE supports parameter but cannot meet parameter, it sets E 2727 flag & rejects reservation 2728 o if M flag not set 2729 > downstream QNE SHOULD interpret parameter 2730 > if QNE does not support parameter it sets the N flag & 2731 optionally accepts or rejects reservation 2732 > if QNE supports parameter but cannot meet parameter, it sets E 2733 flag & optionally accepts or rejects reservation 2734 o R (remapped parameter) flag & Q (non QOSM) flag eliminated 2736 Version -14: 2738 - Section 4.3.3 added text that QOSM specifications SHOULD NOT define 2739 new RMF functions 2740 - Section 5.1 added text that both mechanisms can be used 2741 simultaneously: a) tunneling a QSPEC through a local domain and b) 2742 defining a local QSPEC and encapsulating the initiator QSPEC 2743 - Section 4.1 added text that signaling functionality is only defined 2744 by the QoS NSLP document 2745 - Section 4.1 added text that QOSMs are free to extend QSPECs by 2746 adding parameters but are not permitted to reinterpret or redefine 2747 the standard QSPEC parameters specified in this document 2749 Version -15: 2751 - editorial revisions made to Sections 4.1, 4.3.3, 5.3.1, 5.3.2, and 2752 5.3.3 according to agreements on NSIS discussion list archive. 2754 Version -16: 2756 - QSPEC Types: additional QSPEC Types can be defined per IANA 2757 Considerations Section (already in place); QSPEC Type = 0 is 2758 default 2759 - Initiator/Local QSPEC bit added 2760 - various editorial fixes: DSCP parameter encoding; various edits 2761 carry over from QSPEC-1 parameter removal; QSPEC version number 2762 edits & additional error code 2764 Version -17: 2765 - QSPEC Header format: added Length field 2767 Version -18: 2768 - clarified handling of Traffic Handling Directives in QoS Available 2769 in Sec. 4.3.3 2770 - classified Priority Parameters as Traffic Handling Directives 2771 (Previously and erroneously were classified as Constraint Parameters) 2772 - added units to TMOD parameter in 6.2.1 2773 - fixed error in possible object combination for Resource Queries in 2774 Sec 6.1 2775 - streamlined usage of QSPEC Type and added terminology 2776 Version -19: 2777 - changes made per NSIS chair review (as specified on list) 2779 Version -20: 2780 - changes made to Section 5.2.9 (Admission Priority) as specified on 2781 list 2783 B.2 Open Issues 2785 None. 2787 Intellectual Property Statement 2789 The IETF takes no position regarding the validity or scope of any 2790 Intellectual Property Rights or other rights that might be claimed to 2791 pertain to the implementation or use of the technology described in 2792 this document or the extent to which any license under such rights 2793 might or might not be available; nor does it represent that it has 2794 made any independent effort to identify any such rights. Information 2795 on the procedures with respect to rights in RFC documents can be 2796 found in BCP 78 and BCP 79. 2798 Copies of IPR disclosures made to the IETF Secretariat and any 2799 assurances of licenses to be made available, or the result of an 2800 attempt made to obtain a general license or permission for the use of 2801 such proprietary rights by implementers or users of this 2802 specification can be obtained from the IETF on-line IPR repository at 2803 http://www.ietf.org/ipr. 2805 The IETF invites any interested party to bring to its attention any 2806 copyrights, patents or patent applications, or other proprietary 2807 rights that may cover technology that may be required to implement 2808 this standard. Please address the information to the IETF at 2809 ietf-ipr@ietf.org. 2811 Full Copyright Statement 2813 Copyright (C) The IETF Trust (2008). 2815 This document is subject to the rights, licenses and restrictions 2816 contained in BCP 78, and except as set forth therein, the authors 2817 retain all their rights. 2819 Disclaimer of Validity 2821 This document and the information contained herein are provided on an 2822 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2823 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2824 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2825 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2826 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.