idnits 2.17.1 draft-ietf-nsis-qspec-03.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1161. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1437), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 5) being 61 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 (February 2005) is 7009 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'QoS-Sig' is mentioned on line 527, but not defined == Missing Reference: 'RFC 2212' is mentioned on line 1365, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 1361, but not defined == Missing Reference: 'RFC 2210' is mentioned on line 1355, but not defined -- Looks like a reference, but probably isn't: '2212' on line 1079 -- Looks like a reference, but probably isn't: '2215' on line 1079 == Missing Reference: 'S' is mentioned on line 810, but not defined == Missing Reference: 'M' is mentioned on line 836, but not defined == Missing Reference: 'RFC 3170' is mentioned on line 848, but not defined == Missing Reference: 'RFC 3181' is mentioned on line 924, but not defined == Missing Reference: 'Ctot' is mentioned on line 1084, but not defined == Missing Reference: 'Dtot' is mentioned on line 1086, but not defined == Missing Reference: 'Csum' is mentioned on line 1088, but not defined == Missing Reference: 'Dsum' is mentioned on line 1090, but not defined == Missing Reference: 'RFC2434' is mentioned on line 1122, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'DSCP-REGISTRY' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: 'PHBID-CODES-REGISTRY' is defined on line 1166, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV-CLASS' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'RFC1633' is defined on line 1195, 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 Summary: 10 errors (**), 0 flaws (~~), 20 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft NSIS Working Group Jerry Ash 3 Internet Draft AT&T 4 Attila Bader 5 Expiration Date: August 2005 Ericsson 6 Cornelia Kappler 7 Siemens AG 9 February 2005 11 QoS-NSLP QSPEC Template 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of RFC 3668. 20 Internet-Drafts are Working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 The QoS NSLP protocol is used to signal QoS reservations and is 43 independent of a specific QoS model (QOSM) such as IntServ or 44 DiffServ. Rather, all information specific to a QOSM is encapsulated 45 in a separate object, the QSPEC. This draft defines a template for 46 the QSPEC, which contains both the QoS description and QSPEC control 47 information. The QSPEC format is defined, as are a number of QSPEC 48 parameters. The QSPEC parameters provide a common language to be 49 re-used in several QOSMs, which are derived initially from the 50 IntServ and DiffServ 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 . . . . . . . . . . . . . . . . . . . . 5 65 4.3 Example of NSLP QSPEC Operation . . . . . . . . . . . . 6 66 4.4 Treatment of Mandatory & Optional QSPEC Parameters . . . 8 67 4.5 QSPEC Extensibility. . . . . . . . . . . . . . . . . . . 8 68 5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . 9 69 5.1 QSPEC Control Information . . . . . . . . . . . . . . . 9 70 5.2 QoS Description . . . . . . . . . . . . . . . . . . . . 10 71 5.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . 10 72 5.2.2 QoS Available . . . . . . . . . . . . . . . . . . 11 73 5.2.3 QoS Reserved . . . . . . . . . . . . . . . . . . . 13 74 5.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . 13 75 6. QSPEC Functional Specification . . . . . . . . . . . . . . . 13 76 6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . 13 77 6.2 Parameter . . . . . . . . . . . . . . . 14 78 6.3 & Parameters . . . . . . . . 14 79 6.4 Parameter . . . . . . . . . . . . . . 15 80 6.5 & Parameters . . . . . . . . . . . . . . 15 81 6.6 Parameters . . . . . . . . . . . . . . . 15 82 6.7 Parameters . . . . . . . . . . . . . . . . . 16 83 6.7.1 Parameter . . . . . . . . . . . . . . 16 84 6.7.2 Parameter . . . . . . . . . . . 16 85 6.7.3 Parameter . . . . . . . . . . . 17 86 6.8 Parameters . . . . . . . . . . . . . . . . . 17 87 6.8.1 & 88 Parameters . . . . . . . . . . . . . . . . . . . . 17 89 6.8.2 Parameter . . . . . . . . . 18 90 6.9 Parameters . . . . . . . . . . . . . . . 19 91 6.9.1 Parameter . . . . . . . . . . . . . 19 92 6.9.2 Parameter . . . . . . . . . . . . . 19 93 6.9.3 Parameter . . . . . . . . . . . . . . . 20 94 6.9.4 Parameters . . . . . . 20 95 7. Security Considerations . . . . . . . . . . . . . . . . . . 21 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 98 10. Intellectual Property Considerations . . . . . . . . . . . 21 99 11. Normative References . . . . . . . . . . . . . . . . . . . 22 100 12. Informative References . . . . . . . . . . . . . . . . . . 22 101 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23 102 Appendix A Example QSPECs . . . . . . . . . . . . . . . . . . . 24 103 A.1 QSPEC for Admission Control for DiffServ . . . . . . . . . 24 104 A.2 QSPEC for IntServ Controlled Load Service . . . . . . . . . 24 105 A.3 QSPEC for IntServ Guaranteed Services . . . . . . . . . . . 25 106 Appendix B QoS Models and QSPECs . . . . . . . . . . . . . . . 25 107 Appendix C Mapping of QoS Desired, QoS Available, and QoS 108 Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ. 26 109 Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . 27 110 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 27 112 1. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Introduction 120 The QoS NSLP establishes and maintains state at nodes along the path 121 of a data flow for the purpose of providing forwarding resources 122 (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually 123 similar to RSVP [RFC2205], and meets the requirements of [RFC3726]. 125 A QoS-enabled domain supports a particular QoS model (QOSM), which is 126 a methodology to achieve QoS for a traffic flow that incorporates QoS 127 provisioning methods and a QoS architecture. A QOSM defines the 128 behavior of the resource management function (RMF), including inputs 129 and outputs, and how QSPEC information is interpreted on traffic 130 description, resources required, resources available, and control 131 information required by the RMF. A QOSM also specifies a set of 132 mandatory and optional QSPEC parameters that describe the QoS and how 133 resources will be managed by the RMF. QoS NSLP can support signaling 134 for different QOSMs, such as for IntServ, DiffServ admission control, 135 and those specified in [Y.1541-QOSM, INTSERV-QOSM, RMD-QOSM]. For 136 more information on QOSMs see Appendix B. 138 One of the major differences between RSVP and QoS-NSLP is that 139 QoS-NSLP supports signaling for different QOSMs along the data path, 140 all with one signaling message. For example, the data path may start 141 in a domain supporting DiffServ and end in a domain supporting 142 Y.1541. However, because some typical QoS parameters are 143 standardized and can be reused in different QOSMs, some degree of 144 interoperability between QOSMs exists. 146 The QSPEC object travels in QoS-NSLP messages and is opaque to the 147 QoS NSLP. The content of the QSPEC object is QOSM specific. Since 148 QoS-NSLP signaling operation can be different for different QOSMs, 149 the QSPEC contains two kinds of information, QSPEC control 150 information and QoS description. 152 QSPEC control information contains parameters that governs the RMF. 153 An example of QSPEC control information is how the excess traffic is 154 treated in the RMF queuing functions. 156 The QoS description is composed of objects loosely corresponding to 157 the TSpec, RSpec and AdSpec objects specified in RSVP. This is, the 158 QSPEC may contain a description of QoS desired and QoS reserved. It 159 can also collect information about available resources. Going beyond 160 RSVP functionality, the QoS description also allows indicating a 161 range of acceptable QoS by defining an object denoting minimum QoS. 162 Usage of these objects is not bound to particular message types thus 163 allowing for flexibility. An object collecting information about 164 available resources MAY travel in any QoS NSLP message, for example a 165 QUERY message or a RESERVE message. 167 3. Terminology 169 Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD 170 populate if applicable to the underlying QOSM and a QNE MUST 171 interpret, if populated. 173 Minimum QoS: Minimum QoS is a functionality that MAY be supported by 174 any QNE. Together with a description of desired QoS, it allows the 175 QNI to specify a QoS range, i.e. an upper and lower bound. If the 176 desired QoS is not available, QNEs are going to decrease the 177 reservation until the minimum QoS is hit. 179 Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate 180 if applicable to the underlying QOSM, and a QNE SHOULD interpret if 181 populated and applicable to the QOSM(s) supported by the QNE. (A QNE 182 MAY ignore if it does not support a QOSM needing the optional QSPEC 183 parameter). 185 QNE: QoS NSIS Entity, a node supporting QoS NSLP. 187 QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 189 QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 191 QoS Description: Describes the actual QoS in objects QoS Desired, 192 QoS Available, QoS Reserved, and Minimum QoS. These objects are 193 input or output parameters of the RMF. In a valid QSPEC, at least 194 one object of the type QoS Desired, QoS Available or QoS Reserved 195 MUST be included. 197 QoS Available: Object containing parameters describing the available 198 resources. They are used to collect information along a reservation 199 path. 201 QoS Desired: Object containing parameters describing the desired QoS 202 for which the sender requests reservation. 204 QoS Model (QOSM): A methodology to achieve QoS for a traffic flow, 205 e.g., IntServ Controlled Load. Specifies a set of mandatory and 206 optional QSPEC parameters that describe the QoS and how resources 207 will be managed by the RMF. 209 QoS Reserved: Object containing parameters describing the reserved 210 resources and related QoS parameters, for example, bandwidth. 212 QSPEC Control Information: Control information that is specific to a 213 QSPEC, and contains parameters that govern the RMF. 215 QSPEC: QSPEC is the object of QoS-NSLP containing all QOSM specific 216 information. 218 QSPEC parameter: Any parameter appearing in a QSPEC; includes both 219 QoS description and QSPEC control information parameters, for 220 example, bandwidth, token bucket, and excess treatment parameters. 222 QSPEC object: Main building blocks of QoS Description containing a 223 parameter set that is input or output of an RMF operation. 225 Resource Management Function (RMF): Functions that are related to 226 resource management, specific to a QOSM. It processes the QoS 227 description parameters and QSPEC control parameters. 229 Read-only Parameter: Parameter that is set by initiating or 230 responding QNE and is not changed during the processing of the QSPEC 231 along the path. 233 Read-write Parameter: Parameter that can be changed during the 234 processing of the QSPEC by any QNE along the path. 236 4. QSPEC Parameters, Processing, & Extensibility 238 4.1 QSPEC Parameters 240 The definition of a QOSM includes the specification of how the 241 requested QoS resources will be described and how they will be 242 managed by the RMF. For this purpose, the QOSM specifies a set of 243 QSPEC parameters that describe the QoS and QoS resource control 244 in the RMF. A given QOSM defines which of the mandatory and optional 245 QSPEC parameters it uses, and it MAY define additional optional QSPEC 246 parameters. Mandatory and optional QSPEC parameters provide a common 247 language for QOSM developers to build their QSPECs and are likely to 248 be re-used in several QOSMs. Mandatory and optional QSPEC parameters 249 are defined in this document, and additional optional QSPEC 250 parameters 251 can be defined in separate documents. Specification of additional 252 optional QSPEC parameters requires standards action, as defined in 253 Section 4.5. 255 4.2 QSPEC Processing 257 The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control 258 information and the QoS description are interpreted and MAY be 259 modified by the RMF in a QNE (see description in [QoS-SIG]). 261 A QoS-enabled domain supports a particular QOSM, e.g. DiffServ. If 262 this domain supports QoS-NSLP signaling, its QNEs MUST support the 263 DiffServ QOSM. The QNEs MAY also support additional QOSMs. 265 A QoS NSLP message can contains a stack of 1+n QSPECs. The first on 266 the stack is the Initiator QSPEC. This is a QSPEC provided by the 267 QNI, which travels end-to-end, and therefore the stack always has at 268 least depth 1. QSPEC parameters MUST NOT be deleted from or added to 269 the Initiator QSPEC. In addition, the stack MAY contain n Local 270 QSPECs stacked on top of the Initiator QSPEC, where n is the level of 271 nested QOSM regions. In most cases, we expect the QSPEC stack to be 272 no deeper than 2. A QNE only considers the topmost QSPEC. 274 At the ingress edge of a local QoS domain, a Local QSPEC MAY be 275 pushed on the stack in order to describe the requested resources in a 276 domain-specific manner. Also, the Local QSPECs are popped from the 277 stack at the egress edge of the local QoS domain. 279 This draft provides a template for the QSPEC, which is needed in 280 order to help defining individual QOSMs and in order to promote 281 interoperability between QOSMs. Figure 1 illustrates how the QSPEC 282 is composed of QSPEC control information and QoS description. QoS 283 description in turn is composed of up to four objects (not all of 284 them need to be present), namely QoS desired, QoS available, QoS 285 reserved and Minimum QoS. Each of these objects, as well as QSPEC 286 control information, consists of a number of mandatory and optional 287 QSPEC parameters. 289 +-----------------------+----------------------------------------+ 290 | QSPEC control info | QoS description | 291 +-----------------------+----------------------------------------+ 293 \________________ ______________________/ 294 V 295 +----------+-----------+----------+-------+ 296 |QoS Desir.|QoS Avail. |QoS Rsrv. |Min QoS| 297 +----------+-----------+----------+-------+ 299 \__________ ___________/\_____ ____/\___ ______/\___ _____/\__ ___/ 300 V V V V V 302 +-------------+... +-------------+... 303 |QSPEC para. 1| |QSPEC para. n| 304 +-------------+... +-------------+... 306 Figure 1: Structure of the QSPEC 308 The Initiator QSPEC additionally MAY contain optional QSPEC 309 parameters in each object and in the QSPEC control information, as 310 illustrated in Figure 2. 312 +---------------+------------------------------+------------------------ 313 -+ 314 |QSPEC Object ID| Mandatory QSPEC Parameters |Optional QSPEC 315 Parameters| 317 +---------------+------------------------------+------------------------ 318 -+ 320 Figure 2: Structure of Initiator & Local QSPEC Objects & Control 321 Information 323 4.3 Example of NSLP/QSPEC Operation 325 This Section illustrates the operation and use of the QSPEC within 326 the NSLP. The example configuration in shown in Figure 3. 328 +----------+ /-------\ /--------\ /--------\ 329 | Laptop | | Home | | Cable | | Diffserv | 330 | Computer |-----| Network |-----| Network |-----| Network |----+ 331 +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | 332 \-------/ \--------/ \--------/ | 333 | 334 +-----------------------------------------------+ 335 | 336 | /--------\ +----------+ 337 | | "X"G | | Handheld | 338 +---| Wireless |-----| Device | 339 | XG QOSM | +----------+ 340 \--------/ 342 Figure 3: Example Configuration to Illustrate NSLP/QSPEC Operation 344 In this configuration, a laptop computer and a handheld wireless 345 device are the end points for some application that has QoS 346 requirements. Assume that the two end points are stationary during 347 the application session. For this session, the laptop computer is 348 connected to a home network that has no QoS support. The home 349 network is connected to a CableLabs-type cable access network with 350 dynamic QoS (DQOS) support, such as specified in the 'CMS to CMS 351 Signaling Specification' [CMSS] for cable access networks. That 352 network is connected to a Diffserv core network that uses the RMD 353 QOSM. On the other side of the Diffserv core is a wireless 354 access network built on generation "X" technology with QoS support as 355 defined by generation "X". And finally the handheld endpoint is 356 connected to the wireless access network. 358 We assume that the Laptop is the QNI and Handheld Device is the QNR. 360 The QNI will populate an Initiator QSPEC to achieve the QoS desired 361 on the path. There are two cases to consider: 363 Case 1) The QNI knows, either by discovery or configuration, the 364 QOSMs supported in the downstream domains, and populates the 365 appropriate mandatory and optional QSPEC parameters to achieve the 366 QNI's desired QoS. 368 Case 2) The QNI does not know which QOSMs are supported in the 369 downstream domains, and populates appropriate mandatory and optional 370 QSPEC parameters so that downstream QNEs can interpret the parameters 371 to achieve the QNI's desired QoS. 373 In case 1, the Laptop-QNI discovers which QOSMs are supported on the 374 data path by sending a QUERY message along the data path. The 375 RESPONSE message indicates the preferred QOSM supported in the 376 domains along the path. The Laptop-QNI then knows that the RMD-QOSM 377 and XG-QOSM are in the path and populates the appropriate mandatory 378 and optional QSPEC parameters needed by the RMD-QSPEC and XG-QSPEC in 379 the Initiator QSPEC sent in the RESERVE message. 381 In case 2, the QNI populates mandatory and optional QSPEC parameters 382 to ensure correct treatment of its traffic in domains down the path. 383 Since the QNI does not know the QOSM used in downstream domains, it 384 includes values for all mandatory and optional QSPEC parameters it 385 cares about. For example, if the QNI wants to achieve IntServ-like 386 QoS guarantees, it would include parameters for IntServ Guaranteed 387 Service. Since these parameters give a very precise description of 388 what is desired, QNEs can do their best to satisfy the request. If 389 the QNI thinks DiffServ priority treatment would be sufficient, it 390 just includes the appropriate DiffServ parameters, for example, it 391 identifies the EF PHB in the parameters. 393 In both cases, each QNE on the path reads and interprets the 394 parameters in the Initiator QSPEC that it needs to implement the QOSM 395 within its domain. For example, at the RMD and XG network ingress, 396 a Local QSPEC corresponding to the RMD-QOSM and XG-QOSM are 397 generated, respectively, according to the procedures described in 398 Section 4.5 of [QoS-SIG]. That is, the RMD-QNI and XG-QNI must map 399 the mandatory and optional QSPEC parameters contained in the 400 Initiator QSPEC into the appropriate Local QSPEC objects to be pushed 401 on top of the Initiator QSPEC within the RMD and XG domains, 402 respectively. For example, in the RMD domain the 403 parameter is read if available from the Initiator QSPEC, or 404 alternatively it interprets the needed bandwidth parameter based on 405 parameters in the Initiator QSPEC. 407 This top Local QSPEC becomes the current QSPEC used within the RMD 408 and XG domain, that is, the translated Initiator QSPEC becomes the 409 first (Local) QSPEC, and the Initiator QSPEC is second. This saves 410 the QNEs within the RMD and XG domains the trouble of re-translating 411 the Initiator QSPEC. At the egress edge of the RMD and XG domains, 412 the translated QSPEC is popped, and the Initiator QSPEC returns to 413 the number one position. Eventually the RESERVE request arrives at 414 the QNR. 416 4.4 Treatment of QSPEC Parameters 418 Mandatory and optional QSPEC parameters are defined in this document 419 and are applicable to a number of QOSMs. Mandatory QSPEC parameters 420 are treated as follows: 422 o A QNI SHOULD populate mandatory QSPEC parameters if applicable to 423 the underlying QOSM. 424 o QNEs MUST interpret mandatory QSPEC parameters, if populated. 426 Optional QSPEC parameters are treated as follows: 428 o A QNI SHOULD populate optional QSPEC parameters if applicable to 429 the underlying QOSM. 430 o QNEs SHOULD interpret optional QSPEC parameters, if populated and 431 applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore 432 if it does not support a QOSM needing the optional QSPEC 433 parameter). 435 4.5 QSPEC Extensibility 437 Additional optional QSPEC parameters MAY need to be defined in the 438 future. Additional optional QSPEC parameters are defined in separate 439 Informational documents specific to a given QOSM. 441 5. QSPEC Format Overview 443 QSPEC = 445 As described above, the QSPEC object contains the actual resource 446 description (QoS description) as well as QSPEC control information. 447 Both QoS description and QSPEC control information MAY contain 448 read-write and read-only objects. 450 Read-write objects can be changed by any QNE, whereas read-only 451 objects are fixed by the QNI and/or QNR. An example of a read-write 452 object is , which is updated by intermediate QNEs. 453 An example of a read-only object is as sent by the QNI. 455 Note that all QSPEC parameters defined in the following Sections are 456 mandatory QSPEC parameters unless specifically designated as optional 457 QSPEC parameters. 459 5.1. QSPEC Control Information 461 QSPEC control information is used for signaling QOSM RMF functions 462 not defined in QoS-NSLP. It enables building new RMF functions 463 required by a QOSM within a QoS-NSLP signaling framework, see for 464 example [RMD-QOSM] and [Y.1541-QOSM]. 466 = 467 469 This is a read-write object. 471 is a flag bit telling the QNR (or QNI in a RESPONSE 472 message) whether or not a completely reservation-capable path 473 exists between the QNI and QNR. If the QNR finds this bit set, at 474 least one QNE along the data transmission path between the QNI and 475 QNR can not support QoS-NSLP/QSPEC at all. If this bit is set, the 476 values of all other parameters in the are unreliable. 478 parameter indicates the number of QoS NSLP peers along 479 the path the QNE MUST support and characterize the service in 480 conformance with the relevant QoS-NSLP/QSPEC specification, and if it 481 does not it MUST correctly set the flag parameter. 482 The composition rule for this parameter is to increment the counter 483 by one at each QoS-NSLP/QSPEC-aware hop. This quantity, when 484 composed from the QNI to QNR, informs the QNR (or QNI in a RESPONSE 485 message) of the number of QoS-NSLP/QSPEC-aware QNEs traversed along 486 the path. In a local QSPEC, and refer to 487 the NSLP nodes of the local QOSM. 489 parameter limits the maximum number of QoS-NSLP hops. 490 If is reached, the NSLP message SHOULD be terminated. 492 parameter describes how the QNE will process 493 excess traffic, that is, out-of-profile traffic. Excess traffic MAY 494 be dropped, shaped and/or remarked. The excess treatment parameter is 495 initially set by the QNI and adjusted as needed by QNEs. 497 5.2 QoS Description 499 The QoS Description is broken down into the following objects: 501 = 502 504 Of these objects, QoS desired, QoS available and QoS reserved MUST be 505 supported by QNEs. Minimum QoS MAY be supported. QoS Desired and 506 Minimum QoS are read-only, whereas QoS Available and QoS Reserved are 507 read-write. If it needs to be ensured that QoS Desired and Minimum 508 QoS are indeed not changed along the path, it is possible to apply 509 selective protection of these objects only. The verification is 510 based on cryptographic procedures. 512 On the QSPEC template level, the only restriction on object usage is 513 that SHOULD always travel together with 514 and/or . Otherwise there is no restriction on how many 515 of these objects a QSPEC may carry, nor what type of object is 516 carried in what type of QoS NSLP message. For example, in a 517 receiver-initiated reservation scenario, the QNI MAY send a QUERY 518 carrying a object to probe the available resources 519 on the path. The same QUERY MAY carry a object. The 520 responding QNE can re-use the latter objects in the RESERVE message. 521 A QNI could send a RESERVE with containing a particular 522 parameter, and at the same time include a 523 object for querying availability of this same parameter. If cannot be reserved, the QNR can use the information 525 collected in along the path to signal back to the QNI 526 a more promising value of . The details of such message 527 exchanges are defined in [QoS-Sig]. The QoS NSLP and particularly 528 the QOSMs prescribe how the objects in QSPECs are interpreted and 529 used, and therefore MAY restrict this freedom. 531 5.2.1 533 = 535 These parameters describe the resources the QNI desires to reserve 536 and hence this is a read-only object. includes a 537 description of the traffic the QNI is going to inject into the 538 network. 540 = 542 = link bandwidth needed by flow [RFC 2212, RFC 2215] 544 =

