idnits 2.17.1 draft-ietf-nsis-y1541-qosm-05.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 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 677. 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 (November 5, 2007) is 6010 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'QoS-SIG' is mentioned on line 504, but not defined == Missing Reference: 'QSPEC' is mentioned on line 505, but not defined == Missing Reference: 'Bp' is mentioned on line 260, but not defined == Missing Reference: 'M' is mentioned on line 262, but not defined == Unused Reference: 'I-D.ietf-ippm-framework-compagg' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'I-D.morton-ippm-reporting-metrics' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-15 == 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-04 == Outdated reference: A later version (-07) exists of draft-morton-ippm-reporting-metrics-02 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 11 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: May 8, 2008 P. Tarapore 6 C. Dvorak 7 AT&T Labs 8 Y. El Mghazli 9 Alcatel-Lucent 10 November 5, 2007 12 Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes 13 draft-ietf-nsis-y1541-qosm-05 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 May 8, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . 8 71 4.3. QNE Processing Rules . . . . . . . . . . . . . . . . . . . 8 72 4.4. Processing Example . . . . . . . . . . . . . . . . . . . . 9 73 4.5. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . 10 74 4.6. Preemption Behaviour . . . . . . . . . . . . . . . . . . . 10 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 Intellectual Property and Copyright Statements . . . . . . . . . . 15 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 2.2. Y.1541-QOSM Processing Requirements 198 [TRQ-QoS-SIG] [TRQ-QoS-SIG] provides the requirements for signaling 199 information regarding IP-based QoS at the interface between the user 200 and the network (UNI) and across interfaces between different 201 networks (NNI). To meet specific network performance requirements 202 specified for the Y.1541 QoS classes [Y.1541] , a network needs to 203 provide specific user plane functionality at UNI and NNI interfaces. 204 Dynamic network provisioning at a UNI and/or NNI node allows the 205 ability to dynamically request a traffic contract for an IP flow from 206 a specific source node to one or more destination nodes. In response 207 to the request, the network determines if resources are available to 208 satisfy the request and provision the network. 210 It MUST be possible to derive the following service level parameters 211 as part of the process of requesting service: 213 a. Y.1541 QoS class 215 b. rate (r) 217 c. peak rate (p) 219 d. bucket size (b) 221 e. peak bucket size (Bp)* 223 f. maximum packet size (M)* 225 g. DiffServ PHB class [RFC2475] [RFC2475] 226 h. admission priority 228 i. restoration priority* 230 All parameters except Bp, M, and restoration priority have already 231 been specified in [QSPEC] [I-D.ietf-nsis-qspec]. These additional 232 parameters are specified in Section 3. 234 It MUST be possible to perform the following QoS-NSLP signaling 235 functions to meet Y.1541-QOSM requirements: 237 a. accumulate delay, delay variation and loss ratio across the end- 238 to-end connection, which may span multiple domains 240 b. enable negotiation of Y.1541 QoS class across domains. 242 c. enable negotiation of delay, delay variation, and loss ratio 243 across domains. 245 These signaling requirements are already supported by [QoS-SIG] 246 [I-D.ietf-nsis-qos-nslp] and the functions are illustrated in Section 247 4. 249 3. Additional QSPEC Parameters for Y.1541 QOSM 251 3.1. Traffic Model (TMOD) Extension Parameter 253 The traffic model (TMOD) extension parameter is represented by one 254 floating point number in single-precision IEEE floating point format 255 and one 32-bit unsigned integer. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Maximum Packet Size [M] (32-bit unsigned integer) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 1: TMOD Extension 267 When the Bp term is represented as an IEEE floating point value, the 268 sign bit MUST be zero (all values MUST be non-negative). Exponents 269 less than 127 (i.e., 0) are prohibited. Exponents greater than 162 270 (i.e., positive 35) are discouraged, except for specifying a peak 271 rate of infinity. Infinity is represented with an exponent of all 272 ones (255) and a sign bit and mantissa of all zeros. The maximum 273 packet size (M) is an unsigned integer. 275 The QSPEC parameter behavior for (Bp) and (M) is similar to that 276 defined in [QSPEC] [I-D.ietf-nsis-qspec], section 6.2.1 and 6.2.2. 277 The new parameters (and all traffic-related parameters) are specified 278 independently from the Y.1541 class parameter. 280 3.2. Restoration Priority Parameter 282 Restoration priority is the urgency with which a service requires 283 successful restoration under failure conditions. Restoration 284 priority is achieved by provisioning sufficient backup capacity, as 285 necessary, and allowing relative priority for access to available 286 bandwidth when there is contention for restoration bandwidth. 287 Restoration priority is defined as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Rest. Priority| (Reserved) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 2: Restoration Priority 297 Restoration Priority: 3 priority values are listed here in the order 298 of lowest priority to highest priority: 300 0 - best effort 302 1 - normal 304 2 - high 306 Each restoration priority class has two parameters: 308 a. Time-to-Restore: Total amount of time to restore traffic streams 309 belonging to a given restoration class impacted by the failure. This 310 time period depends on the technology deployed for restoration. A 311 fast recovery period of < 200 ms is based on current experience with 312 SONET rings and a slower recovery period of 2 seconds is suggested in 313 order to enable a voice call to recover without being dropped. 314 Accordingly, candidate restoration objectives are: 316 High Restoration Priority: Time-to-Restore <= 200 ms 318 Normal Restoration Priority: Time-to-Restore <= 2 s 320 Best Effort Restoration Priority: Time-to-Restore = Unspecified 321 b. Extent of Restoration: Percentage of traffic belonging to the 322 restoration class that can be restored. This percentage depends on 323 the amount of spare capacity engineered. All high priority 324 restoration priority traffic, for example, may be "guaranteed" at 325 100% by the service provider. Other classes may offer lesser chances 326 for successful restoration. The restoration extent for these lower 327 priority classes depend on SLA agreements developed between the 328 service provider and the customer. 330 4. Y.1541-QOSM Considerations and Processing Example 332 In this Section we illustrate the operation of the Y.1541 QOSM, and 333 show how current QoS-NSLP and QSPEC functionality is used. No new 334 processing capabilities or parameters (except those described in 335 section 3) are required to enable the Y.1541 QOSM. 337 4.1. Deployment Considerations 339 [TRQ-QoS-SIG] emphasizes the deployment of Y.1541 QNEs at the borders 340 of supporting domains. There may be domain configurations where 341 interior QNEs are desirable, and the example below addresses this 342 possibility. 344 QNEs may be Stateful in some limited aspects, but obviously it is 345 preferable to deploy stateless QNEs. 347 4.2. Applicable QSPEC Procedures 349 All procedures defined in section 5.3 of [QSPEC] 350 [I-D.ietf-nsis-qspec] are applicable to this QOSM. 352 4.3. QNE Processing Rules 354 [TRQ-QoS-SIG] describes the information processing in Y.1541 QNEs. 356 [Y.1541] section 8 defines the accumulation rules for individual 357 performance parameters (e.g., delay, jitter). 359 When a QNI specifies the Y.1541 QoS Class number, , 360 it is a sufficient specification of objectives for the , , and parameters. As described 362 above in section 2, some Y.1541 Classes do not set objectives for all 363 the performance parameters above. For example, Classes 2, 3, and 4, 364 do not specify an objective for (referred to as IP 365 Packet Delay Variation). In the case that the QoS Class leaves a 366 parameter Unspecified, then that parameter need not be included in 367 the accumulation processing. 369 4.4. Processing Example 371 As described in the example given in [QSPEC] [I-D.ietf-nsis-qspec] 372 (Section 4.4) and as illustrated in Figure 3, the QoS NSIS initiator 373 (QNI) initiates an end-to-end, inter-domain QoS NSLP RESERVE message 374 containing the Initiator QSPEC. In the case of the Y.1541 QOSM, the 375 Initiator QSPEC specifies the , , , , , and perhaps 377 other QSPEC parameters for the flow. As described in Section 3, the 378 TMOD extension parameter contains the optional, Y.1541-QOSM-specific 379 parameters Bp and M; restoration priority is also an optional, 380 Y.1541-QOSM-specific parameter. 382 As illustrated in Figure 3, the RESERVE message may cross multiple 383 domains supporting different QOSMs. In this illustration, the 384 initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress 385 node of the local-QOSM domain. As described in [QoS-SIG] 386 [I-D.ietf-nsis-qos-nslp] and [QSPEC] [I-D.ietf-nsis-qspec], at the 387 ingress edge node of the local-QOSM domain, the end-to-end, inter- 388 domain QoS-NSLP message may trigger the generation of a local QSPEC, 389 and the initiator QSPEC encapsulated within the messages signaled 390 through the local domain. The local QSPEC is used for QoS processing 391 in the local-QOSM domain, and the Initiator QSPEC is used for QoS 392 processing outside the local domain. As specified in [QSPEC] 393 [I-D.ietf-nsis-qspec], if any QNE cannot meet the requirements 394 designated by the initiator QSPEC to support an optional QSPEC 395 parameter, with the M bit set to zero for the parameter, for example, 396 it cannot support the accumulation of end-to-end delay with the parameter, the QNE sets the N flag (not supported flag) for 398 the path latency parameter to one. 400 Also, the Y.1541-QOSM requires negotiation of the 401 across domains. This negotiation can be done with the use of the 402 existing procedures already defined in [QoS-SIG] 403 [I-D.ietf-nsis-qos-nslp]. For example, the QNI sets , 404 , objects to include , 405 which specifies objectives for the , , 406 parameters. In the case that the QoS Class leaves a 407 parameter Unspecified, then that parameter need not be included in 408 the accumulation processing. The QNE/domain SHOULD set the Y.1541 409 class and cumulative parameters, e.g., , that can be 410 achieved in the object (but not less than specified 411 in ). This could include, for example, setting the 412 to a lower class than specified in 413 (but not lower than specified in ). If the fails to satisfy one or more of the objectives, 415 the QNE/domain notifies the QNI and the reservation is aborted. 416 Otherwise, the QNR notifies the QNI of the for the 417 reservation. 419 When the available must be reduced from the 420 desired , say because the delay objective has been 421 exceeded, then there is an incentive to respond with an available 422 value for delay in the parameter. If the available 423 is 150 ms (still useful for many applications) and the 424 desired QoS is Class 0 (with its 100 ms objective), then the response 425 would be that Class 0 cannot be achieved and Class 1 is available 426 (with its 400 ms objective). In addition, this QOSM allows the 427 response to include an available = 150 ms, making 428 acceptance of the available more likely. There 429 are many long paths where the propagation delay alone exceeds the 430 Y.1541 Class 0 objective, so this feature adds flexibility to commit 431 to exceed the Class 1 objective when possible. 433 This example illustrates Y.1541-QOSM negotiation of and cumulative parameter values that can be achieve end-to- 435 end. The example illustrates how the QNI can use the cumulative 436 values collected in to decide if a lower than specified in is acceptable. 439 |------| |------| |------| |------| 440 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 441 | QOSM | | QOSM | | QOSM | | QOSM | 442 | | |------| |-------| |-------| |------| | | 443 | NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | 444 |Y.1541| |local | |local | |local | |local | |Y.1541| 445 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 446 |------| |------| |-------| |-------| |------| |------| 447 ----------------------------------------------------------------- 448 |------| |------| |-------| |-------| |------| |------| 449 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 450 |------| |------| |-------| |-------| |------| |------| 451 QNI QNE QNE QNE QNE QNR 452 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 454 Figure 3: Example of Y.1541-QOSM Operation 456 4.5. Bit-Level QSPEC Example 458 TBD 460 4.6. Preemption Behaviour 462 The default QNI behaviour of tearing down a preempted reservation is 463 followed in the Y.1541 QOSM. The restoration priority parameter 464 described above does not rely on preemption. 466 5. IANA Considerations 468 This section defines the registries and initial codepoint assignments 469 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 470 It also defines the procedural requirements to be followed by IANA in 471 allocating new codepoints. 473 This document specifies the following QSPEC parameters to be assigned 474 within the QSPEC Parameter ID registry created in [QSPEC] 475 [I-D.ietf-nsis-qspec]: 477 parameter (Section 3.1) 479 parameter (Section 3.2) 481 This specification creates the following registry with the structure 482 as defined below: 484 Restoration Priority Parameter (8 bits): 486 The following values are allocated by this specification: 488 0-2: assigned as specified in Section 3.2: 490 0: best-effort priority 492 1: normal priority 494 2: high priority 496 The allocation policies for further values are as follows: 498 3-63: Standards Action 500 64-255: Reserved 502 6. Security Considerations 504 The security considerations of [QoS-SIG] [I-D.ietf-nsis-qos-nslp] and 505 [QSPEC] [I-D.ietf-nsis-qspec] apply to this Document. There are no 506 new security considerations based on this document. 508 7. Acknowledgements 510 The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, 511 and Hannes Tschofenig for helpful comments and discussion. 513 8. References 515 8.1. Normative References 517 [I-D.ietf-nsis-qos-nslp] 518 Manner, J., "NSLP for Quality-of-Service Signaling", 519 draft-ietf-nsis-qos-nslp-15 (work in progress), July 2007. 521 [I-D.ietf-nsis-qspec] 522 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 523 QSPEC Template", draft-ietf-nsis-qspec-18 (work in 524 progress), October 2007. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [TRQ-QoS-SIG] 530 ITU-T Supplement, "Signaling Requirements for IP-QoS", 531 January 2004. 533 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 534 communication service - IP packet transfer and 535 availability performance parameters", December 2002. 537 [Y.1541] ITU-T Recommendation Y.1540, "Network Performance 538 Objectives for IP-Based Services", February 2006. 540 8.2. Informative References 542 [E.361] ITU-T Recommendation E.361, "QoS Routing Support for 543 Interworking of QoS Service Classes Across Routing 544 Technologies", May 2003. 546 [I-D.ietf-ippm-framework-compagg] 547 Morton, A., "Framework for Metric Composition", 548 draft-ietf-ippm-framework-compagg-04 (work in progress), 549 July 2007. 551 [I-D.morton-ippm-reporting-metrics] 552 Morton, A., "Reporting Metrics: Different Points of View", 553 draft-morton-ippm-reporting-metrics-02 (work in progress), 554 April 2007. 556 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 557 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 558 Functional Specification", RFC 2205, September 1997. 560 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 561 Services", RFC 2210, September 1997. 563 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 564 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 565 October 1998. 567 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 568 and W. Weiss, "An Architecture for Differentiated 569 Services", RFC 2475, December 1998. 571 Authors' Addresses 573 Jerry Ash 574 AT&T Labs 575 200 Laurel Avenue South 576 Middletown,, NJ 07748 577 USA 579 Phone: 580 Fax: 581 Email: gash@att.com 582 URI: 584 Al Morton 585 AT&T Labs 586 200 Laurel Avenue South 587 Middletown,, NJ 07748 588 USA 590 Phone: +1 732 420 1571 591 Fax: +1 732 368 1192 592 Email: acmorton@att.com 593 URI: http://home.comcast.net/~acmacm/ 595 Martin Dolly 596 AT&T Labs 597 200 Laurel Avenue South 598 Middletown,, NJ 07748 599 USA 601 Phone: 602 Fax: 603 Email: mdolly@att.com 604 URI: 606 Percy Tarapore 607 AT&T Labs 608 200 Laurel Avenue South 609 Middletown,, NJ 07748 610 USA 612 Phone: 613 Fax: 614 Email: tarapore@att.com 615 URI: 617 Chuck Dvorak 618 AT&T Labs 619 180 Park Ave Bldg 2 620 Florham Park,, NJ 07932 621 USA 623 Phone: + 1 973-236-6700 624 Fax: 625 Email: cdvorak@att.com 626 URI: http: 628 Yacine El Mghazli 629 Alcatel-Lucent 630 Route de Nozay 631 Marcoussis cedex, 91460 632 France 634 Phone: +33 1 69 63 41 87 635 Fax: 636 Email: yacine.el_mghazli@alcatel.fr 637 URI: 639 Full Copyright Statement 641 Copyright (C) The IETF Trust (2007). 643 This document is subject to the rights, licenses and restrictions 644 contained in BCP 78, and except as set forth therein, the authors 645 retain all their rights. 647 This document and the information contained herein are provided on an 648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 650 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 651 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 652 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 655 Intellectual Property 657 The IETF takes no position regarding the validity or scope of any 658 Intellectual Property Rights or other rights that might be claimed to 659 pertain to the implementation or use of the technology described in 660 this document or the extent to which any license under such rights 661 might or might not be available; nor does it represent that it has 662 made any independent effort to identify any such rights. Information 663 on the procedures with respect to rights in RFC documents can be 664 found in BCP 78 and BCP 79. 666 Copies of IPR disclosures made to the IETF Secretariat and any 667 assurances of licenses to be made available, or the result of an 668 attempt made to obtain a general license or permission for the use of 669 such proprietary rights by implementers or users of this 670 specification can be obtained from the IETF on-line IPR repository at 671 http://www.ietf.org/ipr. 673 The IETF invites any interested party to bring to its attention any 674 copyrights, patents or patent applications, or other proprietary 675 rights that may cover technology that may be required to implement 676 this standard. Please address the information to the IETF at 677 ietf-ipr@ietf.org. 679 Acknowledgment 681 Funding for the RFC Editor function is provided by the IETF 682 Administrative Support Activity (IASA).