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

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