idnits 2.17.1 draft-ietf-nsis-qspec-16.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2733. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6249 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'QOS-SIG' is mentioned on line 1344, but not defined == Missing Reference: 'S' is mentioned on line 1731, but not defined == Unused Reference: 'RFC4506' is defined on line 2364, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 2376, but no explicit reference was found in the text == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2382, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-1' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-2' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'GIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' -- Duplicate reference: RFC3181, mentioned in 'RFC2434', was also mentioned in 'RFC3181'. Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 13 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 A. Bader 4 Expiration Date: September 2007 Ericsson 5 C. Kappler 6 Siemens Networks GmbH & Co KG 7 D. Oran 8 Cisco Systems, Inc. 10 March 2007 12 QoS NSLP QSPEC Template 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 23, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The QoS NSLP protocol is used to signal QoS reservations and is 46 independent of a specific QoS model (QOSM) such as IntServ or 47 DiffServ. Rather, all information specific to a QOSM is encapsulated 48 in a separate object, the QSPEC. This document defines a template 49 for the QSPEC including a number of QSPEC parameters. The QSPEC 50 parameters provide a common language to be re-used in several QOSMs 51 and thereby aim to ensure the extensibility and interoperability of 52 QoS NSLP. The node initiating the NSIS signaling adds an initiator 53 QSPEC, which indicates the QSPEC parameters that must be interpreted 54 by the downstream nodes less the reservation fails, thereby ensuring 55 the intention of the NSIS initiator is preserved along the signaling 56 path. 58 Table of Contents 60 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. QSPEC Framework . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2 QSPEC Objects . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 10 67 4.3.1 Traffic Model Parameter . . . . . . . . . . . . . . . 10 68 4.3.2 Constraints Parameters . . . . . . . . . . . . . . . 11 69 4.3.3 Traffic Handling Directives . . . . . . . . . . . . . 13 70 4.3.4 Traffic Classifiers . . . . . . . . . . . . . . . . . 13 71 4.4 Example of QSPEC Processing . . . . . . . . . . . . . . . . 14 72 5. QSPEC Processing & Procedures . . . . . . . . . . . . . . . . . 17 73 5.1 Local QSPEC Definition & Processing . . . . . . . . . . . . 17 74 5.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 75 Notification . . . . . . . . . . . . . . . . . . . . . . . 18 76 5.2.1 Reservation Failure & Error E-Flag . . . . . . . . . 19 77 5.2.2 QSPEC Parameter Not Supported N-Flag . . . . . . . . 20 78 5.2.3 INFO_SPEC Coding of Reservation Outcome . . . . . . . 20 79 5.2.4 QNE Generation of a RESPONSE message . . . . . . . . 21 80 5.2.5 Special Case of Local QSPEC . . . . . . . . . . . . . 22 81 5.3 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 22 82 5.3.1 Two-Way Transactions . . . . . . . . . . . . . . . . 22 83 5.3.2 Three-Way Transactions . . . . . . . . . . . . . . . 24 84 5.3.3 Resource Queries . . . . . . . . . . . . . . . . . . 26 85 5.3.4 Bidirectional Reservations . . . . . . . . . . . . . 26 86 5.3.5 Preemption . . . . . . . . . . . . . . . . . . . . . 26 87 5.4 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 27 88 6. QSPEC Functional Specification . . . . . . . . . . . . . . . . 27 89 6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 27 90 6.2 QSPEC Parameter Coding . . . . . . . . . . . . . . . . . . 30 91 6.2.1 Parameter . . . . . . . . . . . . . . . . . 30 92 6.2.2 Parameter . . . . . . . . . . . . . . . . . 31 93 6.2.3 Parameter . . . . . . . . . . . . . . 32 94 6.2.4 Parameter . . . . . . . . . . . . . . . 32 95 6.2.5 Parameter . . . . . . . . . . . . . . . . 33 96 6.2.6 Parameter . . . . . . . . . . . . . . . . 34 97 6.2.7 Parameter . . . . . . . . . . . . . . . 34 98 6.2.8 & 99 Parameters . . . . . . . . . . . . . . . . . . . . . 35 100 6.2.9 Parameter . . . . . . . . . . . 35 101 6.2.10 Parameter . . . . . . . . . . . . . . 36 102 6.2.11 Parameter . . . . . . . . . . . . 37 103 6.2.12 Parameter . . . . . . . . . . . . . . . 39 104 6.2.13 Parameter . . . . . . . . . . . . 40 105 6.2.14 Parameter . . . . . . . . . . . . 40 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 41 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 41 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 109 10. Normative References . . . . . . . . . . . . . . . . . . . . . 46 110 11. Informative References . . . . . . . . . . . . . . . . . . . . 47 111 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 48 112 Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved 113 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 48 114 Appendix B. Change History & Open Issues . . . . . . . . . . . . . 49 115 B.1 Change History (since Version -04) . . . . . . . . 49 116 B.2 Open Issues . . . . . . . . . . . . . . . . . . . 53 117 Intellectual Property Statement . . . . . . . . . . . . . . . . . 53 118 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 54 120 Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 1. Contributors 128 This document is the result of the NSIS Working Group effort. In 129 addition to the authors/editors listed in Section 12, the following 130 people contributed to the document: 132 Chuck Dvorak 133 AT&T 134 Room 2A37 135 180 Park Avenue, Building 2 136 Florham Park, NJ 07932 137 Phone: + 1 973-236-6700 138 Fax:+1 973-236-7453 139 Email: cdvorak@research.att.com 141 Yacine El Mghazli 142 Alcatel 143 Route de Nozay 144 91460 Marcoussis cedex 145 FRANCE 146 Phone: +33 1 69 63 41 87 147 Email: yacine.el_mghazli@alcatel.fr 149 Georgios Karagiannis 150 University of Twente 151 P.O. BOX 217 152 7500 AE Enschede 153 The Netherlands 154 Email: g.karagiannis@ewi.utwente.nl 156 Andrew McDonald 157 Siemens/Roke Manor Research 158 Roke Manor Research Ltd. 159 Romsey, Hants SO51 0ZN 160 UK 161 Email: andrew.mcdonald@roke.co.uk 163 Al Morton 164 AT&T 165 Room D3-3C06 166 200 S. Laurel Avenue 167 Middletown, NJ 07748 168 Phone: + 1 732 420-1571 169 Fax: +.1 732 368-1192 170 Email: acmorton@att.com 172 Percy Tarapore 173 AT&T 174 Room D1-33 175 200 S. Laurel Avenue 176 Middletown, NJ 07748 177 Phone: + 1 732 420-4172 178 Email: tarapore@.att.com 180 Lars Westberg 181 Ericsson Research 182 Torshamnsgatan 23 183 SE-164 80 Stockholm, Sweden 184 Email: Lars.Westberg@ericsson.com 186 2. Introduction 188 The QoS NSIS signaling layer protocol (NSLP) [QoS-SIG] establishes 189 and maintains state at nodes along the path of a data flow for the 190 purpose of providing forwarding resources (QoS) for that flow. The 191 design of QoS NSLP is conceptually similar to RSVP [RFC2205], and 192 meets the requirements of [RFC3726]. 194 A QoS-enabled domain supports a particular QoS model (QOSM), which is 195 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 196 provisioning methods and a QoS architecture. It defines the behavior 197 of the resource management function (RMF) defined in [QoS-SIG], 198 including inputs and outputs. Examples of QOSMs are IntServ, DiffServ 199 admission control, and those specified in [Y.1541-QOSM, CL-QOSM, 200 RMD-QOSM]. 202 The QoS NSLP protocol is used to signal QoS reservations and supports 203 signaling for different QOSMs. All information specific to a QOSM is 204 encapsulated in the QoS specification (QSPEC) object, and this 205 document defines a template for the QSPEC. 207 QSPEC parameters include, for example, a mandatory traffic model 208 (TMOD) parameter, constraints parameters, such as path latency and 209 path jitter, traffic handling directives, such as excess treatment, 210 and traffic classifiers such as PHB class. 212 QSPEC objects loosely correspond to the TSpec, RSpec and AdSpec 213 objects specified in RSVP and may contain, respectively, a 214 description of QoS desired, QoS reserved, and QoS available. 215 Going beyond RSVP functionality, the QSPEC also allows indicating 216 a range of acceptable QoS by defining a QSPEC object denoting 217 minimum QoS. Usage of these QSPEC objects is not bound to particular 218 message types thus allowing for flexibility. A QSPEC object 219 collecting information about available resources may travel in any 220 QoS NSLP message, for example a QUERY message or a RESERVE message. 221 The QSPEC travels in QoS NSLP messages but is opaque to the QoS NSLP, 222 and is only interpreted by the RMF. 224 Interoperability between QoS NSIS entities (QNEs) in different 225 domains is enhanced by the definition of a common set of QSPEC 226 parameters. A QoS NSIS initiator (QNI) initiating the QoS NSLP 227 signaling adds an initiator QSPEC object containing parameters 228 describing the desired QoS, normally based on the QOSM it supports. 229 QSPEC parameters flagged by the QNI must be interpreted by all QNEs 230 in the path, else the reservation fails. In contrast, QSPEC 231 parameters not flagged by the QNI may be skipped if not understood. 232 Additional QSPEC parameters can be defined by informational 233 specification documents, and thereby ensure the extensibility and 234 flexibility of QoS NSLP. 236 A local QSPEC can be defined in a local domain with the initiator 237 QSPEC encapsulated, which is functionally consistent with the 238 initiator QSPEC in terms of defined source traffic (TMOD parameter) 239 and other constraints. A local QSPEC, for example, can enable 240 simpler processing by QNEs within the local domain. 242 In Section 4.4 a worked example of QSPEC processing is provided. 244 3. Terminology 246 Initiator QSPEC: A QSPEC Type. The initiator QSPEC is included into 247 a QoS NSLP message by the QNI/QNR. It travels end-to-end to the 248 QNR/QNI and is never removed. 250 Local QSPEC: A QSPEC Type. A local QSPEC is used in a local domain 251 and is domain specific. It encapsulates the initiator QSPEC and is 252 removed at the egress of the local domain. 254 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 255 any QNE. Together with a description of QoS Desired or QoS 256 Available, it allows the QNI to specify a QoS range, i.e. an upper 257 and lower bound. If the QoS Desired cannot be reserved, QNEs are 258 going to decrease the reservation until the minimum QoS is hit. 260 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 262 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 264 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 266 QoS Available: QSPEC object containing parameters describing the 267 available resources. They are used to collect information along a 268 reservation path. 270 QoS Desired: QSPEC object containing parameters describing the 271 desired QoS for which the sender requests reservation. 273 QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., 274 IntServ Controlled Load; specifies what sub-set of QSPEC QoS 275 constraints & traffic handling directives a QNE implementing that 276 QOSM is capable of supporting & how resources will be managed by the 277 RMF. 279 QoS Reserved: QSPEC object containing parameters describing the 280 reserved resources and related QoS parameters. 282 QSPEC: QSPEC is the object of QoS NSLP containing all QoS-specific 283 information. 285 QSPEC parameter: Any parameter appearing in a QSPEC; for 286 example, traffic model (TMOD), path latency, and excess treatment 287 parameters. 289 QSPEC Object: Main building blocks containing a QSPEC parameter set 290 that is input or output of an RMF operation. 292 Resource Management Function (RMF): Functions that are related to 293 resource management and processing of QSPEC parameters. 295 4. QSPEC Framework 297 The overall framework for the QoS NSLP is that [QoS-SIG] defines QoS 298 signaling and semantics, the QSPEC template defines the container and 299 semantics for QoS parameters and objects, and informational 300 specifications define QoS methods and procedures for using QoS 301 signaling and QSPEC parameters/objects within specific QoS 302 deployments. QoS NSLP is a generic QoS signaling protocol that can 303 signal for many QOSMs. 305 4.1 QoS Models 307 A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ 308 controlled load [CL-QOSM], resource management with DiffServ 309 [RMD-QOSM], and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM]. 310 A QOSM specifies a set of QSPEC parameters that describe the QoS 311 desired and how resources will be managed by the RMF. The RMF 312 implements functions that are related to resource management and 313 processes the QSPEC parameters. 315 QOSMs affect the operation of the RMF in NSIS-capable nodes, the 316 information carried in QSPEC objects, and may under some 317 circumstances (e.g. aggregation) cause a separate NSLP session to be 318 instantiated by having the RMF as a QNI. QOSM specifications may 319 define RMF triggers that cause the QoS NSLP to run semantics within 320 the underlying QoS NSLP signaling state and messaging processing 321 rules, as defined in Section 5.2 of [QoS-SIG]. New QoS NSLP message 322 processing rules can only be defined in Standards Track extensions to 323 the QoS NSLP. If a QOSM specification defines triggers that deviate 324 from existing standard QoS NSLP processing rules (must be standards 325 track in that case), the fallback for QNEs not supporting that QOSM 326 is to use the standard QoS NSLP state transition/message processing 327 rules. 329 The QOSM specification includes how the requested QoS resources will 330 be described and how they will be managed by the RMF. For this 331 purpose, the QOSM specification defines a set of QSPEC parameters it 332 uses to describe the desired QoS and resource control in the RMF, and 333 it may define additional QSPEC parameters. 335 When a QoS NSLP message travels through different domains, it may 336 encounter different QOSMs. Since QOSM use different QSPEC parameters 337 for describing resources, the QSPEC parameters included by the QNI 338 may not be understood in other domains. The QNI therefore can flag 339 those QSPEC parameters it considers vital with the M-flag. QSPEC 340 parameters with the M-flag set must be interpreted by the downstream 341 QNEs, or the reservation fails. QSPEC parameters without the M-flag 342 set should be interpreted by the downstream QNEs, but may be ignored 343 if not understood. 345 A QOSM specification MUST include the following: 347 - role of QNEs, e.g., location, frequency, statefulness, etc. 348 - QSPEC definition including QSPEC parameters 349 - QSPEC procedures applicable to this QOSM 350 - QNE processing rules describing how QSPEC information is treated 351 and interpreted in the RMF, e.g., 352 admission control, scheduling, policy control, QoS parameter 353 accumulation (e.g., delay). 354 - at least one bit-level QSPEC example 355 - QSPEC parameter behavior for new QSPEC parameters the QOSM 356 specification defines 357 - define what happens in case of preemption if the default QNI 358 behavior (tear down preempted reservation) is not followed (see 359 Section 5.3.5) 361 A QOSM specification MAY include the following: 363 - define additional QOSM-specific error codes, as discussed in 364 Section 5.2.3 365 - can state which QoS-NSLP options a QOSM wants to use, when 366 several options are available for a QOSM (e.g., local QSPEC to 367 either a) hide initiator QSPEC within a local domain message, or 368 b) encapsulate initiator QSPEC). 370 QOSMs are free, subject to IANA registration and review rules, to 371 extend QSPECs by adding parameters of any of the kinds supported by 372 the standard QSPEC. This includes traffic description parameters, 373 constraint parameters and traffic handling directives. QOSMs are not 374 permitted, however, to reinterpret or redefine the standard QSPEC 375 parameters specified in this document. Note that signaling 376 functionality is only defined by the QoS NSLP document [QoS-SIG] and 377 not by this document or by QOSM specification documents. 379 4.2 QSPEC Objects 381 The QSPEC is the object of QoS NSLP containing QSPEC objects and 382 parameters. QSPEC objects are the main building blocks of the QSPEC 383 parameter set that is input or output of an RMF operation. QSPEC 384 parameters are the parameters appearing in a QSPEC, which must 385 include traffic (TMOD), and may optionally include constraints (e.g., 386 path latency), traffic handling directives (e.g., excess treatment), 387 and traffic classifiers (e.g., PHB class). The RMF implements 388 functions that are related to resource management and processes the 389 QSPEC parameters. 391 The QSPEC consists of a QSPEC version number and QSPEC objects. IANA 392 assigns a new QSPEC version number when changes that are not 393 backwards compatible are made to the QSPEC and this document is 394 reissued. Note that a new QSPEC version number is not needed when 395 new QSPEC parameters are specified. Later QSPEC versions MUST be 396 backward compatible with earlier QSPEC versions. That is, a version 397 n+1 device must support QSPEC version n (or earlier). On the other 398 hand, if a QSPEC version n (or earlier) device receives an NSLP 399 message specifying QSPEC version n+1, then the version n device 400 responds with an 'Incompatible QSPEC' error code (0x0f) response, as 401 discussed in Section 5.2.3, allowing the QNE that sent the NSLP 402 message to retry with a lower QSPEC version. 404 This document provides a template for the QSPEC in order to promote 405 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 406 is composed of up to four QSPEC objects, namely QoS Desired, QoS 407 Available, QoS Reserved and Minimum QoS. Each of these QSPEC objects 408 consists of a number of QSPEC parameters. A given QSPEC may contain 409 only a subset of the QSPEC objects, e.g. QoS Desired. The QSPEC 410 objects QoS Desired, QoS Available and QoS Reserved MUST be supported 411 by QNEs. Minimum QoS MAY be supported. 413 +---------------------------------------+ 414 | QSPEC Objects | 415 +---------------------------------------+ 417 \________________ ______________________/ 418 V 419 +----------+----------+---------+-------+ 420 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| 421 +----------+----------+---------+-------+ 423 \____ ____/\___ _____/\___ ____/\__ ___/ 424 V V V V 426 +-------------+... +-------------+... 427 |QSPEC Para. 1| |QSPEC Para. n| 428 +-------------+... +-------------+... 430 Figure 1: Structure of the QSPEC 432 The QoS Desired Object describe the resources the QNI desires to 433 reserve and hence this is a read-only QSPEC object in that the QSPEC 434 parameters carried in the object may not be overwritten. QoS Desired 435 is always included in a RESERVE message. 437 The QoS Available Object travels in a RESERVE or QUERY message and 438 collects information on the resources currently available on the 439 path. Hence QoS Available in this case is a read-write object, which 440 means the QSPEC parameters contained in QoS Available may be updated, 441 but they cannot be deleted). Each QNE MUST inspect all parameters of 442 this QSPEC object, and if resources available to this QNE are less 443 than what a particular parameter says currently, the QNE MUST adapt 444 this parameter accordingly. Hence when the message arrives at the 445 recipient of the message, reflects the bottleneck of 446 the resources currently available on a path. It can be used in a 447 QUERY message, for example, to collect the available resources along 448 a data path. 450 When QoS Available travels in a RESPONSE message, it in fact just 451 transports the result of a previous measurement performed by a 452 RESERVE or QUERY message back to the initiator. Therefore in this 453 case, QoS Available is read-only. 455 QoS Reserved reflects the resources that were reserved. It is a 456 read-only object. 458 Minimum QoS does not have an equivalent in RSVP. It allows the QNI 459 to define a range of acceptable QoS levels by including both the 460 desired QoS value and the minimum acceptable QoS in the same message. 461 Parameters cannot be overwritten in this QSPEC object. The desired 462 QoS is included with a QoS Desired and/or a QoS Available QSPEC 463 object seeded to the desired QoS value. The minimum acceptable QoS 464 value MAY be coded in the Minimum QoS QSPEC object. As the message 465 travels towards the QNR, QoS Available is updated by QNEs on the 466 path. If its value drops below the value of Minimum QoS the 467 reservation fails and is aborted. When this method is employed, the 468 QNR SHOULD signal back to the QNI the value of QoS Available 469 attained in the end, because the reservation MAY need to be adapted 470 accordingly. 472 Note that the relationship of QSPEC objects to RSVP objects is 473 covered in Appendix A. 475 4.3 QSPEC Parameters 477 QSPEC parameters provide a common language for building QSPEC 478 objects. This document defines a number of QSPEC parameters, 479 additional parameters may be defined in separate QOSM specification 480 documents. For example, QSPEC parameters are defined in [RMD-QOSM] 481 and [Y.1541-QOSM]. 483 One QSPEC parameter, , is special. It provides a description 484 of the traffic for which resources are reserved. This parameter must 485 be included by the QNI and it must be interpreted by all QNEs. All 486 other QSPEC parameters are populated by a QNI if they are applicable 487 to the underlying QoS desired. For these QSPEC parameters, the QNI 488 sets the M-flag if they must be interpreted by downstream QNEs. If 489 QNEs cannot interpret the parameter the reservation fails. QSPEC 490 parameters populated by a QNI without the M-flag set should be 491 interpreted by downstream QNEs, but may be ignored if not understood. 493 In this document the term 'interpret' means, in relation to RMF 494 processing of QSPEC parameters, that the RMF processes the QSPEC 495 parameter according to the commonly accepted normative procedures 496 specified by references given for each QSPEC parameter. Note that a 497 QNE need only interpret a QSPEC parameter if it is populated in the 498 QSPEC object by the QNI; if not populated in the QSPEC, the QNE does 499 not interpret it of course. 501 Note that when an ingress QNE in a local domain defines a local QSPEC 502 and encapsulates the initiator QSPEC, the QNEs in the interior local 503 domain need only process the local QSPEC and can ignore the initiator 504 (encapsulated) QSPEC. However, edge QNEs in the local domain indeed 505 must interpret the QSPEC parameters populated in the initiator QSPEC 506 with the M-flag set and should interpret QSPEC parameters populated 507 in the initiator QSPEC without the M-flag set 508 As described in the previous section, QoS parameters may be 509 overwritten depending on which QSPEC object, and which message, they 510 appear in. 512 4.3.1 Traffic Model Parameter 514 The (TMOD) parameter is mandatory for the QNI to 515 include in the initiator QSPEC and mandatory for downstream QNEs to 516 interpret The traffic description specified by the TMOD parameter 517 is a container consisting of 4 sub-parameters: 519 o rate (r) 520 o bucket size (b) 521 o peak rate (p) 522 o minimum policed unit (m) 524 All 4 of the sub-parameters MUST be included in the TMOD parameter. 525 The TMOD parameter can be set to describe the traffic source. If, 526 for example, TMOD is set to specify bandwidth only, then set r = peak 527 rate = p, b = large, m = large. As another example if TMOD is set 528 for TCP traffic, then set r = average rate, b = large, p = large. 530 When the TMOD parameter in included in QoS Available, it provides 531 information, for example, about the TMOD resources available along 532 the path followed by a data flow. The value of TMOD at a QNE is an 533 estimate of the TMOD resources the QNE has available for packets 534 following the path up to the next QNE, including its outgoing link, 535 if this link exists. Furthermore, the QNI MUST account for the 536 resources of the ingress link, if this link exists. Computation of 537 the value of this parameter SHOULD take into account all information 538 available to the QNE about the path, taking into consideration 539 administrative and policy controls, as well as physical resources. 541 The output composed value is the minimum of the QNE's value and the 542 input composed value for r, b, and p, and the maximum of the 543 QNE's value and the input composed value for m. This quantity, 544 when composed end-to-end, informs the QNR (or QNI in a RESPONSE 545 message) of the minimal TMOD resources along the path from QNI to 546 QNR. 548 4.3.2 Constraints Parameters 550 , , , and are QSPEC 551 parameters describing the desired path latency, path jitter and path 552 bit error rate respectively. Since these parameters are cumulative, 553 an individual QNE cannot decide whether the desired path latency, 554 etc., is available, and hence they cannot decide whether a 555 reservation fails. Rather, when these parameters are included in 556 , the QNI SHOULD also include corresponding parameters 557 in a QoS Available QSPEC object in order to facilitate collecting 558 this information. 560 The parameter accumulates the latency of the packet 561 forwarding process associated with each QNE, where the latency is 562 defined to be the mean packet delay added by each QNE. This delay 563 results from the combination of speed-of-light propagation delay, 564 packet processing, and queueing. Each QNE MUST add the propagation 565 delay of its outgoing link, if this link exists. Furthermore, the 566 QNI MUST add the propagation delay of the ingress link, if this link 567 exists. The composition rule for the parameter is 568 summation with a clamp of (2**32 - 1) on the maximum value. This 569 quantity, when composed end-to-end, informs the QNR (or QNI in a 570 RESPONSE message) of the minimal packet delay along the path from QNI 571 to QNR. The purpose of this parameter is to provide a minimum path 572 latency for use with services which provide estimates or bounds on 573 additional path delay [RFC2212]. 575 The parameter accumulates the jitter of the packet 576 forwarding process associated with each QNE, where the jitter is 577 defined to be the nominal jitter added by each QNE. IP packet 578 jitter, or delay variation, is defined in [RFC3393], Section 3.4 579 (Type-P-One-way-ipdv), and where the selection function includes the 580 packet with minimum delay such that the distribution is equivalent to 581 2-point delay variation in [Y.1540]. The suggested evaluation 582 interval is 1 minute. This jitter results from packet processing 583 limitations, and includes any variable queuing delay which may be 584 present. Each QNE MUST add the jitter of its outgoing link, if this 585 link exists. Furthermore, the QNI MUST add the jitter of the ingress 586 link, if this link exists. The composition method for the parameter is the combination of several statistics describing 588 the delay variation distribution with a clamp on the maximum value 589 (note that the methods of accumulation and estimation of nominal QNE 590 jitter are specified in clause 8 of [Y.1541]). This quantity, when 591 composed end-to-end, informs the QNR (or QNI in a RESPONSE message) 592 of the nominal packet jitter along the path from QNI to QNR. The 593 purpose of this parameter is to provide a nominal path jitter for use 594 with services that provide estimates or bounds on additional path 595 delay [RFC2212]. 597 The parameter accumulates the packet loss ratio (PLR) of 598 the packet forwarding process associated with each QNE, where the PLR 599 is defined to be the PLR added by each QNE. Each QNE MUST add the 600 PLR of its outgoing link, if this link exists. Furthermore, the QNI 601 MUST add the PLR of the ingress link, if this link exists. The 602 composition rule for the parameter is summation with a 603 clamp on the maximum value (this assumes sufficiently low PLR values 604 such that summation error is not significant, however a more accurate 605 composition function is specified in clause 8 of [Y.1541]). This 606 quantity, when composed end-to-end, informs the QNR (or QNI in a 607 RESPONSE message) of the minimal packet PLR along the path from QNI 608 to QNR. 610 The parameter accumulates the packet error ratio (PER) of 611 the packet forwarding process associated with each QNE, where the PER 612 is defined to be the PER added by each QNE. Each QNE MUST add the 613 PER of its outgoing link, if this link exists. Furthermore, the QNI 614 MUST add the PER of the ingress link, if this link exists. The 615 composition rule for the parameter is summation with a 616 clamp on the maximum value (this assumes sufficiently low PER values 617 such that summation error is not significant, however a more accurate 618 composition function is specified in clause 8 of [Y.1541]). This 619 quantity, when composed end-to-end, informs the QNR (or QNI in a 620 RESPONSE message) of the minimal packet PER along the path from QNI 621 to QNR. 623 The slack term parameter is the difference between desired delay and 624 delay obtained by using bandwidth reservation, and which is used to 625 reduce the resource reservation for a flow [RFC2212]. 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 4.3.3 Traffic Handling Directives 640 An application MAY like to reserve resources for packets and also 641 specify a specific traffic handling behavior, such as . In addition, as discussed in Section 4.1, an application 643 MAY like to define RMF triggers that cause the QoS NSLP to run 644 semantics within the underlying QoS NSLP signaling state and 645 messaging 646 processing rules, as defined in Section 5.2 of [QoS-SIG]. Note, 647 however, that new QoS NSLP message processing rules can only be 648 defined in Standards Track extensions to the QoS NSLP. 650 As with constraints parameters and other QSPEC parameters, 651 traffic-handling-directives parameters may be defined in QOSM 652 specifications in order to provide support for QOSM-specific resource 653 management functions. Such QOSM-specific parameters are already 654 defined, for example, in [RMD-QOSM], [CL-QOSM] and [Y.1541-QOSM]. 656 The parameter describes how the QNE will process 657 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 658 be dropped, shaped and/or remarked. The excess treatment parameter is 659 initially set by the QNI, however setting the excess treatment 660 parameter by a downstream QNE is not precluded. 662 4.3.4 Traffic Classifiers 664 An application MAY like to reserve resources for packets with a 665 particular DiffServ per-hop behavior (PHB) [RFC2475]. Note that PHB 666 class is normally set by a downstream QNE to tell the QNI how to mark 667 traffic to ensure treatment committed by admission control, however, 668 setting of the parameter by the QNI is not precluded. An application 669 MAY like to reserve resources for packets with a particular QoS 670 class, e.g. Y.1541 QoS class [Y.1541] or DiffServ-aware MPLS traffic 671 engineering (DSTE) class type [RFC3564, RFC4124]. These parameters 672 are useful in various QOSMs, e.g., [RMD-QOSM], [Y.1541-QOSM], and 673 other QOSMs yet to be defined (e.g., DSTE-QOSM). This is intended to 674 provide guidelines to QOSMs on how to encode these parameters; use of 675 the PHB class parameter is illustrated in the example in the 676 following section. 678 4.4 Example of QSPEC Processing 680 This section illustrates the operation and use of the QSPEC within 681 the NSLP. The example configuration in shown in Figure 2. 683 +----------+ /-------\ /--------\ /--------\ 684 | Laptop | | Home | | Cable | | DiffServ | 685 | Computer |-----| Network |-----| Network |-----| Network |----+ 686 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 687 \-------/ \--------/ \--------/ | 688 | 689 +-----------------------------------------------+ 690 | 691 | /--------\ +----------+ 692 | | "X"G | | Handheld | 693 +---| Wireless |-----| Device | 694 | XG QOSM | +----------+ 695 \--------/ 697 Figure 2: Example Configuration to Illustrate QoS-NSLP/QSPEC 698 Operation 700 In this configuration, a laptop computer and a handheld wireless 701 device are the endpoints for some application that has QoS 702 requirements. Assume initially that the two endpoints are stationary 703 during the application session, later we consider mobile endpoints. 704 For this session, the laptop computer is connected to a home network 705 that has no QoS support. The home network is connected to a 706 CableLabs-type cable access network with dynamic QoS (DQOS) support, 707 such as specified in the [DQOS] for cable access networks. That 708 network is connected to a DiffServ core network that uses the RMD 709 QOSM [RMD-QOSM]. On the other side of the DiffServ core is a 710 wireless access network built on generation "X" technology with QoS 711 support as defined by generation "X". And finally the handheld 712 endpoint is connected to the wireless access network. 714 We assume that the Laptop is the QNI and handheld device is the QNR. 715 The QNI will signal an initiator QSPEC object to achieve the QoS 716 desired on the path. 718 The QNI sets QoS Desired, QoS Available and possibly Minimum 719 QoS QSPEC objects in the initiator QSPEC, and initializes QoS 720 Available to QoS Desired. Each QNE on the path reads and 721 interprets those parameters in the initiator QSPEC and checks to see 722 if QoS Available resources can be reserved. If not, the QNE reduces 723 the respective parameter values in QoS Available and reserves these 724 values. The minimum parameter values are given in Minimum QoS, if 725 populated, otherwise zero if Minimum QoS is not included. If one or 726 more parameters in QoS Available fails to satisfy the corresponding 727 minimum values in Minimum QoS, the QNE generates a RESPONSE message 728 to the QNI and the reservation is aborted. Otherwise, the QNR 729 generates a RESPONSE to the QNI with the QoS Available for the 730 reservation. If a QNE cannot reserve QoS Desired resources, the 731 reservation fails. 733 The QNI populates QSPEC parameters to ensure correct treatment of its 734 traffic in domains down the path. Let us assume the QNI wants to 735 achieve IntServ-Controlled Load-like QoS guarantees, and also is 736 interested in what path latency it can achieve. Additionally, to 737 ensure correct treatment further down the path, the QNI includes in . The QNI therefore includes in the QSPEC 740 QoS Desired = 741 QoS Available = 743 Since and are not vital parameters from 744 the QNI's perspective, it does not raise their M-flags. 746 There are three possibilities when a RESERVE message is received at a 747 QNE at a domain border (we illustrate these possibilities in the 748 example): 750 - the QNE just leaves the QSPEC as-is. 752 - the QNE can add a local QSPEC and encapsulate the initiator QSPEC 753 (see discussion in Section 5.1; this is new in QoS NSLP, RSVP does 754 not do this). 756 - the QNE can 'hide' the initiator RESERVE message so that only the 757 edge QNE processes the initiator RESERVE message, which then 758 bypasses intermediate nodes between the edges of the domain, and 759 issues its own local RESERVE message (see Section 3.3.1 of 760 [QoS-SIG]). For this new local RESERVE message, the QNE acts as 761 the QNI, and the QSPEC in the domain is an initiator QSPEC. A 762 similar procedure is also used by RSVP in making aggregate 763 reservations, in which case there is not a new intra-domain 764 (aggregate) RESERVE for each newly arriving interdomain (per-flow) 765 RESERVE, but the aggregate reservation is updated by the border 766 QNE (QNI) as need be. This is also how RMD works [RMD-QOSM]. 768 For example, at the RMD domain, a local RESERVE with its own RMD 769 initiator QSPEC corresponding to the RMD-QOSM is generated based on 770 the original initiator QSPEC according to the procedures described in 771 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. The ingress QNE to the 772 RMD domain maps the TMOD parameters contained in the original 773 initiator QSPEC into the equivalent TMOD parameter representing only 774 the peak bandwidth in the local QSPEC. The local RMD QSPEC for 775 example also needs , which in this case was provided by 776 the QNI. 778 Furthermore, the node at the egress to the RMD domain updates QoS 779 Available on behalf of the entire RMD domain if it can. If it 780 cannot (since the M-flag is not set for ) it raises the 781 parameter-specific, 'not-supported' flag, warning the QNR that the 782 final latency value in QoS Available is imprecise. 784 In the XG domain, the initiator QSPEC is translated into a local 785 QSPEC using a similar procedure as described above. The local QSPEC 786 becomes the current QSPEC used within the XG domain, and the 787 initiator QSPEC is encapsulated. This saves the QNEs within the XG 788 domain the trouble of re-translating the initiator QSPEC, and 789 simplifies processing in the local domain. At the egress edge of the 790 XG domain, the translated local QSPEC is removed, and the initiator 791 QSPEC returns to the number one position. 793 If the reservation was successful, eventually the RESERVE request 794 arrives at the QNR (otherwise the QNE at which the reservation failed 795 would have aborted the RESERVE and sent an error RESPONSE back to the 796 QNI). If the RII was included in the QoS NSLP message, the QNR 797 generates a positive RESPONSE with QSPEC objects QoS Reserved and 798 QoS Available. The parameters appearing in QoS Reserved are the 799 same as in QoS Desired, with values copied from QoS Available. 800 Hence, the QNR includes the following QSPEC objects in the RESPONSE: 802 QoS Reserved = 803 QoS Available = 805 If the handheld device on the right of Figure 2 is mobile, and moves 806 through different "XG" wireless networks, then the QoS might change 807 on the path since different XG wireless networks might support 808 different QOSMs. As a result, QoS NSLP/QSPEC processing will have to 809 renegotiate the QoS Available on the path. From a QSPEC 810 perspective, this is like a new reservation on the new section of the 811 path and is basically the same as any other rerouting event - to the 812 QNEs on the new path it looks like a new reservation. That is, in 813 this mobile scenario, the new segment may support a different QOSM 814 than the old segment, and the QNI would now signal a new reservation 815 (explicitly, or implicitly with the next refreshing RESERVE message) 816 to account for the different QOSM in the XG wireless domain. Further 817 details on rerouting are specified in [QoS-SIG]. 819 For bit-level examples of QSPECs see the documents specifying QOSMs 820 [CL-QOSM, Y.1541-QOSM, RMD-QOSM]. 822 5. QSPEC Processing & Procedures 824 The QNI sets the M-flag for each QSPEC parameter it populates that 825 must be interpreted by downstream QNEs. If a QNE does not support 826 parameter it sets the N-flag and fails the reservation. If the QNE 827 supports the parameter but cannot meet the resources requested by the 828 parameter, it sets the E-flag and fails the reservation. 830 If the M-flag is not set, the downstream QNE SHOULD interpret the 831 parameter. If the QNE does not support the parameter it sets the 832 N-flag and forwards the reservation. If the QNE supports the 833 parameter but cannot meet the resources requested by the parameter, 834 it sets the E-flag and fails the reservation. 836 5.1 Local QSPEC Definition & Processing 838 A QNE at the edge of a local domain may either a) translate the 839 initiator QSPEC into a local QSPEC and encapsulate the initiator 840 QSPEC in the RESERVE message, or b) 'hiding' the initiator QSPEC 841 through the local domain and reserve resources by generating a new 842 RESERVE message through the local domain containing the local QSPEC. 843 In either case the initiator QSPEC parameters are interpreted at the 844 local domain edges. 846 A local QSPEC may allow a simpler control plane in a local domain. 847 The edge nodes in the local domain must interpret the initiator 848 QSPEC parameters. They can either initiate a parallel session with 849 local QSPEC or define a local QSPEC and encapsulate the initiator 850 QSPEC, as illustrated in Figure 3. The Initiator/Local QSPEC bit 851 identifies whether the QSPEC is an initiator QSPEC or a local QSPEC. 852 The QSPEC Type indicates, for example, that the initiator of local 853 QSPEC corresponds to a certain QOSM, e.g., CL-QSPEC Type. It may be 854 useful for the QNI to signal a QSPEC Type based on some QOSM (which 855 will necessarily entail populating certain QOSM-related parameters) 856 so that a downstream QNE can chose amongst various QOSM-related 857 processes it might have. That is, the QNI populates the QSPEC Type, 858 e.g., CL-QSPEC Type and sets the Initiator/Local QSPEC bit to 859 'Initiator'. A local QNE can decide, for whatever reasons, to 860 Insert a local QSPEC Type, e.g., RMD-QSPEC Type, and set the local 861 QSPEC Type = RMD-QSPEC and set the Initiator/Local QSPEC bit to 862 'Local' (and encapsulate the Initiator QSPEC in the RESERVE or 863 whatever NSLP message). 865 +--------------------------------+\ 866 | QSPEC Type | \ 867 +--------------------------------+ / Common QQSPEC Header 868 | Init./Local QSPEC bit=Local |/ 869 +================================+\ 870 | Local-QSPEC Parameter 1 | \ 871 +--------------------------------+ \ 872 | .... | Local-QSPEC Parameters 873 +--------------------------------+ / 874 | Local-QSPEC Parameter n | / 875 +--------------------------------+/ 876 | +----------------------------+ | 877 | | QSPEC Type | | 878 | +----------------------------+ | 879 | | Init./Local QSPEC bit=Init.| | 880 | +============================+ | 881 | | | | Encapsulated Initiator QSPEC 882 | | .... | | 883 | +----------------------------+ | 884 +--------------------------------+ 886 Figure 3. Defining a Local QSPEC 888 Here the QoS-NSLP only sees and passes one QSPEC up to the RMF. The 889 type of the QSPEC thus may change within a local domain. Hence 891 o the QNI signals its QoS requirements with the initiator QSPEC, 892 o the ingress edge QNE in the local domain translates the 893 initiator QSPEC parameters to equivalent parameters in the local 894 QSPEC, 895 o the QNEs in the local domain only interpret the local QSPEC 896 parameters 897 o the egress QNE in the local domain processes the local QSPEC and 898 also interprets the QSPEC parameters in the initiator QSPEC. 900 The local QSPEC MUST be consistent with the initiator QSPEC. That 901 is, it MUST NOT specify a lower level of resources than specified 902 by the initiator QSPEC. For example, in RMD the TMOD parameters 903 contained in the original initiator QSPEC are mapped into the 904 equivalent TMOD parameter representing only the peak bandwidth in the 905 local QSPEC. 907 Note that it is possible to use both a) hiding a QSPEC through a 908 local domain by initiating a new RESERVE at the domain edge, and 909 b) defining a local QSPEC and encapsulating the initiator QSPEC, as 910 defined above. However, it is not expected that both the hiding and 911 encapsulating functions would be use at the same time for the same 912 flow. 914 5.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 915 Notification 917 A reservation may not be successful for several reasons: 919 - a reservation may fail because the desired resources are not 920 available. This is a reservation failure condition. 922 - a reservation may fail because the QSPEC is erroneous, or because 923 of a QNE fault. This is an error condition. 925 A reservation may be successful even though some parameters could not 926 be interpreted or updated properly: 928 - a QSPEC parameter cannot be interpreted because it is an unknown 929 QSPEC parameter type. This is a QSPEC parameter not supported 930 condition. The reservation however does not fail. The QNI can 931 still decide whether to keep or tear down the reservation depending 932 on the procedures specified by the QNI's QOSM. 934 The following sections describe the handling of unsuccessful 935 reservations and reservations where some parameters could not be met 936 in more detail, as follows: 938 - details on flags used inside the QSPEC to convey information on 939 success or failure of individual parameters. The formats and 940 semantics of all flags are given in Section 6. 941 - the content of the INFO_SPEC [QoS-SIG], which carries a code 942 indicating the outcome of reservations. 943 - the generation of a RESPONSE message to the QNI containing both 944 QSPEC and INFO_SPEC objects. 946 5.2.1 Reservation Failure & Error E-Flag 948 The QSPEC parameters each have a 'reservation failure error E-flag' 949 to indicate which (if any) parameters could not be satisfied. When a 950 resource cannot be satisfied for a particular parameter, the QNE 951 detecting the problem raises the E-flag in this parameter. Note that 952 the TMOD parameter and all QSPEC parameters with the M flag set MUST 953 be examined by the RMF, and all QSPEC parameters with the M flag not 954 set SHOULD be examined by the RMF, and appropriately flagged. 955 Additionally, the E-flag in the corresponding QSPEC object MUST be 956 raised when a resource cannot be satisfied for this parameter. If 957 the reservation failure problem cannot be located at the parameter 958 level, only the E-flag in the QSPEC object is raised. 960 When an RMF cannot interpret the QSPEC because the coding is 961 erroneous, it raises corresponding reservation failure E-flags in the 962 QSPEC. Normally all QSPEC parameters MUST be examined by the RMF 963 and the erroneous parameters appropriately flagged. In some cases, 964 however, an error condition may occur and the E-flag of the 965 error-causing QSPEC parameter is raised (if possible), but the 966 processing of further parameters may be aborted. 968 Note that if the QSPEC and/or any QSPEC parameter is found to be 969 erroneous, then any QSPEC parameters not satisfied are ignored and 970 the E-Flags in the QSPEC object MUST NOT be set for those parameters 971 (unless they are erroneous). 973 Whether E-flags denote reservation failure or error can be determined 974 by the corresponding error code in the INFO_SPEC in QoS NSLP, as 975 discussed below. 977 5.2.2 QSPEC Parameter Not Supported N-Flag 979 Each QSPEC parameter has an associated 'not supported N-flag'. If 980 the not supported N-flag is set, then at least one QNE along the data 981 transmission path between the QNI and QNR cannot interpret the 982 specified QSPEC parameter. A QNE MUST set the not supported N-flag 983 if it cannot interpret the QSPEC parameter. If the M-flag for the 984 parameter is not set, the message should continue to be forwarded but 985 with the N-flag set, and the QNI has the option of tearing the 986 reservation. 988 If a QNE in the path does not support a QSPEC parameter, e.g., 989 , and sets the N-flag, then downstream QNEs that 990 support the parameter SHOULD still update the parameter, even if the 991 N-flag is set. However, the presence of the N-flag will indicates 992 that the cumulative value only provides a bound, and the QNI/QNR 993 decides whether or not to accept the reservation with the N-flag set. 995 5.2.3 INFO_SPEC Coding of Reservation Outcome 997 As prescribed by [QoS-SIG], the RESPONSE message always contains the 998 INFO_SPEC with an appropriate 'error' code. It usually also contains 999 a QSPEC with QSPEC objects, as described in Section 5.3 on QSPEC 1000 Procedures. The RESPONSE message MAY omit the QSPEC in case of a 1001 successful reservation. 1003 The following guidelines are provided in setting the error codes in 1004 the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of 1005 [QoS-SIG]: 1007 - INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success): 1008 This code is set when all QSPEC parameters have been satisfied. In 1009 this case no E-Flag is set, however one or more N-flags may be set 1011 - INFO_SPEC error class 0x04 (Transient Failure) / 0x08 (Reservation 1012 Failure): 1013 This code is set when at least one QSPEC parameter could not be 1014 satisfied, or when a QSPEC parameter with M-flag could not be 1015 interpreted. E-flags are set for the parameters that could not be 1016 satisfied up to the QNE issuing the RESPONSE message. The N-flag is 1017 set for those parameters that could not be interpreted by at least 1018 one QNE. In this case QNEs receiving the RESPONSE message MUST 1019 remove the corresponding reservation. 1021 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0c (Malformed 1022 QSPEC): 1023 Some QSPEC parameters had associated errors, E-Flags are set for 1024 parameters that had errors, and the QNE where the error was found 1025 rejects the reservation. 1027 - INFO_SPEC error class 0x03 (Protocol Error) / 0x0f (Incompatible 1028 QSPEC): 1029 A higher version QSPEC is signaled and not support by the QNE. 1031 - INFO_SPEC error class 0x06 (QoS Model Error): 1032 QOSM error codes can be defined by QOSM specification documents. A 1033 registry is defined in Section 8 IANA Considerations. 1035 5.2.4 QNE Generation of a RESPONSE message 1037 - Successful Reservation Condition 1039 When a RESERVE message arrives at a QNR and no E-Flag is set, the 1040 reservation is successful. A RESPONSE message may be generated with 1041 INFO_SPEC code 'Reservation Success' as described above and in the 1042 QSPEC Procedures described in Section 5.3. 1044 - Reservation Failure Condition 1046 When a QNE detects that a reservation failure occurs for at least one 1047 parameter, the QNE sets the E-Flags for the QSPEC parameters and 1048 QSPEC object that failed to be satisfied. According to [QoS-SIG], 1049 the QNE behavior depends on whether it is stateful or not. When a 1050 stateful QNE determines the reservation failed, it formulates a 1051 RESPONSE message that includes an INFO_SPEC with the 'reservation 1052 failure' error code and QSPEC object. The QSPEC in the RESPONSE 1053 message includes the failed QSPEC parameters marked with the E-Flag 1054 to clearly identify them. 1056 The default action for a stateless QoS NSLP QNE that detects a 1057 reservation failure condition is that it MUST continue to forward the 1058 RESERVE message to the next stateful QNE, with the E-Flags 1059 appropriately set for each QSPEC parameter. The next stateful QNE 1060 then formulates the RESPONSE message as described above. 1062 - Malformed QSPEC Error Condition 1064 When a stateful QNE detects that one or more QSPEC parameters are 1065 erroneous, the QNE sets the error code 'malformed QSPEC' in the 1066 INFO_SPEC. In this case the QSPEC object with the E-Flags 1067 appropriately set for the erroneous parameters is returned within 1068 the INFO_SPEC object. The QSPEC object can be truncated or fully 1069 included within the INFO_SPEC. 1071 According to [QoS-SIG], the QNE behavior depends on whether it is 1072 stateful or not. When a stateful QNE determines a malformed QSPEC 1073 error condition, it formulates a RESPONSE message that includes an 1074 INFO_SPEC with the 'malformed QSPEC' error code and QSPEC object. 1075 The QSPEC in the RESPONSE message includes, if possible, only the 1076 erroneous QSPEC parameters and no others. The erroneous QSPEC 1077 parameter(s) are marked with the E-Flag to clearly identify them. If 1078 QSPEC parameters are returned in the INFO-SPEC that are not marked 1079 with the E-flag, then any values of these parameters are irrelevant 1080 and MUST be ignored by the QNI. 1082 The default action for a stateless QoS NSLP QNE that detects a 1083 Malformed QSPEC error condition is that it MUST continue to forward 1084 the RESERVE message to the next stateful QNE, with the E-Flags 1085 appropriately set for each QSPEC parameter. The next stateful QNE 1086 will then act as described in [QoS-SIG]. 1088 A 'malformed QSPEC' error code takes precedence over the 'reservation 1089 failure' error code, and therefore the case of reservation failure 1090 and QSPEC/RMF error conditions are disjoint and the same E-Flag can 1091 be used in both cases without ambiguity. 1093 5.2.5 Special Case of Local QSPEC 1095 When an unsuccessful reservation problem occurs inside a local domain 1096 where a local QSPEC is used, only the topmost (local) QSPEC is 1097 affected (e.g. E-flags are raised, etc.). The encapsulated 1098 initiator QSPEC is untouched. When the message (RESPONSE in case of 1099 stateful QNEs, RESERVE in case of stateless QNEs) however reaches the 1100 edge of the local domain, the local QSPEC is removed. The edge QNE 1101 must update the initiator QSPEC on behalf of the entire domain, 1102 reflecting the information received in the local QSPEC. This update 1103 concerns both parameter values and flags. Note that some 1104 intelligence 1105 is needed in mapping the E flags, etc. from the local QSPEC to the 1106 initiator QSPEC. For example, there may be no direct match between 1107 the parameters in the local and initiator QSPECs, but that does not 1108 mean that no E flags should be raised in the latter. 1110 5.3 QSPEC Procedures 1112 While the QSPEC template aims to put minimal restrictions on usage of 1113 QSPEC objects, interoperability between QNEs and between QOSMs must 1114 be ensured. We therefore give below an exhaustive list of QSPEC 1115 object combinations for the message sequences described in QoS NSLP 1116 [QoS-SIG]. A specific QOSM may prescribe that only a subset of the 1117 procedures listed below may be used. 1119 Note that QoS NSLP does not mandate the usage of a RESPONSE message. 1120 A positive RESPONSE message will only be generated if the QNE 1121 includes an RII (Request Identification Information) in the RESERVE 1122 message, and a negative RESPONSE message is always generated in case 1123 of an error or failure. Some of the QSPEC procedures below, 1124 however, are only meaningful when a RESPONSE message is possible. 1125 The QNI SHOULD in these cases include an RII. 1127 5.3.1 Two-Way Transactions 1129 Here the QNI issues a RESERVE message, which may be replied to by a 1130 RESPONSE message. The following 3 cases for QSPEC object usage 1131 exist: 1133 ID | RESERVE | RESPONSE 1134 --------------------------------------------------------------- 1135 1 | QoS Desired | QoS Reserved 1136 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1137 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1139 Case 1: 1141 If only QoS Desired is included in the RESERVE message, the implicit 1142 assumption is that exactly these resources must be reserved. If this 1143 is not possible the reservation fails. The parameters in QoS 1144 Reserved are copied from the parameters in QoS Desired. If the 1145 reservation is successful, the RESPONSE message can be omitted in 1146 this case. If a RESPONSE message was requested by a QNE on the 1147 path, the QSPEC in the RESPONSE message can be omitted. 1149 Case 2: 1151 When QoS Available is included in the RESERVE message also, some 1152 parameters will appear only in QoS Available and not in QoS Desired. 1153 It is assumed that the value of these parameters is collected for 1154 informational purposes only (e.g. path latency). 1156 However, some parameters in QoS Available can be the same as in QoS 1157 Desired. For these parameters the implicit message is that the QNI 1158 would be satisfied by a reservation with lower parameter values than 1159 specified in QoS Desired. For these parameters, the QNI seeds the 1160 parameter values in QoS Available to those in QoS Desired (except for 1161 cumulative parameters such as ). 1163 Each QNE interprets the parameters in QoS 1164 Available according to its current capabilities. Reservations in 1165 each QNE are hence based on current parameter values in QoS Available 1166 (and additionally those parameters that only appear in QoS Desired). 1167 The drawback of this approach is that, if the resulting resource 1168 reservation becomes gradually smaller towards the QNR, QNEs close to 1169 the QNI have an oversized reservation, possibly resulting in 1170 unnecessary costs for the user. Of course, in the RESPONSE the QNI 1171 learns what the actual reservation is (from the QoS RESERVED object) 1172 and can immediately issue a properly sized refreshing RESERVE. The 1173 advantage of the approach is that the reservation is performed in 1174 half-a-roundtrip time. 1176 The QSPEC parameter IDs and values included in the QoS Reserved 1177 object in the RESPONSE message MUST be the same as those in the QoS 1178 Desired object in the RESERVE message. For those QSPEC parameters 1179 that were also included in the QoS Available object in the RESERVE 1180 message, their value is copied into the QoS Desired object. For the 1181 other QSPEC parameters, the value is copied from the QoS Desired 1182 object (the reservation would fail if the corresponding QoS could 1183 not be reserved). 1185 All parameters in the QoS Available object in the RESPONSE message 1186 are copied with their values from the QoS Available object in the 1187 RESERVE message (irrespective of whether they have also been copied 1188 into the QoS Desired object). Note that the parameters in the QoS 1189 Available object can be overwritten in the RESERVE message, whereas 1190 they cannot be overwritten in the RESPONSE message. 1192 In this case, the QNI SHOULD request a RESPONSE message since it will 1193 otherwise not learn what QoS is available. 1195 Case 3: 1197 This case is handled as case 2, except that the reservation fails 1198 when QoS Available becomes less than Minimum QoS for one parameter. 1199 If a parameter appears in the QoS Available object but not in the 1200 Minimum QoS object it is assumed that there is no minimum value for 1201 this parameter. 1203 Regarding , the default rule is that all 1204 QSPEC parameters that have been included in the RESERVE message by 1205 the QNI are also included in the RESPONSE message by the QNR with the 1206 value they had when arriving at the QNR. When traveling in the 1207 RESPONSE message, all parameters are 1208 read-only. Note that a QOSM specification may define its own 1209 parameters and processing rules. 1211 5.3.2 Three-Way Transactions 1213 Here the QNR issues a QUERY message which is replied to by the QNI 1214 with a RESERVE message if the reservation was successful. The QNR in 1215 turn sends a RESPONSE message to the QNI. The following 3 cases for 1216 QSPEC object usage exist: 1218 ID| QUERY | RESERVE | RESPONSE 1219 --------------------------------------------------------------------- 1220 1 |QoS Des. | QoS Des. | QoS Res. 1221 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1222 3 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl. | QoS Res. 1224 Cases 1 and 2: 1226 The idea is that the sender (QNR in this scenario) needs to inform 1227 the receiver (QNI in this scenario) about the QoS it desires. To 1228 this end the sender sends a QUERY message to the receiver including a 1229 QoS Desired QSPEC object. If the QoS is negotiable it additionally 1230 includes a (possibly zero) Minimum QoS object, as in Case 2. 1232 The RESERVE message includes the QoS Available object if the sender 1233 signaled that QoS is negotiable (i.e. it included the Minimum QoS 1234 object). If the Minimum QoS object received from the sender is 1235 included in the QUERY message, the QNR also includes the Minimum QoS 1236 object in the RESERVE message. 1238 For a successful reservation, the RESPONSE message in case 1 is 1239 optional (as is the QSPEC inside). In case 2 however, the RESPONSE 1240 message is necessary in order for the QNI to learn about the QoS 1241 available. 1243 Case 3: 1245 This is the 'RSVP-style' scenario. The sender (QNR in this scenario) 1246 issues a QUERY message with a QoS Desired object informing the 1247 receiver (QNI in this scenario) about the QoS it desires as above. 1248 It also includes a QoS Available object to collect path properties. 1249 Note that here path properties are collected with the QUERY message, 1250 whereas in the previous case 2 path properties were collected in the 1251 RESERVE message. 1253 Some parameters in the QoS Available object may the same as in the 1254 QoS Desired object. For these parameters the implicit message is 1255 that the sender would be satisfied by a reservation with lower 1256 parameter values than specified in QoS Desired. 1258 It is possible for the QoS Available object to contain parameters 1259 that do not appear in the QoS Desired object. It is assumed that the 1260 value of these parameters is collected for informational purposes 1261 only (e.g. path latency). Parameter values in the QoS Available 1262 object are seeded according to the sender's capabilities. Each QNE 1263 remaps or approximately interprets the parameter values according to 1264 its current capabilities. 1266 The receiver (QNI in this scenario) signals the QoS Desired object as 1267 follows: For those parameters that appear in both the QoS Available 1268 object and QoS Desired object in the QUERY message, it takes the 1269 (possibly remapped) QSPEC parameter values from the QoS Available 1270 object. For those parameters that only appear in the QoS Desired 1271 object, it adopts the parameter values from the QoS Desired object. 1273 The parameters in the QoS Available QSPEC object in the RESERVE 1274 message are copied with their values from the QoS Available QSPEC 1275 object in the QUERY message. Note that the parameters in the QoS 1276 Available object can be overwritten in the QUERY message, whereas 1277 they are cannot be overwritten in the RESERVE message. 1279 The advantage of this model compared to the sender-initiated 1280 reservation is that the situation of over-reservation in QNEs close 1281 to the QNI as described above does not occur. On the other hand, the 1282 QUERY message may find, for example, a particular bandwidth is not 1283 available. When the actual reservation is performed, however, the 1284 desired bandwidth may meanwhile have become free. That is, the 'RSVP 1285 style' may result in a smaller reservation than necessary. 1287 The sender includes all QSPEC parameters it cares about in the QUERY 1288 message. Parameters that can be overwritten are updated by QNEs as 1289 the QUERY message travels towards the receiver. The receiver 1290 includes all QSPEC parameters arriving in the QUERY message also in 1291 the RESERVE message, with the value they had when arriving at the 1292 receiver. Again, QOSM-specific QSPEC parameters and procedures may 1293 be defined in QOSM specification documents. 1295 Also in this scenario, the QNI SHOULD request a RESPONSE message 1296 since it will otherwise not learn what QoS is available. 1298 Regarding , the default rule is that all 1299 QSPEC parameters that have been included in the RESERVE message by 1300 the QNI are also included in the RESPONSE message by the QNR with the 1301 value they had when arriving at the QNR. When traveling in the 1302 RESPONSE message, all parameters are 1303 read-only. Note that a QOSM specification may define its own 1304 parameters and processing rules. 1306 5.3.3 Resource Queries 1308 Here the QNI issues a QUERY message in order to investigate what 1309 resources are currently available. The QNR replies with a RESPONSE 1310 message. 1312 ID | QUERY | RESPONSE 1313 -------------------------------------------- 1314 1 | QoS Available | QoS Available 1316 Note that the QoS Available object when traveling in the QUERY 1317 message can be overwritten, whereas in the RESPONSE message cannot be 1318 overwritten. 1320 Regarding , the default rule is that all 1321 QSPEC parameters that have been included in the RESERVE message by 1322 the QNI are also included in the RESPONSE message by the QNR with the 1323 value they had when arriving at the QNR. When traveling in the 1324 RESPONSE message, all parameters are 1325 read-only. Note that a QOSM specification may define its own 1326 parameters and processing rules. 1328 5.3.4 Bidirectional Reservations 1330 On a QSPEC level, bidirectional reservations are no different from 1331 uni-directional reservations, since QSPECs for different directions 1332 never travel in the same message. 1334 5.3.5 Preemption 1336 A flow can be preempted by a QNE based on QNE policy, where a 1337 decision 1338 to preempt a flow may account for various factors such as, for 1339 example, the values of the QSPEC preemption priority and defending 1340 priority parameters as described in Section 6.2.8. In this case the 1341 reservation state for this flow is torn down in this QNE, and the QNE 1342 sends a NOTIFY message to the QNI, as described in [QoS-SIG]. The 1343 NOTIFY message carries an INFO_SPEC with the error code as described 1344 In [QOS-SIG]. A QOSM specification document may specify whether a 1345 NOTIFY message also carries a QSPEC object. The QNI would normally 1346 tear down the preempted reservation by sending a RESERVE message with 1347 the TEAR flag set using the SII of the preempted reservation. 1348 However, the QNI can follow other procedures as specified in its QOSM 1349 specification document. 1351 5.4 QSPEC Extensibility 1353 Additional QSPEC parameters MAY need to be defined in the future 1354 and are defined in separate informational documents. For example, 1355 QSPEC parameters are defined in [RMD-QOSM] and [Y.1541-QOSM]. 1357 Guidelines on the technical criteria to be followed in evaluating 1358 requests for new codepoint assignments for QSPEC objects and QSPEC 1359 parameters are given in Section 8 (IANA Considerations). 1361 Guidelines on the technical criteria to be followed in evaluating 1362 requests for new codepoint assignments beyond QSPEC objects and 1363 QSPEC parameters for the NSIS protocol suite are given in a separate 1364 NSIS extensibility document [NSIS-EXTENSIBILITY]. 1366 6. QSPEC Functional Specification 1368 This section defines the encodings of the QSPEC parameters. We first 1369 give the general QSPEC formats and then the formats of the QSPEC 1370 objects and parameters. 1372 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1373 well as 32-bit floating point numbers, are as specified in [RFC4506, 1374 IEEE754, NETWORK-BYTE-ORDER]. 1376 6.1 General QSPEC Formats 1378 The format of the QSPEC closely follows that used in GIST [GIST] and 1379 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1380 general format: 1382 o The overall format is Type-Length-Value (in that order). 1384 o Some parts of the type field are set aside for control flags. 1386 o Length has the units of 32-bit words, and measures the length of 1387 Value. If there is no Value, Length=0. The Object length 1388 excludes the header. 1390 o Value is a whole number of 32-bit words. If there is any padding 1391 required, the length and location MUST be defined by the 1392 object-specific format information; objects that contain variable 1393 length types may need to include additional length subfields to do 1394 so. 1396 o Any part of the object used for padding or defined as reserved("r") 1397 MUST be set to 0 on transmission and MUST be ignored on reception. 1399 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1401 o Duplicate objects, duplicate parameters, and/or multiple 1402 occurrences of a parameter MUST NOT be used. 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Common QSPEC Header | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 // QSPEC Objects // 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 The Common QSPEC Header is a fixed 4-byte long object containing the 1413 QSPEC Version, QSPEC Type, an identifier for the QSPEC Procedure (see 1414 Section 5.3), and an Initiator/Local QSPEC bit: 1416 0 1 2 3 1417 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 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Version | QSPEC Type | QSPEC Proc. |I| Reserved | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 Note that a length field is not necessary since the overall length of 1422 the QSPEC is contained in the higher level QoS NSLP data object. 1424 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1426 QSPEC Type: Identifies the particular type of QSPEC, e.g., a QSPEC 1427 Type corresponding to a particular QOSM. 1429 QSPEC Proc.: Identifies the QSPEC procedure and is composed of two 1430 times 4 bits. The first field identifies the Message 1431 Sequence, the second field identifies the QSPEC 1432 Object Combination used for this particular message 1433 sequence: 1435 0 1 2 3 4 5 6 7 1436 +-+-+-+-+-+-+-+-+ 1437 |Mes.Sq |Obj.Cmb| 1438 +-+-+-+-+-+-+-+-+ 1440 The Message Sequence field can attain the following 1441 values: 1443 0: Sender-Initiated Reservations 1444 1: Receiver-Initiated Reservations 1445 2: Resource Queries 1447 The Object Combination field can take the values between 1448 1 and 3 indicated in the tables in Section 5.3: 1449 Message Sequence: 0 1450 Object Combination: 1, 2, 3 1451 Semantic: see table in Section 5.3.1 1452 Message Sequence: 1 1453 Object Combination: 1, 2, 3 1454 Semantic: see table in Section 5.3.2 1455 Message Sequence: 2 1456 Object Combination: 1, 2, 3 1457 Semantic: see table in Section 5.3.3 1459 I: Initiator/Local QSPEC bit identifies whether the QSPEC is an 1460 initiator QSPEC or a local QSPEC, and is set to the following 1461 values: 1463 0: Initiator QSPEC 1464 1: Local QSPEC 1466 The QSPEC Objects field is a collection of 1467 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1468 common format and each contain several parameters. 1470 QSPEC objects share a common header format: 1472 0 1 2 3 1473 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 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 |E|r|r|r| Object Type |r|r|r|r| Length | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 E Flag: Set if an error occurs on object level 1479 Object Type = 0: QoS Desired (parameters cannot be overwritten) 1480 = 1: QoS Available (parameters may be overwritten; see 1481 Section 4.3) 1482 = 2: QoS Reserved (parameters cannot be overwritten) 1483 = 3: Minimum QoS (parameters cannot be overwritten) 1485 The r bits are reserved. 1487 Each QSPEC or QSPEC parameter within an object is similarly 1488 encoded in TLV format using a similar parameter header: 1490 0 1 2 3 1491 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 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 |M|E|N|r| Parameter ID |r|r|r|r| Length | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 M Flag: When set indicates the subsequent parameter MUST be 1497 interpreted. Otherwise the parameter can be ignored if not 1498 understood. 1499 E Flag: When set indicates either a) a reservation failure where the 1500 QSPEC parameter is not met, or b) an error occurred when this 1501 parameter was being interpreted (see Section 5.2.1). 1502 N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2). 1503 Parameter ID: Assigned to each parameter (see below) 1505 Parameters are usually coded individually, for example, the parameter (Section 6.2.11). However, it is also possible 1507 to combine several sub-parameters into one parameter field, which is 1508 called 'container coding'. This coding is useful if either a) the 1509 sub-parameters always occur together, as for example the several 1510 sub-parameters that jointly make up the TMOD, or b) in order 1511 to make coding more efficient when the length of each sub-parameter 1512 value is much less than a 32-bit word (as for example described in 1513 [RMD-QOSM]) and to avoid header overload. When a container is 1514 defined, the Parameter ID and the M, E, and N flags refer to the 1515 container. Examples of container parameters are (specified 1516 below) and the PHR container parameter specified in [RMD-QOSM]. 1518 6.2 QSPEC Parameter Coding 1520 6.2.1 Parameter 1522 =

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