idnits 2.17.1 draft-ietf-nsis-qspec-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2636. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2006) is 6525 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'S' is mentioned on line 1744, but not defined == Missing Reference: 'MTU' is mentioned on line 1804, but not defined == Missing Reference: 'Ctot' is mentioned on line 2164, but not defined == Missing Reference: 'Dtot' is mentioned on line 2171, but not defined == Missing Reference: 'Csum' is mentioned on line 2179, but not defined == Missing Reference: 'Dsum' is mentioned on line 2187, but not defined == Unused Reference: 'DSCP-REGISTRY' is defined on line 2366, but no explicit reference was found in the text == Unused Reference: 'PHBID-CODES-REGISTRY' is defined on line 2367, but no explicit reference was found in the text == Unused Reference: 'RFC1832' is defined on line 2372, but no explicit reference was found in the text == Unused Reference: 'IEEE754' is defined on line 2394, but no explicit reference was found in the text == Unused Reference: 'NETWORK-BYTE-ORDER' is defined on line 2399, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DSCP-REGISTRY' -- Possible downref: Non-RFC (?) normative reference: ref. 'PHBID-CODES-REGISTRY' -- Possible downref: Non-RFC (?) normative reference: ref. 'GIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Duplicate reference: RFC3181, mentioned in 'RFC3181', was also mentioned in 'RFC2434'. Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Internet Draft NSIS Working Group Jerry Ash 2 Internet Draft AT&T 3 Attila Bader 4 Expiration Date: December 2006 Ericsson 5 Cornelia Kappler 6 Siemens AG 8 June 2006 10 QoS NSLP QSPEC Template 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 22, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The QoS NSLP protocol is used to signal QoS reservations and is 44 independent of a specific QoS model (QOSM) such as IntServ or 45 DiffServ. Rather, all information specific to a QOSM is encapsulated 46 in a separate object, the QSPEC. This document defines a template 47 for the QSPEC, which contains both the QoS description and QSPEC 48 control information. The QSPEC format is defined, as are a number of 49 QSPEC parameters. The QSPEC parameters provide a common language to 50 be re-used in several QOSMs. To a certain extent QSPEC parameters 51 ensure interoperability of QOSMs. Optional QSPEC parameters aim to 52 ensure the extensibility of QoS NSLP to other QOSMs in the future. 53 The node initiating the NSIS signaling adds an Initiator QSPEC that 54 must not be removed, thereby ensuring the intention of the NSIS 55 initiator is preserved along the signaling path. 57 Table of Contents 59 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. QSPEC Parameters, Processing, & Extensibility . . . . . . . . . 7 63 4.1 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 7 64 4.2 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 8 65 4.3 Example of NSLP/QSPEC Operation . . . . . . . . . . . . . . 10 66 4.4 Treatment of QSPEC Parameters . . . . . . . . . . . . . . . 14 67 4.4.1 Mandatory and Optional QSPEC Parameters . . . . . . . 14 68 4.4.2 Read-only and Read-write QSPEC Parameters . . . . . . 15 69 4.5 Reservation Success/Failure, QSPEC Errors, & INFO_SPEC 70 Notification . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.5.1 Reservation Failure and Error E-Flag . . . . . . . . 16 72 4.5.2 QSPEC Parameter Not Supported N-Flag . . . . . . . . 17 73 4.5.3 QSPEC Tunneled Parameter T-Flag . . . . . . . . . . . 17 74 4.5.4 INFO_SPEC coding of reservation outcome . . . . . . . 17 75 4.5.5 QNE Generation of a RESPONSE message . . . . . . . . 18 76 4.5.6 Special Cases of QSPEC Stacking . . . . . . . . . . . 19 77 4.6 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 19 78 4.7 QOSM Specification Requirements . . . . . . . . . . . . . . 20 79 5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 20 80 5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 21 81 5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 22 82 5.2.1 . . . . . . . . . . . . . . . . . . . . 22 83 5.2.2 . . . . . . . . . . . . . . . . . . . 23 84 5.2.3 . . . . . . . . . . . . . . . . . . . 25 85 5.2.4 . . . . . . . . . . . . . . . . . . . . 26 86 6. QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . . . 26 87 6.1 Sender-Initiated Reservations . . . . . . . . . . . . . . . 26 88 6.2 Receiver-Initiated Reservations . . . . . . . . . . . . . . 28 89 6.3 Resource Queries . . . . . . . . . . . . . . . . . . . . . 29 90 6.4 Bidirectional Reservations . . . . . . . . . . . . . . . . 30 91 6.5 Preemption . . . . . . . . . . . . . . . . . . . . . 30 92 7. QSPEC Functional Specification . . . . . . . . . . . . . . . . 30 93 7.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 30 94 7.2 Parameter Coding . . . . . . . . . . . . . . . . . . . . . 33 95 7.2.1 Parameter . . . . . . . . . . . . . . 33 96 7.2.2 Parameter . . . . . . . . . . . . 34 97 7.2.3 . . . . . . . . . . . . . . . . . . . . . 35 98 7.2.4 Parameter . . . . . . . . . . . . . . . 35 99 7.2.5 Parameters . . . . . . . . . . . . . . 35 100 7.2.6 Parameters . . . . . . . . . . . . . . . 37 101 7.2.6.1 Parameter . . . . . . . . . . . . 37 102 7.2.6.2 Parameter . . . . . . . . 37 103 7.2.6.3 Parameter . . . . . . . . . 38 104 7.2.7 Priority Parameters . . . . . . . . . . . . . . . . . 38 105 7.2.7.1 & 106 Parameters . . . . . . . . . . . . . . . . . 38 107 7.2.7.2 Parameter . . . . . . . 39 108 7.2.7.3 Parameter . . . . . . . . . . 39 109 7.2.8 Parameter . . . . . . . . . . . . . . 41 110 7.2.9 Parameter . . . . . . . . . . . . . . . 41 111 7.2.10 Parameter . . . . . . . . . . . . . . . . 42 112 7.2.11 Parameter . . . . . . . . . . . . . . . . 43 113 7.2.12 Parameters . . . . . . . 43 114 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 44 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 117 11. Normative References . . . . . . . . . . . . . . . . . . . . . 48 118 12. Informative References . . . . . . . . . . . . . . . . . . . . 48 119 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49 120 Appendix A: QoS Models and QSPECs . . . . . . . . . . . . . . . . 50 121 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved 122 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 50 123 Appendix C: Main Changes Since Last Version & Open Issues . . . . 51 124 C.1 Main Changes Since Version -04 . . . . . . . . . . 51 125 C.2 Open Issues . . . . . . . . . . . . . . . . . . . 52 126 Intellectual Property Statement . . . . . . . . . . . . . . . . . 52 127 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 53 128 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 53 130 Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 1. Contributors 138 This document is the result of the NSIS Working Group effort. In 139 addition to the authors/editors listed in Section 13, the following 140 people contributed to the document: 142 Chuck Dvorak 143 AT&T 144 Room 2A37 145 180 Park Avenue, Building 2 146 Florham Park, NJ 07932 147 Phone: + 1 973-236-6700 148 Fax:+1 973-236-7453 149 Email: cdvorak@att.com 151 Yacine El Mghazli 152 Alcatel 153 Route de Nozay 154 91460 Marcoussis cedex 155 FRANCE 156 Phone: +33 1 69 63 41 87 157 Email: yacine.el_mghazli@alcatel.fr 159 Georgios Karagiannis 160 University of Twente 161 P.O. BOX 217 162 7500 AE Enschede 163 The Netherlands 164 Email: g.karagiannis@ewi.utwente.nl 166 Andrew McDonald 167 Siemens/Roke Manor Research 168 Roke Manor Research Ltd. 169 Romsey, Hants SO51 0ZN 170 UK 171 Email: andrew.mcdonald@roke.co.uk 173 Al Morton 174 AT&T 175 Room D3-3C06 176 200 S. Laurel Avenue 177 Middletown, NJ 07748 178 Phone: + 1 732 420-1571 179 Fax: +.1 732 368-1192 180 Email: acmorton@att.com 182 Percy Tarapore 183 AT&T 184 Room D1-33 185 200 S. Laurel Avenue 186 Middletown, NJ 07748 187 Phone: + 1 732 420-4172 188 Email: tarapore@.att.com 190 Lars Westberg 191 Ericsson Research 192 Torshamnsgatan 23 193 SE-164 80 Stockholm, Sweden 194 Email: Lars.Westberg@ericsson.com 196 2. Introduction 198 The QoS NSIS signaling layer protocol (NSLP) [QoS-SIG] establishes 199 and maintains state at nodes along the path of a data flow for the 200 purpose of providing forwarding resources (QoS) for that flow. The 201 design of QoS NSLP is conceptually similar to RSVP [RFC2205], and 202 meets the requirements of [RFC3726]. 204 A QoS-enabled domain supports a particular QoS model (QOSM), which is 205 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 206 provisioning methods and a QoS architecture. It defines the behavior 207 of the resource management function (RMF) defined in [QoS-SIG], 208 including inputs and outputs. 210 The QoS NSLP protocol is used to signal QoS reservations and supports 211 signaling for different QOSMs, such as for IntServ, DiffServ 212 admission control, and those specified in [Y.1541-QOSM, INTSERV-QOSM, 213 RMD-QOSM]. All information specific to a QOSM is encapsulated in 214 the QoS specification (QSPEC) object, which is QOSM specific, and 215 this document defines a template for the QSPEC. A particular QOSM 216 specifies a) a set of mandatory and optional QSPEC parameters, and 217 b) how the QSPEC information is interpreted by the RMF with respect 218 to the QoS description, resources desired, resources available, and 219 control information. 221 Since QoS NSLP signaling operation can be different for different 222 QOSMs, the QSPEC contains two kinds of information, QSPEC control 223 information and QoS description. QSPEC control information contains 224 parameters that governs the behavior of the RMF. An example of QSPEC 225 control information is how the excess traffic is treated in the RMF 226 queuing functions. The QoS description parameters include, for 227 example, traffic description parameters, such as and 228 , and constraints parameters, such as and 229 . 231 The QoS description is composed of QSPEC objects loosely 232 corresponding to the TSpec, RSpec and AdSpec objects specified in 233 RSVP. This is, the QSPEC may contain a description of QoS desired 234 and QoS reserved. It can also collect information about available 235 resources. Going beyond RSVP functionality, the QoS description 236 also allows indicating a range of acceptable QoS by defining a QSPEC 237 object denoting minimum QoS. Usage of these QSPEC objects is not 238 bound to particular message types thus allowing for flexibility. 239 A QSPEC object collecting information about available resources may 240 travel in any QoS NSLP message, for example a QUERY message or a 241 RESERVE message. The QSPEC travels in QoS NSLP messages but is 242 opaque to the QoS NSLP, and is only interpreted by the RMF. 244 Interoperability between QoS NSIS entities (QNEs) in different 245 domains that implement different QOSMs is enhanced (but not 246 guaranteed) by the definition of a common set of mandatory and 247 optional QSPEC parameters. Mandatory parameters in the QSPEC must be 248 meaningfully interpreted by all QNEs in the path, independent of 249 which QOSM they support. This way, NSIS provides a mechanism for 250 interdomain QoS signaling and interworking. Optional QSPEC 251 parameters, in contrast, may be skipped if not understood. 252 Additional optional parameters can be defined by all QOSMs, thereby 253 ensure the extensibility and flexibility of QoS NSLP. 255 A QoS NSIS initiator (QNI) initiating the QoS NSLP signaling adds an 256 initiator QSPEC object containing parameters describing the desired 257 QoS based on the QOSM it supports. A local QSPEC can be stacked on 258 the initiator QSPEC to accommodate different QOSMs being used in 259 different domains. A domain supporting a different local QOSM than 260 the QNI can interpret the initiator QSPEC and stack a local QSPEC 261 to meet the local QOSM requirements. If the local domain cannot 262 fully interpret the initiator QSPEC, it can flag the condition and 263 either continue to forward the reservation or possibly reject the 264 reservation. 266 Thus, one of the major differences between RSVP and QoS NSLP is that 267 QoS NSLP supports signaling for different QOSMs along the data path, 268 all with one signaling message. For example, the data path may start 269 in a domain supporting DiffServ and end in a domain supporting 270 Y.1541. The ability to achieve end-to-end QoS through multiple 271 Internet domains is also an important requirement, and illustrated 272 in this document. 274 3. Terminology 276 Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 277 if applicable to the underlying QOSM and a QNE MUST interpret, if 278 populated. 280 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 281 any QNE. Together with a description of QoS Desired or QoS 282 Available, it allows the QNI to specify a QoS range, i.e. an upper 283 and lower bound. If the QoS Desired cannot be reserved, QNEs are 284 going to decrease the reservation until the minimum QoS is hit. 286 Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 287 if applicable to the underlying QOSM, and a QNE SHOULD interpret if 288 populated and applicable to the QOSM(s) supported by the QNE. (A QNE 289 MAY ignore if it does not support a QOSM needing the optional QSPEC 290 parameter). 292 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 294 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 296 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 298 QoS Description: Describes the actual QoS in QSPEC objects QoS 299 Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC 300 objects are input or output parameters of the RMF. In a valid QSPEC, 301 at least one QSPEC object of the type QoS Desired, QoS Available or 302 QoS Reserved MUST be included. 304 QoS Available: QSPEC object containing parameters describing the 305 available resources. They are used to collect information along a 306 reservation path. 308 QoS Desired: QSPEC object containing parameters describing the 309 desired QoS for which the sender requests reservation. 311 QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g., 312 IntServ Controlled Load. A QOSM specifies a set of mandatory and 313 optional QSPEC parameters that describe the QoS and how resources 314 will be managed by the RMF. It furthermore specifies how to use QoS 315 NSLP to signal for this QOSM. 317 QoS Reserved: QSPEC object containing parameters describing the 318 reserved resources and related QoS parameters, for example, 319 bandwidth. 321 QSPEC Control Information: Control information that is specific to a 322 QSPEC, and contains parameters that govern the RMF. 324 QSPEC: QSPEC is the object of QoS NSLP containing all QOSM-specific 325 information. 327 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 328 QoS description and QSPEC control information parameters, for 329 example, bandwidth, token bucket, and excess treatment parameters. 331 QSPEC Object: Main building blocks of QoS Description containing a 332 QSPEC parameter set that is input or output of an RMF operation. 334 Resource Management Function (RMF): Functions that are related to 335 resource management, specific to a QOSM. It processes the QoS 336 description parameters and QSPEC control parameters. 338 Read-only Parameter: QSPEC Parameter that is set by initiating or 339 responding QNE and is not changed during the processing of the QSPEC 340 along the path. 342 Read-write Parameter: QSPEC Parameter that can be changed during the 343 processing of the QSPEC by any QNE along the path. 345 4. QSPEC Parameters, Processing, & Extensibility 347 4.1 QSPEC Parameters 349 The definition of a QOSM includes the specification of how the 350 requested QoS resources will be described and how they will be 351 managed by the RMF. For this purpose, the QOSM specifies a set of 352 QSPEC parameters that describe the QoS and QoS resource control in 353 the RMF. A given QOSM defines which of the mandatory and optional 354 QSPEC parameters it uses, and it MAY define additional optional QSPEC 355 parameters. Mandatory and optional QSPEC parameters provide a common 356 language for QOSM developers to build their QSPECs and are likely to 357 be re-used in several QOSMs. Mandatory and optional QSPEC parameters 358 are defined in this document, and additional optional QSPEC 359 parameters can be defined in separate documents. 361 As defined in Section 4.6, additional optional QSPEC parameters can 362 be defined in separate Informational documents specific to a given 363 QOSM. For example, optional QSPEC parameters are defined in 364 [RMD-QOSM] and [Y.1541-QOSM]. 366 4.2 QSPEC Processing 368 The QSPEC is opaque to the QoS NSLP processing. The QSPEC control 369 information and the QoS description are interpreted and MAY be 370 modified by the RMF in a QNE (see description in [QoS-SIG]). 372 A QNE MUST support at least one QOSM. A QoS-enabled domain supports 373 a particular QOSM, e.g. DiffServ admission control. If this domain 374 supports QoS NSLP signaling, its QNEs MUST support the DiffServ 375 admission control QOSM. The QNEs MAY also support additional QOSMs. 377 The QSPEC contains a QOSM ID, i.e. information on what QOSM is being 378 signaled by the QNI. However, if a QSPEC arrives at a QNE that does 379 not support the QOSM being signaled, it can still understand the 380 QSPEC content, at least to a basic degree. This is because mandatory 381 parameters have been defined as a common language. Therefore, a QNE 382 MUST at least interpret all the mandatory parameters in a QSPEC even 383 if it does not support the corresponding QOSM. 385 Mandatory parameters provide a minimal subset of parameters. A 386 QNE MUST either a) strictly interpret a mandatory parameter, or 387 b) remap the parameter and raise the flag defined in 388 Section 5.1, where the remapping MUST be specified in the QOSM 389 specification. Here the terminology 'strictly interpret' means that 390 the parameter is implemented according to the commonly accepted 391 definition and/or as specified by references given for each QSPEC 392 parameter. This means that in case a), a parameter 393 must be strictly interpreted as a token bucket. However, in case b), 394 a parameter may be remapped, perhaps to a 395 parameter. 397 In the latter case, the remapping of the to 398 must be specified in the QOSM specification document. 399 For example, QOSM X exclusively uses the parameter . It 400 must define a mapping of the mandatory parameter . 401 The mapping consists of interpreting the Token Bucket Rate as 402 the parameter and disregarding the other Token Bucket 403 parameters. Clearly, some information contained in the parameter is lost by this mapping, and the resulting QoS may 405 not be quite what was intended by the QNI. Therefore, QOSM X also 406 specifies that the flag be raised. Thus, a QNE using 407 QOSM X is able to make an informed decision whether to admit a 408 reservation described in terms of , and at the same 409 time (by means of ) signals to the QNI/QNR that the 410 exact intention of the QNI may not be met. 412 A QoS NSLP message can contain a stack of at most 2. The first on 413 the stack is the Initiator QSPEC. This is a QSPEC provided by the 414 QNI, which travels end-to-end, and therefore the stack always has at 415 least depth 1. QSPEC parameters MUST NOT be deleted from or added to 416 the Initiator QSPEC. In addition, the stack MAY contain a Local 417 QSPEC stacked on top of the Initiator QSPEC. A QNE only considers 418 the topmost QSPEC. 420 When reserving resources with a RESERVE message, a local QSPEC MAY be 421 pushed on the stack at the ingress edge of a local QoS domain, in 422 order to describe the requested resources in a domain-specific 423 manner. Also, the local QSPEC is popped from the stack at the egress 424 edge of the local QoS domain. When a RESPONSE message corresponding 425 to the RESERVE message arrives on its way back at the egress edge, a 426 local QSPEC MUST again be generated, describing the reserved 427 resources in a domain-specific manner. This local QSPEC is popped 428 from the stack at the ingress edge. 430 A domain supporting a different local QOSM than the initiator (QNI) 431 domain inspects all mandatory parameters and consults its local QOSM 432 as to how to interpret these parameters and decides whether it can 433 accommodate the flow. This analysis can have these various outcomes: 434 a) RMF determines that it can accommodate the flow with the QoS 435 Desired specified by the QNI, b) RMF determines that some Initiator 436 QSPEC parameters cannot be satisfied with the available resources, 437 and marks the appropriate error flags (see Section 4.5), but does not 438 reject the reservation, or c) RMF determines that some Initiator 439 QSPEC parameters cannot be satisfied with the available resources, 440 marks the appropriate error flags (see Section 4.5), and also rejects 441 the reservation. The QNE also in any event sets the 442 flag, as described in Section 5.1. 444 When a reservation is successful, the information is passed from the 445 RMF to QoS NSLP processing and translated into the QoS NSLP INFO_SPEC 446 code class 'success' [QoS-SIG]. 448 This document provides a template for the QSPEC, which is needed in 449 order to help define individual QOSMs and in order to promote 450 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 451 is composed of QSPEC control information and QoS description. QoS 452 description in turn is composed of up to four QSPEC objects (not all 453 of them need to be present), namely QoS Desired, QoS Available, QoS 454 Reserved and Minimum QoS. Each of these QSPEC Objects, as well as 455 QSPEC Control Information, consists of a number of mandatory and 456 optional QSPEC parameters. 458 +-------------+---------------------------------------+ 459 |QSPEC Control| QoS | 460 | Information | Description | 461 +-------------+---------------------------------------+ 463 \________________ ______________________/ 464 V 465 +----------+----------+---------+-------+ \ 466 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC 467 +----------+----------+---------+-------+ / Objects 469 \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/ 470 V V V V V 472 +-------------+... +-------------+... 473 |QSPEC Para. 1| |QSPEC Para. n| 474 +-------------+... +-------------+... 476 Figure 1: Structure of the QSPEC 478 The internal structure of each QSPEC object and the QSPEC control 479 information, with mandatory and optional parameters, is illustrated 480 in Figure 2. 482 +------------------+-----------------+---------------+ 483 | QSPEC/Ctrl Info | Mandatory QSPEC |Optional QSPEC | 484 | Object ID | Parameters | Parameters | 485 +------------------+-----------------+---------------+ 487 Figure 2: Structure of QSPEC Objects & Control Information 489 4.3 Example of NSLP/QSPEC Operation 491 This Section illustrates the operation and use of the QSPEC within 492 the NSLP. The example configuration in shown in Figure 3. 494 +----------+ /-------\ /--------\ /--------\ 495 | Laptop | | Home | | Cable | | DiffServ | 496 | Computer |-----| Network |-----| Network |-----| Network |----+ 497 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 498 \-------/ \--------/ \--------/ | 499 | 500 +-----------------------------------------------+ 501 | 502 | /--------\ +----------+ 503 | | "X"G | | Handheld | 504 +---| Wireless |-----| Device | 505 | XG QOSM | +----------+ 506 \--------/ 508 Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC 509 Operation 511 In this configuration, a laptop computer and a handheld wireless 512 device are the endpoints for some application that has QoS 513 requirements. Assume initially that the two endpoints are stationary 514 during the application session, later we consider mobile endpoints. 515 For this session, the laptop computer is connected to a home network 516 that has no QoS support. The home network is connected to a 517 CableLabs-type cable access network with dynamic QoS (DQOS) support, 518 such as specified in the 'CMS to CMS Signaling Specification' [CMSS] 519 for cable access networks. That network is connected to a DiffServ 520 core network that uses the RMD QOSM [RMD-QOSM]. On the other side of 521 the DiffServ core is a wireless access network built on generation 522 "X" technology with QoS support as defined by generation "X". And 523 finally the handheld endpoint is connected to the wireless access 524 network. 526 We assume that the Laptop is the QNI and handheld device is the QNR. 528 The QNI will signal an Initiator QSPEC object to achieve the QoS 529 desired on the path. As stated in Section 4.2, the QNI MUST support 530 at least one QOSM, but it may not know the QOSM supported by the 531 network. In any case, if the QNI supports only one QOSM, it would 532 normally signal a reservation according to the requirements of that 533 QOSM. Furthermore, the QNI would most likely support the QOSM that 534 matches its functionality. For example, the default QOSM for mobile 535 phones might be the XG-QOSM, while the INTSERV-QOSM might be the 536 default for workstations. 538 Referring to Figure 3, the laptop computer may choose the 539 INTSERV-QOSM because it is connected to a wired network. If the 540 handheld device acts as the QNI, it may choose the XG-QOSM because it 541 is connected to the XG wireless network. On the other hand, a 542 particular QOSM could be configured if a user/administrator knows 543 that some particular QOSM is used. For example, if the laptop 544 computer is connected to the XG network via the XG phone, which acts 545 as a modem, then it reasonable to specify the XG-QOSM since resources 546 are accessed through the XG network, 548 In this example we consider two different ways to perform 549 sender-initiated signaling for QoS: 551 Case 1) The QNI sets , and possibly 552 QSPEC objects in the Initiator QSPEC, and initializes 553 to . Since this is a reservation in a 554 heterogenic network with different QOSMs supported in different 555 domains, each QNE on the path reads and interprets those parameters 556 in the Initiator QSPEC that it needs to implement the QOSM within its 557 domain (as described below). Each QNE along the path checks to see if 558 resources can be reserved, and if not, the QNE 559 reduces the respective parameter values in and 560 reserves these values. The minimum parameter values are given in 561 , if populated, otherwise zero if is not 562 included. If one or more parameters in fails to 563 satisfy the corresponding minimum values in Minimum QoS, the QNE 564 notifies the QNI and the reservation is aborted. Otherwise, the QNR 565 notifies the QNI of the for the reservation. 567 Case 2) The QNI signals the Initiator QSPEC with . 568 Since this is a reservation in a heterogenic network with different 569 QOSMs supported in different domains, each QNE on the path reads and 570 interprets those parameters in the Initiator QSPEC that it needs to 571 implement the QOSM within its domain (as described below). If a QNE 572 cannot reserve resources, the reservation fails. 574 In both cases, the QNI populates mandatory and optional QSPEC to 575 ensure correct treatment of its traffic in domains down the path. 576 Since the QNI does not know the QOSM used in downstream domains, it 577 includes values for those mandatory and optional QSPEC parameters 578 consistent with the QOSM it is signaling and any additional 579 parameters it cares about. Let us assume the QNI wants to achieve 580 IntServ-like QoS guarantees, and also is interested in what path 581 latency it can achieve. The QNI therefore includes in the QSPEC the 582 QOSM ID for IntServ Controlled Load Service. The QSPEC objects are 583 signaled with all parameters necessary for IntServ Controlled Load 584 and additionally the parameter to measure path latency, as follows: 586 = 587 = 589 In both cases, each QNE on the path reads and interprets those 590 parameters in the Initiator QSPEC that it needs to implement the QOSM 591 within its domain. It may need additional parameters for its QOSM, 592 which are not specified in the Initiator QSPEC. If possible, these 593 parameters must be inferred from those that are present, according to 594 rules defined in the QOSM implemented by this QNE. 596 There are three possibilities when a RESERVE message is received at a 597 QNE at a domain border (we illustrate these possibilities in the 598 example): 600 - the QNE just leaves the QSPEC as-is. 602 - the QNE can stack a local QSPEC on top of the Initiator QSPEC (this 603 is new in QoS NSLP, RSVP does not do this). 605 - the QNE can tunnel the Initiator RESERVE message through its domain 606 and issue its own Local RESERVE message. For this new Local RESERVE 607 message, the QNE acts as the QNI, and the QSPEC in the domain is an 608 Initiator QSPEC. This procedure is also used by RSVP in making 609 aggregate reservations, in which case there is not a new intra-domain 610 (aggregate) RESERVE for each newly arriving interdomain (per-flow) 611 RESERVE, but the aggregate reservation is updated by the border QNE 612 (QNI) as need be. This is also how RMD works [RMD-QOSM]. 614 For example, at the RMD domain, a local RESERVE with its own RMD 615 Initiator QSPEC corresponding to the RMD-QOSM is generated based on 616 the original Initiator QSPEC according to the procedures described in 617 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE 618 to the RMD domain must map the QSPEC parameters contained in the 619 original Initiator QSPEC into the RMD QSPEC. The RMD QSPEC for 620 example needs and . is generated 621 from the parameter. Information on , 622 however, is not provided. According to the rules laid out in the RMD 623 QOSM, the ingress QNE infers from the fact that an IntServ Controlled 624 Load QOSM was signaled that the EF PHB is appropriate to set the parameter. These RMD QSPEC parameters are populated in the 626 RMD Initiator QSPEC generated within the RMD domain. 628 Furthermore, the node at the egress to the RMD domain updates on behalf of the entire RMD domain if it can. If it 630 cannot, it raises the parameter-specific, 'not-supported' flag, 631 warning the QNR that the final value of these parameters in QoS 632 Available is imprecise. 634 In the XG domain, the Initiator QSPEC is translated into a Local 635 QSPEC using a similar procedure as described above. The Local QSPEC 636 becomes the current QSPEC used within the XG domain, that is, the 637 it becomes the first QSPEC on the stack, and the Initiator QSPEC is 638 second. This saves the QNEs within the XG domain the trouble of 639 re-translating the Initiator QSPEC. At the egress edge of the XG 640 domain, the translated Local QSPEC is popped, and the Initiator QSPEC 641 returns to the number one position. 643 If the reservation was successful, eventually the RESERVE request 644 arrives at the QNR (otherwise the QNE at which the reservation failed 645 would have aborted the RESERVE and sent an error RESPONSE back to the 646 QNI). The QNR generates a positive RESPONSE with QSPEC objects - and for case 1 - additionally . The 648 parameters appearing in are the same as in , with values copied from in case 1, and with 650 the original values from in case 2. That is, it is not 651 necessary to transport the object back to the QNI since 652 the QNI knows what it signaled originally, and the information is not 653 useful for QNEs in the reverse direction. The object 654 should transport all necessary information, although the and objects may end up transporting some of 656 the same information. 658 Hence, the QNR includes the following QSPEC objects: 660 = 661 = 663 If the handheld device on the right of Figure 3 is mobile, and moves 664 through different "XG" wireless networks, then the QoS might change 665 on the path since different XG wireless networks might support 666 different QOSMs. As a result, QoS NSLP/QSPEC processing will have to 667 renegotiate the on the path. From a QSPEC 668 perspective, this is like a new reservation on the new section of the 669 path and is basically the same as any other rerouting event - to the 670 QNEs on the new path it looks like a new reservation. That is, in 671 this mobile scenario, the new segment may support a different QOSM 672 than the old segment, and the QNI would now signal a new reservation 673 (explicitly, or implicitly with the next refreshing RESERVE message) 674 to account for the different QOSM in the XG wireless domain. Further 675 details on rerouting are specified in [QoS-SIG]. 677 For bit-level examples of QSPECs see the documents specifying QOSMs 678 [INTSERV-QOSM, Y.1541-QOSM, RMD-QOSM]. 680 4.4 Treatment of QSPEC Parameters 682 4.4.1 Mandatory and Optional QSPEC Parameters 684 Mandatory and optional QSPEC parameters are defined in this document 685 and are applicable to a number of QOSMs. Mandatory QSPEC parameters 686 are treated as follows: 688 o A QNI SHOULD populate mandatory QSPEC parameters if applicable to 689 the underlying QOSM. 690 o QNEs MUST interpret mandatory QSPEC parameters, if signaled. 692 Optional QSPEC parameters are treated as follows: 694 o A QNI SHOULD populate optional QSPEC parameters if applicable to 695 the QOSM for which it is signaling. 697 o QNEs SHOULD interpret optional QSPEC parameters, if signaled and 698 applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore 699 the optional QSPEC parameter if it does not support a QOSM needing 700 the optional QSPEC parameter). 702 Note that the QNI referred to above can be an ingress QNE in a local 703 domain initiating a local QSPEC object. 705 4.4.2 Read-only and Read-write QSPEC Parameters 707 Both mandatory and optional QSPEC parameters can be read-only or 708 read-write. Read-write parameters can be changed by any QNE, whereas 709 read-only parameters are fixed by the QNI and/or QNR. For example in 710 a RESERVE message, all parameters in are read-write 711 parameters, which are updated by intermediate QNEs. Read-only 712 parameters are, for example, all parameters in as sent 713 by the QNI. 715 QoS description parameters can be both read-only or read-write, 716 depending on which QSPEC object, and which message, they appear in. 717 In particular, all parameters in and are 718 read-only for all messages. More details are provided in Sec. 7.1. 720 In the QSPEC Control Information Object, the property of being 721 read-write or read-only is parameter specific. 723 4.5 Reservation Success/Failure, QSPEC Errors, & INFO_SPEC Notification 725 A reservation may not be successful for several reasons: 727 - a reservation may fail because the desired resources are not 728 available. This is a reservation failure condition. 730 - a reservation may fail because the QSPEC is erroneous, or because 731 of a QNE fault. This is an error condition. 733 A reservation may be successful, but still some parameters could not 734 be interpreted or updated properly: 736 - a QSPEC parameter cannot be interpreted because it is an unknown 737 optional parameter type. This is a QSPEC parameter not supported 738 condition. The reservation however does not fail. The QNI can 739 still decide whether to keep or tear down the reservation depending 740 on the procedures specified by the QNI's QOSM. 742 - a QSPEC parameter value in the object cannot be 743 updated because QoS NSLP was tunneled to the QNE. This is a 744 QSPEC tunneled parameter condition. The reservation however does 745 not fail. As above, the QNI can still decide whether to keep or 746 tear down the reservation. 748 The following sections describe the handling of unsuccessful 749 reservations in more detail, as follows: 751 - details on flags used inside the QSPEC to convey information on 752 success or failure of individual parameters. The formats and 753 semantics of all flags are given in Section 6.1. 754 - the content of the INFO_SPEC [QoS-SIG], which carries a code 755 indicating the outcome of reservations. 756 - the generation of a RESPONSE message to the QNI containing both 757 QSPEC and INFO_SPEC objects. 759 4.5.1 Reservation Failure and Error E-Flag 761 The QSPEC parameters each have a 'reservation failure error E-flag' 762 to indicate which (if any) parameters could not be satisfied. When a 763 resource cannot be satisfied for a particular parameter, the QNE 764 detecting the problem raises the E-flag in this parameter. Note that 765 all QSPEC parameters MUST be examined by the RMF and appropriately 766 flagged. Additionally, the E-flag in the corresponding QSPEC Object 767 MUST be raised. If the reservation failure problem cannot be located 768 at the parameter level, only the E-flag in the QSPEC object is 769 raised. 771 A QNE detecting that some QSPEC parameters have to be remapped and 772 possibly downgraded MUST set the flag. This condition 773 might occur, for example, when a QNE's QOSM is different that the 774 QNI's QOSM, and the QNE's QOSM specifies that some parameters are 775 Remapped and not strictly interpreted (see the example in Section 4.3 776 for an illustration of this condition). In this case no E-Flags are 777 set and the message should continue to be forwarded but with the 778 flag set, and the QNI has the option of not accepting 779 the reservation. 781 When an RMF cannot interpret the QSPEC because the coding is 782 erroneous, it raises corresponding reservation failure E-flags in the 783 QSPEC. Normally all QSPEC parameters MUST be examined by the RMF 784 and the erroneous parameters appropriately flagged. In some cases, 785 however, an error condition may occur and the E-flag of the 786 error-causing QSPEC parameter is raised (if possible), but the 787 processing of further parameters may be aborted. 789 Note that if the QSPEC and/or any QSPEC parameter is found to be 790 erroneous, then any QSPEC parameters not satisfied are ignored and 791 the E-Flags in the QSPEC object MUST NOT be set for those parameters 792 (unless they are erroneous). 794 Whether E-flags denote reservation failure or error can be determined 795 by the corresponding error code in the INFO_SPEC in QoS NSLP, as 796 discussed below. 798 4.5.2 QSPEC Parameter Not Supported N-Flag 800 When the QOSM ID is not known to a QNE, it MUST interpret at least 801 the mandatory parameters. 803 Each optional QSPEC parameter has an associated 'not supported 804 N-flag'. If the not supported N-flag is set, then at least one QNE 805 along the data transmission path between the QNI and QNR cannot 806 support or interpret the specified optional parameter. A QNE MUST 807 set the not supported N-flag if it does not support or cannot 808 interpret the optional parameter, and therefore cannot be sure it can 809 provide the resources. In that case the message should continue to 810 be forwarded but with the N-flag set, and the QNI has the option of 811 not accepting the reservation. 813 4.5.3 QSPEC Tunneled Parameter T-Flag 815 Each QSPEC parameter has an associated 'tunneled-parameter T-flag'. 816 When a RESERVE message is tunneled through a domain, QNEs inside the 817 domain cannot update read-write parameters. The egress QNE in a 818 domain has two choices: either a) it is configured to have the 819 knowledge to update the parameters correctly, or b) it cannot update 820 the parameters. In the latter case it MUST set the 821 tunneled-parameter T-flag to tell the QNI (or QNR) that the 822 information contained in the read-write parameter is most likely 823 incorrect (or a lower bound). The T-flag is interpreted by the QNI, 824 ingress QNE (start of tunnel in a domain), egress QNE (end of tunnel 825 in a domain), or QNR. 827 4.5.4 INFO_SPEC coding of reservation outcome 829 As prescribed by [QoS-SIG], the RESPONSE message always contains the 830 INFO_SPEC with an appropriate "error" code. It usually also contains 831 a QSPEC with QSPEC objects, as described in Section 6 on QoS 832 Procedures. The RESPONSE message MAY omit the QSPEC in case of a 833 successful reservation. 835 The following guidelines are provided in setting the error codes in 836 the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of 837 [QoS-SIG]. 839 - INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success) 840 This code is set when all QSPEC parameters have been satisfied 841 (possibly with downgrading). In this case no E-Flag nor the 842 flag is set, however N-flags or T-flags may be set. 843 This code is also set when one or more mandatory parameters had to 844 be remapped, as indicated by a flag being set. 846 - INFO_SPEC error class 0x04 (Transient Failure) / 0x08 (Reservation 847 Failure) 848 This code is set when at least one parameter could not be 849 satisfied. E-flags are set for the parameters that could not be 850 satisfied up to the QNE issuing the RESPONSE. In this case QNEs 851 receiving the RESPONSE message MUST remove the corresponding 852 reservation. 854 - INFO_SPEC error class 0x03 (Protocol Error)/ 0x0c (Malformed QSPEC) 856 Some QSPEC parameters had associated errors, E-Flags are set for 857 parameters that had errors, and the RMF rejects the reservation. 859 - INFO_SPEC error class 0x06 (QoS Model Error) 860 QOSM error codes can be defined for future releases of this 861 document or as defined by QOSM-specific specification documents. A 862 registry is defined in Section 9 IANA Considerations. 864 4.5.5 QNE Generation of a RESPONSE message 866 - Successful Reservation Condition 868 When a RESERVE message arrives at a QNR and no E-Flag is set, the 869 reservation is successful. A RESPONSE may be generated with 870 INFO_SPEC code 'Reservation Success' as described above and QSPEC as 871 described in Section 6. 873 A raised flag in the QSPEC of the RESERVE message 874 indicates that at least one mandatory parameter may have been 875 remapped. The flag is sent back in the RESPONSE 876 message and the QNI then makes the final determination as to 877 whether to continue or tear down the reservation that has been 878 established. A QOSM specification MAY specify the conditions for 879 rejecting a reservation under such conditions. However, in the 880 absence of such procedures, the default condition SHOULD be 881 'success' if all QSPEC parameters are met and 'reservation failure' 882 if one or more QSPEC parameters are not met. 884 - Reservation Failure Condition 886 When a QNE detects that a reservation failure occurs for at least one 887 parameter, the QNE sets the E-Flags for the QSPEC parameters and 888 QSPEC object that failed to be satisfied. According to [QoS-SIG], 889 the QNE behavior depends on whether it is stateful or not. When a 890 stateful QNE determines the reservation failed, it formulates a 891 RESPONSE message that includes an INFO_SPEC with the 'reservation 892 failure' error code and QSPEC object, as described above. The QSPEC 893 in the RESPONSE message includes the QSPEC object with 894 all parameters values set to zero (or equivalent). Furthermore, the 895 E-Flags of all QSPEC parameters are transferred with their values 896 from , which arrived in the QSPEC of the corresponding 897 RESERVE message. The object can still be used to 898 transfer information about available QoS to the QNI. 900 The default action for a stateless QoS NSLP QNE that detects a 901 reservation failure condition is that it MUST continue to forward the 902 RESERVE message to the next stateful QNE, with the E-Flags 903 appropriately set for each QSPEC parameter. The next stateful QNE 904 will then act as described in [QoS-SIG]. 906 - Malformed QSPEC Error Condition 908 When a stateful QNE detects that one or more QSPEC parameters are 909 erroneous, the QNE sets the error code 'malformed QSPEC' in the 910 INFO_SPEC, as described above. In this case the QSPEC object with 911 the E-Flags appropriately set for the erroneous parameters is 912 returned within the INFO_SPEC object. The QSPEC object can be 913 truncated or fully included within the INFO_SPEC. 915 The default action for a stateless QoS NSLP QNE that detects such an 916 error condition is that none of the QSPEC parameters SHOULD be 917 processed and the RESERVE message SHOULD be forwarded downstream. 919 A 'malformed QSPEC' error code takes precedence over the 'reservation 920 failure' error code, and therefore the case of reservation failure 921 and QSPEC/RMF error conditions are disjoint and the same E-Flag can 922 be used in both cases without ambiguity. 924 4.5.6 Special Cases of QSPEC Stacking 926 When an unsuccessful reservation problem occurs inside a local domain 927 where QSPEC stacking is used, only the topmost (local) QSPEC is 928 affected (e.g. E-flags are raised, etc.). The Initiator QSPEC at the 929 bottom is untouched. When the message (RESPONSE in case of stateful 930 QNEs, RESERVE in case of stateless QNEs) however reaches the edge of 931 the stacking domain, the local QSPEC is popped, and its content, 932 including flags, is translated into the Initiator QSPEC. 934 4.6 QSPEC Extensibility 936 This document defines both mandatory and optional parameters. The 937 set of mandatory parameters defined herein is at this point in time 938 considered complete. The optional parameters in this document 939 correspond to some of the optional parameters considered in QOSMs 940 currently being defined. 942 Additional mandatory parameters may be defined in the future. 943 However, since this requires an update of all QNEs, this should be 944 considered carefully. The definition of new mandatory parameter 945 requires standards action and an update of this document. Such an 946 update also needs a new QSPEC version number. Furthermore, all QOSM 947 definitions must be updated to include how the new mandatory 948 parameter is to be interpreted in the respective QOSM. 950 Additional optional QSPEC parameters MAY need to be defined in the 951 Future and are defined in separate informational documents specific 952 to a given QOSM. For example, optional QSPEC parameters are defined 953 in [RMD-QOSM] and [Y.1541-QOSM]. 955 Guidelines on the technical criteria to be followed in evaluating 956 requests for new codepoint assignments are given for the overall NSIS 957 protocol suite in a separate NSIS extensibility document 958 [NSIS-EXTENSIBILITY]. 960 4.7 QOSM Specification Requirements 962 A QOSM specification MUST define QSPEC parameter behavior for these 963 cases: a) new optional QSPEC parameters the QOSM specification 964 defines, and b) remapping of existing mandatory or optional QSPEC 965 parameters, as described in Section 4.2. Unless otherwise specified 966 in the QOSM specification document, the behaviors to strictly 967 interpret the mandatory and optional QSPEC parameters are defined in 968 this document through the references to RFCs that precisely define 969 the QSPEC parameter behaviors. 971 A QOSM specification MUST define how the mandatory parameters are to 972 be mapped onto the QSPEC parameters used by the QOSM, however the 973 mapping MAY result in slight modification to the intended 974 specification when an exact mapping is not possible. This definition 975 MUST allow a QNE implementing this QOSM to make a decision as to 976 whether a reservation described in terms of mandatory parameters can 977 be admitted. If for a particular mandatory parameter no mapping can 978 be found that guarantees the desired QoS, the QNE is advised to raise 979 the flag. In other words, for all mandatory 980 parameters a mapping must be defined, but it is acknowledged that 981 this mapping may result in slightly bending the original intention of 982 the QNI. 984 A QOSM specification MUST define what happens in case of preemption 985 if the default QNI behavior (tear down preempted reservation) is not 986 followed (see Section 6.5). 988 As discussed in Section 4.5.1, a QOSM specification MAY specify the 989 conditions for a 'partially met' error condition and MAY define 990 additional QOSM specific errors. 992 Further content of a QOSM description is given in Appendix A. 994 5. QSPEC Format Overview 996 QSPEC = 997 999 As described above, the QSPEC contains an identifier for the QOSM, 1000 the actual resource description (QoS description) as well as QSPEC 1001 control information. Note that all QSPEC parameters defined in the 1002 following Sections are mandatory QSPEC parameters unless specifically 1003 designated as optional QSPEC parameters. 1005 A QSPEC object ID identifies whether the object is or . As described below, the is further broken down into , , , and objects. A QSPEC 1009 parameter ID is assigned to identify each QSPEC parameter defined 1010 below. 1012 identifies the QSPEC version number. Later QSPEC 1013 versions MUST be backward compatible with earlier QSPEC versions. 1014 That is, a version n+1 device must support a version n (or earlier) 1015 QSPEC and QSPEC parameters. If the version n device receives 1016 mandatory parameters (with the M-flag set, as discussed in Section 1017 7) that are not supported in version n (only supported in version 1018 n+1), then the version n device concludes that either a) the M-flag 1019 is set incorrectly for an optional parameter it does not support, or 1020 b) the M-flag is correctly set for a mandatory parameter it does not 1021 support. In either case, the version n device responds with a 1022 'Malformed QSPEC' error code (0x03), as discussed in Section 4.5.1. 1024 A new QSPEC version MUST be defined whenever this document is 1025 reissued, for example, whenever a new mandatory parameter is added. 1026 Mandatory parameters in a new QSPEC version MUST be a superset of 1027 those in the previous QSPEC version. 1029 The identifies the particular QOSM being used by the QNI 1030 and tells a QNE which parameters to expect. This may simplify 1031 processing and error analysis. Furthermore, it may be helpful for a 1032 QNE or a domain supporting more than one QOSM to learn which QOSM the 1033 QNI would like to have in order to use the most suitable QOSM. Even 1034 if a QNE does not support the QOSM it MUST interpret at least the 1035 mandatory parameters. Note that more parameters than required by the 1036 QOSM can be included by the QNI. QSPEC version and QOSM IDs are 1037 assigned by IANA. 1039 5.1 QSPEC Control Information 1041 QSPEC control information is used for signaling QOSM RMF functions 1042 not defined in QoS NSLP. It enables building new RMF functions 1043 required by a QOSM within a QoS NSLP signaling framework, such as 1044 specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. 1046 = 1048 Note that is a read-write parameter. is a read-only parameter. 1051 is a flag bit telling the QNR (or QNI in a RESPONSE 1052 message) whether or not a particular QOSM is supported by each QNE 1053 in the path between the QNI and QNR. A QNE sets the 1054 flag parameter if it does not support the relevant QOSM 1055 specification. If the QNR finds this bit set, at least one QNE along 1056 the data transmission path between the QNI and QNR can not support 1057 the specified QOSM. In a local QSPEC, refers to the 1058 QoS NSLP peers of the local QOSM domain. 1060 The parameter describes how the QNE will process 1061 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 1062 be dropped, shaped and/or remarked. The excess treatment parameter is 1063 initially set by the QNI and is read-only. 1065 5.2 QoS Description 1067 The QoS Description is broken down into the following QSPEC objects: 1069 = 1070 1072 Of these QSPEC objects, QoS Desired, QoS Available and QoS Reserved 1073 MUST be supported by QNEs. Minimum QoS MAY be supported. 1075 5.2.1 1077 = 1078 1080 These parameters describe the resources the QNI desires to reserve 1081 and hence this is a read-only QSPEC object. The 1082 resources that the QNI wishes to reserve are of course directly 1083 related to the traffic the QNI is going to inject into the network. 1084 Therefore, when used in the object, refers to traffic injected by the QNI into the network. 1087 = 1089 = link bandwidth needed by flow [RFC2212, RFC2215] 1091 =

