idnits 2.17.1 draft-ietf-nsis-y1541-qosm-01.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 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 532. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6643 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Bb' is mentioned on line 245, but not defined == Missing Reference: 'Rs' is mentioned on line 247, but not defined == Missing Reference: 'RMD' is mentioned on line 329, but not defined == Missing Reference: 'RFC2434' is mentioned on line 422, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC2205' is defined on line 455, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'QSPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRQ-QoS-SIG' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group Jerry Ash 2 Internet Draft Martin Dolly 3 Chuck Dvorak 4 Expiration Date: August 2006 Al Morton 5 Percy Tarapore 6 AT&T 7 Yacine El Mghazli 8 Alcatel 10 February 2006 12 Y.1541-QOSM -- Y.1541 QoS Model 13 for Networks Using Y.1541 QoS Classes 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 28, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T 47 Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 48 standard QoS classes, and the Y.1541-QOSM extensions include 49 additional QSPEC parameters and QOSM control processing guidelines. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Summary of ITU-T Recommendations Y.1541 & Signaling 55 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1 Y.1541 QoS Classes . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Y.1541 Signaling Requirements . . . . . . . . . . . . . . 5 58 3. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . 6 59 3.1 Parameters . . . . . . . . . . . 6 60 3.2 Parameter . . . . . . . . . . . . . 6 61 4. Control Processing for Y.1541 QOSM . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 66 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 67 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 68 11. Intellectual Property Statement . . . . . . . . . . . . . . . 11 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 70 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . 12 72 Conventions Used in This Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [RFC2119]. 78 1. Introduction 80 This draft describes a QoS model (QOSM) for QoS-NSIS signaling 81 layer protocol (QoS-NSLP) application based on ITU-T Recommendation 82 Y.1541 QoS signaling requirements. Y.1541 currently specifies 6 83 standard QoS classes, and the Y.1541-QOSM extensions include 84 additional QSPEC parameters and QOSM control processing guidelines. 85 The extensions are based on standardization work in the ITU-T on QoS 86 signaling requirements [Y.1541, TRQ-QoS-SIG, E.361]. 88 [QoS-SIG] defines message types and control information for the 89 QoS-NSLP generic to all QOSMs. A QOSM is a defined mechanism for 90 achieving QoS as a whole. The specification of a QOSM includes a 91 description of its QSPEC parameter information, as well as how that 92 information should be treated or interpreted in the network. The 93 QSPEC [QSPEC] contains a set of parameters and values describing the 94 requested resources. It is opaque to the QoS-NSLP and similar in 95 purpose to the TSpec, RSpec and AdSpec specified in [RFC2205, 96 RFC2210]. The QSPEC object contains control information and the QoS 97 parameters defined by the QOSM. A QOSM provides a specific set of 98 parameters to be carried in the QSPEC - IntServ [RFC2210], DiffServ 99 [RFC2475], and [Y.1541] are examples of QOSMs. At each QoS NSIS 100 element (QNE), its contents are interpreted by the resource 101 management function (RMF) for the purposes of policy control and 102 traffic control (including admission control and configuration of the 103 packet classifier and scheduler). 105 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements 107 As stated above, Recommendation [Y.1541] is a specification of 108 standardized QoS classes for IP networks (a summary of these classes 109 is given below). Recommendation [TRQ-QoS-SIG] specifies the 110 requirements for achieving end-to-end QoS in IP networks, with Y.1541 111 QoS classes as a basis. Y.1541 recommends a flexible allocation of 112 the end-to-end performance objectives (e.g., delay) across networks, 113 rather than a fixed per-network allocation. NSIS protocols already 114 address most of the requirements, this document identifies additional 115 QSPEC parameters and control information needed to support the Y.1541 116 QOSM. 118 2.1 Y.1541 QoS Classes 120 [Y.1541] proposes grouping services into QoS classes defined 121 according to the desired QoS performance objectives. These QoS 122 classes support a wide range of user applications. The classes group 123 objectives for one-way IP packet delay, IP packet delay variation, IP 124 packet loss ratio, etc. Classes 0 and 1, which generally correspond 125 to the DiffServ EF PHB, support interactive real-time applications. 126 Classes 2, 3, and 4, which generally correspond to the DiffServ AFxy 127 PHB Group, support non-interactive applications. Class 5, which 128 generally corresponds to the DiffServ best-effort PHB, has all the 129 QoS parameters unspecified. These classes serve as a basis for 130 agreements between end-users and service providers, and between 131 service providers. They support a wide range of traffic applications 132 including point-to-point telephony, data transfer, multimedia 133 conferencing, and others. The limited number of classes supports the 134 requirement for feasible implementation, particularly with respect to 135 scale in global networks. 137 The QoS classes apply to a packet flow, where [Y.1541] defines a 138 packet flow as the traffic associated with a given connection or 139 connectionless stream having the same source host, destination host, 140 class of service, and session identification. The characteristics of 141 each Y.1451 QoS class are summarized here: 143 Class 0: Real-time, highly interactive applications, sensitive to 144 jitter. Mean delay upper bound is 100 ms, delay variation is less 145 than 50 ms, and loss ratio is less than 10^-3. Application examples 146 include VoIP, Video Teleconference. 148 Class 1: Real-time, interactive applications, sensitive to jitter. 149 Mean delay upper bound is 400 ms, delay variation is less than 50 ms, 150 and loss ratio is less than 10^-3. Application examples include VoIP, 151 video teleconference. 153 Class 2: Highly interactive transaction data. Mean delay upper bound 154 is 100 ms, delay variation is unspecified, and loss ratio is less 155 Than 10^-3. Application examples include signaling. 157 Class 3: Interactive transaction data. Mean delay upper bound is 400 158 ms, delay variation is unspecified, and loss ratio is less than 159 10^-3. Application examples include signaling. 161 Class 4: Low Loss Only applications. Mean delay upper bound is 1s, 162 delay variation is unspecified, and loss ratio is less than 10^-3. 163 Application examples include short transactions, bulk data, video 164 streaming 166 Class 5: Unspecified applications with unspecified mean delay, delay 167 variation, and loss ratio. Application examples include traditional 168 applications of Default IP Networks 170 These classes enable SLAs to be defined between customers and network 171 service providers with respect to QoS requirements. The service 172 provider then needs to ensure that the requirements are recognized 173 and receive appropriate treatment across network layers. 175 Recommendation Y.1541 is currently being enhanced to provide support 176 for extremely loss-sensitive user applications, such as high quality 177 digital television, TDM circuit emulation, and high capacity 178 transfers using TCP. The plan is to add a minimal number of classes 179 to meet these needs. 181 2.2 Y.1541 Signaling Requirements 183 [TRQ-QoS-SIG] provides the requirements for signaling information 184 regarding IP-based QoS at the interface between the user and the 185 network (UNI) and across interfaces between different networks (NNI). 186 To meet specific network performance requirements specified for the 187 Y.1541 QoS classes, a network needs to provide specific user plane 188 functionality at UNI, NNI, and INI interfaces. Dynamic network 189 provisioning at a UNI and/or NNI node allows the ability to 190 dynamically request a traffic contract for an IP flow from a specific 191 source node to one or more destination nodes. In response to the 192 request, the network determines if resources are available to satisfy 193 the request and provision the network. 195 The call/session control signaling includes an indication of the QoS 196 requirements for each session. Obtaining user-to-user QoS will 197 require standard signaling protocols for communicating the 198 requirements among the major entities. These entities include users 199 and their end terminal equipment, and network service providers and 200 their equipment, especially equipment implementing the inter-working 201 and signaling function between networks, and between users and 202 networks. 204 It MUST be possible to derive the following service level parameters 205 as part of the process of requesting service: 207 a. Y.1541 QoS class 208 b. peak data rate (p) 209 c. peak bucket size (Bp) 210 d. sustainable rate (Rs) 211 e. sustainable bucket size (b) 212 f. token bucket rate (r) 213 g. maximum allowed packet size (M) 214 h. DiffServ field [RFC2475] 215 i. reservation priority class (urgency of establishing service 216 connection) can be requested 217 j. restoration priority class (urgency of restoring service 218 connection under failure) can be requested 220 All parameters except , , and have 221 already been specified in [QSPEC]. These additional parameters are 222 specified in Section 3. 224 It MUST be possible to perform the following QoS-NSLP signaling 225 functions to enable Y.1541-QOSM requirements: 227 a. accumulate delay, delay variation and loss ratio across the 228 end-to-end connection, which may span multiple domains 229 b. enable negotiation of Y.1541 QoS class across domains. 230 c. enable negotiation of delay, delay variation, and loss ratio 231 across domains. 233 Additional signaling functions beyond those already specified in 234 [QSPEC] are discussed in Section 4. 236 3. Additional QSPEC Parameters for Y.1541 QOSM 238 3.1 Parameters 240 The parameters are represented by two 241 floating point numbers in single-precision IEEE floating point 242 format. 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Peak Bucket Size [Bb] (32-bit IEEE floating point number) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Sustainable Rate [Rs] (32-bit IEEE floating point number) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 When the Bp and Rs terms are represented as IEEE floating point 251 values, the sign bit MUST be zero (all values MUST be non-negative). 252 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 253 than 162 (i.e., positive 35) are discouraged, except for specifying a 254 peak rate of infinity. Infinity is represented with an exponent of 255 all ones (255) and a sign bit and mantissa of all zeroes. 257 3.2 Parameter 259 Restoration priority is the urgency with which a service requires 260 successful restoration under failure conditions. Restoration 261 priority is achieved by provisioning sufficient backup capacity, as 262 necessary, and allowing relative priority for access to available 263 bandwidth when there is contention for restoration bandwidth. 264 Restoration priority is defined as follows: 266 0 1 2 3 4 5 6 7 267 +-+-+-+-+-+-+-+-+ 268 | Restoration | 269 | Priority | 270 +-+-+-+-+-+-+-+-+ 272 Restoration Priority: 8 bits 273 3 priority values are listed here in the order of lowest priority to 274 highest priority: 276 2 - best effort 277 1 - normal 278 0 - high 280 Each restoration priority class has two parameters: 282 a. Time-to-Restore: Total amount of time to restore traffic streams 283 belonging to a given restoration class impacted by the failure. This 284 time period depends on the technology deployed for restoration. A 285 fast recovery period of < 200 ms is based on current experience with 286 SONET rings and a slower recovery period of 2 seconds is suggested in 287 order to enable a voice call to recover without being dropped. 288 Accordingly, candidate restoration objectives are: 290 High Restoration Priority: Time-to-Restore <= 200 ms 291 Normal Restoration Priority: Time-to-Restore <= 2 s. 292 Best Effort Restoration Priority: Time-to-Restore = Unspecified 294 b. Extent of Restoration: Percentage of traffic belonging to the 295 restoration class that can be restored. This percentage depends on 296 the amount of spare capacity engineered. All high priority 297 restoration priority traffic, for example, may be "guaranteed" at 298 100% by the service provider. Other classes may offer lesser chances 299 for successful restoration. The restoration extent for these lower 300 priority classes depend on SLA agreements developed between the 301 service provider and the customer. 303 4. Control Processing for Y.1541 QOSM 305 In this Section we illustrate the operation of the Y.1541 QOSM, and 306 show how current QoS-NSLP and QSPEC functionality is used. No new 307 control processing capabilities or parameters are required to enable 308 the Y.1541 QOSM. 310 As described in the example given in [QSPEC], Section 4.3, and as 311 illustrated in Figure 1, the QoS NSIS initiator (QNI) initiates an 312 end-to-end, inter-domain QoS NSLP RESERVE message containing the 313 Initiator QSPEC. In the case of the Y.1541 QOSM, the Initiator QSPEC 314 specifies the , , , , , and 316 perhaps other generic QSPEC parameters for the flow. As described in 317 Section 3, the object contains the 318 optional, Y.1541-QOSM-Specific parameters and ; is also an optional, Y.1541-QOSM-Specific parameter. 321 As illustrated in Figure 1, the RESERVE message may cross multiple 322 domains supporting different QOSMs. In this illustration, the 323 Initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress 324 node of the Local-QOSM domain. As described in [QoS-SIG] and 325 [QSPEC], at the ingress edge node of the Local-QOSM domain, the 326 end-to-end, inter-domain QoS-NSLP messages trigger the generation of 327 a Local QSPEC, which is pushed on top of the Initiator QSPEC. That 328 is, the Initiator QSPEC is translated into a Local-QOSM QSPEC. For 329 example, if the Local-QOSM is the RMD-QOSM [RMD], then the parameter would be translated to the 331 parameter. The Local QSPEC is used for QoS processing in the 332 Local-QOSM domain, and then popped at the egress edge node of the 333 Local-QOSM domain. The Initiator QSPEC is then used for QoS 334 processing at the QoS NSIS receiver (QNR). 336 Each node on the data path checks the availability of resources and 337 accumulating the delay, delay variation, and loss ratio parameters, 338 as described below. If an intermediate node cannot accommodate the 339 new request, it indicates it by marking a single bit, the bit specified in [QSPEC], in the message, and continues 341 forwarding the message. When the message reaches the egress edge 342 node of the Local-QOSM domain, if no intermediate node has denied the 343 reservation, the Initiator QSPEC is forwarded to the next domain, as 344 described above. If an intermediate node has denied the reservation, 345 by setting the bit, the reservation is denied. 347 As specified in [QSPEC], if any QNE does not support the Y.1541 QOSM, 348 it sets the flag to one to indicate that it does not 349 support the Y.1541 QOSM. The flag is normally set to 350 zero. As specified in [QSPEC], if any QNE cannot meet the 351 requirements designated by the Initiator QSPEC to support an optional 352 QSPEC parameter, for example, it cannot support the accumulation of 353 end-to-end delay with the parameter, the QNE sets the 354 to one. The is normally set 355 to zero. 357 Also, the Y.1541-QOSM requires negotiation of the 358 across domains. This negotiation can be done with the use of the 359 existing procedures already defined in [QoS-SIG]. For example, the 360 QNI sets , , objects to 361 include , , , 362 parameters. The QNE/domain SHOULD set the Y.1541 class and 363 cumulative parameters, e.g., , that can be achieved in 364 the object (but not less than specified in ). This could include, for example, setting the to a lower class than specified in (but not 367 lower than specified in ). If the 368 fails to satisfy one or more of the objectives, the 369 QNE/domain notifies the QNI and the reservation is aborted. 370 Otherwise, the QNR notifies the QNI of the for the 371 reservation. 373 When the available must be reduced from the 374 desired , say because the delay objective 375 has been exceeded, then there is an incentive to respond with an 376 available value for delay in the parameter. If the 377 available is 150 ms (still useful for many 378 applications) and the desired QoS is Class 0 (with its 100 ms 379 objective), then the response would be that Class 0 cannot be 380 achieved and Class 1 is available (with its 400 ms objective). In 381 addition, this QOSM allows the response to include an available 382 = 150 ms, making acceptance of the available more likely. There are many long paths where the 384 propagation delay alone exceeds the Y.1541 Class 0 objective, so 385 this feature adds flexibility to commit to exceed the Class 1 386 objective when possible. 388 This example illustrates Y.1541-QOSM negotiation of and cumulative parameter values that can be achieve 390 end-to-end. The example illustrates how the QNI can use the 391 cumulative values collected in to decide if a lower 392 than specified in is acceptable. 394 |------| |------| |------| |------| 395 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 396 | QoS | | QoS | | QoS | | QoS | 397 | | |------| |-------| |-------| |------| | | 398 | | | local|<->| local |<->| local |<->| local| | | 399 | | | QoS | | QoS | | QoS | | QoS | | | 400 | | | | | | | | | | | | 401 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 402 |Y.1541| |local | |local | |local | |local | |Y.1541| 403 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 404 |------| |------| |-------| |-------| |------| |------| 405 ----------------------------------------------------------------- 406 |------| |------| |-------| |-------| |------| |------| 407 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 408 |------| |------| |-------| |-------| |------| |------| 409 QNI QNE QNE QNE QNE QNR 410 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 412 Figure 1 Protocol Model of Y.1541-QOSM Operation 414 5. Security Considerations 416 There are no new security considerations based on this draft. 418 6. IANA Considerations 420 This section provides guidance to the Internet Assigned Numbers 421 Authority (IANA) regarding registration of values related to the 422 QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 424 [QoS-SIG] requires IANA to create a new registry for QoS Model 425 Identifiers. The QoS Model Identifier (QOSM ID) is a 32-bit value 426 carried in a QSPEC object. The allocation policy for new QOSM IDs is 427 TBD. 429 This document also defines 3 new objects for the QSPEC Template, as 430 detailed in Section 3. Values are to be assigned for them from the 431 NTLP Object Type registry. 433 7. Acknowledgements 435 The authors thank Attila Bader, Cornelia Kappler, and Sven Van 436 den Bosch for helpful comments and discussion. 438 8. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 442 [QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service 443 Signaling," work in progress. 444 [QSPEC], Ash, J., et. al., "QoS-NSLP QSPEC Template," work in 445 progress. 446 [TRQ-QoS-SIG] ITU-T Recommendation, "Signaling Requirements for 447 IP-QoS," January 2004. 448 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 449 Objectives for IP-Based Services," May 2002. 451 9. Informative References 453 [E.361] ITU-T Recommendation, "QoS Routing Support for Interworking 454 of QoS Service Classes Across Routing Technologies," May 2003. 455 [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 456 - Version 1 Functional Specification," RFC 2205, September 1997. 457 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 458 Services," RFC 2210, September 1997. 459 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 460 Services", RFC 2475, December 1998. 462 10. Authors' Addresses 464 Jerry Ash 465 AT&T 466 Room MT D5-2A01 467 200 Laurel Avenue 468 Middletown, NJ 07748, USA 469 Phone: +1-(732)-420-4578 470 Email: gash@att.com 472 Martin Dolly 473 AT&T 474 Room E3-3A14 475 200 S. Laurel Avenue 476 Middletown, NJ 07748 477 Phone: + 1 732 420-4574 478 E-mail: mdolly@att.com 479 Chuck Dvorak 480 AT&T 481 Room 2A37 482 180 Park Avenue, Building 2 483 Florham Park, NJ 07932 484 Phone: + 1 973-236-6700 485 E-mail: cdvorak@att.com 487 Yacine El Mghazli 488 Alcatel 489 Route de Nozay 490 91460 Marcoussis cedex - FRANCE 491 Phone: +33 1 69 63 41 87 492 Email: yacine.el_mghazli@alcatel.fr 494 Al Morton 495 AT&T 496 Room D3-3C06 497 200 S. Laurel Avenue 498 Middletown, NJ 07748 499 Phone: + 1 732 420-1571 500 E-mail: acmorton@att.com 502 Percy Tarapore 503 AT&T 504 Room D1-3D33 505 200 S. Laurel Avenue 506 Middletown, NJ 07748 507 Phone: + 1 732 420-4172 508 E-mail: tarapore@.att.com 510 11. Intellectual Property Statement 512 The IETF takes no position regarding the validity or scope of any 513 Intellectual Property Rights or other rights that might be claimed to 514 pertain to the implementation or use of the technology described in 515 this document or the extent to which any license under such rights 516 might or might not be available; nor does it represent that it has 517 made any independent effort to identify any such rights. Information 518 on the procedures with respect to rights in RFC documents can be 519 found in BCP 78 and BCP 79. 521 Copies of IPR disclosures made to the IETF Secretariat and any 522 assurances of licenses to be made available, or the result of an 523 attempt made to obtain a general license or permission for the use of 524 such proprietary rights by implementers or users of this 525 specification can be obtained from the IETF on-line IPR repository at 526 http://www.ietf.org/ipr. 528 The IETF invites any interested party to bring to its attention any 529 copyrights, patents or patent applications, or other proprietary 530 rights that may cover technology that may be required to implement 531 this standard. Please address the information to the IETF at 532 ietf-ipr@ietf.org. 534 Disclaimer of Validity 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Copyright Statement 546 Copyright (C) The Internet Society (2006). This document is subject 547 to the rights, licenses and restrictions contained in BCP 78, and 548 except as set forth therein, the authors retain all their rights.