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

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