[RFC2210] 1093 Note that the Path MTU Discovery (PMTUD) working group is currently 1094 specifying a robust method for determining the MTU supported over an 1095 end-to-end path. This new method is expected to update RFC1191 and 1096 RFC1981, the current standards track protocols for this purpose. 1098 = 1100 An application MAY like to reserve resources for packets with a 1101 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 1102 [RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class 1103 type [RFC3564]. 1105 = 1106 1108 is the priority of the new flow compared with 1109 the defending priority of previously admitted flows. Once a flow is 1110 admitted, the preemption priority becomes irrelevant. is used to compare with the preemption priority of new 1112 flows. For any specific flow, its preemption priority MUST always be 1113 less than or equal to the defending priority. 1114 and provide an essential way to differentiate flows 1115 for emergency services, ETS, E911, etc., and assign them a higher 1116 admission priority than normal priority flows and best-effort 1117 priority flows. 1119 Appropriate security measures need to be taken to prevent abuse of 1120 the parameters, see Section 8 on Security Considerations. 1122 [Y.1540] defines packet transfer outcomes, as follows: 1124 Successful: packet arrives within the preset waiting time with no 1125 errors 1127 Lost: packet fails to arrive within the waiting time 1129 Errored: packet arrives in time, but has one or more bit errors 1130 in the header or payload 1132 Packet Loss Ratio (PLR) = total packets lost/total packets sent 1134 Packet Error Ratio (PER) = total errored packets/total packets sent 1136 , , , and are 1137 optional parameters describing the desired path latency, path jitter 1138 and path bit error rate respectively. Since these parameters are 1139 cumulative, an individual QNE cannot decide whether the desired path 1140 latency, etc., is available, and hence they cannot decide whether a 1141 reservation fails. Rather, when these parameters are included in 1142 , the QNI SHOULD also include corresponding parameters 1143 in a QSPEC object in order to facilitate collecting 1144 this information. 1146 5.2.2 1148 = 1149 1150 1152 When used in the object, refers 1153 to traffic resources available at a QNE in the network. 1155 The Object collects information on the resources 1156 currently available on the path when it travels in a RESERVE or QUERY 1157 message and hence in this case this QSPEC object is read-write. Each 1158 QNE MUST inspect all parameters of this QSPEC object, and if 1159 resources available to this QNE are less than what a particular 1160 parameter says currently, the QNE MUST adapt this parameter 1161 accordingly. Hence when the message arrives at the recipient of the 1162 message, reflects the bottleneck of the resources 1163 currently available on a path. It can be used in a QUERY message, 1164 for example, to collect the available resources along a data path. 1166 When travels in a RESPONSE message, it in fact just 1167 transports the result of a previous measurement performed by a 1168 RESERVE or QUERY message back to the initiator. Therefore in this 1169 case, is read-only. 1171 The parameters and provide information, 1172 for example, about the bandwidth available along the path followed by 1173 a data flow. The local parameter is an estimate of the bandwidth the 1174 QNE has available for packets following the path. Computation of the 1175 value of this parameter SHOULD take into account all information 1176 available to the QNE about the path, taking into consideration 1177 administrative and policy controls on bandwidth, as well as physical 1178 resources. The composition rule for this parameter is the MIN 1179 function. The composed value is the minimum of the QNE's value and 1180 the previously composed value. This quantity, when composed 1181 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 1182 minimal bandwidth link along the path from QNI to QNR. 1184 The parameter accumulates the latency of the packet 1185 forwarding process associated with each QNE, where the latency is 1186 defined to be the mean packet delay added by each QNE. This delay 1187 results from speed-of-light propagation delay, from packet processing 1188 limitations, or both. The mean delay reflects the variable queuing 1189 delay that may be present. Each QNE MUST add the propagation delay 1190 of its outgoing link, which includes the QNR adding the associated 1191 delay for the egress link. Furthermore, the QNI MUST add the 1192 propagation delay of the ingress link. The composition rule for the 1193 parameter is summation with a clamp of (2**32 - 1) on 1194 the maximum value. This quantity, when composed end-to-end, informs 1195 the QNR (or QNI in a RESPONSE message) of the minimal packet delay 1196 along the path from QNI to QNR. The purpose of this parameter is to 1197 provide a minimum path latency for use with services which provide 1198 estimates or bounds on additional path delay [RFC2212]. Together 1199 with the queuing delay bound, this parameter gives the application 1200 knowledge of both the minimum and maximum packet delivery delay. 1201 Knowing both the minimum and maximum latency experienced by data 1202 packets allows the receiving application to know the bound on delay 1203 variation and de-jitter buffer requirements. 1205 The parameter accumulates the jitter of the packet 1206 forwarding process associated with each QNE, where the jitter is 1207 defined to be the nominal jitter added by each QNE. IP packet 1208 jitter, or delay variation, is defined in [RFC3393], Section 3.4 1209 (Type-P-One-way-ipdv), and where the selection function includes the 1210 packet with minimum delay such that the distribution is equivalent to 1211 2-point delay variation in [Y.1540]. The suggested evaluation 1212 interval is 1 minute. This jitter results from packet processing 1213 limitations, and includes any variable queuing delay which may be 1214 present. Each QNE MUST add the jitter of its outgoing link, which 1215 includes the QNR adding the associated jitter for the egress link. 1216 Furthermore, the QNI MUST add the jitter of the ingress link. The 1217 composition method for the parameter is the combination 1218 of several statistics describing the delay variation distribution 1219 with a clamp on the maximum value (note that the methods of 1220 accumulation and estimation of nominal QNE jitter are specified in 1221 clause 8 of [Y.1541]). This quantity, when composed end-to-end, 1222 informs the QNR (or QNI in a RESPONSE message) of the nominal packet 1223 jitter along the path from QNI to QNR. The purpose of this parameter 1224 is to provide a nominal path jitter for use with services that 1225 provide estimates or bounds on additional path delay [RFC2212]. 1226 Together with the and the queuing delay bound, this 1227 parameter gives the application knowledge of the typical packet 1228 delivery delay variation. 1230 The parameter accumulates the packet loss rate (PLR) of 1231 the packet forwarding process associated with each QNE, where the PLR 1232 is defined to be the PLR added by each QNE. Each QNE MUST add the 1233 PLR of its outgoing link, which includes the QNR adding the 1234 associated PLR for the egress link. Furthermore, the QNI MUST add 1235 the PLR of the ingress link. The composition rule for the parameter is summation with a clamp on the maximum value (this 1237 assumes sufficiently low PLR values such that summation error is not 1238 significant, however a more accurate composition function is 1239 specified in clause 8 of [Y.1541]). This quantity, when composed 1240 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 1241 minimal packet PLR along the path from QNI to QNR. 1243 , , , : Error terms C and D represent how the 1244 element's implementation of the guaranteed service deviates from the 1245 fluid model. These two parameters have an additive composition rule. 1246 The error term C is the rate-dependent error term. It represents the 1247 delay a datagram in the flow might experience due to the rate 1248 parameters of the flow. The error term D is the rate-independent, 1249 per-element error term and represents the worst case non-rate-based 1250 transit time variation through the service element. If the 1251 composition function is applied along the entire path to compute the 1252 end-to-end sums of C and D ( and ) and the resulting 1253 values are then provided to the QNR (or QNI in a RESPONSE message). 1254 and are the sums of the parameters C and D between the 1255 last reshaping point and the current reshaping point. 1257 5.2.3 1259 = 1261 These parameters describe the QoS reserved by the QNEs along the data 1262 path, and hence the QoS reserved QSPEC object is read-write. 1264 , and are defined above. 1266 = slack term, which is the difference between desired delay and 1267 delay obtained by using bandwidth reservation, and which is used to 1268 reduce the resource reservation for a flow [RFC2212]. This is an 1269 optional parameter. 1271 5.2.4 1273 = 1275 does not have an equivalent in RSVP. It allows the QNI 1276 to define a range of acceptable QoS levels by including both the 1277 desired QoS value and the minimum acceptable QoS in the same message. 1278 It is a read-only QSPEC object. The desired QoS is included with a 1279 and/or a QSPEC object seeded to the 1280 desired QoS value. The minimum acceptable QoS value MAY be coded in 1281 the QSPEC object. As the message travels towards the 1282 QNR, is updated by QNEs on the path. If its value 1283 drops below the value of the reservation fails and is 1284 aborted. When this method is employed, the QNR SHOULD signal back to 1285 the QNI the value of attained in the end, because the 1286 reservation MAY need to be adapted accordingly. 1288 6. QSPEC Procedures 1290 While the QSPEC template aims to put minimal restrictions on usage of 1291 QSPEC objects in , interoperability between QNEs and 1292 between QOSMs must be ensured. We therefore give below an exhaustive 1293 list of QSPEC object combinations for the message sequences described 1294 in QoS NSLP [QoS-SIG]. A specific QOSM may prescribe that only a 1295 subset of the procedures listed below may be used. 1297 Note that QoS NSLP does not mandate the usage of a RESPONSE message. 1298 In fact, a RESPONSE message will only be generated if the QNI 1299 includes an RII (Request Identification Information) in the RESERVE 1300 message. Some of the QSPEC procedures below, however, are only 1301 meaningful when a RESPONSE message is possible. The QNI SHOULD in 1302 these cases include an RII. 1304 6.1 Sender-Initiated Reservations 1306 Here the QNI issues a RESERVE, which may be replied to by a RESPONSE. 1307 The following possibilities for QSPEC object usage exist: 1309 ID | RESERVE | RESPONSE 1310 --------------------------------------------------------------- 1311 1 | QoS Desired | QoS Reserved 1312 2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1313 3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1315 (1) If only QoS Desired is included in the RESERVE, the implicit 1316 assumption is that exactly these resources must be reserved. If this 1317 is not possible the reservation fails. The parameters in QoS 1318 Reserved are copied from the parameters in QoS Desired. If the 1319 reservation is successful, the RESPONSE can be omitted in this case. 1320 If a RESPONSE was requested by a QNE on the path, the QSPEC in the 1321 RESPONSE can be omitted. 1323 (2) When QoS Available is included in the RESERVE also, some 1324 parameters will appear only in QoS Available and not in QoS Desired. 1325 It is assumed that the value of these parameters is collected for 1326 informational purposes only (e.g. path latency). 1328 However, some parameters in QoS Available can be the same as in QoS 1329 Desired. For these parameters the implicit message is that the QNI 1330 would be satisfied by a reservation with lower parameter values than 1331 specified in QoS Desired. For these parameters, the QNI seeds the 1332 parameter values in QoS Available to those in QoS Desired (except for 1333 cumulative parameters such as ). 1335 Each QNE downgrades the parameters in QoS Available according to its 1336 current capabilities. Reservations in each QNE are hence based on 1337 current parameter values in QoS Available (and additionally those 1338 parameters that only appear in QoS Desired). The drawback of this 1339 approach is that, if the resulting resource reservation becomes 1340 gradually smaller towards the QNR, QNEs close to the QNI have an 1341 oversized reservation, possibly resulting in unnecessary costs for 1342 the user. Of course, in the RESPONSE the QNI learns what the actual 1343 reservation is (from the QoS RESERVED object) and can immediately 1344 issue a properly sized refreshing RESERVE. The advantage of the 1345 approach is that the reservation is performed in half-a-roundtrip 1346 time. 1348 The parameter types included in QoS Reserved in the RESPONSE MUST be 1349 the same as those in QoS Desired in RESERVE. For those parameters 1350 that were also included in QoS Available in RESERVE, their value is 1351 copied into QoS Desired. For the other parameters, the value is 1352 copied from QoS Desired (the reservation would fail if the 1353 corresponding QoS could not be reserved). 1355 All parameters in the QoS Available QSPEC object in the RESPONSE are 1356 copied with their values from the QoS Available QSPEC object in the 1357 RESERVE (irrespective of whether they have also been copied into QoS 1358 Desired). Note that the parameters in QoS Available are read-write 1359 in the RESERVE message, whereas they are read-only in the RESPONSE. 1361 In this case, the QNI SHOULD request a RESPONSE since it will 1362 otherwise not learn what QoS is available. 1364 (3) this case is handled as case (2), except that the reservation 1365 fails when QoS Available becomes less than Minimum QoS for one 1366 parameter. If a parameter appears in QoS Available but not in 1367 Minimum QoS it is assumed that there is no minimum value for this 1368 parameter. 1370 Regarding Control Information, the rule is that all parameters that 1371 have been included in the RESERVE message by the QNI MUST also be 1372 included in the RESPONSE message by the QNR with the value they had 1373 when arriving at the QNR. When traveling in the RESPONSE message, 1374 all Control Information parameters are read-only. 1376 Also in this case, the QNI SHOULD request a RESPONSE. 1378 6.2 Receiver-Initiated Reservations 1380 Here the QNR issues a QUERY which is replied to by the QNI with a 1381 RESERVE if the reservation was successful. The QNR in turn sends a 1382 RESPONSE to the QNI. 1384 ID| QUERY | RESERVE | RESPONSE 1385 --------------------------------------------------------------------- 1386 1 |QoS Des. | QoS Des. | QoS Res. 1387 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1388 3 |Qos Des. QoS Avl. | QoS Des., QoS Avl. | QoS Res. 1390 (1) and (2) The idea is that the sender (QNR in this scenario) needs 1391 to inform the receiver (QNI in this scenario) about the QoS it 1392 desires. To this end the sender sends a QUERY message to the 1393 receiver including a QoS Desired QSPEC object. If the QoS is 1394 negotiable it additionally includes a (possibly zero) Minimum QoS, as 1395 in Case b. 1397 The RESERVE message includes QoS Available if the sender signaled QoS 1398 is negotiable (i.e. it included Minimum QoS). If the Minimum QoS 1399 received from the sender is non-zero, the QNR also includes Minimum 1400 QoS. 1402 For a successful reservation, the RESPONSE message in case (1) is 1403 optional (as is the QSPEC inside). In case (2) however, the RESPONSE 1404 is necessary in order for the QNI to learn about the QoS available. 1406 (3) This is the "RSVP-style" scenario. The sender (QNR) issues a 1407 QUERY with QoS Desired informing the receiver (QNI) about the QoS it 1408 desires as above. It also includes a QoS Available object to collect 1409 path properties. Note that here, path properties are collected with 1410 the QUERY message, whereas in the previous model (2), path properties 1411 were collected in the RESERVE message. 1413 Some parameters in QoS Available may the same as in QoS Desired. For 1414 these parameters the implicit message is that the sender would be 1415 satisfied by a reservation with lower parameter values than specified 1416 in QoS Desired. 1418 It is possible for QoS Available to contain parameters that do not 1419 appear in QoS Desired. It is assumed that the value of these 1420 parameters is collected for informational purposes only (e.g. path 1421 latency). 1423 Parameter values in QoS Available are seeded according to the senders 1424 capabilities. Each QNE downgrades or cumulates the parameter values 1425 according to its current capabilities. 1427 The receiver (QNI) signals QoS Desired as follows: For those 1428 parameters that appear in both QoS Available and QoS Desired in the 1429 QUERY message, it takes the (possibly downgraded) parameter values 1430 from QoS Available. For those parameters that only appear in QoS 1431 Desired, it adopts the parameter values from QoS Desired. 1433 The parameters in the QoS Available QSPEC object in the RESERVE 1434 message are copied with their values from the QoS Available QSPEC 1435 object in the QUERY message. Note that the parameters in QoS 1436 Available are read-write in the QUERY message, whereas they are 1437 read-only in the RESERVE message. 1439 The advantage of this model compared to the sender-initiated 1440 reservation (model 2) is that the situation of over-reservation in 1441 QNEs close to the QNI as described above does not occur. On the 1442 other hand, the QUERY may find, for example, a particular bandwidth 1443 is not available. When the actual reservation is performed, however, 1444 the desired bandwidth may meanwhile have become free. That is, the 1445 'RSVP style' may result in a smaller reservation than necessary. 1447 Regarding Control Information in receiver-initiated reservations, the 1448 sender includes all Control Information it cares about in the QUERY 1449 message. Read-write parameters are updated by QNEs as the QUERY 1450 message travels towards the receiver. The receiver includes all 1451 Control Information parameters arriving in the QUERY message also in 1452 the RESERVE message, as read-only parameters with the value they had 1453 when arriving at the receiver. 1455 Also in this scenario, the QNI SHOULD request a RESPONSE. 1457 6.3 Resource Queries 1459 Here the QNI issues a QUERY in order to investigate what resources 1460 are currently available. The QNR replies with a RESPONSE. 1462 ID | QUERY | RESPONSE 1463 -------------------------------------------- 1464 1 | QoS Available | QoS Available 1466 Note QoS Available when traveling in the QUERY is read-write, whereas 1467 in the RESPONSE it is read-only. 1469 6.4 Bidirectional Reservations 1471 On a QSPEC level, bidirectional reservations are no different from 1472 uni-directional reservations, since QSPECs for different directions 1473 never travel in the same message. 1475 6.5 Preemption 1477 A flow can be preempted by a QNE based on the values of the QSPEC 1478 Priority parameter (see Section 7.2.7). In this case the reservation 1479 state for this flow is torn down in this QNE, and the QNE sends a 1480 NOTIFY message to the QNI, as described in [QoS-SIG]. No QSPEC is 1481 carried in the NOTIFY message. The NOTIFY message carries only the 1482 Session ID and a INFO_SPEC with the error code as described in 1483 [QoS-SIG]. The QNI would normally tear down the preempted 1484 reservation by sending a RESERVE with the TEAR flag set using the SII 1485 of the preempted reservation. However, the QNI can follow other 1486 procedures as specified in its QOSM. 1488 7. QSPEC Functional Specification 1490 This Section defines the encodings of the QSPEC parameters and QSPEC 1491 control information defined in Section 5. We first give the general 1492 QSPEC formats and then the formats of the QSPEC objects and 1493 parameters. 1495 Note that all QoS Description parameters can be either read-write or 1496 read-only, depending on which object and which message they appear 1497 in. However, in a given QSPEC object, all objects are either 1498 read-write or read-only. In order to simplify keeping track of 1499 whether an object is read-write or read-only, a corresponding flag is 1500 associated with each object. 1502 Network byte order ('big-endian') for all 16- and 32-bit integers, as 1503 well as 32-bit floating point numbers, are as specified in [RFC1832, 1504 IEEE754, NETWORK-BYTE-ORDER]. 1506 7.1 General QSPEC Formats 1508 The format of the QSPEC closely follows that used in GIST [GIST] and 1509 QoS NSLP [QoS-SIG]. Every object (and parameter) has the following 1510 general format: 1512 o The overall format is Type-Length-Value (in that order). 1514 o Some parts of the type field are set aside for control flags. 1516 o Length has the units of 32-bit words, and measures the length of 1517 Value. If there is no Value, Length=0. The Object length 1518 excludes the header. 1520 o Value is a whole number of 32-bit words. If there is any padding 1521 required, the length and location MUST be defined by the 1522 object-specific format information; objects that contain variable 1523 length types may need to include additional length subfields to do 1524 so. 1526 o Any part of the object used for padding or defined as reserved("r") 1527 MUST be set to 0 on transmission and MUST be ignored on reception. 1529 o Empty QSPECs and empty QSPEC Objects MUST NOT be used. 1531 o Duplicate objects, duplicate parameters, and/or multiple 1532 occurrences of a parameter MUST NOT be used. 1534 0 1 2 3 1535 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 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Common QSPEC Header | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 // QSPEC Control Information // 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 // QSPEC QoS Objects // 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 The Common QSPEC Header is a fixed 4-byte long object containing the 1545 QOSM ID and an identifier for the QSPEC Procedure (see Section 6.1): 1547 0 1 2 3 1548 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 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Vers. | QOSM ID | QSPEC Proc. | Reserved | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 Note that a length field is not necessary since the overall length of 1554 the QSPEC is contained in the higher level QoS NSLP data object. 1556 Vers.: Identifies the QSPEC version number. It is assigned by IANA. 1558 QOSM ID: Identifies the particular QOSM being used by the QNI. It is 1559 assigned by IANA. 1561 QSPEC Proc.: Is composed of two times 4 bits. The first set of bits 1562 identifies the Message Sequence, the second set 1563 identifies the QSPEC Object Combination used for this 1564 particular message sequence: 1566 0 1 2 3 4 5 6 7 1567 +-+-+-+-+-+-+-+-+ 1568 |Mes.Sq |Obj.Cmb| 1569 +-+-+-+-+-+-+-+-+ 1571 The Message Sequence field can attain the following 1572 values: 1574 0: Sender-Initiated Reservations, as defined in Section 1575 6.1.1 1576 1: Receiver-Initiated Reservations, as defined in 1577 Section 6.1.2 1578 2: Resource Queries, as defined in Section 6.1.3 1580 The Object Combination field can take the values between 1581 1 and 3 indicated in the tables in Section 6.1.1 to 1582 6.1.3. 1584 The QSPEC Control Information is a variable length object containing 1585 one or more parameters. The QSPEC Objects field is a collection of 1586 QSPEC objects (QoS Desired, QoS Available, etc.), which share a 1587 common format and each contain several parameters. 1589 Both the QSPEC Control Information object and the QSPEC QoS objects 1590 share a common header format: 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 |R|E|r|r| Object Type |r|r|r|r| Length | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 R Flag: If set the parameters contained in the object are read-only. 1599 Otherwise they are read-write. Note that in the case of 1600 Object Type = 0 (Control Information), this value is 1601 overwritten by parameter-specific values. 1603 E Flag: Set if an error occurs on object level 1605 Object Type = 0: control information 1606 = 1: QoS Desired 1607 = 2: QoS Available 1608 = 3: QoS Reserved 1609 = 4: Minimum QoS 1611 The r-flags are reserved. 1613 Each optional or mandatory parameter within an object can be 1614 similarly encoded in TLV format using a similar parameter header: 1616 0 1 2 3 1617 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 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 |M|E|N|T| Parameter ID |r|r|r|r| Length | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 M Flag: When set indicates the subsequent parameter is a mandatory 1623 parameter and MUST be interpreted. Otherwise the parameter is 1624 optional and can be ignored if not understood. 1625 E Flag: When set indicates an error occurred when this parameter was 1626 being interpreted. 1627 N Flag: Not-supported Flag (see Section 4.5). For mandatory 1628 parameters the value of this flag is always zero. 1629 T Flag: Tunneled-parameter Flag (see Section 4.5) 1630 Parameter Type: Assigned to each parameter (see below) 1632 7.2 Parameter Coding 1634 Parameters are usually coded individually, for example, the Bandwidth 1635 Parameter (Section 7.2.3). However, it is also possible to combine 1636 several parameters into one parameter field, which is called 1637 "container coding". This coding is useful if either a) the 1638 parameters always occur together, as for example the several 1639 parameters that jointly make up the token bucket, or b) in order to 1640 make coding more efficient because the length of each parameter value 1641 is much less than a 32-bit word (as for example described in 1642 [RMD-QOSM]). Use of containers avoids header overload QSPEC, and 1643 parameters bound together in a container are usually used together in 1644 any QOSM. When a container is defined, the Parameter ID, the M, E, 1645 N, and T flags refer to the container. An example for containers is 1646 the , or the PHR Container specified in [RMD-QOSM]. 1648 7.2.1 Parameter 1650 0 1 2 3 1651 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 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 |1|E|0|T| 0 |r|r|r|r| 1 | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | NON QOSM Hop | Reserved | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 NON QOSM Hop: This field is set to 1 if a non QOSM-aware QNE is 1659 encountered on the path from the QNI to the QNR. It is a read-write 1660 parameter. 1662 7.2.2 Parameter 1664 0 1 2 3 1665 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 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 |1|E|0|T| 1 |r|r|r|r| 1 | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | Excess Trtmnt | Reserved | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 1673 Traffic, that is, traffic not covered by the Traffic Description. 1674 The excess treatment parameter is set by the QNI. It is a read-only 1675 parameter. Allowed values are as follows: 1677 0: drop 1678 1: shape 1679 2: remark 1680 3: no metering or policing is permitted 1682 If the excess treatment is unspecified, then the 1683 parameter SHOULD be omitted. The default excess treatment in case 1684 that none is specified is that there are no guarantees to excess 1685 traffic, i.e. a QNE can do whatever it finds suitable. 1687 If 'no metering or policing is permitted' is signaled, the QNE should 1688 accept the parameter set by the sender with 1689 special care so that excess traffic should not cause a problem. To 1690 request the Null Meter [RFC3290] is especially strong, and should be 1691 used with caution. 1693 A NULL metering application [RFC2997] would not include the traffic 1694 profile, and conceptually it should be possible to support this with 1695 the QSPEC. A QSPEC without a traffic profile is not excluded by the 1696 current specification. However, note that the traffic profile is 1697 important even in those cases when the excess treatment is not 1698 specified, e.g., in negotiating bandwidth for the best effort 1699 aggregate. However, a "NULL Service QOSM" would need to be specified 1700 where the desired QNE Behavior and the corresponding QSPEC format are 1701 described. 1703 As an example behavior for a NULL metering, in the properly 1704 configured DiffServ router, the resources are shared between the 1705 aggregates by the scheduling disciplines. Thus, if the incoming rate 1706 increases, it will influence the state of a queue within that 1707 aggregate, while all the other aggregates will be provided sufficient 1708 bandwidth resources. NULL metering is useful for best effort and 1709 signaling data, where there is no need to meter and police this data 1710 as it will be policed implicitly by the allocated bandwidth and, 1711 possibly, active queue management mechanism. 1713 7.2.3 [RFC2212, RFC2215] 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 |1|E|0|T| 2 |r|r|r|r| 1 | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Bandwidth (32-bit IEEE floating point number) | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 The parameter MUST be nonnegative and is measured in 1724 bytes per second and has the same range and suggested representation 1725 as the bucket and peak rates of the . can 1726 be represented using single-precision IEEE floating point. The 1727 representation MUST be able to express values ranging from 1 byte per 1728 second to 40 terabytes per second. For values of this parameter only 1729 valid non-negative floating point numbers are allowed. Negative 1730 numbers (including "negative zero"), infinities, and NAN's are not 1731 allowed. 1733 A QNE MAY export a local value of zero for this parameter. A network 1734 element or application receiving a composed value of zero for this 1735 parameter MUST assume that the actual bandwidth available is unknown. 1737 7.2.4 Parameter [RFC2212, RFC2215] 1739 0 1 2 3 1740 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 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 |0|E|N|T| 3 |r|r|r|r| 1 | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Slack Term [S] (32-bit integer) | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 Slack term S MUST be nonnegative and is measured in microseconds. 1748 The Slack term, S, can be represented as a 32-bit integer. Its value 1749 can range from 0 to (2**32)-1 microseconds. 1751 7.2.5 Parameters [RFC2215] 1753 The parameters are represented by three floating 1754 point numbers in single-precision IEEE floating point format followed 1755 by two 32-bit integers in network byte order. The first floating 1756 point value is the rate (r), the second floating point value is the 1757 bucket size (b), the third floating point is the peak rate (p), the 1758 first unsigned integer is the minimum policed unit (m), and the 1759 second unsigned integer is the maximum datagram size (MTU). 1761 Note that the two sets of parameters can be 1762 distinguished, as could be needed for example to support DiffServ 1763 applications (see Section 7.2). 1765 Token Bucket #1 Parameter ID = 4 1766 Token Bucket #1: Mandatory QSPEC Parameter 1768 Parameter Values: 1770 0 1 2 3 1771 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 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 |1|E|0|T| 4 |r|r|r|r| 5 | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | Token Bucket Size [b] (32-bit IEEE floating point number) | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Peak Data Rate [p] (32-bit IEEE floating point number) | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | Minimum Policed Unit [m] (32-bit unsigned integer) | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | Maximum Packet Size [MTU] (32-bit unsigned integer) | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 Token Bucket #2 Parameter ID = 5 1787 Token Bucket #2: Optional QSPEC Parameter 1789 Parameter Values: 1791 0 1 2 3 1792 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 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 |0|E|N|T| 5 |r|r|r|r| 5 | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | Token Bucket Size [b] (32-bit IEEE floating point number) | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Peak Data Rate [p] (32-bit IEEE floating point number) | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Minimum Policed Unit [m] (32-bit unsigned integer) | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Maximum Packet Size [MTU] (32-bit unsigned integer) | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 When r, b, and p terms are represented as IEEE floating point values, 1808 the sign bit MUST be zero (all values MUST be non-negative). 1809 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 1810 than 162 (i.e., positive 35) are discouraged, except for specifying a 1811 peak rate of infinity. Infinity is represented with an exponent of 1812 all ones (255) and a sign bit and mantissa of all zeroes. 1814 7.2.6 Parameters 1816 7.2.6.1 Parameter [RFC3140] 1818 As prescribed in RFC 3140, the encoding for a single PHB is the 1819 recommended DSCP value for that PHB, left-justified in the 16 bit 1820 field, with bits 6 through 15 set to zero. 1822 0 1 2 3 1823 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 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 |1|E|0|T| 6 |r|r|r|r| 1 | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | DSCP |0 0 0 0 0 0 0 0 0 0| Reserved | 1828 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1830 The registries needed to use RFC 3140 already exist, see [DSCP- 1831 REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs to be 1832 created for this purpose. 1834 7.2.6.2 Parameter [Y.1541] 1836 0 1 2 3 1837 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 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 |1|E|0|T| 7 |r|r|r|r| 1 | 1840 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1841 |Y.1541 QoS Cls.| Reserved | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 1845 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 1847 Class 0: 1848 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1849 Real-time, highly interactive applications, sensitive to jitter. 1850 Application examples include VoIP, Video Teleconference. 1852 Class 1: 1853 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1854 Real-time, interactive applications, sensitive to jitter. 1855 Application examples include VoIP, Video Teleconference. 1857 Class 2: 1858 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 1859 10^-3. Highly interactive transaction data. Application examples 1860 include signaling. 1862 Class 3: 1863 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 1864 10^-3. Interactive transaction data. Application examples include 1865 signaling. 1867 Class 4: 1868 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 1869 10^-3. Low Loss Only applications. Application examples include 1870 short transactions, bulk data, video streaming. 1872 Class 5: 1873 Mean delay unspecified, delay variation unspecified, loss ratio 1874 unspecified. Unspecified applications. Application examples include 1875 traditional applications of default IP networks. 1877 Class 6: 1878 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1879 Applications that are highly sensitive to loss, such as television 1880 transport, high-capacity TCP transfers, and TDM circuit emulation. 1882 Class 7: 1883 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 1884 Applications that are highly sensitive to loss, such as television 1885 transport, high-capacity TCP transfers, and TDM circuit emulation. 1887 7.6.2.3 Parameter [RFC3564] 1889 DSTE class type is defined as follows: 1891 0 1 2 3 1892 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 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 |1|E|0|T| 8 |r|r|r|r| 1 | 1895 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1896 |DSTE Cls. Type | Reserved | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 DSTE Class Type: Indicates the DSTE class type. Values currently 1900 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 1902 7.2.7 Priority Parameters 1904 7.2.7.1 & Parameters 1905 [RFC3181] 1907 0 1 2 3 1908 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 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 |1|E|0|T| 9 |r|r|r|r| 1 | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Preemption Priority | Defending Priority | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 Preemption Priority: The priority of the new flow compared with the 1916 defending priority of previously admitted flows. Higher values 1917 represent higher priority. 1919 Defending Priority: Once a flow is admitted, the preemption priority 1920 becomes irrelevant. Instead, its defending priority is used to 1921 compare with the preemption priority of new flows. 1923 As specified in [RFC3181], and are 16-bit integer values and both MUST be populated if the 1925 parameter is used. 1927 7.2.7.2 Parameter [PRIORITY-RQMTS] 1929 0 1 2 3 1930 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 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 |1|E|0|T| 10 |r|r|r|r| 1 | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 + Admission | Reserved | 1935 + Priority | | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 High priority flows, normal priority flows, and best-effort priority 1939 flows can have access to resources depending on their admission 1940 priority value, as described in [PRIORITY-RQMTS], as follows: 1942 Admission Priority: 1944 0 - best-effort priority flow 1945 1 - normal priority flow 1946 2 - high priority flow 1948 A reservation without an parameter MUST be 1949 treated as a reservation with an = 1. 1951 7.2.7.3 Parameter [SIP-PRIORITY] 1953 0 1 2 3 1954 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 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 |1|E|0|T| 11 |r|r|r|r| 1 | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 + RPH Namespace | RPH Priority | Reserved | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 [SIP-PRIORITY] defines a resource priority header (RPH) with 1962 parameters "RPH Namespace" and "RPH Priority" combination, and if 1963 populated is applicable only to flows with high reservation priority, 1964 as follows: 1966 RPH Namespace: 1968 0 - dsn 1969 1 - drsn 1970 2 - q735 1971 3 - ets 1972 4 - wps 1973 5 - not used 1975 RPH Priority: 1976 Each namespace has a finite list of relative priority-values. Each 1977 is listed here in the order of lowest priority to highest priority: 1979 4 - dsn.routine 1980 3 - dsn.priority 1981 2 - dsn.immediate 1982 1 - dsn.flash 1983 0 - dsn.flash-override 1985 5 - drsn.routine 1986 4 - drsn.priority 1987 3 - drsn.immediate 1988 2 - drsn.flash 1989 1 - drsn.flash-override 1990 0 - drsn.flash-override-override 1992 4 - q735.4 1993 3 - q735.3 1994 2 - q735.2 1995 1 - q735.1 1996 0 - q735.0 1998 4 - ets.4 1999 3 - ets.3 2000 2 - ets.2 2001 1 - ets.1 2002 0 - ets.0 2004 4 - wps.4 2005 3 - wps.3 2006 2 - wps.2 2007 1 - wps.1 2008 0 - wps.0 2010 Note that the parameter MAY be used in 2011 combination with the parameter, which depends on the 2012 supported QOSM. Furthermore, if more then one RPH namespace is 2013 supported by a QOSM, then the QOSM MUST specify how the mapping 2014 between the priorities belonging to the different RPH namespaces are 2015 mapped to each other. 2017 Note also that additional work is needed to communicate these flow 2018 priority values to bearer-level network elements 2019 [VERTICAL-INTERFACE]. 2021 7.2.8 Parameter [RFC2210, RFC2215] 2023 0 1 2 3 2024 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 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 |0|E|N|T| 12 |r|r|r|r| 1 | 2027 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2028 | Path Latency (32-bit integer) | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 The Path Latency is a single 32-bit integer in network byte order. 2032 The composition rule for the parameter is summation 2033 with a clamp of (2**32 - 1) on the maximum value. The latencies are 2034 average values reported in units of one microsecond. A system with 2035 resolution less than one microsecond MUST set unused digits to zero. 2036 An individual QNE can advertise a latency value between 1 and 2**28 2037 (somewhat over two minutes) and the total latency added across all 2038 QNEs can range as high as (2**32)-2. If the sum of the different 2039 elements delays exceeds (2**32)-2, the end-to-end advertised delay 2040 SHOULD be reported as indeterminate. A QNE that cannot accurately 2041 predict the latency of packets it is processing MUST raise the 2042 not-supported flagand either leave the value of Path Latency as is, 2043 or add its best estimate of its lower bound. A raised not-supported 2044 flagflag indicates the value of Path Latency is a lower bound of the 2045 real Path Latency. The distinguished value (2**32)-1 is taken to 2046 mean indeterminate latency because the composition function limits 2047 the composed sum to this value, it indicates the range of the 2048 composition calculation was exceeded. 2050 7.2.9 Parameter 2052 0 1 2 3 2053 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 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 |0|E|N|T| 13 |r|r|r|r| 3 | 2056 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2057 | Path Jitter STAT1(variance) (32-bit integer) | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 The Path Jitter is a set of three 32-bit integers in network byte 2065 order. The Path Jitter parameter is the combination of three 2066 statistics describing the Jitter distribution with a clamp of 2067 (2**32 - 1) on the maximum of each value. The jitter STATs are 2068 reported in units of one microsecond. A system with resolution less 2069 than one microsecond MUST set unused digits to zero. An individual 2070 QNE can advertise jitter values between 1 and 2**28 (somewhat over 2071 two minutes) and the total jitter computed across all QNEs can range 2072 as high as (2**32)-2. If the combination of the different element 2073 values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be 2074 reported as indeterminate. A QNE that cannot accurately predict the 2075 jitter of packets it is processing MUST raise the not-supported flag 2076 and either leave the value of Path Jitter as is, or add its best 2077 estimate of its STAT values. A raised not-supported flag indicates 2078 the value of Path Jitter is a lower bound of the real Path Jitter. 2079 The distinguished value (2**32)-1 is taken to mean indeterminate 2080 jitter. A QNE that cannot accurately predict the jitter of packets 2081 it is processing SHOULD set its local parameter to this value. 2082 Because the composition function limits the total to this value, 2083 receipt of this value at a network element or application indicates 2084 that the true path jitter is not known. This MAY happen because one 2085 or more network elements could not supply a value, or because the 2086 range of the composition calculation was exceeded. 2088 NOTE: The Jitter composition function makes use of the 2089 parameter. Composition functions for loss, latency and jitter may be 2090 found in [Y.1541]. 2092 7.2.10 Parameter 2094 0 1 2 3 2095 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 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 |0|E|N|T| 14 |r|r|r|r| 1 | 2098 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2099 | Path Packet Loss Ratio (32-bit floating point) | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 The Path PLR is a single 32-bit single precision IEEE floating point 2103 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 2105 value. The PLRs are reported in units of 10^-11. A system with 2106 resolution less than one microsecond MUST set unused digits to zero. 2107 An individual QNE can advertise a PLR value between zero and 10^-2 2108 and the total PLR added across all QNEs can range as high as 10^-1. 2109 If the sum of the different elements values exceeds 10^-1, the 2110 end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE 2111 that cannot accurately predict the PLR of packets it is processing 2112 MUST raise the not-supported flag and either leave the value of Path 2113 PLR as is, or add its best estimate of its lower bound. A raised 2114 not-supported flag indicates the value of Path PLR is a lower bound 2115 of the real Path PLR. The distinguished value 10^-1 is taken to mean 2116 indeterminate PLR. A QNE which cannot accurately predict the PLR of 2117 packets it is processing SHOULD set its local parameter to this 2118 value. Because the composition function limits the composed sum to 2119 this value, receipt of this value at a network element or application 2120 indicates that the true path PLR is not known. This MAY happen 2121 because one or more network elements could not supply a value, or 2122 because the range of the composition calculation was exceeded. 2124 7.2.11 Parameter 2126 0 1 2 3 2127 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 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 |0|E|N|T| 15 |r|r|r|r| 1 | 2130 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2131 | Path Packet Error Ratio (32-bit floating point) | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 The Path PER is a single 32-bit single precision IEEE floating point 2135 number in network byte order. The composition rule for the parameter is summation with a clamp of 10^-1 on the maximum 2137 value. The PERs are reported in units of 10^-11. A system with 2138 resolution less than one microsecond MUST set unused digits to zero. 2139 An individual QNE can advertise a PER value between zero and 10^-2 2140 and the total PER added across all QNEs can range as high as 10^-1. 2141 If the sum of the different elements values exceeds 10^-1, the 2142 end-to-end advertised PER SHOULD be reported as indeterminate. A QNE 2143 that cannot accurately predict the PER of packets it is processing 2144 MUST raise the not-supported flag and either leave the value of Path 2145 PER as is, or add its best estimate of its lower bound. A raised 2146 not-supported flag indicates the value of Path PER is a lower bound 2147 of the real Path PER. The distinguished value 10^-1 is taken to mean 2148 indeterminate PER. A QNE which cannot accurately predict the PER of 2149 packets it is processing SHOULD set its local parameter to this 2150 value. Because the composition function limits the composed sum to 2151 this value, receipt of this value at a network element or application 2152 indicates that the true path PER is not known. This MAY happen 2153 because one or more network elements could not supply a value, or 2154 because the range of the composition calculation was exceeded. 2156 7.2.12 Parameters [RFC2210, RFC2212, 2157 RFC2215] 2159 0 1 2 3 2160 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 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 |0|E|N|T| 16 |r|r|r|r| 1 | 2163 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2164 | End-to-end composed value for C [Ctot] (32-bit integer) | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 0 1 2 3 2167 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 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 |0|E|N|T| 17 |r|r|r|r| 1 | 2170 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2171 | End-to-end composed value for D [Dtot] (32-bit integer) | 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 0 1 2 3 2175 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 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 |0|E|N|T| 18 |r|r|r|r| 1 | 2178 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2179 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 0 1 2 3 2183 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 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 |0|E|N|T| 19 |r|r|r|r| 1 | 2186 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2187 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 The error term C is measured in units of bytes. An individual QNE 2191 can advertise a C value between 1 and 2**28 (a little over 250 2192 megabytes) and the total added over all QNEs can range as high as 2193 (2**32)-1. Should the sum of the different QNEs delay exceed 2194 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 2195 error term D is measured in units of one microsecond. An individual 2196 QNE can advertise a delay value between 1 and 2**28 (somewhat over 2197 two minutes) and the total delay added over all QNEs can range as 2198 high as (2**32)-1. Should the sum of the different QNEs delay 2199 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 2201 8. Security Considerations 2203 The priority parameter raises possibilities for Theft of Service 2204 Attacks because users could claim an emergency priority for their 2205 flows without real need, thereby effectively preventing serious 2206 emergency calls to get through. Several options exist for countering 2207 such attacks, for example 2209 - only some user groups (e.g. the police) are authorized to set the 2210 emergency priority bit 2212 - any user is authorized to employ the emergency priority bit for 2213 particular destination addresses (e.g. police) 2215 9. IANA Considerations 2217 This section defines the registries and initial codepoint assignments 2218 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 2219 It also defines the procedural requirements to be followed by IANA in 2220 allocating new codepoints. 2222 This specification allocates the following codepoints in existing 2223 registries: 2225 PHB Class Parameter [RFC3140] (Section 7.2.6.1) 2227 The registries needed to use RFC 3140 already exist [DSCP-REGISTRY, 2228 PHBID-CODES-REGISTRY]. 2230 This specification creates the following registries with the 2231 structures as defined below: 2233 Object Types (12 bits): 2234 The following values are allocated by this specification: 2235 0-4: assigned as specified in Section 7. 2236 The allocation policies for further values are as follows: 2237 5-63: Standards Action 2238 64-127: Private/Experimental Use 2239 128-4095: Reserved 2241 QSPEC Version (4 bits): 2242 The following value is allocated by this specification: 2243 0: assigned to Version 0 QSPEC 2244 The allocation policies for further values are as follows: 2245 1-15: Standards Action 2247 QOSM ID (12 bits): 2248 The allocation policies are as follows: 2249 0-63: Specification Required 2250 64-127: Private/Experimental Use 2251 128-4095: Reserved 2253 Note that QOSM ID assignments are normally requested in QOSM 2254 specification documents. 2256 QSPEC Procedure (8 bits): 2257 Broken down into 2258 Message Sequence (4 bits): 2259 The following values are allocated by this specification: 2260 0-2: assigned as specified in Section 7.1 2261 The allocation policies for further values are as follows: 2262 3-15: Standards Action 2263 Object Combination: 2264 The following values are allocated by this specification: 2265 0-2: assigned as specified in tables in Section 6.1.1 --> 6.1.3 2266 The allocation policies for further values are as follows: 2267 3-15: Standards Action 2269 Error Code (16 bits) 2270 The following values are allocated by this specification: 2271 1-3: assigned as specified in Section 4.5.1 2272 The allocation policies for further values are as follows: 2273 4-127: Specification Required (e.g., QOSM specification document) 2274 128-255: Private/Experimental Use 2275 255-65535: Reserved 2277 Parameter ID (12 bits): 2278 The following values are allocated by this specification: 2279 0-18: assigned as specified in Sections 7.2.1 --> 7.2.12. 2280 The allocation policies for further values are as follows: 2281 19-63: Standards Action (for mandatory parameters) 2282 64-127: Specification Required (for optional parameters) 2283 128-255: Private/Experimental Use 2284 255-4095: Reserved 2286 Note that if additional mandatory parameters are defined in the 2287 future, this requires a standards action equivalent to reissuing 2288 this document as a QSPEC-bis. 2290 Excess Treatment Parameter (8 bits): 2291 The following values are allocated by this specification: 2292 0-3: assigned as specified in Section 7.2.2 2293 The allocation policies for further values are as follows: 2294 4-63: Standards Action 2295 64-255: Reserved 2297 Y.1541 QoS Class Parameter (12 bits): 2298 The following values are allocated by this specification: 2299 0-7: assigned as specified in Section 7.2.6.2 2300 The allocation policies for further values are as follows: 2301 8-63: Standards Action 2302 64-4095: Reserved 2304 DSTE Class Type Parameter (12 bits): 2305 The following values are allocated by this specification: 2306 0-7: assigned as specified in Section 7.2.6.3 2307 The allocation policies for further values are as follows: 2308 8-63: Standards Action 2309 64-4095: Reserved 2311 Admission Priority Parameter (8 bits): 2312 The following values are allocated by this specification: 2313 0-2: assigned as specified in Section 7.2.6.2 2314 The allocation policies for further values are as follows: 2315 3-63: Standards Action 2316 64-255: Reserved 2317 RPH Namespace Parameter (16 bits): 2318 The following values are allocated by this specification: 2319 0-5: assigned as specified in Section 7.2.7.2 2320 The allocation policies for further values are as follows: 2321 6-63: Standards Action 2322 64-65535: Reserved 2324 RPH Priority Parameter (8 bits): 2325 dsn namespace: 2326 The following values are allocated by this specification: 2327 0-4: assigned as specified in Section 7.2.7.2 2328 The allocation policies for further values are as follows: 2329 5-63: Standards Action 2330 64-255: Reserved 2331 drsn namespace: 2332 The following values are allocated by this specification: 2333 0-5: assigned as specified in Section 7.2.7.2 2334 The allocation policies for further values are as follows: 2335 6-63: Standards Action 2336 64-255: Reserved 2337 Q735 namespace: 2338 The following values are allocated by this specification: 2339 0-4: assigned as specified in Section 7.2.7.2 2340 The allocation policies for further values are as follows: 2341 5-63: Standards Action 2342 64-255: Reserved 2343 ets namespace: 2344 The following values are allocated by this specification: 2345 0-4: assigned as specified in Section 7.2.7.2 2346 The allocation policies for further values are as follows: 2347 5-63: Standards Action 2348 64-255: Reserved 2349 wts namespace: 2350 The following values are allocated by this specification: 2351 0-4: assigned as specified in Section 7.2.7.2 2352 The allocation policies for further values are as follows: 2353 5-63: Standards Action 2354 64-255: Reserved 2356 10. Acknowledgements 2358 The authors would like to thank (in alphabetical order) David Black, 2359 Anna Charny, Adrian Farrel, Matthias Friedrich, Xiaoming Fu, Robert 2360 Hancock, Chris Lang, Jukka Manner, Dave Oran, Tom Phelan, Alexander 2361 Sayenko, Bernd Schloer, Hannes Tschofenig, and Sven van den Bosch 2362 for their very helpful suggestions. 2364 11. Normative References 2366 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 2367 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 2368 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet 2369 Signaling Transport," work in progress. 2370 [QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service 2371 Signaling," work in progress. 2372 [RFC1832] Srinivasan, R., "XDR: External Data Representation 2373 Standard," RFC 1832, August 1995. 2374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2375 Requirement Levels", BCP 14, RFC 2119, March 1997. 2376 [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 2377 -- Version 1 Functional Specification," RFC 2205, September 1997. 2378 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2379 Services", RFC 2210, September 1997. 2380 [RFC2212] Shenker, S., et. al., "Specification of Guaranteed Quality 2381 of Service," September 1997. 2382 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 2383 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 2384 1997. 2385 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 2386 Services", RFC 2475, December 1998. 2387 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2388 Codes," June 2001. 2390 12. Informative References 2392 [CMSS] "PacketCable (TM) CMS to CMS Signaling Specification, 2393 PKT-SP-CMSS-103-040402, April 2004. 2394 [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE 2395 Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard 2396 754-1985, August 1985. 2397 [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ 2398 Controlled-Load Service with NSIS," work in progress. 2399 [NETWORK-BYTE-ORDER] Wikipedia, "Endianness," 2400 http://en.wikipedia.org/wiki/Endianness. 2401 [NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work 2402 in progress. 2403 [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels 2404 for IP Networks and Services," T1A1/2003-196 R3, November 2004. 2405 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 2406 Protocol - Capability Set 3" Sep. 2003 2407 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 2408 IANA Considerations Section in RFCs," RFC 3181, October 1998. 2409 [RFC2997] Bernet, Y., et. al., "Specification of the Null Service 2410 Type," RFC 2997, November 2000. 2411 [RFC3140] Black, D., et. al., "Per Hop Behavior Identification 2412 Codes," RFC 3140, June 2001. 2414 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element," 2415 RFC 3181, October 2001. 2416 [RFC3290] Bernet, Y., et. al., "An Informal Management Model for 2417 Diffserv Routers," RFC 3290, May 2002. 2418 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation 2419 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 2420 [RFC3564] Le Faucheur, F., et. al., Requirements for Support of 2421 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 2422 July 2003 2423 [RFC3726] Brunner, M., et. al., "Requirements for Signaling 2424 Protocols", RFC 3726, April 2004. 2425 [RMD-QOSM] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling 2426 Policy Model for Networks 2427 Using Resource Management in DiffServ (RMD)," work in progress. 2428 [SIP-PRIORITY] Schulzrinne, H., Polk, J., "Communications Resource 2429 Priority for the Session Initiation Protocol(SIP)." work in 2430 progress. 2431 [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion 2432 on Associating of Control Signaling Messages with Media Priority 2433 Levels," T1S1.7 & PRQC, October 2004. 2434 [Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data 2435 Communication Service - IP Packet Transfer and Availability 2436 Performance Parameters," December 2002. 2437 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 2438 for IP-Based Services," May 2002. 2439 [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 2440 Networks Using Y.1541 QoS Classes," work in progress. 2442 13. Authors' Addresses 2444 Jerry Ash (Editor) 2445 AT&T 2446 Room MT D5-2A01 2447 200 Laurel Avenue 2448 Middletown, NJ 07748, USA 2449 Phone: +1-(732)-420-4578 2450 Fax: +1-(732)-368-8659 2451 Email: gash@att.com 2453 Attila Bader (Editor) 2454 Traffic Lab 2455 Ericsson Research 2456 Ericsson Hungary Ltd. 2457 Laborc u. 1 H-1037 2458 Budapest Hungary 2459 Email: Attila.Bader@ericsson.com 2461 Cornelia Kappler (Editor) 2462 Siemens AG 2463 Siemensdamm 62 2464 Berlin 13627 2465 Germany 2466 Email: cornelia.kappler@siemens.com 2468 Appendix A: QoS Models and QSPECs 2470 This Appendix gives a description of QoS Models and QSPECs and 2471 explains what is the relation between them. Once these descriptions 2472 are contained in a stable form in the appropriate IDs this Appendix 2473 will be removed. 2475 QoS NSLP is a generic QoS signaling protocol that can signal for many 2476 QOSMs. A QOSM is a particular QoS provisioning method or QoS 2477 architecture such as IntServ Controlled Load or Guaranteed Service, 2478 DiffServ, or RMD for DiffServ. 2480 The definition of the QOSM is independent from the definition of QoS 2481 NSLP. Existing QOSMs do not specify how to use QoS NSLP to signal 2482 for them. Therefore, we need to define the QOSM specific signaling 2483 functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM]. 2485 A QOSM must include the following information: 2487 - Role of QNEs in this QOSM: E.g., location, frequency, statefulness, 2488 etc. 2489 - QSPEC Definition: A QOSM must specify the QSPEC, including a value 2490 for the QOSM ID, and which QSPEC parameters must be included. 2491 Furthermore it needs to explain how QSPEC parameters not used in 2492 this QOSM are mapped onto parameters defined therein. 2493 - QSPEC procedures: A QOSM must describe which QSPEC procedures are 2494 applicable to this QOSM. 2495 - Processing rules in QNEs: It describes how QSPEC info is treated 2496 and interpreted in the RMF and QOSM specific processing. E.g., 2497 admission control, scheduling, policy control, QoS parameter 2498 accumulation (e.g., delay). 2499 - QSPEC example: It includes at least one bit-level QSPEC example. 2501 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved of 2502 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 2504 The union of QoS Desired, QoS Available and QoS Reserved can provide 2505 all functionality of the objects specified in RSVP IntServ, however 2506 it is difficult to provide an exact mapping. 2508 In RSVP, the Sender TSpec specifies the traffic an application is 2509 going to send (e.g. token bucket). The AdSpec can collect path 2510 characteristics (e.g. delay). Both are issued by the sender. The 2511 receiver sends the FlowSpec which includes a Receiver TSpec 2512 describing the resources reserved using the same parameters as the 2513 Sender TSpec, as well as a RSpec which provides additional IntServ 2514 QoS Model specific parameters, e.g. Rate and Slack. 2516 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 2517 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 2518 knowledge of the authors it is not possible for the sender to specify 2519 a desired maximum delay except implicitly and mutably by seeding the 2520 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 2521 the receiver-issued RSVP RESERVE message. For this reason our 2522 discussion at this point leads us to a slightly different mapping of 2523 necessary functionality to objects, which should result in more 2524 flexible signaling models. 2526 Appendix C: Main Changes Since Last Version & Open Issues 2528 C.1 Main Changes Since Version -04 2530 Version -05: 2532 - fixed in Sec. 5 and 6.2 as discussed at Interim Meeting 2533 - discarded QSPEC parameter (Maximum packet size) since MTU 2534 discovery is expected to be handled by procedure currently defined 2535 by PMTUD WG 2536 - added "container QSPEC parameter" in Sec. 6.1 to augment encoding 2537 efficiency 2538 - added the 'tunneled QSPEC parameter flag' to Sections 5 and 6 2539 - revised Section 6.2.2 on SIP priorities 2540 - added QSPEC procedures for "RSVP-style reservation", resource 2541 queries and bidirectional reservations in Sec. 7.1 2542 - reworked Section 7.2 2544 Version -06: 2546 - defined "not-supported flag" and "tunneled parameter flag" 2547 (subsumes "optional parameter flag") 2548 - defined "error flag" for error handling 2549 - updated bit error rate (BER) parameter to packet loss ratio (PLR) 2550 parameter 2551 - added packet error ratio (PER) parameter 2552 - coding checked by independent expert 2553 - coding updated to include RE flags in QSPEC objects and MENT flags 2554 in QSPEC parameters 2556 Version -07: 2558 - added text (from David Black) on DiffServ QSPEC example in Section 2559 6 2560 - re-numbered QSPEC parameter IDs to start with 0 (Section 7) 2561 - expanded IANA Considerations Section 9 2563 Version -08: 2565 - update to 'RSVP-style' reservation in Section 6.1.2 to mirror what 2566 is done in RSVP 2568 - modified text (from David Black) on DiffServ QSPEC example in 2569 Section 6.2 2570 - update to general QSPEC parameter formats in Section 7.1 (length 2571 restrictions, etc.) 2572 - re-numbered QSPEC parameter IDs in Section 7.2 2573 - modified parameter values in Section 7.2.2 2574 - update to reservation priority Section 7.2.7 2575 - specify the 3 "STATS" in the parameter, Section 2576 7.2.9.4 2577 - minor updates to IANA Considerations Section 9 2579 Version -09: 2581 - remove the DiffServ example in Section 6.2 (intent is use text as a 2582 basis for a separate DIFFSERV-QOSM I-D) 2583 - update wording in example in Section 4.3, to reflect use of default 2584 QOSM and QOSM selection by QNI 2585 - make minor changes to Section 7.2.7.2, per the exchange on the list 2586 - add comment on error codes, after the first paragraph in Section 2587 4.5.1 2589 Version -10: 2591 - rewrote Section 2.0 for clarity 2592 - added clarifications on mandatory parameters in Section 4.2; added 2593 discussion of forwarding options when a domain supports a different 2594 QOSM than the QNI 2595 - expanded Section 4.5 on error code handling, including redefined 2596 E-Flag and editorial changes to the N-Flag and T-Flag discussions 2597 - made some editorial clarifications in Section 4.6 on defining new 2598 mandatory parameters, and also reference the [NSIS-EXTENSIBILITY] 2599 document 2600 - Section 4.7 added to identify what a QOSM specification document 2601 must include 2602 - clarified the requirements in Section 5.0 for defining a new QSPEC 2603 Version 2604 - made editorial changes to Section 6, and added procedures for 2605 handling preemption 2606 - removed QOSM ID assignments in Section 9.0; clarified procedures 2607 for defining new mandatory parameters; added registry of QOSM error 2608 codes 2610 C.2 Open Issues 2612 None. 2614 Intellectual Property Statement 2616 The IETF takes no position regarding the validity or scope of any 2617 Intellectual Property Rights or other rights that might be claimed to 2618 pertain to the implementation or use of the technology described in 2619 this document or the extent to which any license under such rights 2620 might or might not be available; nor does it represent that it has 2621 made any independent effort to identify any such rights. Information 2622 on the procedures with respect to rights in RFC documents can be 2623 found in BCP 78 and BCP 79. 2625 Copies of IPR disclosures made to the IETF Secretariat and any 2626 assurances of licenses to be made available, or the result of an 2627 attempt made to obtain a general license or permission for the use of 2628 such proprietary rights by implementers or users of this 2629 specification can be obtained from the IETF on-line IPR repository at 2630 http://www.ietf.org/ipr. 2632 The IETF invites any interested party to bring to its attention any 2633 copyrights, patents or patent applications, or other proprietary 2634 rights that may cover technology that may be required to implement 2635 this standard. Please address the information to the IETF at 2636 ietf-ipr@ietf.org. 2638 Disclaimer of Validity 2640 This document and the information contained herein are provided on an 2641 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2642 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2643 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2644 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2645 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2646 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2648 Copyright Statement 2650 Copyright (C) The Internet Society (2006). This document is subject 2651 to the rights, licenses and restrictions contained in BCP 78, and 2652 except as set forth therein, the authors retain all their rights.