idnits 2.17.1 draft-ietf-nsis-y1541-qosm-02.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 555. ** 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 (May 2006) is 6556 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 256, but not defined == Missing Reference: 'Rs' is mentioned on line 258, but not defined -- 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' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group Jerry Ash 3 Internet Draft Martin Dolly 4 Chuck Dvorak 5 Expiration Date: November 2006 Al Morton 6 Percy Tarapore 7 AT&T 8 Yacine El Mghazli 9 Alcatel 11 May 2006 13 Y.1541-QOSM -- Y.1541 QoS Model 14 for Networks Using Y.1541 QoS Classes 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on November 4, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T 48 Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 49 standard QoS classes, and the Y.1541-QOSM extensions include 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 . . . . . . . . . . . . . 7 61 4. Control Processing for Y.1541 QOSM . . . . . . . . . . . . . . 8 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 66 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 67 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 68 11. Intellectual Property Statement . . . . . . . . . . . . . . . 11 69 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . 12 70 Copyright Statement . . .. . . . . . . . . . . . . . . . . . . . 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 124 objectives for one-way IP packet delay, IP packet delay variation, IP 125 packet loss ratio, etc. Classes 0 and 1, which generally correspond 126 to the DiffServ EF PHB, support interactive real-time applications. 127 Classes 2, 3, and 4, which generally correspond to the DiffServ AFxy 128 PHB Group, support non-interactive applications. Class 5, which 129 generally corresponds to the DiffServ best-effort PHB, has all the 130 QoS parameters unspecified. These classes serve as a basis for 131 agreements between end-users and service providers, and between 132 service providers. They support a wide range of traffic applications 133 including point-to-point telephony, data transfer, multimedia 134 conferencing, and others. The limited number of classes supports the 135 requirement for feasible implementation, particularly with respect to 136 scale in global networks. 138 The QoS classes apply to a packet flow, where [Y.1541] defines a 139 packet flow as the traffic associated with a given connection or 140 connectionless stream having the same source host, destination host, 141 class of service, and session identification. The characteristics of 142 each Y.1451 QoS class are summarized here: 144 Class 0: Real-time, highly interactive applications, sensitive to 145 jitter. Mean delay upper bound is 100 ms, delay variation is less 146 than 50 ms, and loss ratio is less than 10^-3. Application examples 147 include VoIP, Video Teleconference. 149 Class 1: Real-time, interactive applications, sensitive to jitter. 150 Mean delay upper bound is 400 ms, delay variation is less than 50 ms, 151 and loss ratio is less than 10^-3. Application examples include VoIP, 152 video teleconference. 154 Class 2: Highly interactive transaction data. Mean delay upper bound 155 is 100 ms, delay variation is unspecified, and loss ratio is less 156 Than 10^-3. Application examples include signaling. 158 Class 3: Interactive transaction data. Mean delay upper bound is 400 159 ms, delay variation is unspecified, and loss ratio is less than 160 10^-3. Application examples include signaling. 162 Class 4: Low Loss Only applications. Mean delay upper bound is 1s, 163 delay variation is unspecified, and loss ratio is less than 10^-3. 164 Application examples include short transactions, bulk data, video 165 streaming 167 Class 5: Unspecified applications with unspecified mean delay, delay 168 variation, and loss ratio. Application examples include traditional 169 applications of Default IP Networks 171 Class 6: 172 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 173 Applications that are highly sensitive to loss, such as television 174 transport, high-capacity TCP transfers, and TDM circuit emulation. 176 Class 7: 177 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. 178 Applications that are highly sensitive to loss, such as television 179 transport, high-capacity TCP transfers, and TDM circuit emulation. 181 These classes enable SLAs to be defined between customers and network 182 service providers with respect to QoS requirements. The service 183 provider then needs to ensure that the requirements are recognized 184 and receive appropriate treatment across network layers. 186 Recommendation Y.1541 is currently being enhanced to provide support 187 for extremely loss-sensitive user applications, such as high quality 188 digital television, TDM circuit emulation, and high capacity 189 transfers using TCP. The plan is to add a minimal number of classes 190 to meet these needs. 192 2.2 Y.1541 Signaling Requirements 194 [TRQ-QoS-SIG] provides the requirements for signaling information 195 regarding IP-based QoS at the interface between the user and the 196 network (UNI) and across interfaces between different networks (NNI). 197 To meet specific network performance requirements specified for the 198 Y.1541 QoS classes, a network needs to provide specific user plane 199 functionality at UNI, NNI, and INI interfaces. Dynamic network 200 provisioning at a UNI and/or NNI node allows the ability to 201 dynamically request a traffic contract for an IP flow from a specific 202 source node to one or more destination nodes. In response to the 203 request, the network determines if resources are available to satisfy 204 the request and provision the network. 206 The call/session control signaling includes an indication of the QoS 207 requirements for each session. Obtaining user-to-user QoS will 208 require standard signaling protocols for communicating the 209 requirements among the major entities. These entities include users 210 and their end terminal equipment, and network service providers and 211 their equipment, especially equipment implementing the inter-working 212 and signaling function between networks, and between users and 213 networks. 215 It MUST be possible to derive the following service level parameters 216 as part of the process of requesting service: 218 a. Y.1541 QoS class 219 b. peak data rate (p) 220 c. peak bucket size (Bp) 221 d. sustainable rate (Rs) 222 e. sustainable bucket size (b) 223 f. token bucket rate (r) 224 g. maximum allowed packet size (M) 225 h. DiffServ field [RFC2475] 226 i. reservation priority class (urgency of establishing service 227 connection) can be requested 228 j. restoration priority class (urgency of restoring service 229 connection under failure) can be requested 231 All parameters except , , and have 232 already been specified in [QSPEC]. These additional parameters are 233 specified in Section 3. 235 It MUST be possible to perform the following QoS-NSLP signaling 236 functions to enable Y.1541-QOSM requirements: 238 a. accumulate delay, delay variation and loss ratio across the 239 end-to-end connection, which may span multiple domains 240 b. enable negotiation of Y.1541 QoS class across domains. 241 c. enable negotiation of delay, delay variation, and loss ratio 242 across domains. 244 Additional signaling functions beyond those already specified in 245 [QSPEC] are discussed in Section 4. 247 3. Additional QSPEC Parameters for Y.1541 QOSM 249 3.1 Parameters 251 The parameters are represented by two 252 floating point numbers in single-precision IEEE floating point 253 format. 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Peak Bucket Size [Bb] (32-bit IEEE floating point number) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Sustainable Rate [Rs] (32-bit IEEE floating point number) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 When the Bp and Rs terms are represented as IEEE floating point 262 values, the sign bit MUST be zero (all values MUST be non-negative). 263 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 264 than 162 (i.e., positive 35) are discouraged, except for specifying a 265 peak rate of infinity. Infinity is represented with an exponent of 266 all ones (255) and a sign bit and mantissa of all zeroes. 268 3.2 Parameter 270 Restoration priority is the urgency with which a service requires 271 successful restoration under failure conditions. Restoration 272 priority is achieved by provisioning sufficient backup capacity, as 273 necessary, and allowing relative priority for access to available 274 bandwidth when there is contention for restoration bandwidth. 275 Restoration priority is defined as follows: 277 0 1 2 3 4 5 6 7 278 +-+-+-+-+-+-+-+-+ 279 | Restoration | 280 | Priority | 281 +-+-+-+-+-+-+-+-+ 283 Restoration Priority: 8 bits 284 3 priority values are listed here in the order of lowest priority to 285 highest priority: 287 0 - best effort 288 1 - normal 289 2 - high 291 Each restoration priority class has two parameters: 293 a. Time-to-Restore: Total amount of time to restore traffic streams 294 belonging to a given restoration class impacted by the failure. This 295 time period depends on the technology deployed for restoration. A 296 fast recovery period of < 200 ms is based on current experience with 297 SONET rings and a slower recovery period of 2 seconds is suggested in 298 order to enable a voice call to recover without being dropped. 299 Accordingly, candidate restoration objectives are: 301 High Restoration Priority: Time-to-Restore <= 200 ms 302 Normal Restoration Priority: Time-to-Restore <= 2 s. 303 Best Effort Restoration Priority: Time-to-Restore = Unspecified 305 b. Extent of Restoration: Percentage of traffic belonging to the 306 restoration class that can be restored. This percentage depends on 307 the amount of spare capacity engineered. All high priority 308 restoration priority traffic, for example, may be "guaranteed" at 309 100% by the service provider. Other classes may offer lesser chances 310 for successful restoration. The restoration extent for these lower 311 priority classes depend on SLA agreements developed between the 312 service provider and the customer. 314 4. Control Processing for Y.1541 QOSM 316 In this Section we illustrate the operation of the Y.1541 QOSM, and 317 show how current QoS-NSLP and QSPEC functionality is used. No new 318 control processing capabilities or parameters are required to enable 319 the Y.1541 QOSM. 321 As described in the example given in [QSPEC], Section 4.3, and as 322 illustrated in Figure 1, the QoS NSIS initiator (QNI) initiates an 323 end-to-end, inter-domain QoS NSLP RESERVE message containing the 324 Initiator QSPEC. In the case of the Y.1541 QOSM, the Initiator QSPEC 325 specifies the , , , , , and 327 perhaps other generic QSPEC parameters for the flow. As described in 328 Section 3, the object contains the 329 optional, Y.1541-QOSM-Specific parameters and ; is also an optional, Y.1541-QOSM-Specific parameter. 332 As illustrated in Figure 1, the RESERVE message may cross multiple 333 domains supporting different QOSMs. In this illustration, the 334 Initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress 335 node of the Local-QOSM domain. As described in [QoS-SIG] and 336 [QSPEC], at the ingress edge node of the Local-QOSM domain, the 337 end-to-end, inter-domain QoS-NSLP messages trigger the generation of 338 a Local QSPEC, which is pushed on top of the Initiator QSPEC. That 339 is, the Initiator QSPEC is translated into a Local-QOSM QSPEC. For 340 example, if the Local-QOSM is the RMD-QOSM [RMD], then the parameter would be translated to the 342 parameter. The Local QSPEC is used for QoS processing in the 343 Local-QOSM domain, and then popped at the egress edge node of the 344 Local-QOSM domain. The Initiator QSPEC is then used for QoS 345 processing at the QoS NSIS receiver (QNR). 347 Each node on the data path checks the availability of resources and 348 accumulating the delay, delay variation, and loss ratio parameters, 349 as described below. If an intermediate node cannot accommodate the 350 new request, it indicates it by marking a single bit, the bit specified in [QSPEC], in the message, and continues 352 forwarding the message. When the message reaches the egress edge 353 node of the Local-QOSM domain, if no intermediate node has denied the 354 reservation, the Initiator QSPEC is forwarded to the next domain, as 355 described above. If an intermediate node has denied the reservation, 356 by setting the bit, the reservation is denied. 358 As specified in [QSPEC], if any QNE does not support the Y.1541 QOSM, 359 it sets the flag to one to indicate that it does not 360 support the Y.1541 QOSM. The flag is normally set to 361 zero. As specified in [QSPEC], if any QNE cannot meet the 362 requirements designated by the Initiator QSPEC to support an optional 363 QSPEC parameter, for example, it cannot support the accumulation of 364 end-to-end delay with the parameter, the QNE sets the 365 to one. The is normally set 366 to zero. 368 Also, the Y.1541-QOSM requires negotiation of the 369 across domains. This negotiation can be done with the use of the 370 existing procedures already defined in [QoS-SIG]. For example, the 371 QNI sets , , objects to 372 include , , , 373 parameters. The QNE/domain SHOULD set the Y.1541 class and 374 cumulative parameters, e.g., , that can be achieved in 375 the object (but not less than specified in ). This could include, for example, setting the to a lower class than specified in (but not 378 lower than specified in ). If the 379 fails to satisfy one or more of the objectives, the 380 QNE/domain notifies the QNI and the reservation is aborted. 381 Otherwise, the QNR notifies the QNI of the for the 382 reservation. 384 When the available must be reduced from the 385 desired , say because the delay objective 386 has been exceeded, then there is an incentive to respond with an 387 available value for delay in the parameter. If the 388 available is 150 ms (still useful for many 389 applications) and the desired QoS is Class 0 (with its 100 ms 390 objective), then the response would be that Class 0 cannot be 391 achieved and Class 1 is available (with its 400 ms objective). In 392 addition, this QOSM allows the response to include an available 393 = 150 ms, making acceptance of the available more likely. There are many long paths where the 395 propagation delay alone exceeds the Y.1541 Class 0 objective, so 396 this feature adds flexibility to commit to exceed the Class 1 397 objective when possible. 399 This example illustrates Y.1541-QOSM negotiation of and cumulative parameter values that can be achieve 401 end-to-end. The example illustrates how the QNI can use the 402 cumulative values collected in to decide if a lower 403 than specified in is acceptable. 405 |------| |------| |------| |------| 406 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 407 | QoS | | QoS | | QoS | | QoS | 408 | | |------| |-------| |-------| |------| | | 409 | | | local|<->| local |<->| local |<->| local| | | 410 | | | QoS | | QoS | | QoS | | QoS | | | 411 | | | | | | | | | | | | 412 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 413 |Y.1541| |local | |local | |local | |local | |Y.1541| 414 | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 415 |------| |------| |-------| |-------| |------| |------| 416 ----------------------------------------------------------------- 417 |------| |------| |-------| |-------| |------| |------| 418 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | 419 |------| |------| |-------| |-------| |------| |------| 420 QNI QNE QNE QNE QNE QNR 421 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 423 Figure 1 Protocol Model of Y.1541-QOSM Operation 425 5. Security Considerations 427 The security considerations of [QoS-SIG] and [QSPEC] apply to this 428 Document. There are no new security considerations based on this 429 document. 431 6. IANA Considerations 433 This section defines the registries and initial codepoint assignments 434 for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. 435 It also defines the procedural requirements to be followed by IANA in 436 allocating new codepoints. Guidelines on the technical criteria to 437 be followed in evaluating requests for new codepoint assignments are 438 given for the overall NSIS protocol suite in a separate NSIS 439 extensibility document [NSIS-EXTENSIBILITY]. 441 This specification creates the following registry with the structure 442 as defined below: 444 Restoration Priority Parameter (8 bits): 445 The following values are allocated by this specification: 446 0-2: assigned as specified in Section 3.2 447 The allocation policies for further values are as follows: 448 3-63: Standards Action 449 64-255: Reserved 451 7. Acknowledgements 453 The authors thank Attila Bader, Cornelia Kappler, and Sven Van 454 den Bosch for helpful comments and discussion. 456 8. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service 461 Signaling," work in progress. 462 [QSPEC], Ash, J., et. al., "QoS-NSLP QSPEC Template," work in 463 progress. 464 [TRQ-QoS-SIG] ITU-T Recommendation, "Signaling Requirements for 465 IP-QoS," January 2004. 466 [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 467 Objectives for IP-Based Services," 2006. 469 9. Informative References 471 [E.361] ITU-T Recommendation, "QoS Routing Support for Interworking 472 of QoS Service Classes Across Routing Technologies," May 2003. 473 [NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work 474 in progress. 475 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 476 Services," RFC 2210, September 1997. 477 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 478 Considerations Section in RFCs," RFC 2434, October 1998. 479 [RFC2475] Blake, S., et. al., "An Architecture for Differentiated 480 Services", RFC 2475, December 1998. 481 [RMD] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling Policy 482 Model for Networks 484 10. Authors' Addresses 486 Jerry Ash 487 AT&T 488 Room MT D5-2A01 489 200 Laurel Avenue 490 Middletown, NJ 07748, USA 491 Phone: +1-(732)-420-4578 492 Email: gash@att.com 494 Martin Dolly 495 AT&T 496 Room E3-3A14 497 200 S. Laurel Avenue 498 Middletown, NJ 07748 499 Phone: + 1 732 420-4574 500 E-mail: mdolly@att.com 502 Chuck Dvorak 503 AT&T 504 Room 2A37 505 180 Park Avenue, Building 2 506 Florham Park, NJ 07932 507 Phone: + 1 973-236-6700 508 E-mail: cdvorak@att.com 510 Yacine El Mghazli 511 Alcatel 512 Route de Nozay 513 91460 Marcoussis cedex - FRANCE 514 Phone: +33 1 69 63 41 87 515 Email: yacine.el_mghazli@alcatel.fr 517 Al Morton 518 AT&T 519 Room D3-3C06 520 200 S. Laurel Avenue 521 Middletown, NJ 07748 522 Phone: + 1 732 420-1571 523 E-mail: acmorton@att.com 525 Percy Tarapore 526 AT&T 527 Room D1-33 528 200 S. Laurel Avenue 529 Middletown, NJ 07748 530 Phone: + 1 732 420-4172 531 E-mail: tarapore@.att.com 533 11. Intellectual Property Statement 535 The IETF takes no position regarding the validity or scope of any 536 Intellectual Property Rights or other rights that might be claimed to 537 pertain to the implementation or use of the technology described in 538 this document or the extent to which any license under such rights 539 might or might not be available; nor does it represent that it has 540 made any independent effort to identify any such rights. Information 541 on the procedures with respect to rights in RFC documents can be 542 found in BCP 78 and BCP 79. 544 Copies of IPR disclosures made to the IETF Secretariat and any 545 assurances of licenses to be made available, or the result of an 546 attempt made to obtain a general license or permission for the use of 547 such proprietary rights by implementers or users of this 548 specification can be obtained from the IETF on-line IPR repository at 549 http://www.ietf.org/ipr. 551 The IETF invites any interested party to bring to its attention any 552 copyrights, patents or patent applications, or other proprietary 553 rights that may cover technology that may be required to implement 554 this standard. Please address the information to the IETF at 555 ietf-ipr@ietf.org. 557 Disclaimer of Validity 559 This document and the information contained herein are provided on an 560 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 561 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 562 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 563 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 564 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 567 Copyright Statement 569 Copyright (C) The Internet Society (2006). This document is subject 570 to the rights, licenses and restrictions contained in BCP 78, and 571 except as set forth therein, the authors retain all their rights.