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

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