[RFC 2210] 546 = 548 An application MAY like to reserve resources for packets with a 549 particular QoS class, e.g. a DiffServ per-hop behavior (PHB) 550 [RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class 551 type [RFC3564]. 553 = 554 556 is an essential way to differentiate flows for 557 emergency services, ETS, E911, etc., and assign them a higher 558 admission priority than normal priority flows and best-effort 559 priority flows. is the priority of the new 560 flow compared with the defending priority of previously admitted 561 flows. Once a flow was admitted, the preemption priority becomes 562 irrelevant. is used to compare with the 563 preemption priority of new flows. For any specific flow, its 564 preemption priority MUST always be less than or equal to the 565 defending priority. 567 Appropriate security measures need to be taken to prevent abuse of 568 the parameters. 570 5.2.2 572 = 573 575 , , , , , , 576 and are optional QSPEC parameters. 578 These parameters describe the resources currently available on the 579 path and hence the object is read-write. Each QNE MUST inspect this 580 object, and if resources available to this QNE are less than what 581 says currently, the QNE MUST adapt it accordingly. 582 Hence when the message arrives at the recipient of the message, reflects the bottleneck of the resources currently 584 available on a path. It can be used in a QUERY message, for example, 585 to collect the available resources along a data path. The parameters are defined in [RFC 2210, 2212, 2215]. 588 The parameters provide information, for 589 example, about the bandwidth available along the path followed by a 590 data flow. The local parameter is an estimate of the bandwidth the 591 QNE has available for packets following the path. Computation of the 592 value of this parameter SHOULD take into account all information 593 available to the QNE about the path, taking into consideration 594 administrative and policy controls on bandwidth, as well as physical 595 resources. The composition rule for this parameter is the MIN 596 function. The composed value is the minimum of the QNE's value and 597 the previously composed value. This quantity, when composed 598 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 599 minimal bandwidth link along the path from QNI to QNR. 601 The parameter accumulates the latency of the packet 602 forwarding process associated with each QNE, where the latency is 603 defined to be the smallest possible packet delay added by each QNE. 604 This delay results from speed-of-light propagation delay, from packet 605 processing limitations, or both. It does not include any variable 606 queuing delay which may be present. Each QNE MUST add the 607 propagation delay of its outgoing link, which includes the QNR adding 608 the associated delay for the egress link. Furthermore, the QNI MUST 609 add the propagation delay of the ingress link. The composition rule 610 for the parameter is summation with a clamp of 611 (2**32 - 1) on the maximum value. This quantity, when composed 612 end-to-end, informs the QNR (or QNI in a RESPONSE message) of the 613 minimal packet delay along the path from QNI to QNR. The purpose of 614 this parameter is to provide a minimum path latency for use with 615 services which provide estimates or bounds on additional path delay 616 [RFC 2212]. Together with the queuing delay bound, this parameter 617 gives the application knowledge of both the minimum and maximum 618 packet delivery delay. Knowing both the minimum and maximum latency 619 experienced by data packets allows the receiving application to know 620 the bound on delay variation and de-jitter buffer requirements. 622 The parameter accumulates the jitter of the packet 623 forwarding process associated with each QNE, where the jitter is 624 defined to be the nominal jitter added by each QNE. IP packet 625 jitter, or delay variation, is defined in RFC 3393 [RFC3393], Section 626 4.6 (Type-P-One-way-peak-to-peak-ipdv), where the suggested 627 evaluation interval is 1 minute. Note that the method to estimate 628 peak-to-peak IP delay variation without active measurements requires 629 more study. This jitter results from packet processing limitations, 630 and includes any variable queuing delay which may be present. Each 631 QNE MUST add the jitter of its outgoing link, which includes the QNR 632 adding the associated jitter for the egress link. Furthermore, the 633 QNI MUST add the jitter of the ingress link. The composition rule 634 for the parameter is summation of a large percentage of 635 the peak-to-peak variation with a clamp on the maximum value (note 636 that the methods of accumulation and estimation of nominal QNE jitter 637 is under study). This quantity, when composed end-to-end, informs 638 the QNR (or QNI in a RESPONSE message) of the nominal packet jitter 639 along the path from QNI to QNR. The purpose of this parameter is to 640 provide a nominal path jitter for use with services that provide 641 estimates or bounds on additional path delay [RFC 2212]. Together 642 with the and the queuing delay bound, this parameter 643 gives the application knowledge of the typical packet delivery delay 644 variation. 646 The parameter accumulates the bit error rate (BER) of the 647 packet forwarding process associated with each QNE, where the BER is 648 defined to be the smallest possible BER added by each QNE. Each QNE 649 MUST add the BER of its outgoing link, which includes the QNR adding 650 the associated BER for the egress link. Furthermore, the QNI MUST 651 add the BER of the ingress link. The composition rule for the 652 parameter is summation with a clamp on the maximum value 653 (this assumes sufficiently low BER values such that summation error 654 is not significant). This quantity, when composed end-to-end, 655 informs the QNR (or QNI in a RESPONSE message) of the minimal packet 656 BER along the path from QNI to QNR. As with , the method to 657 estimate requires more study. 659 , , , : Error terms C and D represent how the 660 element's implementation of the guaranteed service deviates from the 661 fluid model. These two parameters have an additive composition rule. 662 The error term C is the rate-dependent error term. It represents the 663 delay a datagram in the flow might experience due to the rate 664 parameters of the flow. The error term D is the rate-independent, 665 per-element error term and represents the worst case non-rate-based 666 transit time variation through the service element. If the 667 composition function is applied along the entire path to compute the 668 end-to-end sums of C and D ( and ) and the resulting 669 values are then provided to the QNR (or QNI in a RESPONSE message). 670 and are the sums of the parameters C and D between the 671 last reshaping point and the current reshaping point. 673 5.2.3 675 = 677 These parameters describe the QoS reserved by the QNEs down the path, 678 and hence the object is read-write. 680 , and are defined above. 682 = slack term: difference between desired delay and delay obtained 683 by using bandwidth reservation (used to reduce resource 684 reservation for flow) [RFC 2212]. 686 5.2.4 688 = 690 does not have an equivalent in RSVP. It allows the QNI 691 to define a range of acceptable QoS levels by including both the 692 desired QoS value and the minimum acceptable QoS in the same message. 693 It is a read-only object. The desired QoS is included with a and/or a object seeded to the desired QoS 695 value. The minimum acceptable QoS value MAY be coded in the object. As the message travels towards the QNR, 697 is updated by QNEs on the path. If its value drops below the value 698 of the reservation failed and can be aborted. When this 699 method is employed the QNR SHOULD signal back to the QNI the value 700 attained in the end, because the reservation MAY need 701 to be adapted accordingly. 703 Future versions of this document will describe how can 704 be used by the QNI to send a discrete set of desired parameters. 706 6. QSPEC Functional Specification 708 This Section defines the encodings of the QSPEC parameters and QSPEC 709 control information defined in Section 4. We first give the general 710 QSPEC formats and then the formats of the QSPEC objects. 712 6.1 General QSPEC Formats: 714 Note: This section is in a first draft state and further work is 715 needed to define exact formats of objects. 717 Type: QSPEC 718 Length: Variable 719 Value: This object contains a 2 byte QOSM ID and variable length 720 QSPEC information, which is QOSM specific. 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | QOSM ID | Length | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Object ID | Parameter ID | Length | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 // Parameter Values // 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Object ID | Parameter ID | Length | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 // Parameter Values // 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 .... 737 Object ID: 738 0: control information 739 1: QoS Desired 740 2: QoS Available 741 3: QoS Reserved 742 4: Min QoS 744 6.2 & Parameters [RFC 2210, 2215] 746 0 1 747 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | NON NSLP Hop | NSLP Hops | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 NON NSLP Hop: 8 bits 753 This field is set to 1 if a non NSLP-aware QNE is encountered on 754 the path from the QNI to the QNR. 756 NSLP Hops: 8 bits 757 Indicates the number of NSLP hops between the QNI and QNR. 758 Values of the composed parameter will range from 1 to 255, 759 limited by the bound specified by the parameter. 761 6.3 Parameter 763 0 1 2 3 4 5 6 7 764 +-+-+-+-+-+-+-+-+ 765 | Max NSLP Hops | 766 +-+-+-+-+-+-+-+-+ 768 Max NSLP Hops: 8 bits 769 Indicates the maximum number of NSLP hops between the QNI and 770 QNR. Values of the composed parameter will range from 1 to 255, 771 limited by the bound on IP hop count. The default value of 772 is 255. 774 6.4 Parameter 776 0 1 2 3 4 5 6 7 777 +-+-+-+-+-+-+-+-+ 778 | Excess | 779 | Treatment | 780 +-+-+-+-+-+-+-+-+ 782 Excess Treatment: 8 bits 783 Indicates how the QNE SHOULD process out-of-profile traffic. 784 Allowed values are as follows: 785 0: drop 786 1: shape 787 2: remark 788 The excess treatment parameter is initially set by the QNI and 789 adjusted as needed by QNEs. 791 6.5 & Parameters [RFC 2212, RFC 2215] 793 The parameter MUST be nonnegative and is measured in 794 bytes per second and has the same range and suggested representation 795 as the bucket and peak rates of the . can 796 be represented using single-precision IEEE floating point. The 797 representation MUST be able to express values ranging from 1 byte per 798 second to 40 terabytes per second. For values of this parameter only 799 valid non-negative floating point numbers are allowed. Negative 800 numbers (including "negative zero"), infinities, and NAN's are not 801 allowed. 803 A QNE MAY export a local value of zero for this parameter. A network 804 element or application receiving a composed value of zero for this 805 parameter MUST assume that the actual bandwidth available is unknown. 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Bandwidth (32-bit IEEE floating point number) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Slack Term [S] (32-bit integer) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Slack term S MUST be nonnegative and is measured in microseconds. 814 The Slack term, S, can be represented as a 32-bit integer. Its value 815 can range from 0 to (2**32)-1 microseconds. 817 6.6 Parameters [RFC 2215] 819 The parameters are represented by three floating 820 Point numbers in single-precision IEEE floating point format followed 821 by two 32-bit integers in network byte order. The first floating 822 point value is the rate (r), the second floating point value is the 823 bucket size (b), the third floating point is the peak rate (p), the 824 first integer is the minimum policed unit (m), and the second integer 825 is the maximum datagram size (M). 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Token Bucket Size [b] (32-bit IEEE floating point number) | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Peak Data Rate [p] (32-bit IEEE floating point number) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Minimum Policed Unit [m] (32-bit integer) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Maximum Packet Size [M] (32-bit integer) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 When r, b, p, and R terms are represented as IEEE floating point 840 values, the sign bit MUST be zero (all values MUST be non-negative). 841 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 842 than 162 (i.e., positive 35) are discouraged, except for specifying a 843 peak rate of infinity. Infinity is represented with an exponent of 844 all ones (255) and a sign bit and mantissa of all zeroes. 846 6.7 Parameters 848 6.7.1 Parameter [RFC 3170] 850 As prescribed in RFC 3170, the encoding for a single PHB is the 851 recommended DSCP value for that PHB, left-justified in the 16 bit 852 field, with bits 6 through 15 set to zero. 854 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 855 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 856 | DSCP | 0 0 0 0 0 0 0 0 0 0 | 857 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 859 The registries needed to use RFC 3140 already exist, see [DSCP- 860 REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs to be 861 created for this purpose. 863 6.7.2 Parameter [Y.1541] 865 Y.1541 QoS classes are defined as follows: 867 0 1 2 3 4 5 6 7 868 +-+-+-+-+-+-+-+-+ 869 | Y.1541 | 870 | QoS Class | 871 +-+-+-+-+-+-+-+-+ 873 Y.1541 QoS Class: 8 bits 874 Indicates the Y.1541 QoS Class. Values currently allowed are 0, 875 1, 2, 3, 4, 5. 877 Class 0: 878 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10-3. 879 Real-time, highly interactive applications, sensitive to jitter. 880 Application examples include VoIP, Video Teleconference. 882 Class 1: 883 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10-3. 884 Real-time, interactive applications, sensitive to jitter. 885 Application examples include VoIP, Video Teleconference. 887 Class 2: 888 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 889 10-3. Highly interactive transaction data. Application examples 890 include signaling. 892 Class 3: 893 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 894 10-3. Interactive transaction data. Application examples include 895 signaling. 897 Class 4: 898 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 10-3. 899 Low Loss Only applications. Application examples include short 900 transactions, bulk data, video streaming. 902 Class 5: 903 Mean delay unspecified, delay variation unspecified, loss ratio 904 unspecified. Unspecified applications. Application examples include 905 traditional applications of default IP networks. 907 6.7.3 Parameter [RFC3564] 909 DSTE class type is defined as follows: 911 0 1 2 3 4 5 6 7 912 +-+-+-+-+-+-+-+-+ 913 | DSTE | 914 | Class Type | 915 +-+-+-+-+-+-+-+-+ 917 DSTE Class Type: 8 bits 918 Indicates the DSTE class type. Values currently allowed are 0, 1, 919 2, 3, 4, 5, 6, 7. 921 6.8 Priority Parameters 923 6.8.1 & Parameters 924 [RFC 3181] 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Preemption Priority | Defending Priority | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Preemption Priority: 16 bits (unsigned) 933 The priority of the new flow compared with the defending priority 934 of previously admitted flows. Higher values represent higher 935 priority. 937 Defending Priority: 16 bits (unsigned) 939 6.8.2 Parameter [SIP-PRIORITY] 941 0 1 942 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Reservation | Reservation | 945 | Priority | Priority | 946 | Namespace | | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 High priority flows, normal priority flows, and best-effort priority 950 flows can have access to resources depending on their {"Namespace", 951 "Reservation Priority"} combination as follows: 953 Reservation Priority Namespace: 8 bits 954 0 - dsn high priority 955 1 - drsn high priority 956 2 - q735 high priority 957 3 - ets high priority 958 4 - wps high priority 959 5 - normal priority 960 6 - best-effort priority 962 Reservation Priority: 8 bits 963 Each namespace has a finite list of relative priority-values. Each 964 is listed here in the order of lowest priority to highest priority: 966 4 - dsn.routine 967 3 - dsn.priority 968 2 - dsn.immediate 969 1 - dsn.flash 970 0 - dsn.flash-override 972 5 - drsn.routine 973 4 - drsn.priority 974 3 - drsn.immediate 975 2 - drsn.flash 976 1 - drsn.flash-override 977 0 - drsn.flash-override-override 979 4 - q735.4 980 3 - q735.3 981 2 - q735.2 982 1 - q735.1 983 0 - q735.0 985 4 - ets.4 986 3 - ets.3 987 2 - ets.2 988 1 - ets.1 989 0 - ets.0 990 4 - wps.4 991 3 - wps.3 992 2 - wps.2 993 1 - wps.1 994 0 - wps.0 996 0 - normal.0 998 0 - best.effort.0 1000 Note that additional work is needed to communicate these flow 1001 priority values to bearer-level network elements 1002 [VERTICAL-INTERFACE]. 1004 6.9 Parameters 1006 6.9.1 Parameter [RFC 2210, 2215] 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Path Latency (32-bit integer) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 The composition rule for the parameter is summation 1015 with a clamp of (2**32 - 1) on the maximum value. The latencies are 1016 reported in units of one microsecond. An individual QNE can advertise 1017 a latency value between 1 and 2**28 (somewhat over two minutes) and 1018 the total latency added across all QNEs can range as high as 1019 (2**32)-2. If the sum of the different elements delays exceeds 1020 (2**32)-2, the end-to-end advertised delay SHOULD be reported as 1021 indeterminate. The distinguished value (2**32)-1 is taken to mean 1022 indeterminate latency. A QNE that cannot accurately predict the 1023 latency of packets it is processing SHOULD set its local parameter 1024 to this value. Because the composition function limits the composed 1025 sum to this value, receipt of this value at a network element or 1026 application indicates that the true path latency is not known. This 1027 MAY happen because one or more network elements could not supply a 1028 value, or because the range of the composition calculation was 1029 exceeded. 1031 6.9.2 Parameter 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Path Jitter (32-bit integer) | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 The composition rule for the parameter is summation 1040 with a clamp of (2**32 - 1) on the maximum value. The jitters are 1041 reported in units of one microsecond. An individual QNE can advertise 1042 a jitter value between 1 and 2**28 (somewhat over two minutes) and 1043 the total jitter added across all QNEs can range as high as 1044 (2**32)-2. If the sum of the different elements delays exceeds 1045 (2**32)-2, the end-to-end advertised jitter SHOULD be reported as 1046 indeterminate. The distinguished value (2**32)-1 is taken to mean 1047 indeterminate jitter. A QNE which cannot accurately predict the 1048 jitter of packets it is processing SHOULD set its local parameter 1049 to this value. Because the composition function limits the composed 1050 sum to this value, receipt of this value at a network element or 1051 application indicates that the true path jitter is not known. This 1052 MAY happen because one or more network elements could not supply a 1053 value, or because the range of the composition calculation was 1054 exceeded. 1056 6.9.3 Parameter 1058 0 1 2 3 1059 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 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Path Bit Error Rate (32-bit integer) | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 The composition rule for the parameter is summation with 1065 a clamp of 10^-2 on the maximum value. The BERs are reported in 1066 units of 10^-11. An individual QNE can advertise a BER value between 1067 1 and 2**28 and the total BER added across all QNEs can range as high 1068 as (2**32)-2. If the sum of the different elements delays exceeds 1069 (2**32)-2, the end-to-end advertised BER SHOULD be reported as 1070 indeterminate. The distinguished value (2**32)-1 is taken to mean 1071 indeterminate BER. A QNE which cannot accurately predict the BER of 1072 packets it is processing SHOULD set its local parameter to this 1073 value. Because the composition function limits the composed sum to 1074 this value, receipt of this value at a network element or application 1075 indicates that the true path BER is not known. This MAY happen 1076 because one or more network elements could not supply a value, or 1077 because the range of the composition calculation was exceeded. 1079 6.9.4 Parameters [RFC 2210, 2212, 2215] 1081 0 1 2 3 1082 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 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | End-to-end composed value for C [Ctot] (32-bit integer) | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | End-to-end composed value for D [Dtot] (32-bit integer) | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Since-last-reshaping point composed C [Csum] (32-bit integer) | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 The error term C is measured in units of bytes. An individual QNE 1094 can advertise a C value between 1 and 2**28 (a little over 250 1095 megabytes) and the total added over all QNEs can range as high as 1096 (2**32)-1. Should the sum of the different QNEs delay exceed 1097 (2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The 1098 error term D is measured in units of one microsecond. An individual 1099 QNE can advertise a delay value between 1 and 2**28 (somewhat over 1100 two minutes) and the total delay added over all QNEs can range as 1101 high as (2**32)-1. Should the sum of the different QNEs delay 1102 exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1. 1104 7. Security Considerations 1106 The priority parameter raises possibilities for Theft of Service 1107 Attacks because users could claim an emergency priority for their 1108 flows without real need, thereby effectively preventing serious 1109 emergency calls to get through. Several options exist for countering 1110 such attacks, for example 1112 - only some user groups (e.g. the police) are authorized to set the 1113 emergency priority bit 1115 - any user is authorized to employ the emergency priority bit for 1116 particular destination addresses (e.g. police) 1118 8. IANA Considerations 1120 This section provides guidance to the Internet Assigned Numbers 1121 Authority (IANA) regarding registration of values related to the 1122 QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 1124 [QoS-SIG] requires IANA to create a new registry for QoS Signaling 1125 Policy Identifiers. The QoS Signaling Policy Identifier (QOSM ID) is 1126 a 32 bit value carried in a QSPEC object. The allocation policy for 1127 new QOSM IDs is TBD. 1129 This document also defines 24 objects for the QSPEC Template, as 1130 Detailed in Section 5. Values are to be assigned for them from the 1131 GIMPS Object Type registry. 1133 9. Acknowledgements 1135 The authors would like to thank David Black, Robert Hancock, Dave 1136 Oran, Tom Phelan, Hannes Tschofenig, and Sven van den Bosch, for 1137 their very helpful suggestions. 1139 10. Intellectual Property Considerations 1141 The IETF takes no position regarding the validity or scope of any 1142 Intellectual Property Rights or other rights that might be claimed 1143 to pertain to the implementation or use of the technology described 1144 in this document or the extent to which any license under such 1145 rights might or might not be available; nor does it represent that 1146 it has made any independent effort to identify any such rights. 1147 Information on the procedures with respect to rights in RFC 1148 documents can be found in BCP 78 and BCP 79. 1150 Copies of IPR disclosures made to the IETF Secretariat and any 1151 assurances of licenses to be made available, or the result of an 1152 attempt made to obtain a general license or permission for the use 1153 of such proprietary rights by implementers or users of this 1154 specification can be obtained from the IETF on-line IPR repository 1155 at http://www.ietf.org/ipr. 1157 The IETF invites any interested party to bring to its attention any 1158 copyrights, patents or patent applications, or other proprietary 1159 rights that may cover technology that may be required to implement 1160 this standard. Please address the information to the IETF at ietf- 1161 ipr@ietf.org. 1163 11. Normative References 1165 [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry 1166 [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes 1167 [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 1168 Signaling," work in progress. 1169 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, March 1997. 1171 [RFC2205] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) 1172 -- Version 1 Functional Specification," RFC 2205, September 1997. 1173 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1174 Services", RFC 2210, September 1997. 1175 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 1176 Network Element Service", RFC 2211, Sept. 1997. 1177 [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality 1178 of Service," September 1997. 1179 [RFC2215] S. Shenker and J. Wroclawski, "General Characterization 1180 Parameters for Integrated Service Network Elements", RFC 2215, Sept. 1181 1997. 1182 [RFC2475] S. Blake et. al., "An Architecture for Differentiated 1183 Services", RFC 2475, December 1998. 1185 12. Informative References 1187 [CMSS] "PacketCable (TM) CMS to CMS Signaling Specification, 1188 PKT-SP-CMSS-103-040402, April 2004. 1189 [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines 1190 for DiffServ Service Classes," work in progress. 1191 [INTSERV-QOSM] C. Kappler, "A QoS Model for Signaling IntServ 1192 Controlled-Load Service with NSIS," work in progress. 1193 [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 1194 Protocol - Capability Set 3" Sep. 2003 1195 [RFC1633] B. Braden et. al., "Integrated Services in the Internet 1196 Architecture: an Overview," RFC 1633, June 1994. 1197 [RFC3393] C. Demichelis, P. Chimento, "IP Packet Delay Variation 1198 Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. 1199 [RFC3564] F. Le Faucheur et. al., Requirements for Support of 1200 Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 1201 July 2003 1202 [RFC3726] M. Brunner et. al., "Requirements for Signaling Protocols", 1203 RFC 3726, April 2004. 1204 [RMD-QOSM] A. Bader, L. Westberg, G. Karagiannis, C. Kappler and T. 1205 Phelan, " RMD-QOSM: An NSIS QoS Signaling Policy Model for Networks 1206 Using Resource Management in Diffserv (RMD)," work in progress. 1207 [SIP-PRIORITY] H. Schulzrinne, J. Polk, "Communications Resource 1208 Priority for the Session Initiation Protocol(SIP)." work in 1209 progress. 1210 [VERTICAL-INTERFACE] M. Dolly, P. S. Tarapore, S. Sayers, 1211 "Discussion on Associating of Control Signaling Messages with Media 1212 Priority Levels," T1S1.7 & PRQC, October 2004. 1214 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 1215 Objectives for IP-Based Services," May 2002. 1216 [Y.1541-QOSM] J. Ash, et. al., "NSIS Network Service Layer Protocol 1217 QoS Signaling Proof-of-Concept," work in progress. 1219 13. Authors' Addresses 1221 Jerry Ash 1222 AT&T 1223 Room MT D5-2A01 1224 200 Laurel Avenue 1225 Middletown, NJ 07748, USA 1226 Phone: +1-(732)-420-4578 1227 Fax: +1-(732)-368-8659 1228 EMail: gash@att.com 1230 Attila Bader 1231 Traffic Lab 1232 Ericsson Research 1233 Ericsson Hungary Ltd. 1234 Laborc u. 1 H-1037 1235 Budapest Hungary 1236 EMail: Attila.Bader@ericsson.com 1238 Chuck Dvorak 1239 AT&T 1240 Room 2A37 1241 180 Park Avenue, Building 2 1242 Florham Park, NJ 07932 1243 Phone: + 1 973-236-6700 1244 Fax:+1 973-236-7453 1245 E-mail: cdvorak@att.com 1247 Yacine El Mghazli 1248 Alcatel 1249 Route de Nozay 1250 91460 Marcoussis cedex 1251 FRANCE 1252 Phone: +33 1 69 63 41 87 1253 EMail: yacine.el_mghazli@alcatel.fr 1255 Cornelia Kappler 1256 Siemens AG 1257 Siemensdamm 62 1258 Berlin 13627 1259 Germany 1260 EMail: cornelia.kappler@siemens.com 1262 Georgios Karagiannis 1263 University of Twente 1264 P.O. BOX 217 1265 7500 AE Enschede 1266 The Netherlands 1267 EMail: g.karagiannis@ewi.utwente.nl 1268 Andrew McDonald 1269 Siemens/Roke Manor Research 1270 Roke Manor Research Ltd. 1271 Romsey, Hants SO51 0ZN 1272 UK 1273 EMail: andrew.mcdonald@roke.co.uk 1275 Al Morton 1276 AT&T 1277 Room D3-3C06 1278 200 S. Laurel Avenue 1279 Middletown, NJ 07748 1280 Phone: + 1 732 420-1571 1281 Fax: +.1 732 368-1192 1282 E-mail: acmorton@att.com 1284 Percy Tarapore 1285 AT&T 1286 Room D1-33 1287 200 S. Laurel Avenue 1288 Middletown, NJ 07748 1289 Phone: + 1 732 420-4172 1290 E-mail: tarapore@.att.com 1292 Lars Westberg 1293 Ericsson Research 1294 Torshamnsgatan 23 1295 SE-164 80 Stockholm, Sweden 1296 EMail: Lars.Westberg@ericsson.com 1298 Appendix A: Example QSPECs 1300 Note the mere definition of QSPECs is not sufficient for determining 1301 how to signal for DiffServ and IntServ respectively. Rather, the full 1302 QOSM needs to be defined. 1304 A.1 QSPEC for Admission Control for DiffServ 1306 QSPEC for Diffserv QOSM in general may be provided in future versions 1307 of this draft. A QSPEC for a DiffServ QOSM is included in 1308 [RMD-QOSM]. 1310 A.2 QSPEC for IntServ Controlled Load Service 1312 The QoS Model for IntServ Controlled Load is defined in [RFC2211]. 1313 The QSPEC can be derived from usage of RSVP to signal for this QoS 1314 Model, as defined in [RFC2210] and [RFC2215]. 1316 The QSPEC for IntServ Controlled Load is composed of the objects 1317 and , as well as . Which 1318 object is present in a particular QSPEC depends on the message 1319 type (RESERVE, QUERY etc) in which the QSPEC travels. Details MUST 1320 be provided in a corresponding QOSM. Parameters in the QSPEC are as 1321 follows: 1323 = 1324 = 1325 = 1326 = 1327 = 1329 An IntServ over Diffserv QSPEC is 1331 = 1332 = 1333 = 1334 = 1335 = 1337 Or a simple QSPEC for Diffserv requesting bandwidths for different 1338 PHBs is 1340 = 1341 = 1343 A.3 QSPEC for IntServ Guaranteed Services 1345 The QoS Model is defined in [RFC 2212]. The required parameters to 1346 achieve guarantied service with RSVP are specified in [RFC 2210] and 1347 [RFC 2215]. 1349 The QSPEC for guaranteed services is the following: 1351 = 1352 = 1353 = 1355 This object contains token bucket parameters defined in [RFC 2210]. 1356 (equivalent to TSpec defined in RSVP). 1358 = 1359 1361 These parameters are defined in [RFC 2212] and [RFC 2215]. This 1362 object is equivalent to the AdSpec of RSVP. 1364 = 1365 Requested Rate and Slack Term defined in [RFC 2212], equivalent to 1366 RSpec of RSVP. 1368 Note that the Guaranteed Services QoS Model only works with receiver 1369 initiated reservation signaling, because and are 1370 derived from parameters contained in , and MAY be 1371 updated on the return paths. 1373 Appendix B: QoS Models and QSPECs 1375 This Appendix gives a description of QoS Models and QSPECs and 1376 explains what is the relation between them. Once these descriptions 1377 are contained in a stable form in the appropriate IDs this Appendix 1378 will be removed. 1380 QoS NSLP is a generic QoS signaling protocol that can signal for many 1381 QOSMs. A QOSM is a particular QoS provisioning method or QoS 1382 architecture such as IntServ Controlled Load or Guaranteed Service, 1383 DiffServ, or RMD for DiffServ. 1385 The definition of the QOSM is independent from the definition of QoS 1386 NSLP. Existing QOSMs do not specify how to use QoS NSLP to signal 1387 for them. Therefore, we need to define the QOSM specific signaling 1388 functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM]. 1390 A QOSM SHOULD include the following information: 1392 - Role of QNEs in this QOSM: 1393 E.g. location, frequency, statefulness... 1394 - QSPEC Definition: 1395 A QOSM SHOULD specify the QSPEC, including QSPEC parameters. 1396 Furthermore it needs to explain how QSPEC parameters not used in this 1397 QOSM are mapped onto parameters defined therein. 1398 - Message Format 1399 Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY 1400 - State Management 1401 It describes how QSPEC info is treated and interpreted in the 1402 RMF and QOSM specific processing. E.g. 1403 admission control, scheduling, policy control, QoS parameter 1404 accumulation (e.g. delay). 1405 - Operation and Sequence of Events 1406 Usage of QoS-NSLP messages to signal the QOSM. 1408 Appendix C: Mapping of QoS Desired, QoS Available and QoS Reserved of 1409 NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ 1411 The union of QoS Desired, QoS Available and QoS Reserved can provide 1412 all functionality of the objects specified in RSVP IntServ, however 1413 it is difficult to provide an exact mapping. 1415 In RSVP, the Sender TSpec specifies the traffic an application is 1416 going to send (e.g. token bucket). The AdSpec can collect path 1417 characteristics (e.g. delay). Both are issued by the sender. The 1418 receiver sends the FlowSpec which includes a Receiver TSpec 1419 describing the resources reserved using the same parameters as the 1420 Sender TSpec, as well as a RSpec which provides additional IntServ 1421 QoS Model specific parameters, e.g. Rate and Slack. 1423 The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated 1424 signaling employed by RSVP, and the IntServ QoS Model. E.g. to the 1425 knowledge of the authors it is not possible for the sender to specify 1426 a desired maximum delay except implicitly and mutably by seeding the 1427 AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in 1428 the receiver-issued RSVP RESERVE message. For this reason our 1429 discussion at this point leads us to a slightly different mapping of 1430 necessary functionality to objects, which should result in more 1431 flexible signaling models. 1433 Full Copyright Statement 1435 Copyright (C) The Internet Society (2005). This document is subject 1436 to the rights, licenses and restrictions contained in BCP 78 and 1437 except as set forth therein, the authors retain all their rights. 1439 This document and the information contained herein are provided on an 1440 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1441 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1442 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1443 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1444 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1445 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1447 Disclaimer of Validity 1449 This document and the information contained herein are provided on 1450 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1451 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1452 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1453 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1454 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.