idnits 2.17.1 draft-ietf-nsis-y1541-qosm-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2010) is 5188 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Bp' is mentioned on line 577, but not defined == Missing Reference: 'M' is mentioned on line 573, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-ippm-spatial-composition-10 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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: Experimental M. Dolly 5 Expires: August 8, 2010 P. Tarapore 6 C. Dvorak 7 AT&T Labs 8 Y. El Mghazli 9 Alcatel-Lucent 10 February 4, 2010 12 Y.1541-QOSM -- Model for Networks Using Y.1541 QoS Classes 13 draft-ietf-nsis-y1541-qosm-10 15 Abstract 17 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T 18 Recommendation Y.1541 Network QoS Classes and related guidance on 19 signaling. Y.1541 specifies 8 classes of Network Performance 20 objectives, and the Y.1541-QOSM extensions include additional QSPEC 21 parameters and QOSM processing guidelines. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on August 8, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 72 Without obtaining an adequate license from the person(s) controlling 73 the copyright in such materials, this document may not be modified 74 outside the IETF Standards Process, and derivative works of it may 75 not be created outside the IETF Standards Process, except to format 76 it for publication as an RFC or to translate it into languages other 77 than English. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Summary of ITU-T Recommendations Y.1541 & Signaling 83 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2.1. Description of Y.1541 Classes . . . . . . . . . . . . . . 3 85 2.2. Y.1541-QOSM Processing Requirements . . . . . . . . . . . 5 86 3. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . 7 87 3.1. Traffic Model (TMOD) Extension Parameter . . . . . . . . . 7 88 3.2. Restoration Priority Parameter . . . . . . . . . . . . . . 7 89 4. Y.1541-QOSM Considerations and Processing Example . . . . . . 9 90 4.1. Deployment Considerations . . . . . . . . . . . . . . . . 9 91 4.2. Applicable QSPEC Procedures . . . . . . . . . . . . . . . 9 92 4.3. QNE Processing Rules . . . . . . . . . . . . . . . . . . . 10 93 4.4. Processing Example . . . . . . . . . . . . . . . . . . . . 10 94 4.5. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . 12 95 4.6. Preemption Behaviour . . . . . . . . . . . . . . . . . . . 13 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 97 5.1. Assignment of QSPEC Parameter IDs . . . . . . . . . . . . 14 98 5.2. Restoration Priority Parameter Registry . . . . . . . . . 14 99 5.2.1. Restoration Priority Field . . . . . . . . . . . . . . 14 100 5.2.2. Time to Restore Field . . . . . . . . . . . . . . . . 14 101 5.2.3. Extent of Restoration Field . . . . . . . . . . . . . 15 102 5.2.4. Reserved Bits . . . . . . . . . . . . . . . . . . . . 15 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 106 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 107 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 110 1. Introduction 112 This draft describes a QoS model (QOSM) for Next Steps in Signaling 113 (NSIS) QoS signaling layer protocol (QoS-NSLP) application based on 114 ITU-T Recommendation Y.1541 Network QoS Classes and related guidance 115 on signaling. [Y.1541] currently specifies 8 classes of Network 116 Performance objectives, and the Y.1541-QOSM extensions include 117 additional QSPEC [I-D.ietf-nsis-qspec] parameters and QOSM processing 118 guidelines. The extensions are based on standardization work in the 119 ITU-T on QoS signaling requirements [Y.1541] and [E.361], and 120 guidance in [TRQ-QoS-SIG]. 122 [I-D.ietf-nsis-qos-nslp] defines message types and control 123 information for the QoS-NSLP generic to all QOSMs. A QOSM is a 124 defined mechanism for achieving QoS as a whole. The specification of 125 a QOSM includes a description of its QSPEC parameter information, as 126 well as how that information should be treated or interpreted in the 127 network. The QSPEC [I-D.ietf-nsis-qspec] contains a set of 128 parameters and values describing the requested resources. It is 129 opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and 130 AdSpec specified in [RFC2205] [RFC2210]. A QOSM provides a specific 131 set of parameters to be carried in the QSPEC object. At each QoS 132 NSIS Entity (QNE), the QSPEC contents are interpreted by the resource 133 management function (RMF) for purposes of policy control and traffic 134 control, including admission control and configuration of the 135 scheduler. 137 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements 139 As stated above, [Y.1541] is a specification of standardized QoS 140 classes for IP networks (a summary of these classes is given below). 141 Section 7 of [TRQ-QoS-SIG] describes the signaling features needed to 142 achieve end-to-end QoS in IP networks, with Y.1541 QoS classes as a 143 basis. [Y.1541] recommends a flexible allocation of the end-to-end 144 performance objectives (e.g., delay) across networks, rather than a 145 fixed per-network allocation. NSIS protocols already address most of 146 the requirements; this document identifies additional QSPEC 147 parameters and processing requirements needed to support the Y.1541 148 QOSM. 150 2.1. Description of Y.1541 Classes 152 [Y.1541] proposes grouping services into QoS classes defined 153 according to the desired QoS performance objectives. These QoS 154 classes support a wide range of user applications. The classes group 155 objectives for one-way IP packet delay, IP packet delay variation, IP 156 packet loss ratio, etc., where the parameters themselves are defined 157 in [Y.1540]. 159 Note that [Y.1541] is maintained by the ITU-T and subject to 160 occasional updates and revisions. The material in this section is 161 provided for information and to make this document easier to read. 162 In the event of any discrepancies, the normative definitions found in 163 [Y.1541] take precidence. 165 Classes 0 and 1 might be implemented using the DiffServ Expedited 166 Forwarding (EF) Per-Hop Behavior (PHB), and support interactive real- 167 time applications[RFC3246]. Classes 2, 3, and 4 might be implemented 168 using the DiffServ Assured Forwarding (AFxy) PHB Group, and support 169 data transfer applications with various degrees of 170 interactivity[RFC2597]. Class 5 generally corresponds to the 171 DiffServ Default PHB, has all the QoS parameters unspecified 172 consistent with a best-effort service[RFC2474]. Classes 6 and 7 173 provide support for extremely loss-sensitive user applications, such 174 as high quality digital television, Time Division Multiplex (TDM) 175 circuit emulation, and high capacity file transfers using TCP. These 176 classes are intended to serve as a basis for agreements between end- 177 users and service providers, and between service providers. They 178 support a wide range of user applications including point-to-point 179 telephony, data transfer, multimedia conferencing, and others. The 180 limited number of classes supports the requirement for feasible 181 implementation, particularly with respect to scale in global 182 networks. 184 The QoS classes apply to a packet flow, where [Y.1541] defines a 185 packet flow as the traffic associated with a given connection or 186 connectionless stream having the same source host, destination host, 187 class of service, and session identification. The characteristics of 188 each Y.1541 QoS class are summarized here: 190 Class 0: Real-time, highly interactive applications, sensitive to 191 jitter. Mean delay upper bound is 100 ms, delay variation is less 192 than 50 ms, and loss ratio is less than 10^-3. Application examples 193 include VoIP, Video Teleconference. 195 Class 1: Real-time, interactive applications, sensitive to jitter. 196 Mean delay upper bound is 400 ms, delay variation is less than 50 ms, 197 and loss ratio is less than 10^-3. Application examples include 198 VoIP, video teleconference. 200 Class 2: Highly interactive transaction data. Mean delay upper bound 201 is 100 ms, delay variation is unspecified, and loss ratio is less 202 than 10^-3. Application examples include signaling. 204 Class 3: Interactive transaction data. Mean delay upper bound is 400 205 ms, delay variation is unspecified, and loss ratio is less than 206 10^-3. Application examples include signaling. 208 Class 4: Low Loss Only applications. Mean delay upper bound is 1s, 209 delay variation is unspecified, and loss ratio is less than 10^-3. 210 Application examples include short transactions, bulk data, video 211 streaming 213 Class 5: Unspecified applications with unspecified mean delay, delay 214 variation, and loss ratio. Application examples include traditional 215 applications of Default IP Networks 217 Class 6: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio 218 <= 10^-5. Applications that are highly sensitive to loss, such as 219 television transport, high-capacity TCP transfers, and TDM circuit 220 emulation. 222 Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio 223 <= 10^-5. Applications that are highly sensitive to loss, such as 224 television transport, high-capacity TCP transfers, and TDM circuit 225 emulation. 227 These classes enable SLAs to be defined between customers and network 228 service providers with respect to QoS requirements. The service 229 provider then needs to ensure that the requirements are recognized 230 and receive appropriate treatment across network layers. 232 Work is in progress to specify methods for combining local values of 233 performance metrics to estimate the performance of the complete path. 234 See section 8 of [Y.1541], [I-D.ietf-ippm-framework-compagg], and 235 [I-D.ietf-ippm-spatial-composition]. 237 2.2. Y.1541-QOSM Processing Requirements 239 [TRQ-QoS-SIG] guides the specification of signaling information for 240 IP-based QoS at the interface between the user and the network (UNI) 241 and across interfaces between different networks (NNI). To meet 242 specific network performance requirements specified for the Y.1541 243 QoS classes [Y.1541] , a network needs to provide specific user plane 244 functionality at UNI and NNI interfaces. Dynamic network 245 provisioning at a UNI and/or NNI node allows the ability to 246 dynamically request a traffic contract for an IP flow from a specific 247 source node to one or more destination nodes. In response to the 248 request, the network determines if resources are available to satisfy 249 the request and provision the network. 251 For implementations to claim compliance with this memo, it MUST be 252 possible to derive the following service level parameters as part of 253 the process of requesting service: 255 a. Y.1541 QoS class, 32 bit integer, range : 0-7 257 b. rate (r), octets per second 259 c. peak rate (p), octets per second 261 d. bucket size (b), octets 263 e. maximum packet size (M), octets, IP header + IP payload 265 f. DiffServ PHB class [RFC2475] 267 g. admission priority, 32 bit integer, range : 0-2 269 Compliant implementations MAY derive the following service level 270 parameters as part of the service request process: 272 h. peak bucket size (Bp)*, octets, 32 bit floating point number in 273 single-precision IEEE floating point format [IEEE754] 275 i. restoration priority*, multiple integer values defined in Section 276 3 below 278 All parameters except Bp and restoration priority have already been 279 specified in [I-D.ietf-nsis-qspec]. These additional parameters are 280 defined as 282 o Bp, The size of the peak-rate bucket in a dual token bucket 283 arrangement, essentially setting the maximum length of bursts in 284 the peak-rate stream. For example, see Annex B of [Y.1221] 286 o restoration priority, as defined in Section 3 of this memo 288 and their QSPEC Parameter format is specified in Section 3. 290 It MUST be possible to perform the following QoS-NSLP signaling 291 functions to meet Y.1541-QOSM requirements: 293 a. accumulate delay, delay variation and loss ratio across the end- 294 to-end connection, which may span multiple domains 296 b. enable negotiation of Y.1541 QoS class across domains. 298 c. enable negotiation of delay, delay variation, and loss ratio 299 across domains. 301 These signaling requirements are supported in 302 [I-D.ietf-nsis-qos-nslp] and the functions are illustrated in Section 303 4 of this memo. 305 3. Additional QSPEC Parameters for Y.1541 QOSM 307 The specifications in this section extend the QSPEC 308 [I-D.ietf-nsis-qspec]. 310 3.1. Traffic Model (TMOD) Extension Parameter 312 The traffic model (TMOD) extension parameter is represented by one 313 floating point number in single-precision IEEE floating point format 314 and one 32-bit reserved field. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |M|E|N|r| 15 |r|r|r|r| 1 | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 1: TMOD Extension 326 The Peak Bucket Size term, Bp, is represented as an IEEE floating 327 point value [IEEE754] in units of octets. The sign bit MUST be zero 328 (all values MUST be non-negative). Exponents less than 127 (i.e., 0) 329 are prohibited. Exponents greater than 162 (i.e., positive 35) are 330 discouraged, except for specifying a peak rate of infinity. Infinity 331 is represented with an exponent of all ones (255) and a sign bit and 332 mantissa of all zeros. 334 The QSPEC parameter behavior for the TMOD extended parameter follows 335 that defined in Section 3.3.1 of[I-D.ietf-nsis-qspec]. The new 336 parameter (and all traffic-related parameters) are specified 337 independently from the Y.1541 class parameter. 339 3.2. Restoration Priority Parameter 341 Restoration priority is the urgency with which a service requires 342 successful restoration under failure conditions. Restoration 343 priority is achieved by provisioning sufficient backup capacity, as 344 necessary, and allowing relative priority for access to available 345 bandwidth when there is contention for restoration bandwidth. 346 Restoration priority is defined as follows: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |M|E|N|r| 16 |r|r|r|r| 1 | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Rest. Priority| TTR | EOR | (Reserved) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 2: Restoration Priority Parameter 358 This parameter has three fields and a reserved area, as defined 359 below. 361 Restoration Priority Field (8-bit unsigned integer): 3 priority 362 values are listed here in the order of lowest priority to highest 363 priority: 365 0 - best effort 367 1 - normal 369 2 - high 371 These priority values are described in [Y.2172], where best effort 372 priority is the same as Priority level 3, normal priority is Priority 373 level 2, and high priority is the same as Priority level 1. There 374 are several ways to elaborate on restoration priority, and the two 375 current parameters are described below. 377 Time-to-Restore (TTR) Field (4-bit unsigned integer): Total amount of 378 time to restore traffic streams belonging to a given restoration 379 class impacted by the failure. This time period depends on the 380 technology deployed for restoration. A fast recovery period of < 200 381 ms is based on current experience with SONET rings and a slower 382 recovery period of 2 seconds is suggested in order to enable a voice 383 call to recover without being dropped. Accordingly, TTR restoration 384 suggested ranges are: 386 0 - Unspecified Time-to-Restore 388 1 - Best Time-to-Restore: <= 200 ms 390 2 - Normal Time-to-Restore <= 2 s 392 Extent of Restoration (EOR) Field (4-bit unsigned integer): 393 Percentage of traffic belonging to the restoration class that can be 394 restored. This percentage depends on the amount of spare capacity 395 engineered. All high priority restoration priority traffic, for 396 example, may be "guaranteed" at 100% by the service provider. Other 397 classes may offer lesser chances for successful restoration. The 398 restoration extent for these lower priority classes depend on SLA 399 agreements developed between the service provider and the customer. 401 EOR values are assigned as follows: 403 0 - unspecified EOR 405 1 - high priority restored at 100%; medium priority restored at 100% 407 2 - high priority restored at 100%; medium priority restored at 80% 409 3 - high priority restored >= 80%; medium priority restored >= 80% 411 4 - high priority restored >= 80%; medium priority restored >= 60% 413 5 - high priority restored >= 60%; medium priority restored >= 60% 415 Reserved: These 2 octets are reserved. The Reserved bits MAY be 416 designated for other uses in the future. Senders conforming to this 417 version of the Y.1541 QOSM SHALL set the Reserved bits to zero. 418 Receivers conforming to this version of the Y.1541 QOSM SHALL ignore 419 the Reserved bits. 421 4. Y.1541-QOSM Considerations and Processing Example 423 In this Section we illustrate the operation of the Y.1541 QOSM, and 424 show how current QoS-NSLP and QSPEC functionality is used. No new 425 processing capabilities are required to enable the Y.1541 QOSM 426 (excluding the two OPTIONAL new parameters specified in Section 3). 428 4.1. Deployment Considerations 430 [TRQ-QoS-SIG] emphasizes the deployment of Y.1541 QNEs at the borders 431 of supporting domains. There may be domain configurations where 432 interior QNEs are desirable, and the example below addresses this 433 possibility. 435 4.2. Applicable QSPEC Procedures 437 All procedures defined in section 5.3 of [I-D.ietf-nsis-qspec] are 438 applicable to this QOSM. 440 4.3. QNE Processing Rules 442 Section 7 of [TRQ-QoS-SIG] describes the information processing in 443 Y.1541 QNEs. 445 Section 8 of [Y.1541] defines the accumulation rules for individual 446 performance parameters (e.g., delay, jitter). 448 When a QoS NSIS initiator (QNI) specifies the Y.1541 QoS Class 449 number, , it is a sufficient specification of 450 objectives for the , , and 451 parameters. As described above in section 2, some Y.1541 Classes do 452 not set objectives for all the performance parameters above. For 453 example, Classes 2, 3, and 4, do not specify an objective for (referred to as IP Packet Delay Variation). In the case that 455 the QoS Class leaves a parameter Unspecified, then that parameter 456 need not be included in the accumulation processing. 458 4.4. Processing Example 460 As described in the example given in Section 3.4 of 461 [I-D.ietf-nsis-qspec] and as illustrated in Figure 3, the QoS NSIS 462 initiator (QNI) initiates an end-to-end, inter-domain QoS NSLP 463 RESERVE message containing the Initiator QSPEC. In the case of the 464 Y.1541 QOSM, the Initiator QSPEC specifies the , 465 , , , , and perhaps other QSPEC parameters for the flow. As 467 described in Section 3, the TMOD extension parameter contains the 468 OPTIONAL Y.1541-QOSM-specific terms; restoration priority is also an 469 OPTIONAL Y.1541-QOSM-specific parameter. 471 As Figure 3 below shows, the RESERVE message may cross multiple 472 domains supporting different QOSMs. In this illustration, the 473 initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress 474 node of the local-QOSM domain. As described in 475 [I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec], at the ingress 476 edge node of the local-QOSM domain, the end-to-end, inter-domain QoS- 477 NSLP message may trigger the generation of a local QSPEC, and the 478 initiator QSPEC encapsulated within the messages signaled through the 479 local domain. The local QSPEC is used for QoS processing in the 480 local-QOSM domain, and the Initiator QSPEC is used for QoS processing 481 outside the local domain. As specified in [I-D.ietf-nsis-qspec], if 482 any QNE cannot meet the requirements designated by the initiator 483 QSPEC to support an optional QSPEC parameter, with the M bit set to 484 zero for the parameter, for example, it cannot support the 485 accumulation of end-to-end delay with the parameter, 486 the QNE sets the N flag (not supported flag) for the path latency 487 parameter to one. 489 Also, the Y.1541-QOSM requires negotiation of the 490 across domains. This negotiation can be done with the use of the 491 existing procedures already defined in [I-D.ietf-nsis-qos-nslp]. For 492 example, the QNI sets , , 493 objects to include , which specifies objectives for 494 the , , parameters. In the 495 case that the QoS Class leaves a parameter Unspecified, then that 496 parameter need not be included in the accumulation processing. The 497 QNE/domain SHOULD set the Y.1541 class and cumulative parameters, 498 e.g., , that can be achieved in the 499 object (but not less than specified in ). This could 500 include, for example, setting the to a lower class 501 than specified in (but not lower than specified in 502 ). If the fails to satisfy one or more 503 of the objectives, the QNE/domain notifies the QNI and 504 the reservation is aborted. Otherwise, the QoS NSIS Receiver (QNR) 505 notifies the QNI of the for the reservation. 507 When the available must be reduced from the 508 desired , say because the delay objective has been 509 exceeded, then there is an incentive to respond with an available 510 value for delay in the parameter. If the available 511 is 150 ms (still useful for many applications) and the 512 desired QoS is Class 0 (with its 100 ms objective), then the response 513 would be that Class 0 cannot be achieved and Class 1 is available 514 (with its 400 ms objective). In addition, this QOSM allows the 515 response to include an available = 150 ms, making 516 acceptance of the available more likely. There 517 are many long paths where the propagation delay alone exceeds the 518 Y.1541 Class 0 objective, so this feature adds flexibility to commit 519 to exceed the Class 1 objective when possible. 521 This example illustrates Y.1541-QOSM negotiation of and cumulative parameter values that can be achieved end-to- 523 end. The example illustrates how the QNI can use the cumulative 524 values collected in to decide if a lower than specified in is acceptable. 527 |------| |------| |------| |------| 528 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 529 | QOSM | | QOSM | | QOSM | | QOSM | 530 | | |------| |-------| |-------| |------| | | 531 | NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | 532 |Y.1541| |local | |local | |local | |local | |Y.1541| 533 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 534 |------| |------| |-------| |-------| |------| |------| 535 ----------------------------------------------------------------- 536 |------| |------| |-------| |-------| |------| |------| 537 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 538 |------| |------| |-------| |-------| |------| |------| 539 QNI QNE QNE QNE QNE QNR 540 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 542 Figure 3: Example of Y.1541-QOSM Operation 544 4.5. Bit-Level QSPEC Example 546 This is an example where the QOS Desired specification contains the 547 TMOD-1 parameters and TMOD extended parameters defined in this 548 specification, as well as the Y.1541 Class parameter. The QOS 549 Available specification utilizes the Latency, Jitter, and Loss 550 parameters to enable accumulation of these parameters for easy 551 comparison with the objectives desired fir the Y.1541 Class. 553 This example assumes that all the parameters MUST be supported by the 554 QNEs, so all M-flags have been set to "1". 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Vers.|QType=I|QSPEC Proc.=0/1|0|R|R|R| Length = 23 | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 10 | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Maximum Packet Size [M] (32-bit unsigned integer) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 |1|E|N|r| 15 |r|r|r|r| 1 | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 |1|E|N|r| 14 |r|r|r|r| 1 | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 |Y.1541 QoS Cls.| (Reserved) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |E|r|r|r| Type = 1 (QoS Avail) |r|r|r|r| Length = 11 | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 |1|E|N|r| 3 |r|r|r|r| 1 | 586 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 587 | Path Latency (32-bit integer) | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 |1|E|N|r| 4 |r|r|r|r| 4 | 590 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 591 | Path Jitter STAT1(variance) (32-bit integer) | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Path Jitter STAT4(Reserved) (32-bit integer) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |1|E|N|r| 5 |r|r|r|r| 1 | 600 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 601 | Path Packet Loss Ratio (32-bit floating point) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |1|E|N|r| 14 |r|r|r|r| 1 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |Y.1541 QoS Cls.| (Reserved) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 4: An Example QSPEC (Initiator) 610 where 32-bit floating point numbers are as specified in [IEEE754]. 612 4.6. Preemption Behaviour 614 The default QNI behaviour of tearing down a preempted reservation is 615 followed in the Y.1541 QOSM. The restoration priority parameter 616 described above does not rely on preemption. 618 5. IANA Considerations 620 This section defines additional codepoint assignments in the QSPEC 621 Parameter ID registry and requests the establishment of one new 622 registry for the Restoration Priority Parameter (and assigns initial 623 values), in accordance with BCP 26 [RFC5226]. It also defines the 624 procedural requirements to be followed by IANA in allocating new 625 codepoints for the new Registry. 627 5.1. Assignment of QSPEC Parameter IDs 629 This document specifies the following QSPEC parameters to be assigned 630 within the QSPEC Parameter ID registry created in 631 [I-D.ietf-nsis-qspec]: 633 parameter (Section 3.1 above, suggested ID=15) 635 parameter (Section 3.2 above, suggested ID=16) 637 5.2. Restoration Priority Parameter Registry 639 The Registry for Restoration Priority contains assignments for three 640 fields in the 4 octet word, and a Reserved section of the word. 642 This specification creates the following registry with the structure 643 as defined below: 645 5.2.1. Restoration Priority Field 647 The Restoration Priority Field is 8 bits in length. 649 The following values are allocated by this specification: 651 0-2: assigned as specified in Section 3.2: 653 0: best-effort priority 655 1: normal priority 657 2: high priority 659 The allocation policies for further values are as follows: 661 3-255: Specification Required 663 5.2.2. Time to Restore Field 665 The Time to Restore Field is 4 bits in length. 667 The following values are allocated by this specification: 669 0-2: assigned as specified in Section 3.2: 671 0 - Unspecified Time-to-Restore 673 1 - Best Time-to-Restore: <= 200 ms 675 2 - Normal Time-to-Restore <= 2 s 677 The allocation policies for further values are as follows: 679 3-15: Specification Required 681 5.2.3. Extent of Restoration Field 683 The Extent of Restoration (EOR) Field is 4 bits in length. 685 The following values are allocated by this specification: 687 0-5: assigned as specified in Section 3.2: 689 EOR values are assigned as follows: 691 0 - unspecified EOR 693 1 - high priority restored at 100%; medium priority restored at 100% 695 2 - high priority restored at 100%; medium priority restored at 80% 697 3 - high priority restored >= 80%; medium priority restored >= 80% 699 4 - high priority restored >= 80%; medium priority restored >= 60% 701 5 - high priority restored >= 60%; medium priority restored >= 60% 703 The allocation policies for further values are as follows: 705 6-15: Specification Required 707 5.2.4. Reserved Bits 709 The remaining bits in the Restoration Priority Parameter are 710 Reserved. The Reserved bits MAY be designated for other uses in the 711 future. 713 6. Security Considerations 715 The security considerations of [I-D.ietf-nsis-qos-nslp] and 716 [I-D.ietf-nsis-qspec] apply to this Document. 718 The restoration priority parameter raises possibilities for theft of 719 service attacks because users could claim an emergency priority for 720 their flows without real need, thereby effectively preventing serious 721 emergency calls to get through. Several options exist for countering 722 such attacks, for example 724 - only some user groups (e.g. the police) are authorized to set the 725 emergency priority bit 727 - any user is authorized to employ the emergency priority bit for 728 particular destination addresses (e.g. police or fire departments) 730 There are no other known security considerations based on this 731 document. 733 7. Acknowledgements 735 The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, 736 and Hannes Tschofenig for helpful comments and discussion. 738 8. References 740 8.1. Normative References 742 [I-D.ietf-nsis-qos-nslp] 743 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 744 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 745 (work in progress), January 2010. 747 [I-D.ietf-nsis-qspec] 748 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 749 Template", draft-ietf-nsis-qspec-24 (work in progress), 750 January 2010. 752 [IEEE754] ANSI/IEEE, "ANSI/IEEE 754-1985, IEEE Standard for Binary 753 Floating-Point Arithmetic", 1985. 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [Y.1221] ITU-T Recommendation Y.1221, "Traffic control and 759 congestion control in IP based networks", March 2002. 761 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 762 communication service - IP packet transfer and 763 availability performance parameters", December 2007. 765 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 766 Objectives for IP-Based Services", February 2006. 768 [Y.2172] ITU-T Recommendation Y.2172, "Service restoration priority 769 levels in Next Generation Networks", June 2007. 771 8.2. Informative References 773 [E.361] ITU-T Recommendation E.361, "QoS Routing Support for 774 Interworking of QoS Service Classes Across Routing 775 Technologies", May 2003. 777 [I-D.ietf-ippm-framework-compagg] 778 Morton, A., "Framework for Metric Composition", 779 draft-ietf-ippm-framework-compagg-09 (work in progress), 780 December 2009. 782 [I-D.ietf-ippm-spatial-composition] 783 Morton, A. and E. Stephan, "Spatial Composition of 784 Metrics", draft-ietf-ippm-spatial-composition-10 (work in 785 progress), October 2009. 787 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 788 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 789 Functional Specification", RFC 2205, September 1997. 791 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 792 Services", RFC 2210, September 1997. 794 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 795 "Definition of the Differentiated Services Field (DS 796 Field) in the IPv4 and IPv6 Headers", RFC 2474, 797 December 1998. 799 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 800 and W. Weiss, "An Architecture for Differentiated 801 Services", RFC 2475, December 1998. 803 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 804 "Assured Forwarding PHB Group", RFC 2597, June 1999. 806 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 807 J., Courtney, W., Davari, S., Firoiu, V., and D. 808 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 809 Behavior)", RFC 3246, March 2002. 811 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 812 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 813 May 2008. 815 [TRQ-QoS-SIG] 816 ITU-T Supplement 51 to the Q-Series, "Signaling 817 Requirements for IP-QoS", January 2004. 819 Authors' Addresses 821 Gerald Ash 822 AT&T Labs 823 200 Laurel Avenue South 824 Middletown,, NJ 07748 825 USA 827 Phone: 828 Fax: 829 Email: gash5107@yahoo.com 830 URI: 832 Al Morton 833 AT&T Labs 834 200 Laurel Avenue South 835 Middletown,, NJ 07748 836 USA 838 Phone: +1 732 420 1571 839 Fax: +1 732 368 1192 840 Email: acmorton@att.com 841 URI: http://home.comcast.net/~acmacm/ 842 Martin Dolly 843 AT&T Labs 844 200 Laurel Avenue South 845 Middletown,, NJ 07748 846 USA 848 Phone: 849 Fax: 850 Email: mdolly@att.com 851 URI: 853 Percy Tarapore 854 AT&T Labs 855 200 Laurel Avenue South 856 Middletown,, NJ 07748 857 USA 859 Phone: 860 Fax: 861 Email: tarapore@att.com 862 URI: 864 Chuck Dvorak 865 AT&T Labs 866 180 Park Ave Bldg 2 867 Florham Park,, NJ 07932 868 USA 870 Phone: + 1 973-236-6700 871 Fax: 872 Email: cdvorak@att.com 873 URI: http: 875 Yacine El Mghazli 876 Alcatel-Lucent 877 Route de Nozay 878 Marcoussis cedex, 91460 879 France 881 Phone: +33 1 69 63 41 87 882 Fax: 883 Email: yacine.el_mghazli@alcatel.fr 884 URI: