idnits 2.17.1 draft-ietf-nsis-qspec-04.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 1916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1906. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (May 2005) is 6919 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: 'RFC 2212' is mentioned on line 1635, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 1630, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 1625, but not defined == Missing Reference: 'S' is mentioned on line 920, but not defined == Missing Reference: 'M' is mentioned on line 945, but not defined == Missing Reference: 'MTU' is mentioned on line 960, but not defined == Missing Reference: 'RFC 3170' is mentioned on line 972, but not defined == Missing Reference: 'RFC 3181' is mentioned on line 1066, but not defined -- Looks like a reference, but probably isn't: '2215' on line 1262 -- Looks like a reference, but probably isn't: '2212' on line 1262 == Missing Reference: 'Ctot' is mentioned on line 1277, but not defined == Missing Reference: 'Dtot' is mentioned on line 1279, but not defined == Missing Reference: 'Csum' is mentioned on line 1281, but not defined == Missing Reference: 'Dsum' is mentioned on line 1283, but not defined == Missing Reference: 'QOS-SIG' is mentioned on line 1399, but not defined == Missing Reference: 'RFC2434' is mentioned on line 1661, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'DSCP-REGISTRY' is defined on line 1680, but no explicit reference was found in the text == Unused Reference: 'PHBID-CODES-REGISTRY' is defined on line 1681, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1697, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV-CLASS' is defined on line 1716, but no explicit reference was found in the text == Unused Reference: 'RFC1633' is defined on line 1722, 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. 'QoS-SIG' ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 2697 ** Downref: Normative reference to an Informational RFC: RFC 2698 Summary: 7 errors (**), 0 flaws (~~), 22 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: November 2005 Ericsson 5 Cornelia Kappler 6 Siemens AG 8 May 2005 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 November 26, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 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 draft defines a template for 47 the QSPEC, which contains both the QoS description and QSPEC control 48 information. The QSPEC format is defined, as are a number of QSPEC 49 parameters. The QSPEC parameters provide a common language to be 50 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. Conventions Used in This Document . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. QSPEC Parameters, Processing, & Extensibility . . . . . . . . . 5 63 4.1 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 5 64 4.2 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 6 65 4.3 Example of NSLP QSPEC Operation . . . . . . . . . . . . . . 8 66 4.4 Treatment of QSPEC Parameters . . . . . . . . . . . . . . 11 67 4.4.1 Mandatory & Optional QSPEC Parameters . . . . . . . . 11 68 4.4.2 Read-only and Read-write QSPEC Parameters . . . . . . 11 69 4.5 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 12 70 5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 12 71 5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 13 72 5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 13 73 5.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . 13 74 5.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . 14 75 5.2.3 QoS Reserved . . . . . . . . . . . . . . . . . . . . 17 76 5.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . 17 77 6. QSPEC Functional Specification . . . . . . . . . . . . . . . . 17 78 6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 18 79 6.2 Parameter . . . . . . . . . . . . . . . 18 80 6.3 & Parameters . . . . . . . . . . . . . . . 19 81 6.4 Parameters . . . . . . . . . . . . . . . . . 19 82 6.5 Parameters . . . . . . . . . . . . . . . . . . 20 83 6.5.1 Parameter . . . . . . . . . . . . . . . . 20 84 6.5.2 Parameter . . . . . . . . . . . . 21 85 6.5.3 Parameter . . . . . . . . . . . . . 22 86 6.6 Parameters . . . . . . . . . . . . . . . . . . . 22 87 6.6.1 & 88 Parameters . . . . . . . . . . . . . . . . . . . . . 22 89 6.6.2 Parameter . . . . . . . . . . 23 90 6.7 Parameter . . . . . . . . . . . . . . . . . 24 91 6.8 Parameter . . . . . . . . . . . . . . . . . . 25 92 6.9 Parameter . . . . . . . . . . . . . . . . . . . 25 93 6.10 Parameters . . . . . . . . . . 26 94 6.11 , , 95 , , , , 96 . . . . . . . . . . . . . . 27 97 7. QSPEC Procedures & Examples . . . . . . . . . . . . . . . . . . 29 98 7.1 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 29 99 7.1.1 Sender-Initiated Reservations . . . . . . . . . . . . 29 100 7.1.2 Receiver-Initiated Reservations . . . . . . . . . . . 30 101 7.1.3 Setting Optional Parameter Flags . . . . . . . . . . 31 102 7.2 QOSM & QSPEC Examples . . . . . . . . . . . . . . . . . . . 31 103 7.2.1 QOSM & QSPEC for DiffServ Admission Control . . . . . 31 104 7.2.2 QOSM & QSPEC for IntServ Controlled Load Service . . 33 105 7.2.3 QOSM & QSPEC for IntServ Guaranteed Services . . . . 33 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 109 11. Normative References . . . . . . . . . . . . . . . . . . . . 34 110 12. Informative References . . . . . . . . . . . . . . . . . . . 35 111 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 112 Appendix A QoS Models and QSPECs . . . . . . . . . . . . . . . . . 37 113 Appendix B Mapping of QoS Desired, QoS Available, and QoS 114 Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ . . 38 115 Intellectual Property Statement . . . . . . . . . . . . . . . . . 38 116 Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 39 117 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . 39 119 1. Conventions Used in This Document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Introduction 127 The QoS NSLP establishes and maintains state at nodes along the path 128 of a data flow for the purpose of providing forwarding resources 129 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually 130 similar to RSVP [RFC2205], and meets the requirements of [RFC3726]. 132 A QoS-enabled domain supports a particular QoS model (QOSM), which is 133 a method to achieve QoS for a traffic flow. A QOSM incorporates QoS 134 provisioning methods and a QoS architecture. It defines the behavior 135 of the resource management function (RMF), including inputs and 136 outputs, and how QSPEC information is interpreted on traffic 137 description, resources required, resources available, and control 138 information required by the RMF. A QOSM also specifies a set of 139 mandatory and optional QSPEC parameters that describe the QoS and how 140 resources will be managed by the RMF. QoS NSLP can support signaling 141 for different QOSMs, such as for IntServ, DiffServ admission control, 142 and those specified in [Y.1541-QOSM, INTSERV-QOSM, RMD-QOSM]. For 143 more information on QOSMs see Section 7.2 and Appendix A. 145 One of the major differences between RSVP and QoS-NSLP is that 146 QoS-NSLP supports signaling for different QOSMs along the data path, 147 all with one signaling message. For example, the data path may start 148 in a domain supporting DiffServ and end in a domain supporting 149 Y.1541. However, because some typical QoS parameters are 150 standardized and can be reused in different QOSMs, some degree of 151 interoperability between QOSMs exists. 153 The QSPEC travels in QoS-NSLP messages and is opaque to the 154 QoS NSLP. The content of the QSPEC is QOSM specific. Since 155 QoS-NSLP signaling operation can be different for different QOSMs, 156 the QSPEC contains two kinds of information, QSPEC control 157 information and QoS description. 159 QSPEC control information contains parameters that governs the RMF. 160 An example of QSPEC control information is how the excess traffic is 161 treated in the RMF queuing functions. 163 The QoS description is composed of QSPEC objects loosely 164 corresponding to the TSpec, RSpec and AdSpec objects specified in 165 RSVP. This is, the QSPEC may contain a description of QoS desired 166 and QoS reserved. It can also collect information about available 167 resources. Going beyond RSVP functionality, the QoS description 168 also allows indicating a range of acceptable QoS by defining a QSPEC 169 object denoting minimum QoS. Usage of these QSPEC objects is not 170 bound to particular message types thus allowing for flexibility. A 171 QSPEC object collecting information about available resources MAY 172 travel in any QoS-NSLP message, for example a QUERY message or a 173 RESERVE message. 175 3. Terminology 177 Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 178 if applicable to the underlying QOSM and a QNE MUST interpret, if 179 populated. 181 Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by 182 any QNE. Together with a description of QoS Desired or QoS 183 Available, it allows the QNI to specify a QoS range, i.e. an upper 184 and lower bound. If the QoS Desired cannot be reserved, QNEs are 185 going to decrease the reservation until the minimum QoS is hit. 187 Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 188 if applicable to the underlying QOSM, and a QNE SHOULD interpret if 189 populated and applicable to the QOSM(s) supported by the QNE. (A QNE 190 MAY ignore if it does not support a QOSM needing the optional QSPEC 191 parameter). 193 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 195 QNI: QoS NSIS Initiator, a node initiating QoS-NSLP signaling. 197 QNR: QoS NSIS Receiver, a node terminating QoS-NSLP signaling. 199 QoS Description: Describes the actual QoS in QSPEC objects QoS 200 Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC 201 objects are input or output parameters of the RMF. In a valid QSPEC, 202 at least one QSPEC object of the type QoS Desired, QoS Available or 203 QoS Reserved MUST be included. 205 QoS Available: QSPEC object containing parameters describing the 206 available resources. They are used to collect information along a 207 reservation path. 209 QoS Desired: QSPEC object containing parameters describing the 210 desired QoS for which the sender requests reservation. 212 QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g., 213 IntServ Controlled Load. A QOSM specifies a set of mandatory and 214 optional QSPEC parameters that describe the QoS and how resources 215 will be managed by the RMF. It furthermore specifies how to use QoS 216 NSLP to signal for this QOSM. 218 QoS Reserved: QSPEC object containing parameters describing the 219 reserved resources and related QoS parameters, for example, 220 bandwidth. 222 QSPEC Control Information: Control information that is specific to a 223 QSPEC, and contains parameters that govern the RMF. 225 QSPEC: QSPEC is the object of QoS-NSLP containing all QOSM-specific 226 information. 228 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 229 QoS description and QSPEC control information parameters, for 230 example, bandwidth, token bucket, and excess treatment parameters. 232 QSPEC Object: Main building blocks of QoS Description containing a 233 parameter set that is input or output of an RMF operation. 235 Resource Management Function (RMF): Functions that are related to 236 resource management, specific to a QOSM. It processes the QoS 237 description parameters and QSPEC control parameters. 239 Read-only Parameter: Parameter that is set by initiating or 240 responding QNE and is not changed during the processing of the QSPEC 241 along the path. 243 Read-write Parameter: Parameter that can be changed during the 244 processing of the QSPEC by any QNE along the path. 246 4. QSPEC Parameters, Processing, & Extensibility 248 4.1 QSPEC Parameters 250 The definition of a QOSM includes the specification of how the 251 requested QoS resources will be described and how they will be 252 managed by the RMF. For this purpose, the QOSM specifies a set of 253 QSPEC parameters that describe the QoS and QoS resource control in 254 the RMF. A given QOSM defines which of the mandatory and optional 255 QSPEC parameters it uses, and it MAY define additional optional QSPEC 256 parameters. Mandatory and optional QSPEC parameters provide a common 257 language for QOSM developers to build their QSPECs and are likely to 258 be re-used in several QOSMs. Mandatory and optional QSPEC parameters 259 are defined in this document, and additional optional QSPEC 260 parameters can be defined in separate documents. Specification of 261 additional optional QSPEC parameters requires standards action, as 262 defined in Section 4.5. 264 4.2 QSPEC Processing 266 The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control 267 information and the QoS description are interpreted and MAY be 268 modified by the RMF in a QNE (see description in [QoS-SIG]). 270 A QoS-enabled domain supports a particular QOSM, e.g. DiffServ 271 admission control. If this domain supports QoS-NSLP signaling, its 272 QNEs MUST support the DiffServ admission control QOSM. The QNEs MAY 273 also support additional QOSMs. 275 A QoS NSLP message can contain a stack of 2 or more QSPECs (note: it 276 is an open issue in QoS-NSLP if more than 2 QSPECs are allowed in the 277 stack). The first on the stack is the Initiator QSPEC. This is a 278 QSPEC provided by the QNI, which travels end-to-end, and therefore 279 the stack always has at least depth 1. QSPEC parameters MUST NOT be 280 deleted from or added to the Initiator QSPEC. In addition, the stack 281 MAY contain a Local QSPEC stacked on top of the Initiator QSPEC. A 282 QNE only considers the topmost QSPEC. 284 At the ingress edge of a local QoS domain, a Local QSPEC MAY be 285 pushed on the stack in order to describe the requested resources in a 286 domain-specific manner. Also, the Local QSPEC is popped from the 287 stack at the egress edge of the local QoS domain. 289 This draft provides a template for the QSPEC, which is needed in 290 order to help define individual QOSMs and in order to promote 291 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 292 is composed of QSPEC control information and QoS description. QoS 293 description in turn is composed of up to four QSPEC objects (not all 294 of them need to be present), namely QoS desired, QoS available, QoS 295 reserved and Minimum QoS. Each of these QSPEC objects, as well as 296 QSPEC control information, consists of a number of mandatory and 297 optional QSPEC parameters. 299 +-------------+---------------------------------------+ 300 |QSPEC Control| QoS | 301 | Information | Description | 302 +-------------+---------------------------------------+ 304 \________________ ______________________/ 305 V 306 +----------+----------+---------+-------+ \ 307 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC 308 +----------+----------+---------+-------+ / Objects 310 \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/ 311 V V V V V 313 +-------------+... +-------------+... 314 |QSPEC Para. 1| |QSPEC Para. n| 315 +-------------+... +-------------+... 317 Figure 1: Structure of the QSPEC 319 The internal structure of each QSPEC object and the QSPEC control 320 information, with mandatory and optional parameters, is illustrated 321 in Figure 2. 323 +------------------+-----------------+---------------+ 324 |QSPEC Parameter ID| Mandatory QSPEC |Optional QSPEC | 325 | | Parameters | Parameters | 326 +------------------+-----------------+---------------+ 328 Figure 2: Structure of QSPEC Objects & Control Information 330 4.3 Example of NSLP/QSPEC Operation 332 This Section illustrates the operation and use of the QSPEC within 333 the NSLP. The example configuration in shown in Figure 3. 335 +----------+ /-------\ /--------\ /--------\ 336 | Laptop | | Home | | Cable | | DiffServ | 337 | Computer |-----| Network |-----| Network |-----| Network |----+ 338 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 339 \-------/ \--------/ \--------/ | 340 | 341 +-----------------------------------------------+ 342 | 343 | /--------\ +----------+ 344 | | "X"G | | Handheld | 345 +---| Wireless |-----| Device | 346 | XG QOSM | +----------+ 347 \--------/ 349 Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC 350 Operation 352 In this configuration, a laptop computer and a handheld wireless 353 device are the endpoints for some application that has QoS 354 requirements. Assume initially that the two endpoints are stationary 355 during the application session, later we consider mobile endpoints. 356 For this session, the laptop computer is connected to a home network 357 that has no QoS support. The home network is connected to a 358 CableLabs-type cable access network with dynamic QoS (DQOS) support, 359 such as specified in the 'CMS to CMS Signaling Specification' [CMSS] 360 for cable access networks. That network is connected to a DiffServ 361 core network that uses the RMD QOSM [RMD-QOSM]. On the other side of 362 the DiffServ core is a wireless access network built on generation 363 "X" technology with QoS support as defined by generation "X". And 364 finally the handheld endpoint is connected to the wireless access 365 network. 367 We assume that the Laptop is the QNI and handheld device is the QNR. 369 The QNI will populate an Initiator QSPEC to achieve the QoS desired 370 on the path. In this example we consider two different ways to 371 signal for QoS: 373 Case 1) The QNI sets , and possibly 374 QSPEC objects in the Initiator QSPEC, and initializes 375 to . Since this is a reservation in a 376 heterogenic network with different QOSMs supported in different 377 domains, each QNE on the path reads and interprets those parameters 378 in the Initiator QSPEC that it needs to implement the QOSM within its 379 domain (as described below). Each QNE along the path checks to see if 380 resources can be reserved, and if not, the QNE 381 reduces the parameter values in and reserves these 382 values. The minimum parameter values are given in , if 383 populated, otherwise zero if is not included. If the 384 fails to satisfy one or more of the objectives, the 385 QNE notifies the QNI and the reservation is aborted. Otherwise, the 386 QNR notifies the QNI of the for the reservation. 388 Case 2) The QNI populated the Initiator QSPEC with . 389 Since this is a reservation in a heterogenic network with different 390 QOSMs supported in different domains, each QNE on the path reads and 391 interprets those parameters in the Initiator QSPEC that it needs to 392 implement the QOSM within its domain (as described below). If a QNE 393 cannot reserve resources, the reservation fails. 395 In both cases, the QNI populates mandatory and optional QSPEC to 396 ensure correct treatment of its traffic in domains down the path. 397 Since the QNI does not know the QOSM used in downstream domains, it 398 includes values for those mandatory and optional QSPEC parameters it 399 cares about. Let us assume the QNI wants to achieve IntServ-like QoS 400 guarantees, and also is interested in what path latency it can 401 achieve. The QNI therefore includes in the QSPEC the QOSM ID for 402 IntServ Controlled Load Service. The QSPEC objects are populated with 403 all parameters necessary for IntServ Controlled Load and additionally 404 to enable the QoS Class parameter to be derived, as follows: 406 = 407 = 409 In both cases, each QNE on the path reads and interprets those 410 parameters in the Initiator QSPEC that it needs to implement the QOSM 411 within its domain. It may need additional parameters for its QOSM, 412 which are not specified in the Initiator QSPEC. These parameters 413 must be inferred from those that are present according to rules 414 defined in the QOSM implemented by this QNE. 416 There are two possibilities when a RESERVE message is received at a 417 QNE at a domain border (we illustrate both possibilities in the 418 example): 420 - the QNE can stack a local QSPEC on top of the Initiator QSPEC (this 421 is new in QoS NSLP, RSVP does not do this). 423 - the QNE can tunnel the RESERVE message through its domain and issue 424 its own RESERVE message. For this new RESERVE message, the QNE acts 425 as the QNI, and the QSPEC in the domain is an Initiator QSPEC. This 426 procedure is also used by RSVP in making aggregate reservations, in 427 which case there is not a new intra-domain (aggregate) RESERVE for 428 each newly arriving interdomain (per-flow) RESERVE, but the aggregate 429 reservation is updated by the border QNE (QNI) as need be. This is 430 also how RMD works [RMD-QOSM]. 432 For example, at the RMD domain, a local RESERVE with its own RMD 433 Initiator QSPEC corresponding to the RMD-QOSM is generated based on 434 the original Initiator QSPEC according to the procedures described in 435 Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE 436 to the RMD domain must map the QSPEC parameters contained in the 437 original Initiator QSPEC into the RMD QSPEC. The RMD QSPEC for 438 example needs and . is generated 439 from the parameter. Information on , 440 however, is not provided. According to the rules laid out in the RMD 441 QOSM, the ingress QNE infers from the fact that an IntServ Controlled 442 Load QOSM was signaled that the EF PHB is appropriate to set the parameter. These RMD QSPEC parameters are populated in the 444 RMD Initiator QSPEC generated within the RMD domain. 446 Furthermore, the node at the egress to the RMD domain updates on behalf of the entire RMD domain. It must have the 448 knowledge to update the mandatory parameters and . 449 If it happens to additionally support the optional parameter , it also updates it. Otherwise it sets a parameter specific to the parameter warning the 452 QNR that the final value in is a lower bound. 454 In the XG domain, the Initiator QSPEC is translated into a Local 455 QSPEC using a similar procedure as described above. The Local QSPEC 456 becomes the current QSPEC used within the XG domain, that is, the 457 translated Initiator QSPEC becomes the first (Local) QSPEC, and the 458 Initiator QSPEC is second. This saves the QNEs within the XG domain 459 the trouble of re-translating the Initiator QSPEC. At the egress 460 edge of the XG domain, the translated Local QSPEC is popped, and the 461 Initiator QSPEC returns to the number one position. 463 If the reservation was successful, eventually the RESERVE request 464 arrives at the QNR (otherwise the QNE at which the reservation failed 465 would have aborted the RESERVE and sent an error RESPONSE back to the 466 QNI). The QNR generates a positive RESPONSE with QSPEC objects - and for case 1 - additionally . The 468 parameters appearing in are the same as in , with values copied from in case 1, and with 470 the original values from in case 2. The 471 QSPEC object is copied from the RESERVE message except that the 472 parameters that also appear in are deleted because they 473 are redundant. That is, it is not necessary to transport the object back to the QNI since the QNI knows what it signaled 475 originally, and the information is not useful for QNEs in the reverse 476 direction. The object should transport all necessary 477 information, although the and objects 478 may end up transporting some of the same information. 480 Hence, the QNR populates the following QSPEC objects: 482 = 483 = 485 If the handheld device on the right of Figure 3 is mobile, and moves 486 through different "XG" wireless networks, then the QoS might change 487 on the path since different XG wireless networks might support 488 different QOSMs. As a result, QoS-NSLP/QSPEC processing will have to 489 renegotiate the on the path. From a QSPEC 490 perspective, this is like a new reservation on the new section of the 491 path and is basically the same as any other rerouting event - to the 492 QNEs on the new path it looks like a new reservation. That is, in 493 this mobile scenario, the new segment may support a different QOSM 494 than the old segment, and the QNI would now signal a new reservation 495 (explicitly, or implicitly with the next refreshing RESERVE message) 496 to account for the different QOSM in the XG wireless domain. Further 497 details on rerouting are specified in [QoS-SIG]. 499 4.4 Treatment of QSPEC Parameters 501 4.4.1 Mandatory and Optional QSPEC Parameters 503 Mandatory and optional QSPEC parameters are defined in this document 504 and are applicable to a number of QOSMs. Mandatory QSPEC parameters 505 are treated as follows: 507 o A QNI SHOULD populate mandatory QSPEC parameters if applicable to 508 the underlying QOSM. 509 o QNEs MUST interpret mandatory QSPEC parameters, if populated. 511 Optional QSPEC parameters are treated as follows: 513 o A QNI SHOULD populate optional QSPEC parameters if applicable to 514 the QOSM for which it is signaling. 516 o QNEs SHOULD interpret optional QSPEC parameters, if populated and 517 applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore 518 the optional QSPEC parameter if it does not support a QOSM needing 519 the optional QSPEC parameter). 521 4.4.2 Read-only and Read-write QSPEC Parameters 523 Both mandatory and optional QSPEC parameters can be read-only or 524 read-write. Read-write parameters can be changed by any QNE, whereas 525 read-only parameters are fixed by the QNI and/or QNR. For example in 526 a RESERVE message, all parameters in are read-write 527 parameters, which are updated by intermediate QNEs. Read-only 528 parameters are, for example, all parameters in as sent 529 by the QNI. 531 QoS description parameters can be both read-only or read-write, 532 depending on which QSPEC object, and which message, they appear in. 534 In particular, all parameters in and are 535 read-only for all messages. Parameters in are 536 read-write in a RESERVE and QUERY message, and they are read-only in 537 a RESPONSE or NOTIFY message. Parameters in are 538 read-write in a RESERVE message, and read-only in a response message. 540 If it needs to be ensured that read-only parameters are indeed not 541 changed along the path, it is possible to apply selective protection 542 of these parameters only. The verification is based on cryptographic 543 procedures. Future versions of this draft will contain more details. 545 In the QSPEC Control Information Object, the property of being 546 read-write or read-only is parameter specific. 548 4.5 QSPEC Extensibility 550 Additional optional QSPEC parameters MAY need to be defined in the 551 future. Additional optional QSPEC parameters are defined in separate 552 Informational documents specific to a given QOSM. For example, 553 optional QSPEC parameters are defined in [RMD-QOSM] and 554 [Y.1541-QOSM]. 556 5. QSPEC Format Overview 558 QSPEC = 560 As described above, the QSPEC contains the actual resource 561 description (QoS description) as well as QSPEC control information. 562 Note that all QSPEC parameters defined in the following Sections are 563 mandatory QSPEC parameters unless specifically designated as optional 564 QSPEC parameters. Each optional QSPEC parameter has an associated 565 flag. If such a flag is set, at least one QNE along the data 566 transmission path between the QNI and QNR can not support the 567 specified optional parameter. 569 A QSPEC object ID identifies whether the object is or . As described below, the , , , and objects. A QSPEC 573 parameter ID is assigned to identify each QSPEC parameter defined 574 below. 576 A QOSM ID is included in the QSPEC and tells a QNE which parameters 577 to expect. This may simplify processing and error analysis. 578 Furthermore, it may be helpful for a QNE or a domain supporting more 579 than one QOSM to learn which QOSM the QNI would like to have in order 580 to use the most suitable QOSM. Note that the QSPEC parameters do not 581 uniquely define the QNI QOSM since more parameters than required by 582 the QNI QOSM can be included by the QNI. 584 5.1. QSPEC Control Information 586 QSPEC control information is used for signaling QOSM RMF functions 587 not defined in QoS-NSLP. It enables building new RMF functions 588 required by a QOSM within a QoS-NSLP signaling framework, such as 589 specified, for example, in [RMD-QOSM] and [Y.1541-QOSM]. 591 = 592 594 Note that and are read-write parameters 595 and is a read-only parameter. 597 The parameter indicates the number of QoS-NSLP peers 598 along the path that support the relevant QOSM specification, and if 599 it does not it MUST correctly set the flag parameter. 600 The composition rule for this parameter is to increment the counter 601 by one at each QOSM-aware hop. This quantity, when composed from the 602 QNI to QNR, informs the QNR (or QNI in a RESPONSE message) of the 603 number of QOSM-aware QNEs traversed along the path. In a local 604 QSPEC, and refer to the QoS-NSLP peers of 605 the local QOSM domain. 607 is a flag bit telling the QNR (or QNI in a RESPONSE 608 message) whether or not a particular QOSM is supported by each QNE 609 in the path between the QNI and QNR. If the QNR finds this bit set, 610 at least one QNE along the data transmission path between the QNI and 611 QNR can not support the specified QOSM. 613 The parameter describes how the QNE will process 614 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 615 be dropped, shaped and/or remarked. The excess treatment parameter is 616 initially set by the QNI and is read-only. 618 5.2 QoS Description 620 The QoS Description is broken down into the following QSPEC objects: 622 = 623 625 Of these QSPEC objects, QoS desired, QoS available and QoS reserved 626 MUST be supported by QNEs. Minimum QoS MAY be supported. 628 5.2.1 QoS Desired 630 = 631 633 These parameters describe the resources the QNI desires to reserve 634 and hence this is a read-only QSPEC object. includes a 635 description of the traffic the QNI is going to inject into the 636 network. 638 = 640 = link bandwidth needed by flow [RFC 2212, RFC 2215] 642 =

