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

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