idnits 2.17.1 draft-ietf-nsis-y1541-qosm-06.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2008) is 5900 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'QoS-SIG' is mentioned on line 411, but not defined == Missing Reference: 'QSPEC' is mentioned on line 545, but not defined == Missing Reference: 'Bp' is mentioned on line 496, but not defined == Missing Reference: 'M' is mentioned on line 498, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-16 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-18 == Outdated reference: A later version (-09) exists of draft-ietf-ippm-framework-compagg-06 == Outdated reference: A later version (-16) exists of draft-ietf-ippm-spatial-composition-05 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Ash 3 Internet-Draft A. Morton 4 Intended status: Informational M. Dolly 5 Expires: August 27, 2008 P. Tarapore 6 C. Dvorak 7 AT&T Labs 8 Y. El Mghazli 9 Alcatel-Lucent 10 February 24, 2008 12 Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes 13 draft-ietf-nsis-y1541-qosm-06 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 27, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T 47 Recommendation Y.1541 Network QoS Classes and related signaling 48 requirements. Y.1541 specifies 8 classes of Network Performance 49 objectives, and the Y.1541-QOSM extensions include additional QSPEC 50 parameters and QOSM processing guidelines. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Summary of ITU-T Recommendations Y.1541 & Signaling 62 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Y.1541 Classes . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Y.1541-QOSM Processing Requirements . . . . . . . . . . . 5 65 3. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . 6 66 3.1. Traffic Model (TMOD) Extension Parameter . . . . . . . . . 6 67 3.2. Restoration Priority Parameter . . . . . . . . . . . . . . 7 68 4. Y.1541-QOSM Considerations and Processing Example . . . . . . 8 69 4.1. Deployment Considerations . . . . . . . . . . . . . . . . 8 70 4.2. Applicable QSPEC Procedures . . . . . . . . . . . . . . . 9 71 4.3. QNE Processing Rules . . . . . . . . . . . . . . . . . . . 9 72 4.4. Processing Example . . . . . . . . . . . . . . . . . . . . 9 73 4.5. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . 11 74 4.6. Preemption Behaviour . . . . . . . . . . . . . . . . . . . 12 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Intellectual Property and Copyright Statements . . . . . . . . . . 17 84 1. Introduction 86 This draft describes a QoS model (QOSM) for NSIS QoS signaling layer 87 protocol (QoS-NSLP) application based on ITU-T Recommendation Y.1541 88 Network QoS Classes and related signaling requirements. Y.1541 89 [Y.1541] currently specifies 8 classes of Network Performance 90 objectives, and the Y.1541-QOSM extensions include additional QSPEC 91 parameters and QOSM processing guidelines. The extensions are based 92 on standardization work in the ITU-T on QoS signaling requirements 93 [Y.1541] [TRQ-QoS-SIG] [E.361]. 95 [QoS-SIG] [I-D.ietf-nsis-qos-nslp] defines message types and control 96 information for the QoS-NSLP generic to all QOSMs. A QOSM is a 97 defined mechanism for achieving QoS as a whole. The specification of 98 a QOSM includes a description of its QSPEC parameter information, as 99 well as how that information should be treated or interpreted in the 100 network. The QSPEC [QSPEC] [I-D.ietf-nsis-qspec] contains a set of 101 parameters and values describing the requested resources. It is 102 opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and 103 AdSpec specified in [RFC2205, RFC2210] [RFC2205] [RFC2210] . The 104 QSPEC object contains the QoS parameters defined by the QOSM. A QOSM 105 provides a specific set of parameters to be carried in the QSPEC. At 106 each QoS NSIS element (QNE), the QSPEC contents are interpreted by 107 the resource management function (RMF) for purposes of policy control 108 and traffic control, including admission control and configuration of 109 the scheduler. 111 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements 113 As stated above, [Y.1541] [Y.1541] is a specification of standardized 114 QoS classes for IP networks (a summary of these classes is given 115 below). [TRQ-QoS-SIG] [TRQ-QoS-SIG] specifies the requirements for 116 achieving end-to-end QoS in IP networks, with Y.1541 QoS classes as a 117 basis. [Y.1541] [Y.1541] recommends a flexible allocation of the 118 end-to-end performance objectives (e.g., delay) across networks, 119 rather than a fixed per-network allocation. NSIS protocols already 120 address most of the requirements, this document identifies additional 121 QSPEC parameters and processing requirements needed to support the 122 Y.1541 QOSM. 124 2.1. Y.1541 Classes 126 [Y.1541] [Y.1541] proposes grouping services into QoS classes defined 127 according to the desired QoS performance objectives. These QoS 128 classes support a wide range of user applications. The classes group 129 objectives for one-way IP packet delay, IP packet delay variation, IP 130 packet loss ratio, etc., where the parameters themselves are defined 131 in [Y.1540]. Classes 0 and 1 might be implemented using the DiffServ 132 EF PHB, and support interactive real-time applications. Classes 2, 133 3, and 4 might be implemented using the DiffServ AFxy PHB Group, and 134 support data transfer applications with various degrees of 135 interactivity. Class 5 generally corresponds to the DiffServ Default 136 PHB, has all the QoS parameters unspecified consistent with a best- 137 effort service. Classes 6 and 7 provide support for extremely loss- 138 sensitive user applications, such as high quality digital television, 139 TDM circuit emulation, and high capacity file transfers using TCP. 140 These classes are intended to serve as a basis for agreements between 141 end-users and service providers, and between service providers. They 142 support a wide range of user applications including point-to-point 143 telephony, data transfer, multimedia conferencing, and others. The 144 limited number of classes supports the requirement for feasible 145 implementation, particularly with respect to scale in global 146 networks. 148 The QoS classes apply to a packet flow, where [Y.1541] [Y.1541] 149 defines a packet flow as the traffic associated with a given 150 connection or connectionless stream having the same source host, 151 destination host, class of service, and session identification. The 152 characteristics of each Y.1451 QoS class are summarized here: 154 Class 0: Real-time, highly interactive applications, sensitive to 155 jitter. Mean delay upper bound is 100 ms, delay variation is less 156 than 50 ms, and loss ratio is less than 10^-3. Application examples 157 include VoIP, Video Teleconference. 159 Class 1: Real-time, interactive applications, sensitive to jitter. 160 Mean delay upper bound is 400 ms, delay variation is less than 50 ms, 161 and loss ratio is less than 10^-3. Application examples include 162 VoIP, video teleconference. 164 Class 2: Highly interactive transaction data. Mean delay upper bound 165 is 100 ms, delay variation is unspecified, and loss ratio is less 166 Than 10^-3. Application examples include signaling. 168 Class 3: Interactive transaction data. Mean delay upper bound is 400 169 ms, delay variation is unspecified, and loss ratio is less than 170 10^-3. Application examples include signaling. 172 Class 4: Low Loss Only applications. Mean delay upper bound is 1s, 173 delay variation is unspecified, and loss ratio is less than 10^-3. 174 Application examples include short transactions, bulk data, video 175 streaming 177 Class 5: Unspecified applications with unspecified mean delay, delay 178 variation, and loss ratio. Application examples include traditional 179 applications of Default IP Networks 181 Class 6: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio 182 <= 10^-5. Applications that are highly sensitive to loss, such as 183 television transport, high-capacity TCP transfers, and TDM circuit 184 emulation. 186 Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio 187 <= 10^-5. Applications that are highly sensitive to loss, such as 188 television transport, high-capacity TCP transfers, and TDM circuit 189 emulation. 191 These classes enable SLAs to be defined between customers and network 192 service providers with respect to QoS requirements. The service 193 provider then needs to ensure that the requirements are recognized 194 and receive appropriate treatment across network layers. 196 Work is in progress to specify methods for combining local values of 197 performance metrics to estimate the performance of the complete path. 198 See section 8 of [Y.1541], [I-D.ietf-ippm-framework-compagg], and 199 [I-D.ietf-ippm-spatial-composition]. 201 2.2. Y.1541-QOSM Processing Requirements 203 [TRQ-QoS-SIG] [TRQ-QoS-SIG] provides the requirements for signaling 204 information regarding IP-based QoS at the interface between the user 205 and the network (UNI) and across interfaces between different 206 networks (NNI). To meet specific network performance requirements 207 specified for the Y.1541 QoS classes [Y.1541] , a network needs to 208 provide specific user plane functionality at UNI and NNI interfaces. 209 Dynamic network provisioning at a UNI and/or NNI node allows the 210 ability to dynamically request a traffic contract for an IP flow from 211 a specific source node to one or more destination nodes. In response 212 to the request, the network determines if resources are available to 213 satisfy the request and provision the network. 215 It MUST be possible to derive the following service level parameters 216 as part of the process of requesting service: 218 a. Y.1541 QoS class 220 b. rate (r) 222 c. peak rate (p) 224 d. bucket size (b) 226 e. peak bucket size (Bp)* 227 f. maximum packet size (M)* 229 g. DiffServ PHB class [RFC2475] [RFC2475] 231 h. admission priority 233 i. restoration priority* 235 All parameters except Bp, M, and restoration priority have already 236 been specified in [QSPEC] [I-D.ietf-nsis-qspec]. These additional 237 parameters are specified in Section 3. 239 It MUST be possible to perform the following QoS-NSLP signaling 240 functions to meet Y.1541-QOSM requirements: 242 a. accumulate delay, delay variation and loss ratio across the end- 243 to-end connection, which may span multiple domains 245 b. enable negotiation of Y.1541 QoS class across domains. 247 c. enable negotiation of delay, delay variation, and loss ratio 248 across domains. 250 These signaling requirements are already supported by [QoS-SIG] 251 [I-D.ietf-nsis-qos-nslp] and the functions are illustrated in Section 252 4. 254 3. Additional QSPEC Parameters for Y.1541 QOSM 256 3.1. Traffic Model (TMOD) Extension Parameter 258 The traffic model (TMOD) extension parameter is represented by one 259 floating point number in single-precision IEEE floating point format 260 and one 32-bit unsigned integer. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |M|E|N|r| 15 |r|r|r|r| 2 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Maximum Packet Size [M] (32-bit unsigned integer) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 1: TMOD Extension 274 When the Bp term is represented as an IEEE floating point value, the 275 sign bit MUST be zero (all values MUST be non-negative). Exponents 276 less than 127 (i.e., 0) are prohibited. Exponents greater than 162 277 (i.e., positive 35) are discouraged, except for specifying a peak 278 rate of infinity. Infinity is represented with an exponent of all 279 ones (255) and a sign bit and mantissa of all zeros. The maximum 280 packet size (M) is an unsigned integer. 282 The QSPEC parameter behavior for (Bp) and (M) is similar to that 283 defined in [QSPEC] [I-D.ietf-nsis-qspec], section 6.2.1 and 6.2.2. 284 The new parameters (and all traffic-related parameters) are specified 285 independently from the Y.1541 class parameter. 287 3.2. Restoration Priority Parameter 289 Restoration priority is the urgency with which a service requires 290 successful restoration under failure conditions. Restoration 291 priority is achieved by provisioning sufficient backup capacity, as 292 necessary, and allowing relative priority for access to available 293 bandwidth when there is contention for restoration bandwidth. 294 Restoration priority is defined as follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |M|E|N|r| 16 |r|r|r|r| 1 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Rest. Priority| (Reserved) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 2: Restoration Priority 306 Restoration Priority: 3 priority values are listed here in the order 307 of lowest priority to highest priority: 309 0 - best effort 310 1 - normal 312 2 - high 314 Each restoration priority class has two parameters: 316 a. Time-to-Restore: Total amount of time to restore traffic streams 317 belonging to a given restoration class impacted by the failure. This 318 time period depends on the technology deployed for restoration. A 319 fast recovery period of < 200 ms is based on current experience with 320 SONET rings and a slower recovery period of 2 seconds is suggested in 321 order to enable a voice call to recover without being dropped. 322 Accordingly, candidate restoration objectives are: 324 High Restoration Priority: Time-to-Restore <= 200 ms 326 Normal Restoration Priority: Time-to-Restore <= 2 s 328 Best Effort Restoration Priority: Time-to-Restore = Unspecified 330 b. Extent of Restoration: Percentage of traffic belonging to the 331 restoration class that can be restored. This percentage depends on 332 the amount of spare capacity engineered. All high priority 333 restoration priority traffic, for example, may be "guaranteed" at 334 100% by the service provider. Other classes may offer lesser chances 335 for successful restoration. The restoration extent for these lower 336 priority classes depend on SLA agreements developed between the 337 service provider and the customer. 339 4. Y.1541-QOSM Considerations and Processing Example 341 In this Section we illustrate the operation of the Y.1541 QOSM, and 342 show how current QoS-NSLP and QSPEC functionality is used. No new 343 processing capabilities or parameters (except those described in 344 section 3) are required to enable the Y.1541 QOSM. 346 4.1. Deployment Considerations 348 [TRQ-QoS-SIG] emphasizes the deployment of Y.1541 QNEs at the borders 349 of supporting domains. There may be domain configurations where 350 interior QNEs are desirable, and the example below addresses this 351 possibility. 353 QNEs may be Stateful in some limited aspects, but obviously it is 354 preferable to deploy stateless QNEs. 356 4.2. Applicable QSPEC Procedures 358 All procedures defined in section 5.3 of [QSPEC] 359 [I-D.ietf-nsis-qspec] are applicable to this QOSM. 361 4.3. QNE Processing Rules 363 [TRQ-QoS-SIG] describes the information processing in Y.1541 QNEs. 365 [Y.1541] section 8 defines the accumulation rules for individual 366 performance parameters (e.g., delay, jitter). 368 When a QNI specifies the Y.1541 QoS Class number, , 369 it is a sufficient specification of objectives for the , , and parameters. As described 371 above in section 2, some Y.1541 Classes do not set objectives for all 372 the performance parameters above. For example, Classes 2, 3, and 4, 373 do not specify an objective for (referred to as IP 374 Packet Delay Variation). In the case that the QoS Class leaves a 375 parameter Unspecified, then that parameter need not be included in 376 the accumulation processing. 378 4.4. Processing Example 380 As described in the example given in [QSPEC] [I-D.ietf-nsis-qspec] 381 (Section 4.4) and as illustrated in Figure 3, the QoS NSIS initiator 382 (QNI) initiates an end-to-end, inter-domain QoS NSLP RESERVE message 383 containing the Initiator QSPEC. In the case of the Y.1541 QOSM, the 384 Initiator QSPEC specifies the , , , , , and perhaps 386 other QSPEC parameters for the flow. As described in Section 3, the 387 TMOD extension parameter contains the optional, Y.1541-QOSM-specific 388 parameters Bp and M; restoration priority is also an optional, 389 Y.1541-QOSM-specific parameter. 391 As illustrated in Figure 3, the RESERVE message may cross multiple 392 domains supporting different QOSMs. In this illustration, the 393 initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress 394 node of the local-QOSM domain. As described in [QoS-SIG] 395 [I-D.ietf-nsis-qos-nslp] and [QSPEC] [I-D.ietf-nsis-qspec], at the 396 ingress edge node of the local-QOSM domain, the end-to-end, inter- 397 domain QoS-NSLP message may trigger the generation of a local QSPEC, 398 and the initiator QSPEC encapsulated within the messages signaled 399 through the local domain. The local QSPEC is used for QoS processing 400 in the local-QOSM domain, and the Initiator QSPEC is used for QoS 401 processing outside the local domain. As specified in [QSPEC] 402 [I-D.ietf-nsis-qspec], if any QNE cannot meet the requirements 403 designated by the initiator QSPEC to support an optional QSPEC 404 parameter, with the M bit set to zero for the parameter, for example, 405 it cannot support the accumulation of end-to-end delay with the parameter, the QNE sets the N flag (not supported flag) for 407 the path latency parameter to one. 409 Also, the Y.1541-QOSM requires negotiation of the 410 across domains. This negotiation can be done with the use of the 411 existing procedures already defined in [QoS-SIG] 412 [I-D.ietf-nsis-qos-nslp]. For example, the QNI sets , 413 , objects to include , 414 which specifies objectives for the , , 415 parameters. In the case that the QoS Class leaves a 416 parameter Unspecified, then that parameter need not be included in 417 the accumulation processing. The QNE/domain SHOULD set the Y.1541 418 class and cumulative parameters, e.g., , that can be 419 achieved in the object (but not less than specified 420 in ). This could include, for example, setting the 421 to a lower class than specified in 422 (but not lower than specified in ). If the fails to satisfy one or more of the objectives, 424 the QNE/domain notifies the QNI and the reservation is aborted. 425 Otherwise, the QNR notifies the QNI of the for the 426 reservation. 428 When the available must be reduced from the 429 desired , say because the delay objective has been 430 exceeded, then there is an incentive to respond with an available 431 value for delay in the parameter. If the available 432 is 150 ms (still useful for many applications) and the 433 desired QoS is Class 0 (with its 100 ms objective), then the response 434 would be that Class 0 cannot be achieved and Class 1 is available 435 (with its 400 ms objective). In addition, this QOSM allows the 436 response to include an available = 150 ms, making 437 acceptance of the available more likely. There 438 are many long paths where the propagation delay alone exceeds the 439 Y.1541 Class 0 objective, so this feature adds flexibility to commit 440 to exceed the Class 1 objective when possible. 442 This example illustrates Y.1541-QOSM negotiation of and cumulative parameter values that can be achieve end-to- 444 end. The example illustrates how the QNI can use the cumulative 445 values collected in to decide if a lower than specified in is acceptable. 448 |------| |------| |------| |------| 449 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 450 | QOSM | | QOSM | | QOSM | | QOSM | 451 | | |------| |-------| |-------| |------| | | 452 | NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | 453 |Y.1541| |local | |local | |local | |local | |Y.1541| 454 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 455 |------| |------| |-------| |-------| |------| |------| 456 ----------------------------------------------------------------- 457 |------| |------| |-------| |-------| |------| |------| 458 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 459 |------| |------| |-------| |-------| |------| |------| 460 QNI QNE QNE QNE QNE QNR 461 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 463 Figure 3: Example of Y.1541-QOSM Operation 465 4.5. Bit-Level QSPEC Example 467 This is an example where the QOS Desired specification contains the 468 TMOD-1 parameters and TMOD extended parameters defined in this 469 specification, as well as the Y.1541 Class parameter. The QOS 470 Available specification utilizes the Latency, Jitter, and Loss 471 parameters to enable accumulation of these parameters for easy 472 comparison with the objectives desired fir the Y.1541 Class. 474 This example assumes that all the parameters MUST be supported by the 475 QNEs, so all M flags have been set to "1". 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Vers.|QType=I|QSPEC Proc.=0/1|0|R|R|R| Length = 23 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 10 | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |1|E|0|r| ID = 1 |r|r|r|r| Length = 4 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 |1|E|N|r| 15 |r|r|r|r| 2 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Maximum Packet Size [M] (32-bit unsigned integer) | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 |1|E|N|r| 14 |r|r|r|r| 1 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 |Y.1541 QoS Cls.| (Reserved) | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 |E|r|r|r| Type = 1 (QoS Avail) |r|r|r|r| Length = 11 | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |1|E|N|r| 3 |r|r|r|r| 1 | 507 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 508 | Path Latency (32-bit integer) | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |1|E|N|r| 4 |r|r|r|r| 4 | 511 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 512 | Path Jitter STAT1(variance) (32-bit integer) | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Path Jitter STAT4(Reserved) (32-bit integer) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |1|E|N|r| 5 |r|r|r|r| 1 | 521 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 522 | Path Packet Loss Ratio (32-bit floating point) | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |1|E|N|r| 14 |r|r|r|r| 1 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |Y.1541 QoS Cls.| (Reserved) | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Figure 4: An Example QSPEC (Initiator) 531 4.6. Preemption Behaviour 533 The default QNI behaviour of tearing down a preempted reservation is 534 followed in the Y.1541 QOSM. The restoration priority parameter 535 described above does not rely on preemption. 537 5. IANA Considerations 539 This section defines the registries and initial codepoint assignments 540 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 541 It also defines the procedural requirements to be followed by IANA in 542 allocating new codepoints. 544 This document specifies the following QSPEC parameters to be assigned 545 within the QSPEC Parameter ID registry created in [QSPEC] 546 [I-D.ietf-nsis-qspec]: 548 parameter (Section 3.1, suggested ID=15) 550 parameter (Section 3.2, suggested ID=16) 552 This specification creates the following registry with the structure 553 as defined below: 555 Restoration Priority Parameter (8 bits): 557 The following values are allocated by this specification: 559 0-2: assigned as specified in Section 3.2: 561 0: best-effort priority 563 1: normal priority 565 2: high priority 567 The allocation policies for further values are as follows: 569 3-63: Standards Action 571 64-255: Reserved 573 6. Security Considerations 575 The security considerations of [I-D.ietf-nsis-qos-nslp] and 576 [I-D.ietf-nsis-qspec] apply to this Document. There are no new 577 security considerations based on this document. 579 7. Acknowledgements 581 The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, 582 and Hannes Tschofenig for helpful comments and discussion. 584 8. References 585 8.1. Normative References 587 [I-D.ietf-nsis-qos-nslp] 588 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 589 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 590 (work in progress), February 2008. 592 [I-D.ietf-nsis-qspec] 593 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 594 QSPEC Template", draft-ietf-nsis-qspec-18 (work in 595 progress), October 2007. 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [TRQ-QoS-SIG] 601 ITU-T Supplement, "Signaling Requirements for IP-QoS", 602 January 2004. 604 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 605 communication service - IP packet transfer and 606 availability performance parameters", December 2002. 608 [Y.1541] ITU-T Recommendation Y.1540, "Network Performance 609 Objectives for IP-Based Services", February 2006. 611 8.2. Informative References 613 [E.361] ITU-T Recommendation E.361, "QoS Routing Support for 614 Interworking of QoS Service Classes Across Routing 615 Technologies", May 2003. 617 [I-D.ietf-ippm-framework-compagg] 618 Morton, A., "Framework for Metric Composition", 619 draft-ietf-ippm-framework-compagg-06 (work in progress), 620 February 2008. 622 [I-D.ietf-ippm-spatial-composition] 623 Morton, A. and E. Stephan, "Spatial Composition of 624 Metrics", draft-ietf-ippm-spatial-composition-05 (work in 625 progress), November 2007. 627 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 628 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 629 Functional Specification", RFC 2205, September 1997. 631 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 632 Services", RFC 2210, September 1997. 634 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 635 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 636 October 1998. 638 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 639 and W. Weiss, "An Architecture for Differentiated 640 Services", RFC 2475, December 1998. 642 Authors' Addresses 644 Jerry Ash 645 AT&T Labs 646 200 Laurel Avenue South 647 Middletown,, NJ 07748 648 USA 650 Phone: 651 Fax: 652 Email: gash5107@yahoo.com 653 URI: 655 Al Morton 656 AT&T Labs 657 200 Laurel Avenue South 658 Middletown,, NJ 07748 659 USA 661 Phone: +1 732 420 1571 662 Fax: +1 732 368 1192 663 Email: acmorton@att.com 664 URI: http://home.comcast.net/~acmacm/ 666 Martin Dolly 667 AT&T Labs 668 200 Laurel Avenue South 669 Middletown,, NJ 07748 670 USA 672 Phone: 673 Fax: 674 Email: mdolly@att.com 675 URI: 677 Percy Tarapore 678 AT&T Labs 679 200 Laurel Avenue South 680 Middletown,, NJ 07748 681 USA 683 Phone: 684 Fax: 685 Email: tarapore@att.com 686 URI: 688 Chuck Dvorak 689 AT&T Labs 690 180 Park Ave Bldg 2 691 Florham Park,, NJ 07932 692 USA 694 Phone: + 1 973-236-6700 695 Fax: 696 Email: cdvorak@att.com 697 URI: http: 699 Yacine El Mghazli 700 Alcatel-Lucent 701 Route de Nozay 702 Marcoussis cedex, 91460 703 France 705 Phone: +33 1 69 63 41 87 706 Fax: 707 Email: yacine.el_mghazli@alcatel.fr 708 URI: 710 Full Copyright Statement 712 Copyright (C) The IETF Trust (2008). 714 This document is subject to the rights, licenses and restrictions 715 contained in BCP 78, and except as set forth therein, the authors 716 retain all their rights. 718 This document and the information contained herein are provided on an 719 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 720 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 721 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 722 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 723 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 724 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 726 Intellectual Property 728 The IETF takes no position regarding the validity or scope of any 729 Intellectual Property Rights or other rights that might be claimed to 730 pertain to the implementation or use of the technology described in 731 this document or the extent to which any license under such rights 732 might or might not be available; nor does it represent that it has 733 made any independent effort to identify any such rights. Information 734 on the procedures with respect to rights in RFC documents can be 735 found in BCP 78 and BCP 79. 737 Copies of IPR disclosures made to the IETF Secretariat and any 738 assurances of licenses to be made available, or the result of an 739 attempt made to obtain a general license or permission for the use of 740 such proprietary rights by implementers or users of this 741 specification can be obtained from the IETF on-line IPR repository at 742 http://www.ietf.org/ipr. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights that may cover technology that may be required to implement 747 this standard. Please address the information to the IETF at 748 ietf-ipr@ietf.org. 750 Acknowledgment 752 Funding for the RFC Editor function is provided by the IETF 753 Administrative Support Activity (IASA).