[RFC 2210] 644 Note that the parameters, such as , MAY be used 645 separately or in combination. 647 = 649 An application MAY like to reserve resources for packets with a 650 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 651 [RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class 652 type [RFC3564]. 654 = 655 657 is an essential way to differentiate flows for 658 emergency services, ETS, E911, etc., and assign them a higher 659 admission priority than normal priority flows and best-effort 660 priority flows. is the priority of the new 661 flow compared with the defending priority of previously admitted 662 flows. Once a flow is admitted, the preemption priority becomes 663 irrelevant. is used to compare with the 664 preemption priority of new flows. For any specific flow, its 665 preemption priority MUST always be less than or equal to the 666 defending priority. 668 Appropriate security measures need to be taken to prevent abuse of 669 the parameters, see Section 8 on Security Considerations. 671 , and are optional parameters 672 describing the desired path latency, path jitter and path bit error 673 rate respectively. Since these parameters are cumulative, an 674 individual QNE cannot decide whether the desired path latency, etc., 675 is available, and hence they cannot decide whether a reservation 676 fails. Rather, when these parameters are included in , 677 the QNI SHOULD also include corresponding parameters in a QSPEC object in order to facilitate collecting this 679 information. 681 5.2.2 683 = 684 685 687 , , , , , , 688 and are optional QSPEC parameters. As such, each of these 689 optional QSPEC parameters has an associated flag, that is, , , , , 691 , , and . If these flags are set, 692 then at least one QNE along the data transmission path between the 693 QNI and QNR can not support the specified optional parameter. This 694 means the value collected in the corresponding parameter is a lower 695 bound to the "real" value. A QNE MUST be able to set the optional 696 parameter flag if it does not support the optional parameter, and as 697 such the optional parameter flags are mandatory QSPEC parameters. 699 The parameters describe the resources currently 700 available on the path and hence the QSPEC object is read-write. Each 701 QNE MUST inspect this QSPEC object, and if resources available to 702 this QNE are less than what says currently, the QNE 703 MUST adapt it accordingly. Hence when the message arrives at the 704 recipient of the message, reflects the bottleneck of 705 the resources currently available on a path. It can be used in a 706 QUERY message, for example, to collect the available resources along 707 a data path. 709 The parameters and provide information, 710 for example, about the bandwidth available along the path followed by 711 a data flow. The local parameter is an estimate of the bandwidth the 712 QNE has available for packets following the path. Computation of the 713 value of this parameter SHOULD take into account all information 714 available to the QNE about the path, taking into consideration 715 administrative and policy controls on bandwidth, as well as physical 716 resources. The composition rule for this parameter is the MIN 717 function. The composed value is the minimum of the QNE's value and 718 the previously composed value. This quantity, when composed 719 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 720 minimal bandwidth link along the path from QNI to QNR. 722 The parameter accumulates the latency of the packet 723 forwarding process associated with each QNE, where the latency is 724 defined to be the smallest possible packet delay added by each QNE. 725 This delay results from speed-of-light propagation delay, from packet 726 processing limitations, or both. It does not include any variable 727 queuing delay which may be present. Each QNE MUST add the 728 propagation delay of its outgoing link, which includes the QNR adding 729 the associated delay for the egress link. Furthermore, the QNI MUST 730 add the propagation delay of the ingress link. The composition rule 731 for the parameter is summation with a clamp of 732 (2**32 - 1) on the maximum value. This quantity, when composed 733 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 734 minimal packet delay along the path from QNI to QNR. The purpose of 735 this parameter is to provide a minimum path latency for use with 736 services which provide estimates or bounds on additional path delay 737 [RFC 2212]. Together with the queuing delay bound, this parameter 738 gives the application knowledge of both the minimum and maximum 739 packet delivery delay. Knowing both the minimum and maximum latency 740 experienced by data packets allows the receiving application to know 741 the bound on delay variation and de-jitter buffer requirements. 743 The parameter accumulates the jitter of the packet 744 forwarding process associated with each QNE, where the jitter is 745 defined to be the nominal jitter added by each QNE. IP packet 746 jitter, or delay variation, is defined in RFC 3393 [RFC3393], Section 747 4.6 (Type-P-One-way-peak-to-peak-ipdv), where the suggested 748 evaluation interval is 1 minute. Note that the method to estimate 749 peak-to-peak IP delay variation without active measurements requires 750 more study. This jitter results from packet processing limitations, 751 and includes any variable queuing delay which may be present. Each 752 QNE MUST add the jitter of its outgoing link, which includes the QNR 753 adding the associated jitter for the egress link. Furthermore, the 754 QNI MUST add the jitter of the ingress link. The composition rule 755 for the parameter is summation of a large percentage of 756 the peak-to-peak variation with a clamp on the maximum value (note 757 that the methods of accumulation and estimation of nominal QNE jitter 758 are under study). This quantity, when composed end-to-end, informs 759 the QNR (or QNI in a RESPONSE message) of the nominal packet jitter 760 along the path from QNI to QNR. The purpose of this parameter is to 761 provide a nominal path jitter for use with services that provide 762 estimates or bounds on additional path delay [RFC 2212]. Together 763 with the and the queuing delay bound, this parameter 764 gives the application knowledge of the typical packet delivery delay 765 variation. 767 The parameter accumulates the bit error rate (BER) of the 768 packet forwarding process associated with each QNE, where the BER is 769 defined to be the smallest possible BER added by each QNE. Each QNE 770 MUST add the BER of its outgoing link, which includes the QNR adding 771 the associated BER for the egress link. Furthermore, the QNI MUST 772 add the BER of the ingress link. The composition rule for the 773 parameter is summation with a clamp on the maximum value 774 (this assumes sufficiently low BER values such that summation error 775 is not significant). This quantity, when composed end-to-end, 776 informs the QNR (or QNI in a RESPONSE message) of the minimal packet 777 BER along the path from QNI to QNR. As with , the method to 778 estimate requires more study. 780 , , , : Error terms C and D represent how the 781 element's implementation of the guaranteed service deviates from the 782 fluid model. These two parameters have an additive composition rule. 783 The error term C is the rate-dependent error term. It represents the 784 delay a datagram in the flow might experience due to the rate 785 parameters of the flow. The error term D is the rate-independent, 786 per-element error term and represents the worst case non-rate-based 787 transit time variation through the service element. If the 788 composition function is applied along the entire path to compute the 789 end-to-end sums of C and D ( and ) and the resulting 790 values are then provided to the QNR (or QNI in a RESPONSE message). 791 and are the sums of the parameters C and D between the 792 last reshaping point and the current reshaping point. 794 5.2.3 796 = 798 These parameters describe the QoS reserved by the QNEs along the data 799 path, and hence the QoS reserved QSPEC object is read-write. 801 , and are defined above. 803 = slack term, which is the difference between desired delay and 804 delay obtained by using bandwidth reservation, and which is used to 805 reduce the resource reservation for a flow [RFC 2212]. This is an 806 optional parameter. 808 5.2.4 810 = 812 does not have an equivalent in RSVP. It allows the QNI 813 to define a range of acceptable QoS levels by including both the 814 desired QoS value and the minimum acceptable QoS in the same message. 815 It is a read-only QSPEC object. The desired QoS is included with a 816 and/or a QSPEC object seeded to the 817 desired QoS value. The minimum acceptable QoS value MAY be coded in 818 the QSPEC object. As the message travels towards the 819 QNR, is updated by QNEs on the path. If its value 820 drops below the value of the reservation fails and is 821 aborted. When this method is employed, the QNR SHOULD signal back to 822 the QNI the value of attained in the end, because the 823 reservation MAY need to be adapted accordingly. 825 Future versions of this document will describe how can 826 be used by the QNI to send a discrete set of desired parameters. 828 6. QSPEC Functional Specification 830 This Section defines the encodings of the QSPEC parameters and QSPEC 831 control information defined in Section 5. We first give the general 832 QSPEC formats and then the formats of the QSPEC objects and 833 parameters. 835 Note that all QoS Description parameters can be either read-write or 836 read-only, depending on which object and which message they appear 837 in. 839 6.1 General QSPEC Formats: 841 Note: This section is in a draft state and further work is needed to 842 define exact formats of objects. 844 Type: QSPEC 845 Length: Variable 846 Value: This object contains a 2 byte QOSM ID and variable length 847 QSPEC information, which is QOSM specific. 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | QOSM ID | Length | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Object ID | Parameter ID | Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 // Parameter Values // 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Object ID | Parameter ID | Length | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 // Parameter Values // 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Object ID: 864 0: control information 865 1: QoS Desired 866 2: QoS Available 867 3: QoS Reserved 868 4: Min QoS 870 6.2 Parameter 872 Object ID = 0 873 Parameter ID = 0 874 Length = 8 bits 875 Mandatory QSPEC Parameter 877 Parameter Values: 879 0 1 2 3 4 5 6 7 880 +-+-+-+-+-+-+-+-+ 881 | Excess | 882 | Treatment | 883 +-+-+-+-+-+-+-+-+ 885 Excess Treatment: Indicates how the QNE SHOULD process out-of-profile 886 traffic. Allowed values are as follows: 887 0: drop 888 1: shape 889 2: remark 890 The excess treatment parameter is set by the QNI. 892 6.3 & Parameters [RFC 2212, RFC 2215] 894 The parameter MUST be nonnegative and is measured in 895 bytes per second and has the same range and suggested representation 896 as the bucket and peak rates of the . can 897 be represented using single-precision IEEE floating point. The 898 representation MUST be able to express values ranging from 1 byte per 899 second to 40 terabytes per second. For values of this parameter only 900 valid non-negative floating point numbers are allowed. Negative 901 numbers (including "negative zero"), infinities, and NAN's are not 902 allowed. 904 A QNE MAY export a local value of zero for this parameter. A network 905 element or application receiving a composed value of zero for this 906 parameter MUST assume that the actual bandwidth available is unknown. 908 Object ID = 1-4 909 Bandwidth Parameter ID = 1 910 Slack Term Parameter ID = 2 911 Length = 32 bits 912 Bandwidth is Mandatory QSPEC Parameter 913 Slack Term is Optional QSPEC Parameter 915 Parameter Values: 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Bandwidth (32-bit IEEE floating point number) | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Slack Term [S] (32-bit integer) | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Slack term S MUST be nonnegative and is measured in microseconds. 924 The Slack term, S, can be represented as a 32-bit integer. Its value 925 can range from 0 to (2**32)-1 microseconds. 927 6.4 Parameters [RFC 2215] 929 The parameters are represented by three floating 930 point numbers in single-precision IEEE floating point format followed 931 by two 32-bit integers in network byte order. The first floating 932 point value is the rate (r), the second floating point value is the 933 bucket size (b), the third floating point is the peak rate (p), the 934 first integer is the minimum policed unit (m), and the second integer 935 is the maximum datagram size (MTU). 937 Note that the parameters, such as , MAY be used 938 separately or in combination. 940 Object ID = 1-4 941 Token Bucket Rate [r] Parameter ID = 3 942 Token Bucket Size [b] Parameter ID = 4 943 Peak Data Rate [p] Parameter ID = 5 944 Minimum Policed Unit [m] Parameter ID = 6 945 Maximum Packet Size [M] Parameter ID = 7 946 Length = 32 bits 947 Mandatory QSPEC Parameters 949 Parameter Values: 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Token Bucket Size [b] (32-bit IEEE floating point number) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Peak Data Rate [p] (32-bit IEEE floating point number) | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Minimum Policed Unit [m] (32-bit integer) | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Maximum Packet Size [MTU] (32-bit integer) | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 When r, b, p, and R terms are represented as IEEE floating point 964 values, the sign bit MUST be zero (all values MUST be non-negative). 965 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 966 than 162 (i.e., positive 35) are discouraged, except for specifying a 967 peak rate of infinity. Infinity is represented with an exponent of 968 all ones (255) and a sign bit and mantissa of all zeroes. 970 6.5 Parameters 972 6.5.1 Parameter [RFC 3170] 974 As prescribed in RFC 3170, the encoding for a single PHB is the 975 recommended DSCP value for that PHB, left-justified in the 16 bit 976 field, with bits 6 through 15 set to zero. 978 Object ID = 1-4 979 PHB Class Parameter ID = 9 980 Length = 16 bits 981 Mandatory QSPEC Parameter 982 Parameter Values: 984 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 985 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 986 | DSCP | 0 0 0 0 0 0 0 0 0 0 | 987 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 989 The registries needed to use RFC 3140 already exist, see [DSCP- 990 REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs to be 991 created for this purpose. 993 6.5.2 Parameter [Y.1541] 995 Y.1541 QoS classes are defined as follows: 997 Object ID = 1-4 998 Y.1541 QoS Class Parameter ID = 10 999 Length = 8 bits 1000 Mandatory QSPEC Parameter 1002 Parameter Values: 1004 0 1 2 3 4 5 6 7 1005 +-+-+-+-+-+-+-+-+ 1006 | Y.1541 | 1007 | QoS Class | 1008 +-+-+-+-+-+-+-+-+ 1010 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 1011 allowed are 0, 1, 2, 3, 4, 5. 1013 Class 0: 1014 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1015 Real-time, highly interactive applications, sensitive to jitter. 1016 Application examples include VoIP, Video Teleconference. 1018 Class 1: 1019 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. 1020 Real-time, interactive applications, sensitive to jitter. 1021 Application examples include VoIP, Video Teleconference. 1023 Class 2: 1024 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 1025 10^-3. Highly interactive transaction data. Application examples 1026 include signaling. 1028 Class 3: 1029 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 1030 10^-3. Interactive transaction data. Application examples include 1031 signaling. 1033 Class 4: 1034 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 1035 10^-3. Low Loss Only applications. Application examples include 1036 short transactions, bulk data, video streaming. 1038 Class 5: 1039 Mean delay unspecified, delay variation unspecified, loss ratio 1040 unspecified. Unspecified applications. Application examples include 1041 traditional applications of default IP networks. 1043 6.5.3 Parameter [RFC3564] 1045 DSTE class type is defined as follows: 1047 Object ID = 1-4 1048 DSTE Class Type Parameter ID = 11 1049 Length = 8 bits 1050 Mandatory QSPEC Parameter 1052 Parameter Values: 1054 0 1 2 3 4 5 6 7 1055 +-+-+-+-+-+-+-+-+ 1056 | DSTE | 1057 | Class Type | 1058 +-+-+-+-+-+-+-+-+ 1060 DSTE Class Type: Indicates the DSTE class type. Values currently 1061 allowed are 0, 1, 2, 3, 4, 5, 6, 7. 1063 6.6 Priority Parameters 1065 6.6.1 & Parameters 1066 [RFC 3181] 1068 Object ID = 1-4 1069 Preemption Priority Parameter ID = 12 1070 Defending Priority Parameter ID = 13 1071 Length = 16 bits (unsigned) 1072 Mandatory QSPEC Parameter 1074 Parameter Values: 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Preemption Priority | Defending Priority | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 Preemption Priority: The priority of the new flow compared with the 1083 defending priority of previously admitted flows. Higher values 1084 represent higher priority. 1086 Defending Priority: 1088 6.6.2 Parameter [SIP-PRIORITY] 1090 Object ID = 1-4 1091 Reservation Priority Parameter ID = 14 1092 Length = 16 bits 1093 Mandatory QSPEC Parameter 1095 Parameter Values 1096 0 1 1097 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Reservation | Reservation | 1100 | Priority | Priority | 1101 | Namespace | | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 High priority flows, normal priority flows, and best-effort priority 1105 flows can have access to resources depending on their {"Namespace", 1106 "Reservation Priority"} combination as follows: 1108 Reservation Priority Namespace: 8 bits 1110 0 - dsn high priority 1111 1 - drsn high priority 1112 2 - q735 high priority 1113 3 - ets high priority 1114 4 - wps high priority 1115 5 - normal priority 1116 6 - best-effort priority 1118 Reservation Priority: 8 bits 1119 Each namespace has a finite list of relative priority-values. Each 1120 is listed here in the order of lowest priority to highest priority: 1122 4 - dsn.routine 1123 3 - dsn.priority 1124 2 - dsn.immediate 1125 1 - dsn.flash 1126 0 - dsn.flash-override 1128 5 - drsn.routine 1129 4 - drsn.priority 1130 3 - drsn.immediate 1131 2 - drsn.flash 1132 1 - drsn.flash-override 1133 0 - drsn.flash-override-override 1134 4 - q735.4 1135 3 - q735.3 1136 2 - q735.2 1137 1 - q735.1 1138 0 - q735.0 1140 4 - ets.4 1141 3 - ets.3 1142 2 - ets.2 1143 1 - ets.1 1144 0 - ets.0 1146 4 - wps.4 1147 3 - wps.3 1148 2 - wps.2 1149 1 - wps.1 1150 0 - wps.0 1152 0 - normal.0 1154 0 - best.effort.0 1156 Note that additional work is needed to communicate these flow 1157 priority values to bearer-level network elements 1158 [VERTICAL-INTERFACE]. 1160 6.7 Parameter [RFC 2210, 2215] 1162 Object ID = 1-4 1163 Path Latency Parameter ID = 15 1164 Length = 32 bits 1165 Optional QSPEC Parameter 1167 Parameter Values: 1169 0 1 2 3 1170 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 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Path Latency (32-bit integer) | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 The composition rule for the parameter is summation 1176 with a clamp of (2**32 - 1) on the maximum value. The latencies are 1177 reported in units of one microsecond. An individual QNE can advertise 1178 a latency value between 1 and 2**28 (somewhat over two minutes) and 1179 the total latency added across all QNEs can range as high as 1180 (2**32)-2. If the sum of the different elements delays exceeds 1181 (2**32)-2, the end-to-end advertised delay SHOULD be reported as 1182 indeterminate. A QNE that cannot accurately predict the latency of 1183 packets it is processing MUST raise the Path Latency Flag and either 1184 leave the value of Path Latency as is, or add its best estimate of 1185 its lower bound. A raised Path Latency Flag indicates the value of 1186 Path Latency is a lower bound of the real Path Latency. The 1187 distinguished value (2**32)-1 is taken to mean indeterminate latency 1188 because the composition function limits the composed sum to this 1189 value, it indicates the range of the composition calculation was 1190 exceeded. 1192 6.8 Parameter 1194 Object ID = 1-4 1195 Path Jitter Parameter ID = 16 1196 Length = 32 bits 1197 Optional QSPEC Parameter 1199 Parameter Values: 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Path Jitter (32-bit integer) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 The composition rule for the parameter is summation 1208 with a clamp of (2**32 - 1) on the maximum value. The jitters are 1209 reported in units of one microsecond. An individual QNE can advertise 1210 a jitter value between 1 and 2**28 (somewhat over two minutes) and 1211 the total jitter added across all QNEs can range as high as 1212 (2**32)-2. If the sum of the different elements delays exceeds 1213 (2**32)-2, the end-to-end advertised jitter SHOULD be reported as 1214 indeterminate. A QNE that cannot accurately predict the jitter of 1215 packets it is processing MUST raise the Path Jitter Flag and either 1216 leave the value of Path Jitter as is, or add its best estimate of its 1217 lower bound. A raised Path Jitter Flag indicates the value of Path 1218 Jitter is a lower bound of the real Path Jitter. The distinguished 1219 value (2**32)-1 is taken to mean indeterminate jitter. A QNE which 1220 cannot accurately predict the jitter of packets it is processing 1221 SHOULD set its local parameter to this value. Because the 1222 composition function limits the composed sum to this value, receipt 1223 of this value at a network element or application indicates that the 1224 true path jitter is not known. This MAY happen because one or more 1225 network elements could not supply a value, or because the range of 1226 the composition calculation was exceeded. 1228 6.9 Parameter 1230 Object ID = 1-4 1231 Path BER Parameter ID = 17 1232 Length = 32 bits 1233 Optional QSPEC Parameter 1234 Parameter Values: 1236 0 1 2 3 1237 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 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | Path Bit Error Rate (32-bit integer) | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 The composition rule for the parameter is summation with 1243 a clamp of 10^-2 on the maximum value. The BERs are reported in 1244 units of 10^-11. An individual QNE can advertise a BER value between 1245 1 and 2**28 and the total BER added across all QNEs can range as high 1246 as (2**32)-2. If the sum of the different elements delays exceeds 1247 (2**32)-2, the end-to-end advertised BER SHOULD be reported as 1248 indeterminate. A QNE that cannot accurately predict the BER of 1249 packets it is processing MUST raise the Path BER Flag and either 1250 leave the value of Path BER as is, or add its best estimate of its 1251 lower bound. A raised Path BER Flag indicates the value of Path BER 1252 is a lower bound of the real Path BER. The distinguished value 1253 (2**32)-1 is taken to mean indeterminate BER. A QNE which cannot 1254 accurately predict the BER of packets it is processing SHOULD set its 1255 local parameter to this value. Because the composition function 1256 limits the composed sum to this value, receipt of this value at a 1257 network element or application indicates that the true path BER is 1258 not known. This MAY happen because one or more network elements 1259 could not supply a value, or because the range of the composition 1260 calculation was exceeded. 1262 6.10 Parameters [RFC 2210, 2212, 2215] 1264 Object ID = 1-4 1265 Ctot Parameter ID = 18 1266 Dtot Parameter ID = 19 1267 Csum Parameter ID = 20 1268 Dsum Parameter ID = 21 1269 Length = 32 bits 1270 Optional QSPEC Parameters 1272 Parameter Values: 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | End-to-end composed value for C [Ctot] (32-bit integer) | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | End-to-end composed value for D [Dtot] (32-bit integer) | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 The error term C is measured in units of bytes. An individual QNE 1286 can advertise a C value between 1 and 2**28 (a little over 250 1287 megabytes) and the total added over all QNEs can range as high as 1288 (2**32)-1. Should the sum of the different QNEs delay exceed 1289 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 1290 error term D is measured in units of one microsecond. An individual 1291 QNE can advertise a delay value between 1 and 2**28 (somewhat over 1292 two minutes) and the total delay added over all QNEs can range as 1293 high as (2**32)-1. Should the sum of the different QNEs delay 1294 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 1296 6.11 , , , 1297 , , , 1298 1300 Object ID = 1-4 1301 Path Latency Flag Parameter ID = 22 1302 Path Latency Flag Parameter ID = 23 1303 Path Latency Flag Parameter ID = 24 1304 Ctot Flag Parameter ID = 25 1305 Dtot Flag Parameter ID = 26 1306 Csum Flag Parameter ID = 27 1307 Dsum Flag Parameter ID = 28 1308 Slack Term Flag Parameter ID = 29 1309 Length = 8 bits 1310 Mandatory QSPEC Parameters 1312 0 1 2 3 4 5 6 7 1313 +-+-+-+-+-+-+-+-+ 1314 | Path Latency | 1315 | Flag | 1316 +-+-+-+-+-+-+-+-+ 1318 Path Latency Flag: This field is set to 1 if a QNE is encountered 1319 that does not support the parameter on the path from 1320 the QNI to the QNR. 1322 0 1 2 3 4 5 6 7 1323 +-+-+-+-+-+-+-+-+ 1324 | Path Jitter | 1325 | Flag | 1326 +-+-+-+-+-+-+-+-+ 1328 Path Jitter Flag: This field is set to 1 if a QNE is encountered that 1329 does not support the parameter on the path from the QNI 1330 to the QNR. 1332 0 1 2 3 4 5 6 7 1333 +-+-+-+-+-+-+-+-+ 1334 | Path BER Flag | 1335 +-+-+-+-+-+-+-+-+ 1337 Path BER Flag: This field is set to 1 if a QNE is encountered that 1338 does not support the parameter on the path from the QNI 1339 to the QNR. 1341 0 1 2 3 4 5 6 7 1342 +-+-+-+-+-+-+-+-+ 1343 | Path Ctot | 1344 | Flag | 1345 +-+-+-+-+-+-+-+-+ 1347 Path Ctot Flag: This field is set to 1 if a QNE is encountered that 1348 does not support the parameter on the path from the QNI 1349 to the QNR. 1351 0 1 2 3 4 5 6 7 1352 +-+-+-+-+-+-+-+-+ 1353 | Path Dtot | 1354 | Flag | 1355 +-+-+-+-+-+-+-+-+ 1357 Path Dtot Flag: This field is set to 1 if a QNE is encountered that 1358 does not support the parameter on the path from the QNI 1359 to the QNR. 1361 0 1 2 3 4 5 6 7 1362 +-+-+-+-+-+-+-+-+ 1363 | Path Csum | 1364 | Flag | 1365 +-+-+-+-+-+-+-+-+ 1367 Path Csum Flag: This field is set to 1 if a QNE is encountered that 1368 does not support the parameter on the path from the QNI 1369 to the QNR. 1371 0 1 2 3 4 5 6 7 1372 +-+-+-+-+-+-+-+-+ 1373 | Path Dsum | 1374 | Flag | 1375 +-+-+-+-+-+-+-+-+ 1377 Path Dsum Flag: This field is set to 1 if a QNE is encountered that 1378 does not support the parameter on the path from the QNI 1379 to the QNR. 1381 0 1 2 3 4 5 6 7 1382 +-+-+-+-+-+-+-+-+ 1383 | Slack Term | 1384 | Flag | 1385 +-+-+-+-+-+-+-+-+ 1387 Slack Term Flag: This field is set to 1 if a QNE is encountered that 1388 does not support the parameter on the path from the QNI to the 1389 QNR. 1391 7. QSPEC Procedures & Examples 1393 7.1 QSPEC Procedures 1395 While the QSPEC template aims to put minimal restrictions on usage of 1396 QSPEC objects in , interoperability between QNEs and 1397 between QOSMs must be ensured. We therefore give below an exhaustive 1398 list of QSPEC object combinations for the message sequences described 1399 in QoS NSLP [QOS-SIG]. A specific QOSM may impose more restrictions 1400 on the QNI or QNR freedom. 1402 7.1.1 Sender-Initiated Reservations 1404 Here the QNI issues a RESERVE, which is replied to by a RESPONSE. 1405 This response is generated either by the QNR or, in case the 1406 reservation was unsuccessful, by a QNE. The following possibilities 1407 for QSPEC object usage exist: 1409 | RESERVE | RESPONSE 1410 --------------------------------------------------------------- 1411 a.| QoS Desired | QoS Reserved 1412 b.| QoS Desired, QoS Avail. | QoS Reserved, QoS Avail. 1413 c.| QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail. 1415 a.) If only QoS Desired is included in the RESERVE, the implicit 1416 assumption is that exactly these resources must be reserved. If this 1417 is not possible the reservation fails. The parameters in QoS 1418 Reserved are copied from the parameters in QoS Desired. 1420 b.) When QoS Available is included in the RESERVE also, some 1421 parameters will appear only in QoS Available and not in QoS Desired. 1422 It is assumed that the value of these parameters is collected for 1423 informational purposes only (e.g. path latency). 1425 However, some parameters in QoS Available can be the same as in QoS 1426 Desired. For these parameters the implicit message is that the QNI 1427 would be satisfied by a reservation with lower parameter values than 1428 specified in QoS Desired. For these parameters, the QNI seeds the 1429 parameter values in QoS Available to those in QoS Desired. Each QNE 1430 adapts the parameters in QoS Available according to its current 1431 capabilities. Reservations in each QNE are hence based on current 1432 parameter values in QoS Available (and additionally those parameters 1433 that only appear in QoS Desired). The drawback of this approach is 1434 that, if the resulting resource reservation becomes gradually smaller 1435 towards the QNR, QNEs close to the QNI have an oversized reservation, 1436 possibly resulting in unnecessary costs for the user. Of course, in 1437 the RESPONSE the QNI learns what the actual reservation is (from the 1438 QoS RESERVED object) and can immediately issue a properly sized 1439 refreshing RESERVE. The advantage of the approach is that the 1440 reservation is performed in half-a-roundtrip time. 1442 The parameter types included in QoS Reserved in RESPONSE must be the 1443 same as those in QoS Desired in RESERVE. For those parameters that 1444 were also included in QoS Available in RESERVE, their value is copied 1445 into QoS Desired. For the other parameters, the value is copied from 1446 QoS Desired (the reservation would fail if the corresponding QoS 1447 could not be reserved). 1449 The parameters in the QoS Available QSPEC object in the RESPONSE are 1450 copied with their values from the QoS Available QSPEC object in the 1451 RESERVE. Note that the parameters in QoS Available are read-write 1452 in the RESERVE message, whereas they are read-only in the RESPONSE. 1454 c.) this case is handled as case (b), except that the reservation 1455 fails when QoS Available becomes less than Minimum QoS for one 1456 parameter. If a parameter appears in QoS Available but not in 1457 Minimum QoS it is assumed that the minimum value for this parameter 1458 is that given in QoS Desired. 1460 7.1.2 Receiver-Initiated Reservations 1462 Here the QNI issues a QUERY which is replied to by the QNR with a 1463 RESERVE if the reservation was successful. The QNI in turn sends a 1464 RESPONSE to the QNR. 1466 QUERY | RESERVE | RESPONSE 1467 --------------------------------------------------------------------- 1468 a. QoS Des. | QoS Des. | QoS Res. 1469 b. QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl. 1471 a.) and b.) The idea is that the sender (QNR in this scenario) needs 1472 to inform the receiver (QNI in this scenario) about the QoS it 1473 desires. To this end the sender sends a QUERY message to the 1474 receiver including a QoS Desired QSPEC object. If the QoS is 1475 negotiable it additionally includes a (possibly zero) Minimum QoS, as 1476 in Case b. 1478 The RESERVE message includes QoS Available if the sender signaled QoS 1479 is negotiable (i.e. it included Minimum QoS). If the Minimum QoS 1480 received from the sender is non-zero, the QNR also includes Minimum 1481 QoS. 1483 Note we do not yet cover here a model where the sender issues a QUERY 1484 with QoS Available to collect path properties, and the QoS Desired in 1485 the RESERVE issued by the receiver is populated from the parameter 1486 values in QoS Available from the QUERY message. This is in fact the 1487 model used in RSVP. The advantage of this model is that situation of 1488 over-reservation in QNEs close to the QNI as described above does not 1489 occur. On the other hand, the QUERY may find, for example, a 1490 particular bandwidth is not available. When the actual reservation 1491 is 1492 performed, however, the desired bandwidth may meanwhile have become 1493 free. That is, the 'RSVP model' may result in a worse reservation 1494 than necessary. What scenarios to include are TBD. 1496 Future versions of this draft will additionally contain procedures 1497 for bidirectional reservations and pure resource queries without 1498 subsequent reservations. 1500 7.1.3 Setting Optional Parameter Flags 1502 An optional parameter is always accompanied by an optional parameter 1503 flag in all objects. For example, if the QNI populates an optional 1504 parameter in QoS Desired, it MUST also populate the optional 1505 parameter flag in . Hence, if a QNE wants to check 1506 for support of optional parameters, it MUST include a 1507 object and the optional parameter flags are only in that object. If 1508 a QNE does not support the optional parameter, it MUST set the 1509 optional parameter flag in the QoS Available object. Optional 1510 parameter flags SHOULD only travel in the object, and 1511 are generally not included in the QoS Desired, Minimum QoS and QoS 1512 Reserved objects. 1514 7.2 QOSM & QSPEC Examples 1516 This Section provides the QOSM and QSPECs for DiffServ admission 1517 control and IntServ. Note that DiffServ and IntServ form the basis 1518 for the QSPEC template specification in this document. 1520 7.2.1 QOSM & QSPEC for DiffServ Admission Control 1522 The QSPEC for DiffServ admission control is composed of the QSPEC 1523 objects and , as well as . Which QSPEC object is present in a particular QSPEC 1525 depends on the message type (RESERVE, QUERY etc) in which the QSPEC 1526 travels. Parameters in the QSPEC for DiffServ requesting bandwidths 1527 for different PHBs are as follows: 1529 For the DiffServ EF PHB [RFC3297]: 1531 = 1532 = 1533 = 1534 = 1535 = 1536 = 1537 = 1539 In general, the EF PHB is a property of the service that is NOT 1540 dependent on the input traffic characteristics. A server of rate R 1541 and latency E that is compliant with the EF PHB must deliver at least 1542 the configured service rate R with at most latency E for any traffic 1543 characterization. Therefore, strictly speaking, there is no specific 1544 traffic descriptor required to deliver the EF PHB (which by 1545 definition is a local per-hop characterization). However, in order 1546 to deliver a reasonable end-to-end delay, it is typically assumed 1547 that EF traffic is shaped at the ingress. A typical assumption is 1548 that input traffic at any ingress is constrained by a single rate 1549 token bucket. Therefore, a single rate token bucket is sufficient 1550 to signal in QoS-NSLP/QSPEC for the DiffServ-QOSM. 1552 For the DiffServ AFxy PHB [RFC2597]: 1554 = 1555 = 1556 = 1557 = 1558 1559 = 1560 = 1561 = 1563 QNEs MUST process two sets of token bucket parameters to implement 1564 the DiffServ AF QOSM, one token bucket for the average (CBS) traffic 1565 and one token bucket for the burst (EBS) traffic. These 2 token 1566 buckets are sufficient to cover most of the ways in which one would 1567 distinguish among 3 levels of drop precedence at the queuing 1568 mechanics level, as described in the Appendix to [RFC2597]. 1570 QoS-NSLP/QSPEC can support signaling the parameters required for the 1571 DiffServ marker elements described in [RFC2697] and [RFC2698]. 1572 [RFC2697] defines a Single Rate Three Color Marker (srTCM), which 1573 can be used as component in a DiffServ traffic conditioner [RFC2475, 1574 RFC2474]. The srTCM meters a traffic stream and marks its packets 1575 according to three traffic parameters, Committed Information Rate 1576 (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be 1577 either green, yellow, or red. A packet is marked green if it does 1578 not exceed the CBS, yellow if it does exceed the CBS, but not the 1579 EBS, and red otherwise. 1581 RFC 2697 and RFC 2698 provide specific procedures, where in essence, 1582 RFC 2697 is using two token buckets that run at the same rate. 1583 TBD: Text to explain how to use the two token buckets to carry the 1584 configuration information needed for RFC 2697 and 2698. 1586 7.2.2 QOSM & QSPEC for IntServ Controlled Load Service 1588 The QOSM for IntServ Controlled Load is defined in [RFC2211]. 1589 The QSPEC can be derived from usage of RSVP to signal for this QoS 1590 Model, as defined in [RFC2210] and [RFC2215]. 1592 The QSPEC for IntServ Controlled Load is composed of the QSPEC 1593 objects and , as well as . 1594 Which QSPEC object is present in a particular QSPEC depends on the 1595 message type (RESERVE, QUERY etc) in which the QSPEC travels. 1596 Parameters in the QSPEC are as follows: 1598 = 1599 = 1600 = 1601 = 1602 = 1604 An IntServ over DiffServ QSPEC is as follows: 1606 = 1607 = 1608 = 1609 = 1610 = 1612 7.2.3 QOSM & QSPEC for IntServ Guaranteed Services 1614 The QOSM is defined in [RFC 2212]. The required parameters to 1615 achieve guarantied service with RSVP are specified in [RFC 2210] 1616 and [RFC 2215]. 1618 The QSPEC for guaranteed services is as follows: 1620 = 1621 = 1622 = 1624 This QSPEC object contains token bucket parameters defined in 1625 [RFC 2210], equivalent to TSPEC defined in RSVP. 1627 = 1628 1630 These parameters are defined in [RFC 2212] and [RFC 2215]. This 1631 QSPEC object is equivalent to the ADSPEC of RSVP. 1633 = 1635 Requested Rate and Slack Term are defined in [RFC 2212], equivalent 1636 to RSPEC of RSVP. 1638 Note that the Guaranteed Services QoS Model only works with receiver 1639 initiated reservation signaling, because and are 1640 derived from parameters contained in , and MAY be 1641 updated on the return paths. 1643 8. Security Considerations 1645 The priority parameter raises possibilities for Theft of Service 1646 Attacks because users could claim an emergency priority for their 1647 flows without real need, thereby effectively preventing serious 1648 emergency calls to get through. Several options exist for countering 1649 such attacks, for example 1651 - only some user groups (e.g. the police) are authorized to set the 1652 emergency priority bit 1654 - any user is authorized to employ the emergency priority bit for 1655 particular destination addresses (e.g. police) 1657 9. IANA Considerations 1659 This section provides guidance to the Internet Assigned Numbers 1660 Authority (IANA) regarding registration of values related to the 1661 QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 1663 [QoS-SIG] requires IANA to create a new registry for QoS Signaling 1664 Policy Identifiers. The QoS Signaling Policy Identifier (QOSM ID) is 1665 a 32 bit value carried in a QSPEC. The allocation policy for 1666 new QOSM IDs is TBD. 1668 This document also defines 29 objects and parameters for the QSPEC 1669 Template, as Detailed in Section 6. Values are to be assigned for 1670 them from the NTLP Object Type registry. 1672 10. Acknowledgements 1674 The authors would like to thank David Black, Anna Charny, Robert 1675 Hancock, Dave Oran, Tom Phelan, Hannes Tschofenig, and Sven van den 1676 Bosch, for their very helpful suggestions. 1678 11. Normative References 1680 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 1681 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 1682 [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 1683 Signaling," work in progress. 1684 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1685 Requirement Levels", BCP 14, RFC 2119, March 1997. 1686 [RFC2205] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) 1687 -- Version 1 Functional Specification," RFC 2205, September 1997. 1688 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1689 Services", RFC 2210, September 1997. 1690 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 1691 Network Element Service", RFC 2211, Sept. 1997. 1692 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 1693 of Service," September 1997. 1694 [RFC2215] S. Shenker and J. Wroclawski, "General Characterization 1695 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 1696 1997. 1697 [RFC2474] Nichols, K., et. al., "Definition of the Differentiated 1698 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, 1699 December 1998. 1700 [RFC2475] S. Blake et. al., "An Architecture for Differentiated 1701 Services", RFC 2475, December 1998. 1702 [RFC2597] J. Heinanen, et. al., "Assured Forwarding PHB Group," RFC 1703 2597, June 1999. 1704 [RFC2697] J. Heinanen, R. Guerin, "A Single Rate Three Color Marker," 1705 RFC 2697, September 1999. 1706 [RFC2698] J. Heinanen, R. Guerin, "A Two Rate Three Color Marker," 1707 RFC 2698, September 1999. 1708 [RFC3297] A. Charny, et. al., "Supplemental Information for the New 1709 Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)," 1710 RFC 3297, March 2002. 1712 12. Informative References 1714 [CMSS] "PacketCable (TM) CMS to CMS Signaling Specification, 1715 PKT-SP-CMSS-103-040402, April 2004. 1716 [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines 1717 for DiffServ Service Classes," work in progress. 1718 [INTSERV-QOSM] C. Kappler, "A QoS Model for Signaling IntServ 1719 Controlled-Load Service with NSIS," work in progress. 1720 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 1721 Protocol - Capability Set 3" Sep. 2003 1722 [RFC1633] B. Braden et. al., "Integrated Services in the Internet 1723 Architecture: an Overview," RFC 1633, June 1994. 1724 [RFC3393] C. Demichelis, P. Chimento, "IP Packet Delay Variation 1725 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 1726 [RFC3564] F. Le Faucheur et. al., Requirements for Support of 1727 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 1728 July 2003 1729 [RFC3726] M. Brunner et. al., "Requirements for Signaling Protocols", 1730 RFC 3726, April 2004. 1731 [RMD-QOSM] A. Bader, et. al., " RMD-QOSM: An NSIS QoS Signaling 1732 Policy Model for Networks 1733 Using Resource Management in DiffServ (RMD)," work in progress. 1734 [SIP-PRIORITY] H. Schulzrinne, J. Polk, "Communications Resource 1735 Priority for the Session Initiation Protocol(SIP)." work in 1736 progress. 1737 [VERTICAL-INTERFACE] M. Dolly, P. S. Tarapore, S. Sayers, 1738 "Discussion on Associating of Control Signaling Messages with Media 1739 Priority Levels," T1S1.7 & PRQC, October 2004. 1740 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives 1741 for IP-Based Services," May 2002. 1742 [Y.1541-QOSM] J. Ash, et. al., "Y.1541-QOSM -- Y.1541 QoS Model for 1743 Networks Using Y.1541 QoS Classes," work in progress. 1745 13. Authors' Addresses 1747 Jerry Ash 1748 AT&T 1749 Room MT D5-2A01 1750 200 Laurel Avenue 1751 Middletown, NJ 07748, USA 1752 Phone: +1-(732)-420-4578 1753 Fax: +1-(732)-368-8659 1754 Email: gash@att.com 1756 Attila Bader 1757 Traffic Lab 1758 Ericsson Research 1759 Ericsson Hungary Ltd. 1760 Laborc u. 1 H-1037 1761 Budapest Hungary 1762 EMail: Attila.Bader@ericsson.com 1764 Chuck Dvorak 1765 AT&T 1766 Room 2A37 1767 180 Park Avenue, Building 2 1768 Florham Park, NJ 07932 1769 Phone: + 1 973-236-6700 1770 Fax:+1 973-236-7453 1771 E-mail: cdvorak@att.com 1773 Yacine El Mghazli 1774 Alcatel 1775 Route de Nozay 1776 91460 Marcoussis cedex 1777 FRANCE 1778 Phone: +33 1 69 63 41 87 1779 Email: yacine.el_mghazli@alcatel.fr 1781 Cornelia Kappler 1782 Siemens AG 1783 Siemensdamm 62 1784 Berlin 13627 1785 Germany 1786 Email: cornelia.kappler@siemens.com 1787 Georgios Karagiannis 1788 University of Twente 1789 P.O. BOX 217 1790 7500 AE Enschede 1791 The Netherlands 1792 EMail: g.karagiannis@ewi.utwente.nl 1794 Andrew McDonald 1795 Siemens/Roke Manor Research 1796 Roke Manor Research Ltd. 1797 Romsey, Hants SO51 0ZN 1798 UK 1799 EMail: andrew.mcdonald@roke.co.uk 1801 Al Morton 1802 AT&T 1803 Room D3-3C06 1804 200 S. Laurel Avenue 1805 Middletown, NJ 07748 1806 Phone: + 1 732 420-1571 1807 Fax: +.1 732 368-1192 1808 E-mail: acmorton@att.com 1810 Percy Tarapore 1811 AT&T 1812 Room D1-33 1813 200 S. Laurel Avenue 1814 Middletown, NJ 07748 1815 Phone: + 1 732 420-4172 1816 E-mail: tarapore@.att.com 1818 Lars Westberg 1819 Ericsson Research 1820 Torshamnsgatan 23 1821 SE-164 80 Stockholm, Sweden 1822 EMail: Lars.Westberg@ericsson.com 1824 Appendix A: QoS Models and QSPECs 1826 This Appendix gives a description of QoS Models and QSPECs and 1827 explains what is the relation between them. Once these descriptions 1828 are contained in a stable form in the appropriate IDs this Appendix 1829 will be removed. 1831 QoS NSLP is a generic QoS signaling protocol that can signal for many 1832 QOSMs. A QOSM is a particular QoS provisioning method or QoS 1833 architecture such as IntServ Controlled Load or Guaranteed Service, 1834 DiffServ, or RMD for DiffServ. 1836 The definition of the QOSM is independent from the definition of QoS 1837 NSLP. Existing QOSMs do not specify how to use QoS NSLP to signal 1838 for them. Therefore, we need to define the QOSM specific signaling 1839 functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM]. 1841 A QOSM SHOULD include the following information: 1843 - Role of QNEs in this QOSM: 1844 E.g. location, frequency, statefulness... 1845 - QSPEC Definition: 1846 A QOSM SHOULD specify the QSPEC, including QSPEC parameters. 1847 Furthermore it needs to explain how QSPEC parameters not used in this 1848 QOSM are mapped onto parameters defined therein. 1849 - Message Format 1850 QSPEC objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY 1851 - State Management 1852 It describes how QSPEC info is treated and interpreted in the 1853 RMF and QOSM specific processing. E.g. 1854 admission control, scheduling, policy control, QoS parameter 1855 accumulation (e.g. delay). 1856 - Operation and Sequence of Events 1857 Usage of QoS-NSLP messages to signal the QOSM. 1859 Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved of 1860 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 1862 The union of QoS Desired, QoS Available and QoS Reserved can provide 1863 all functionality of the objects specified in RSVP IntServ, however 1864 it is difficult to provide an exact mapping. 1866 In RSVP, the Sender TSpec specifies the traffic an application is 1867 going to send (e.g. token bucket). The AdSpec can collect path 1868 characteristics (e.g. delay). Both are issued by the sender. The 1869 receiver sends the FlowSpec which includes a Receiver TSpec 1870 describing the resources reserved using the same parameters as the 1871 Sender TSpec, as well as a RSpec which provides additional IntServ 1872 QoS Model specific parameters, e.g. Rate and Slack. 1874 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 1875 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 1876 knowledge of the authors it is not possible for the sender to specify 1877 a desired maximum delay except implicitly and mutably by seeding the 1878 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 1879 the receiver-issued RSVP RESERVE message. For this reason our 1880 discussion at this point leads us to a slightly different mapping of 1881 necessary functionality to objects, which should result in more 1882 flexible signaling models. 1884 Intellectual Property Statement 1886 The IETF takes no position regarding the validity or scope of any 1887 Intellectual Property Rights or other rights that might be claimed to 1888 pertain to the implementation or use of the technology described in 1889 this document or the extent to which any license under such rights 1890 might or might not be available; nor does it represent that it has 1891 made any independent effort to identify any such rights. Information 1892 on the procedures with respect to rights in RFC documents can be 1893 found in BCP 78 and BCP 79. 1895 Copies of IPR disclosures made to the IETF Secretariat and any 1896 assurances of licenses to be made available, or the result of an 1897 attempt made to obtain a general license or permission for the use of 1898 such proprietary rights by implementers or users of this 1899 specification can be obtained from the IETF on-line IPR repository at 1900 http://www.ietf.org/ipr. 1902 The IETF invites any interested party to bring to its attention any 1903 copyrights, patents or patent applications, or other proprietary 1904 rights that may cover technology that may be required to implement 1905 this standard. Please address the information to the IETF at 1906 ietf-ipr@ietf.org. 1908 Disclaimer of Validity 1910 This document and the information contained herein are provided on an 1911 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1912 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1913 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1914 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1915 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1916 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1918 Copyright Statement 1920 Copyright (C) The Internet Society (2005). This document is subject 1921 to the rights, licenses and restrictions contained in BCP 78, and 1922 except as set forth therein, the authors retain all their rights.