idnits 2.17.1 draft-ietf-nsis-y1541-qosm-07.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 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. 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 (October 27, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'QoS-SIG' is mentioned on line 414, but not defined == Missing Reference: 'Bp' is mentioned on line 499, but not defined == Missing Reference: 'M' is mentioned on line 501, 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-20 == 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-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 8 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: April 30, 2009 P. Tarapore 6 C. Dvorak 7 AT&T Labs 8 Y. El Mghazli 9 Alcatel-Lucent 10 October 27, 2008 12 Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes 13 draft-ietf-nsis-y1541-qosm-07 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 April 30, 2009. 40 Abstract 42 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T 43 Recommendation Y.1541 Network QoS Classes and related signaling 44 requirements. Y.1541 specifies 8 classes of Network Performance 45 objectives, and the Y.1541-QOSM extensions include additional QSPEC 46 parameters and QOSM processing guidelines. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Summary of ITU-T Recommendations Y.1541 & Signaling 58 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Y.1541 Classes . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Y.1541-QOSM Processing Requirements . . . . . . . . . . . 5 61 3. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . 6 62 3.1. Traffic Model (TMOD) Extension Parameter . . . . . . . . . 6 63 3.2. Restoration Priority Parameter . . . . . . . . . . . . . . 7 64 4. Y.1541-QOSM Considerations and Processing Example . . . . . . 8 65 4.1. Deployment Considerations . . . . . . . . . . . . . . . . 9 66 4.2. Applicable QSPEC Procedures . . . . . . . . . . . . . . . 9 67 4.3. QNE Processing Rules . . . . . . . . . . . . . . . . . . . 9 68 4.4. Processing Example . . . . . . . . . . . . . . . . . . . . 9 69 4.5. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . 11 70 4.6. Preemption Behaviour . . . . . . . . . . . . . . . . . . . 12 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Intellectual Property and Copyright Statements . . . . . . . . . . 17 80 1. Introduction 82 This draft describes a QoS model (QOSM) for NSIS QoS signaling layer 83 protocol (QoS-NSLP) application based on ITU-T Recommendation Y.1541 84 Network QoS Classes and related signaling requirements. [Y.1541] 85 currently specifies 8 classes of Network Performance objectives, and 86 the Y.1541-QOSM extensions include additional QSPEC parameters and 87 QOSM processing guidelines. The extensions are based on 88 standardization work in the ITU-T on QoS signaling requirements 89 [Y.1541] [TRQ-QoS-SIG] [E.361]. 91 [QoS-SIG] [I-D.ietf-nsis-qos-nslp] defines message types and control 92 information for the QoS-NSLP generic to all QOSMs. A QOSM is a 93 defined mechanism for achieving QoS as a whole. The specification of 94 a QOSM includes a description of its QSPEC parameter information, as 95 well as how that information should be treated or interpreted in the 96 network. The QSPEC [I-D.ietf-nsis-qspec] contains a set of 97 parameters and values describing the requested resources. It is 98 opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and 99 AdSpec specified in [RFC2205] [RFC2210] . The QSPEC object contains 100 the QoS parameters defined by the QOSM. A QOSM provides a specific 101 set of parameters to be carried in the QSPEC. At each QoS NSIS 102 element (QNE), the QSPEC contents are interpreted by the resource 103 management function (RMF) for purposes of policy control and traffic 104 control, including admission control and configuration of the 105 scheduler. 107 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements 109 As stated above, [Y.1541] is a specification of standardized QoS 110 classes for IP networks (a summary of these classes is given below). 111 [TRQ-QoS-SIG] specifies the requirements for achieving end-to-end QoS 112 in IP networks, with Y.1541 QoS classes as a basis. [Y.1541] 113 recommends a flexible allocation of the end-to-end performance 114 objectives (e.g., delay) across networks, rather than a fixed per- 115 network allocation. NSIS protocols already address most of the 116 requirements, this document identifies additional QSPEC parameters 117 and processing requirements needed to support the Y.1541 QOSM. 119 2.1. Y.1541 Classes 121 [Y.1541] proposes grouping services into QoS classes defined 122 according to the desired QoS performance objectives. These QoS 123 classes support a wide range of user applications. The classes group 124 objectives for one-way IP packet delay, IP packet delay variation, IP 125 packet loss ratio, etc., where the parameters themselves are defined 126 in [Y.1540]. Classes 0 and 1 might be implemented using the DiffServ 127 EF PHB, and support interactive real-time applications. Classes 2, 128 3, and 4 might be implemented using the DiffServ AFxy PHB Group, and 129 support data transfer applications with various degrees of 130 interactivity. Class 5 generally corresponds to the DiffServ Default 131 PHB, has all the QoS parameters unspecified consistent with a best- 132 effort service. Classes 6 and 7 provide support for extremely loss- 133 sensitive user applications, such as high quality digital television, 134 TDM circuit emulation, and high capacity file transfers using TCP. 135 These classes are intended to serve as a basis for agreements between 136 end-users and service providers, and between service providers. They 137 support a wide range of user applications including point-to-point 138 telephony, data transfer, multimedia conferencing, and others. The 139 limited number of classes supports the requirement for feasible 140 implementation, particularly with respect to scale in global 141 networks. 143 The QoS classes apply to a packet flow, where [Y.1541] defines a 144 packet flow as the traffic associated with a given connection or 145 connectionless stream having the same source host, destination host, 146 class of service, and session identification. The characteristics of 147 each Y.1451 QoS class are summarized here: 149 Class 0: Real-time, highly interactive applications, sensitive to 150 jitter. Mean delay upper bound is 100 ms, delay variation is less 151 than 50 ms, and loss ratio is less than 10^-3. Application examples 152 include VoIP, Video Teleconference. 154 Class 1: Real-time, interactive applications, sensitive to jitter. 155 Mean delay upper bound is 400 ms, delay variation is less than 50 ms, 156 and loss ratio is less than 10^-3. Application examples include 157 VoIP, video teleconference. 159 Class 2: Highly interactive transaction data. Mean delay upper bound 160 is 100 ms, delay variation is unspecified, and loss ratio is less 161 than 10^-3. Application examples include signaling. 163 Class 3: Interactive transaction data. Mean delay upper bound is 400 164 ms, delay variation is unspecified, and loss ratio is less than 165 10^-3. Application examples include signaling. 167 Class 4: Low Loss Only applications. Mean delay upper bound is 1s, 168 delay variation is unspecified, and loss ratio is less than 10^-3. 169 Application examples include short transactions, bulk data, video 170 streaming 172 Class 5: Unspecified applications with unspecified mean delay, delay 173 variation, and loss ratio. Application examples include traditional 174 applications of Default IP Networks 175 Class 6: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio 176 <= 10^-5. Applications that are highly sensitive to loss, such as 177 television transport, high-capacity TCP transfers, and TDM circuit 178 emulation. 180 Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio 181 <= 10^-5. Applications that are highly sensitive to loss, such as 182 television transport, high-capacity TCP transfers, and TDM circuit 183 emulation. 185 These classes enable SLAs to be defined between customers and network 186 service providers with respect to QoS requirements. The service 187 provider then needs to ensure that the requirements are recognized 188 and receive appropriate treatment across network layers. 190 Work is in progress to specify methods for combining local values of 191 performance metrics to estimate the performance of the complete path. 192 See section 8 of [Y.1541], [I-D.ietf-ippm-framework-compagg], and 193 [I-D.ietf-ippm-spatial-composition]. 195 2.2. Y.1541-QOSM Processing Requirements 197 [TRQ-QoS-SIG] provides the requirements for signaling information 198 regarding IP-based QoS at the interface between the user and the 199 network (UNI) and across interfaces between different networks (NNI). 200 To meet specific network performance requirements specified for the 201 Y.1541 QoS classes [Y.1541] , a network needs to provide specific 202 user plane functionality at UNI and NNI interfaces. Dynamic network 203 provisioning at a UNI and/or NNI node allows the ability to 204 dynamically request a traffic contract for an IP flow from a specific 205 source node to one or more destination nodes. In response to the 206 request, the network determines if resources are available to satisfy 207 the request and provision the network. 209 It MUST be possible to derive the following service level parameters 210 as part of the process of requesting service: 212 a. Y.1541 QoS class 214 b. rate (r) 216 c. peak rate (p) 218 d. bucket size (b) 220 e. peak bucket size (Bp)*, octets 222 f. maximum packet size (M)*, octets 223 g. DiffServ PHB class [RFC2475] 225 h. admission priority 227 i. restoration priority* 229 All parameters except Bp, M, and restoration priority have already 230 been specified in [I-D.ietf-nsis-qspec]. These additional parameters 231 are specified in Section 3. 233 It MUST be possible to perform the following QoS-NSLP signaling 234 functions to meet Y.1541-QOSM requirements: 236 a. accumulate delay, delay variation and loss ratio across the end- 237 to-end connection, which may span multiple domains 239 b. enable negotiation of Y.1541 QoS class across domains. 241 c. enable negotiation of delay, delay variation, and loss ratio 242 across domains. 244 These signaling requirements are already supported by 245 [I-D.ietf-nsis-qos-nslp] and the functions are illustrated in Section 246 4. 248 3. Additional QSPEC Parameters for Y.1541 QOSM 250 3.1. Traffic Model (TMOD) Extension Parameter 252 The traffic model (TMOD) extension parameter is represented by one 253 floating point number in single-precision IEEE floating point format 254 and one 32-bit unsigned integer. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |M|E|N|r| 15 |r|r|r|r| 2 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Maximum Packet Size [M] (32-bit unsigned integer) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 1: TMOD Extension 268 When the Bp term is represented as an IEEE floating point value, the 269 sign bit MUST be zero (all values MUST be non-negative). Exponents 270 less than 127 (i.e., 0) are prohibited. Exponents greater than 162 271 (i.e., positive 35) are discouraged, except for specifying a peak 272 rate of infinity. Infinity is represented with an exponent of all 273 ones (255) and a sign bit and mantissa of all zeros. The maximum 274 packet size (M) is an unsigned integer. 276 The QSPEC parameter behavior for (Bp) and (M) is similar to that 277 defined in [I-D.ietf-nsis-qspec], section 6.2.1 and 6.2.2. The new 278 parameters (and all traffic-related parameters) are specified 279 independently from the Y.1541 class parameter. 281 3.2. Restoration Priority Parameter 283 Restoration priority is the urgency with which a service requires 284 successful restoration under failure conditions. Restoration 285 priority is achieved by provisioning sufficient backup capacity, as 286 necessary, and allowing relative priority for access to available 287 bandwidth when there is contention for restoration bandwidth. 288 Restoration priority is defined as follows: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |M|E|N|r| 16 |r|r|r|r| 1 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Rest. Priority| (Reserved) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 2: Restoration Priority 300 Restoration Priority: 3 priority values are listed here in the order 301 of lowest priority to highest priority: 303 0 - best effort 304 1 - normal 306 2 - high 308 These priority values are described in [Y.2172], where best effort 309 priority is the same as Priority level 3, normal priority is Priority 310 level 2, and high priority is the same as Priority level 1. 312 Reserved: These 3 octets are reserved for future use. There are 313 several ways to elaborate on restoration priority, and two 314 possibilities are described below: 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 Best Time-to-Restore: <= 200 ms 326 Normal Time-to-Restore <= 2 s 328 Unspecified Time-to-Restore = 0 (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 The Reserved octets MAY be designated for these or other uses in the 340 future. 342 4. Y.1541-QOSM Considerations and Processing Example 344 In this Section we illustrate the operation of the Y.1541 QOSM, and 345 show how current QoS-NSLP and QSPEC functionality is used. No new 346 processing capabilities or parameters (except those described in 347 section 3) are required to enable the Y.1541 QOSM. 349 4.1. Deployment Considerations 351 [TRQ-QoS-SIG] emphasizes the deployment of Y.1541 QNEs at the borders 352 of supporting domains. There may be domain configurations where 353 interior QNEs are desirable, and the example below addresses this 354 possibility. 356 QNEs may be Stateful in some limited aspects, but obviously it is 357 preferable to deploy stateless QNEs. 359 4.2. Applicable QSPEC Procedures 361 All procedures defined in section 5.3 of [I-D.ietf-nsis-qspec] are 362 applicable to this QOSM. 364 4.3. QNE Processing Rules 366 [TRQ-QoS-SIG] describes the information processing in Y.1541 QNEs. 368 [Y.1541] section 8 defines the accumulation rules for individual 369 performance parameters (e.g., delay, jitter). 371 When a QNI specifies the Y.1541 QoS Class number, , 372 it is a sufficient specification of objectives for the , , and parameters. As described 374 above in section 2, some Y.1541 Classes do not set objectives for all 375 the performance parameters above. For example, Classes 2, 3, and 4, 376 do not specify an objective for (referred to as IP 377 Packet Delay Variation). In the case that the QoS Class leaves a 378 parameter Unspecified, then that parameter need not be included in 379 the accumulation processing. 381 4.4. Processing Example 383 As described in the example given in [I-D.ietf-nsis-qspec] (Section 384 4.4) and as illustrated in Figure 3, the QoS NSIS initiator (QNI) 385 initiates an end-to-end, inter-domain QoS NSLP RESERVE message 386 containing the Initiator QSPEC. In the case of the Y.1541 QOSM, the 387 Initiator QSPEC specifies the , , , , , and perhaps 389 other QSPEC parameters for the flow. As described in Section 3, the 390 TMOD extension parameter contains the optional, Y.1541-QOSM-specific 391 parameters Bp and M; restoration priority is also an optional, 392 Y.1541-QOSM-specific parameter. 394 As illustrated in Figure 3, the RESERVE message may cross multiple 395 domains supporting different QOSMs. In this illustration, the 396 initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress 397 node of the local-QOSM domain. As described in 398 [I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec], at the ingress 399 edge node of the local-QOSM domain, the end-to-end, inter-domain QoS- 400 NSLP message may trigger the generation of a local QSPEC, and the 401 initiator QSPEC encapsulated within the messages signaled through the 402 local domain. The local QSPEC is used for QoS processing in the 403 local-QOSM domain, and the Initiator QSPEC is used for QoS processing 404 outside the local domain. As specified in [I-D.ietf-nsis-qspec], if 405 any QNE cannot meet the requirements designated by the initiator 406 QSPEC to support an optional QSPEC parameter, with the M bit set to 407 zero for the parameter, for example, it cannot support the 408 accumulation of end-to-end delay with the parameter, 409 the QNE sets the N flag (not supported flag) for the path latency 410 parameter to one. 412 Also, the Y.1541-QOSM requires negotiation of the 413 across domains. This negotiation can be done with the use of the 414 existing procedures already defined in [QoS-SIG] 415 [I-D.ietf-nsis-qos-nslp]. For example, the QNI sets , 416 , objects to include , 417 which specifies objectives for the , , 418 parameters. In the case that the QoS Class leaves a 419 parameter Unspecified, then that parameter need not be included in 420 the accumulation processing. The QNE/domain SHOULD set the Y.1541 421 class and cumulative parameters, e.g., , that can be 422 achieved in the object (but not less than specified 423 in ). This could include, for example, setting the 424 to a lower class than specified in 425 (but not lower than specified in ). If the fails to satisfy one or more of the objectives, 427 the QNE/domain notifies the QNI and the reservation is aborted. 428 Otherwise, the QNR notifies the QNI of the for the 429 reservation. 431 When the available must be reduced from the 432 desired , say because the delay objective has been 433 exceeded, then there is an incentive to respond with an available 434 value for delay in the parameter. If the available 435 is 150 ms (still useful for many applications) and the 436 desired QoS is Class 0 (with its 100 ms objective), then the response 437 would be that Class 0 cannot be achieved and Class 1 is available 438 (with its 400 ms objective). In addition, this QOSM allows the 439 response to include an available = 150 ms, making 440 acceptance of the available more likely. There 441 are many long paths where the propagation delay alone exceeds the 442 Y.1541 Class 0 objective, so this feature adds flexibility to commit 443 to exceed the Class 1 objective when possible. 445 This example illustrates Y.1541-QOSM negotiation of and cumulative parameter values that can be achieve end-to- 447 end. The example illustrates how the QNI can use the cumulative 448 values collected in to decide if a lower than specified in is acceptable. 451 |------| |------| |------| |------| 452 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 453 | QOSM | | QOSM | | QOSM | | QOSM | 454 | | |------| |-------| |-------| |------| | | 455 | NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | 456 |Y.1541| |local | |local | |local | |local | |Y.1541| 457 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 458 |------| |------| |-------| |-------| |------| |------| 459 ----------------------------------------------------------------- 460 |------| |------| |-------| |-------| |------| |------| 461 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 462 |------| |------| |-------| |-------| |------| |------| 463 QNI QNE QNE QNE QNE QNR 464 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 466 Figure 3: Example of Y.1541-QOSM Operation 468 4.5. Bit-Level QSPEC Example 470 This is an example where the QOS Desired specification contains the 471 TMOD-1 parameters and TMOD extended parameters defined in this 472 specification, as well as the Y.1541 Class parameter. The QOS 473 Available specification utilizes the Latency, Jitter, and Loss 474 parameters to enable accumulation of these parameters for easy 475 comparison with the objectives desired fir the Y.1541 Class. 477 This example assumes that all the parameters MUST be supported by the 478 QNEs, so all M flags have been set to "1". 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Vers.|QType=I|QSPEC Proc.=0/1|0|R|R|R| Length = 23 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 10 | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |1|E|0|r| ID = 1 |r|r|r|r| Length = 4 | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 |1|E|N|r| 15 |r|r|r|r| 2 | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Maximum Packet Size [M] (32-bit unsigned integer) | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |1|E|N|r| 14 |r|r|r|r| 1 | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 |Y.1541 QoS Cls.| (Reserved) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 |E|r|r|r| Type = 1 (QoS Avail) |r|r|r|r| Length = 11 | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |1|E|N|r| 3 |r|r|r|r| 1 | 510 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 511 | Path Latency (32-bit integer) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |1|E|N|r| 4 |r|r|r|r| 4 | 514 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 515 | Path Jitter STAT1(variance) (32-bit integer) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Path Jitter STAT4(Reserved) (32-bit integer) | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |1|E|N|r| 5 |r|r|r|r| 1 | 524 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 525 | Path Packet Loss Ratio (32-bit floating point) | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 |1|E|N|r| 14 |r|r|r|r| 1 | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |Y.1541 QoS Cls.| (Reserved) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 4: An Example QSPEC (Initiator) 534 4.6. Preemption Behaviour 536 The default QNI behaviour of tearing down a preempted reservation is 537 followed in the Y.1541 QOSM. The restoration priority parameter 538 described above does not rely on preemption. 540 5. IANA Considerations 542 This section defines the registries and initial codepoint assignments 543 for the QSPEC template, in accordance with BCP 26 [RFC5226]. It also 544 defines the procedural requirements to be followed by IANA in 545 allocating new codepoints. 547 This document specifies the following QSPEC parameters to be assigned 548 within the QSPEC Parameter ID registry created in 549 [I-D.ietf-nsis-qspec]: 551 parameter (Section 3.1, suggested ID=15) 553 parameter (Section 3.2, suggested ID=16) 555 This specification creates the following registry with the structure 556 as defined below: 558 Restoration Priority Parameter (8 bits): 560 The following values are allocated by this specification: 562 0-2: assigned as specified in Section 3.2: 564 0: best-effort priority 566 1: normal priority 568 2: high priority 570 The allocation policies for further values are as follows: 572 3-63: Standards Action 574 64-255: Reserved 576 6. Security Considerations 578 The security considerations of [I-D.ietf-nsis-qos-nslp] and 579 [I-D.ietf-nsis-qspec] apply to this Document. There are no new 580 security considerations based on this document. 582 7. Acknowledgements 584 The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, 585 and Hannes Tschofenig for helpful comments and discussion. 587 8. References 589 8.1. Normative References 591 [I-D.ietf-nsis-qos-nslp] 592 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 593 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 594 (work in progress), February 2008. 596 [I-D.ietf-nsis-qspec] 597 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 598 QSPEC Template", draft-ietf-nsis-qspec-20 (work in 599 progress), April 2008. 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [TRQ-QoS-SIG] 605 ITU-T Supplement, "Signaling Requirements for IP-QoS", 606 January 2004. 608 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 609 communication service - IP packet transfer and 610 availability performance parameters", December 2007. 612 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 613 Objectives for IP-Based Services", February 2006. 615 [Y.2172] ITU-T Recommendation Y.1540, "Service restoration priority 616 levels in Next Generation Networks", June 2007. 618 8.2. Informative References 620 [E.361] ITU-T Recommendation E.361, "QoS Routing Support for 621 Interworking of QoS Service Classes Across Routing 622 Technologies", May 2003. 624 [I-D.ietf-ippm-framework-compagg] 625 Morton, A., "Framework for Metric Composition", 626 draft-ietf-ippm-framework-compagg-06 (work in progress), 627 February 2008. 629 [I-D.ietf-ippm-spatial-composition] 630 Morton, A. and E. Stephan, "Spatial Composition of 631 Metrics", draft-ietf-ippm-spatial-composition-07 (work in 632 progress), July 2008. 634 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 636 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 637 Functional Specification", RFC 2205, September 1997. 639 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 640 Services", RFC 2210, September 1997. 642 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 643 and W. Weiss, "An Architecture for Differentiated 644 Services", RFC 2475, December 1998. 646 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 647 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 648 May 2008. 650 Authors' Addresses 652 Jerry Ash 653 AT&T Labs 654 200 Laurel Avenue South 655 Middletown,, NJ 07748 656 USA 658 Phone: 659 Fax: 660 Email: gash5107@yahoo.com 661 URI: 663 Al Morton 664 AT&T Labs 665 200 Laurel Avenue South 666 Middletown,, NJ 07748 667 USA 669 Phone: +1 732 420 1571 670 Fax: +1 732 368 1192 671 Email: acmorton@att.com 672 URI: http://home.comcast.net/~acmacm/ 673 Martin Dolly 674 AT&T Labs 675 200 Laurel Avenue South 676 Middletown,, NJ 07748 677 USA 679 Phone: 680 Fax: 681 Email: mdolly@att.com 682 URI: 684 Percy Tarapore 685 AT&T Labs 686 200 Laurel Avenue South 687 Middletown,, NJ 07748 688 USA 690 Phone: 691 Fax: 692 Email: tarapore@att.com 693 URI: 695 Chuck Dvorak 696 AT&T Labs 697 180 Park Ave Bldg 2 698 Florham Park,, NJ 07932 699 USA 701 Phone: + 1 973-236-6700 702 Fax: 703 Email: cdvorak@att.com 704 URI: http: 706 Yacine El Mghazli 707 Alcatel-Lucent 708 Route de Nozay 709 Marcoussis cedex, 91460 710 France 712 Phone: +33 1 69 63 41 87 713 Fax: 714 Email: yacine.el_mghazli@alcatel.fr 715 URI: 717 Full Copyright Statement 719 Copyright (C) The IETF Trust (2008). 721 This document is subject to the rights, licenses and restrictions 722 contained in BCP 78, and except as set forth therein, the authors 723 retain all their rights. 725 This document and the information contained herein are provided on an 726 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 727 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 728 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 729 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 730 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 731 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 733 Intellectual Property 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed to 737 pertain to the implementation or use of the technology described in 738 this document or the extent to which any license under such rights 739 might or might not be available; nor does it represent that it has 740 made any independent effort to identify any such rights. Information 741 on the procedures with respect to rights in RFC documents can be 742 found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use of 747 such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository at 749 http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights that may cover technology that may be required to implement 754 this standard. Please address the information to the IETF at 755 ietf-ipr@ietf.org.