idnits 2.17.1 draft-ietf-rtgwg-ipfrr-framework-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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 549. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 10) being 78 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 (October 2004) is 7134 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 section? 'MPLSFRR' on line 177 looks like a reference -- Missing reference section? 'BFD' on line 275 looks like a reference -- Missing reference section? 'BASE' on line 302 looks like a reference -- Missing reference section? 'U-TURNS' on line 315 looks like a reference -- Missing reference section? 'TUNNELS' on line 318 looks like a reference -- Missing reference section? 'MICROLOOP' on line 455 looks like a reference -- Missing reference section? 'ZININ' on line 455 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Shand 2 Internet Draft 3 Expiration Date: April 2005 Cisco Systems 5 October 2004 7 IP Fast Reroute Framework 9 draft-ietf-rtgwg-ipfrr-framework-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsolete by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document provides a framework for the development of IP 35 fast-reroute mechanisms which provide protection against link or 36 router failure by invoking locally determined repair paths. Unlike 37 MPLS Fast-reroute, the mechanisms are applicable to a network 38 employing conventional IP routing and forwarding. An essential part 39 of such mechanisms is the prevention of packet loss caused by the 40 loops which normally occur during the re-convergence of the network 41 following a failure. 43 Terminology 45 This section defines words and acronyms used in this draft and other 46 drafts discussing IP Fast-reroute. 48 D Used to denote the destination router under 49 discussion. 51 Distance_opt(A,B) The distance of the shortest path from A 52 to B. 54 Downstream Path This is a subset of the loop-free alternates 55 where the neighbor N meet the following 56 condition:- 58 Distance_opt(N, D) < Distance_opt(S,D) 60 E Used to denote the router which is the 61 primary next-hop neighbor to get from S to 62 the destination D. Where there is an ECMP set 63 for the shortest path from S to D, these are 64 referred to as E_1, E_2, etc. 66 ECMP Equal cost multi-path: Where, for a 67 particular destination D, multiple primary 68 next-hops are used to forward traffic because 69 there exist multiple shortest paths from S 70 via different output layer-3 interfaces. 72 FIB Forwarding Information Base. The database 73 used by the packet forwarder to determine 74 what actions to perform on a packet. 76 IPFRR IP fast-reroute 78 Link(A->B) A link connecting router A to router B. 80 Loop-Free This is a neighbor N, that is not a primary 81 Alternate next-hop neighbor E, whose shortest path to 82 the destination D does not go back through 83 the router S. The neighbor N must meet the 84 following condition:- 86 Distance_opt(N, D) < Distance_opt(N, S) + 87 Distance_opt(S, D) 89 Loop-Free A neighbor N_i, which is not the particular 90 Neighbor primary neighbor E_k under discussion, and 91 whose shortest path to D does not traverse S. 92 For example, if there are two primary 93 neighbors E_1 and E_2, E_1 is a loop-free 94 neighbor with regard to E_2 and vice versa. 96 Loop-Free This is a path via a Loop-Free Neighbor N_i 97 Link-Protecting which does not go through the particular link 98 Alternate of S which is being protected to reach the 99 destination D. 101 Loop-Free This is a path via a Loop-Free Neighbor N_i 102 Node-Protecting which does not go through the particular 103 Alternate primary neighbor of S which is being 104 protected to reach the destination D. 106 Micro-loop A temporary forwarding loop which exists 107 during a routing transition as a result of 108 temporary inconsistencies between FIBs. 110 N_i The ith neighbor of S. 112 Primary Neighbor A neighbor N_i of S which is one of the next 113 hops for destination D in S's FIB prior to 114 any failure. 116 R_i_j The jth neighbor of N_i. 118 Routing The process whereby routers converge on a new 119 transition topology. In conventional networks this 120 process frequently causes some disruption to 121 packet delivery. 123 RPF Reverse Path Forwarding. I.e. checking that a 124 packet is received over the interface which 125 would be used to send packets addressed to 126 the source address of the packet. 128 S Used to denote a router that is the source of 129 a repair that is computed in anticipation of 130 the failure of a neighboring router denoted 131 as E, or of the link between S and E. It is 132 the viewpoint from which IP Fast-Reroute is 133 described. 135 S_i The set of neighbors of E, in addition to S, 136 which will independently take the role of S 137 for the traffic they carry. 139 SPF Shortest Path First, e.g. Dijkstra's 140 algorithm. 142 SPT Shortest path tree 144 Upstream This is a forwarding loop which involves a 145 Forwarding Loop set of routers, none of which are directly 146 connected to the link which has caused the 147 topology change that triggered a new SPF in 148 any of the routers. 150 1. Introduction 152 When a link or node failure occurs in a routed network, there is 153 inevitably a period of disruption to the delivery of traffic until 154 the network re-converges on the new topology. Packets for 155 destinations which were previously reached by traversing the failed 156 component may be dropped or may suffer looping. Traditionally such 157 disruptions have lasted for periods of at least several seconds, and 158 most applications have been constructed to tolerate such a quality of 159 service. 161 Recent advances in routers have reduced this interval to under a 162 second for carefully configured networks using link state IGPs. 163 However, new Internet services are emerging which may be sensitive to 164 periods of traffic loss which are orders of magnitude shorter than 165 this. 167 Addressing these issues is difficult because the distributed nature 168 of the network imposes an intrinsic limit on the minimum convergence 169 time which can be achieved. 171 However, there is an alternative approach, which is to compute backup 172 routes that allow the failure to be repaired locally by the router(s) 173 detecting the failure without the immediate need to inform other 174 routers of the failure. In this case, the disruption time can be 175 limited to the small time taken to detect the adjacent failure and 176 invoke the backup routes. This is analogous to the technique employed 177 by MPLS Fast-Reroute [MPLSFRR], but the mechanisms employed for the 178 backup routes in pure IP networks are necessarily very different. 180 This document provides a framework for the development of this 181 approach. 183 2. Problem Analysis 185 The duration of the packet delivery disruption caused by a 186 conventional routing transition is determined by a number of factors: 188 1. The time taken to detect the failure. This may be of the order 189 of a few mS when it can be detected at the physical layer, up to 190 several tens of seconds when a routing protocol hello is 191 employed. During this period packets will be unavoidably lost. 193 2. The time taken for the local router to react to the failure. 194 This will typically involve generating and flooding new routing 195 updates, perhaps after some hold-down delay, and re-computing 196 the router's FIB. 198 3. The time taken to pass the information about the failure to 199 other routers in the network. In the absence of routing protocol 200 packet loss, this is typically between 10mS and 100mS per hop. 202 4. The time taken to re-compute the forwarding tables. This is 203 typically a few mS for a link state protocol using Dijkstra's 204 algorithm. 206 5. The time taken to load the revised forwarding tables into the 207 forwarding hardware. This time is very implementation dependant 208 and also depends on the number of prefixes affected by the 209 failure, but may be several hundred mS. 211 The disruption will last until the routers adjacent to the failure 212 have completed steps 1 and 2, and then all the routers in the network 213 whose paths are affected by the failure have completed the remaining 214 steps. 216 The initial packet loss is caused by the router(s) adjacent to the 217 failure continuing to attempt to transmit packets across the failure 218 until it is detected. This loss is unavoidable, but the detection 219 time can be reduced to a few tens of mS as described in section 3.1. 221 Subsequent packet loss is caused by the "micro-loops" which form 222 because of temporary inconsistencies between routers' forwarding 223 tables. These occur as a result of the different times at which 224 routers update their forwarding tables to reflect the failure. These 225 variable delays are caused by steps 3, 4 and 5 above and in many 226 routers it is step 5 which is both the largest factor and which has 227 the greatest variance between routers. The large variance arises from 228 implementation differences and from the differing impact that a 229 failure has on each individual router. For example, the number of 230 prefixes affected by the failure may vary dramatically from one 231 router to another. 233 In order to achieve packet disruption times which are commensurate 234 with the failure detection times it is necessary to perform two 235 distinct tasks: 237 1. Provide a mechanism for the router(s) adjacent to the failure to 238 rapidly invoke a repair path, which is unaffected by any 239 subsequent re-convergence. 241 2. Provide a mechanism to prevent the effects of micro-loops during 242 subsequent re-convergence. 244 Performing the first task without the second will result in the 245 repair path being starved of traffic and hence being redundant. 246 Performing the second without the first will result in traffic being 247 discarded by the router(s) adjacent to the failure. Both tasks are 248 necessary for an effective solution to the problem. 250 However, repair paths can be used in isolation where the failure is 251 short-lived. The repair paths can be kept in place until the failure 252 is repaired and there is no need to advertise the failure to other 253 routers. 255 Similarly, micro-loop avoidance can be used in isolation to prevent 256 loops arising from pre-planned management action. 258 Note that micro-loops can also occur when a link or node is restored 259 to service and thus a micro-loop avoidance mechanism is required for 260 both link up and link down cases. 262 3. Mechanisms for IP Fast-reroute 264 The set of mechanisms required for an effective solution to the 265 problem can be broken down into the following sub-problems. 267 3.1. Mechanisms for fast failure detection 269 It is critical that the failure detection time is minimized. A number 270 of approaches are possible, such as: 272 1. Physical detection; for example, loss of light. 274 2. Routing protocol independent protocol detection; for example, 275 The Bidirectional Failure Detection protocol [BFD]. 277 3. Routing protocol detection; for example, use of "fast hellos". 279 3.2. Mechanisms for repair paths 281 Once a failure has been detected by one of the above mechanisms, 282 traffic which previously traversed the failure is transmitted over 283 one or more repair paths. The design of the repair paths should be 284 such that they can be pre-calculated in anticipation of each local 285 failure and made available for invocation with minimal delay. There 286 are three basic categories of repair paths: 288 1. Equal cost multi-paths (ECMP). Where such paths exist, and one 289 or more of the alternate paths do not traverse the failure, they 290 may trivially be used as repair paths. 292 2. Loop free alternate paths. Such a path exists when a direct 293 neighbor of the router adjacent to the failure has a path to the 294 destination which can be guaranteed not to traverse the failure. 296 3. Multi-hop repair paths. When there is no feasible downstream 297 path it may still be possible to locate a router, which is more 298 than one hop away from the router adjacent to the failure, from 299 which traffic will be forwarded to the destination without 300 traversing the failure. 302 ECMP and loop free alternate paths (as described in [BASE]) offer the 303 simplest repair paths and would normally be used when they are 304 available. It is anticipated that around 80% of failures (see section 305 3.2.2) can be repaired using these alone. 307 Multi-hop repair paths are considerably more complex, both in the 308 computations required to determine their existence, and in the 309 mechanisms required to invoke them. They can be further classified 310 as: 312 1. Mechanisms where one or more alternate FIBs are pre-computed in 313 all routers and the repaired packet is instructed to be 314 forwarded using a "repair FIB" by some method of signaling such 315 as detecting a "U-turn" [U-TURNS] or marking the packet. 317 2. Mechanisms functionally equivalent to a loose source route which 318 is invoked using the normal FIB. These include tunnels [TUNNELS] 319 and label based mechanisms. 321 In many cases a repair path which reaches two hops away from the 322 router detecting the failure will suffice, and it is anticipated that 323 around 98% of failures (see section 3.2.2) can be repaired by this 324 method. However, to provide complete repair coverage some use of 325 longer multi-hop repair paths is generally necessary. 327 3.2.1. Scope of repair paths 329 A particular repair path may be valid for all destinations which 330 require repair or may only be valid for a subset of destinations. If 331 a repair path is valid for a node immediately downstream of the 332 failure, then it will be valid for all destinations previously 333 reachable by traversing the failure. However, in cases where such a 334 repair path is difficult to achieve because it requires a high order 335 multi-hop repair path, it may still be possible to identify lower 336 order repair paths (possibly even loop free alternate paths) which 337 allow the majority of destinations to be repaired. When IPFRR is 338 unable to provide complete repair, it is desirable that the extent of 339 the repair coverage can be determined and reported via network 340 management. 342 There is a tradeoff to be achieved between minimizing the number of 343 repair paths to be computed, and minimizing the overheads incurred in 344 using higher order multi-hop repair paths for destinations for which 345 they are not strictly necessary. However, the computational cost of 346 determining repair paths on an individual destination basis can be 347 very high. 349 The use of repair paths may result in excessive traffic passing over 350 a link, resulting in congestion discard. This reduces the 351 effectiveness of IPFRR. Mechanisms to influence the distribution of 352 repaired traffic to minimize this effect are therefore desirable. 354 3.2.2. Analysis of repair coverage 356 In some cases the repair strategy will permit the repair of all 357 single link or node failures in the network for all possible 358 destinations. This can be defined as 100% coverage. However, where 359 the coverage is less than 100% it is important for the purposes of 360 comparisons between different proposed repair strategies to define 361 what is meant by such a percentage. There are three possibilities: 363 1. The percentage of links (or nodes) which can be fully protected 364 for all destinations. This is appropriate where the requirement 365 is to protect all traffic, but some percentage of the possible 366 failures may be identified as being un-protectable. 368 2. The percentage of destinations which can be fully protected for 369 all link (or node) failures. This is appropriate where the 370 requirement is to protect against all possible failures, but 371 some percentage of destinations may be identified as being 372 un-protectable. 374 3. For all destinations (d) and for all failures (f), the 375 percentage of the total potential failure cases (d*f) which are 376 protected. This is appropriate where the requirement is an 377 overall "best effort" protection. 379 The coverage obtained is dependent on the repair strategy and highly 380 dependent on the detailed topology and metrics. Any figures quoted in 381 this document are for illustrative purposes only. 383 3.2.3. Link or node repair 385 A repair path may be computed to protect against failure of an 386 adjacent link, or failure of an adjacent node. In general, link 387 protection is simpler to achieve. A repair which protects against 388 node failure will also protect against link failure for all 389 destinations except those for which the adjacent node is a single 390 point of failure. 392 In some cases it may be necessary to distinguish between a link or 393 node failure in order that the optimal repair strategy is invoked. 394 Methods for link/node failure determination may be based on 395 techniques such as BFD. This determination may be made prior to 396 invoking any repairs, but this will increase the period of packet 397 loss following a failure unless the determination can be performed as 398 part of the failure detection mechanism itself. Alternatively, a 399 subsequent determination can be used to optimise an already invoked 400 default strategy. 402 3.2.4. Maintenance of Repair paths 404 In order to meet the response time goals, it is expected (though not 405 required) that repair paths, and their associated FIB entries, will 406 be pre-computed and installed ready for invocation when a failure is 407 detected. Following invocation the repair paths remain in effect 408 until they are no longer required. This will normally be when the 409 routing protocol has re-converged on the new topology taking into 410 account the failure, and traffic will no longer be using the repair 411 paths. 413 The repair paths have the property that they are unaffected by any 414 topology changes resulting from the failure which caused their 415 instantiation. Therefore there is no need to re-compute them during 416 the convergence period. They may be affected by an unrelated 417 simultaneous topology change, but such events are out of scope of 418 this work (see section 3.2.5). 420 Once the routing protocol has re-converged it is necessary for all 421 repair paths to take account of the new topology. Various 422 optimizations may permit the efficient identification of repair paths 423 which are unaffected by the change, and hence do not require full 424 re-computation. Since the new repair paths will not be required until 425 the next failure occurs, the re-computation may be performed as a 426 background task and be subject to a hold-down, but excessive delay in 427 completing this operation will increase the risk of a new failure 428 occurring before the repair paths are in place. 430 3.2.5. Multiple failures and Shared Risk Groups 432 Complete protection against multiple unrelated failures is out of 433 scope of this work. However, it is important that the occurrence of a 434 second failure while one failure is undergoing repair should not 435 result in a level of service which is significantly worse than that 436 which would have been achieved in the absence of any repair strategy. 438 Shared Risk Groups are an example of multiple related failures, and 439 their protection is a matter for further study. 441 One specific example of an SRLG which is clearly within the scope of 442 this work is a node failure. This causes the simultaneous failure of 443 multiple links, but their closely defined topological relationship 444 makes the problem more tractable. 446 3.3. Mechanisms for micro-loop prevention 448 Control of micro-loops is important not only because they can cause 449 packet loss in traffic which is affected by the failure, but because 450 by saturating a link with looping packets they can also cause 451 congestion loss of traffic flowing over that link which would 452 otherwise be unaffected by the failure. 454 A number of solutions to the problem of micro-loop formation have 455 been proposed [MICROLOOP, ZININ]. The following factors are 456 significant in their classification: 458 1. Partial or complete protection against micro-loops. 460 2. Delay imposed upon convergence. 462 3. Tolerance of multiple failures (from node failures, and in 463 general). 465 4. Computational complexity (pre-computed or real time). 467 5. Applicability to scheduled events. 469 6. Applicability to link/node reinstatement. 471 4. Management Considerations 473 While many of the management requirements will be specific to 474 particular IPFRR solutions, the following general aspects need to be 475 addressed: 477 1. Configuration 479 a. Enabling/disabling IPFRR support. 481 b. Enabling/disabling protection on a per link/node basis. 483 c. Expressing preferences regarding the links/nodes used for 484 repair paths. 486 d. Configuration of failure detection mechanisms. 488 e. Configuration of loop avoidance strategies. 490 2. Monitoring 492 a. Notification of links/nodes/destinations which cannot be 493 protected. 495 b. Notification of pre-computed repair paths, and anticipated 496 traffic patterns. 498 c. Counts of failure detections, protection invocations and 499 packets forwarded over repair paths. 501 5. Scope and applicability 503 Link state protocols provide ubiquitous topology information, which 504 facilitates the computation of repairs paths. Therefore the initial 505 scope of this work is in the context of link state IGPs. 507 Provision of similar facilities in non-link state IGPs and BGP is a 508 matter for further study, but the correct operation of the repair 509 mechanisms for traffic with a destination outside the IGP domain is 510 an important consideration for solutions based on this framework 512 6. IANA considerations 514 There are no IANA considerations that arise from this framework 515 document. 517 7. Security Considerations 519 This framework document does not itself introduce any security 520 issues, but attention must be paid to the security implications of 521 any proposed solutions to the problem. 523 8. IPR Disclosure Acknowledgement 525 Certain IPR may be applicable to the mechanisms outlined in this 526 document. Please check the detailed specifications for possible IPR 527 notices. 529 The IETF takes no position regarding the validity or scope of any 530 Intellectual Property Rights or other rights that might be claimed to 531 pertain to the implementation or use of the technology described in 532 this document or the extent to which any license under such rights 533 might or might not be available; nor does it represent that it has 534 made any independent effort to identify any such rights. Information 535 on the procedures with respect to rights in RFC documents can be 536 found in BCP 78 and BCP 79. 538 Copies of IPR disclosures made to the IETF Secretariat and any 539 assurances of licenses to be made available, or the result of an 540 attempt made to obtain a general license or permission for the use of 541 such proprietary rights by implementers or users of this 542 specification can be obtained from the IETF on-line IPR repository at 543 http://www.ietf.org/ipr. 545 The IETF invites any interested party to bring to its attention any 546 copyrights, patents or patent applications, or other proprietary 547 rights that may cover technology that may be required to implement 548 this standard. Please address the information to the IETF at 549 ietf-ipr@ietf.org. 551 9. Normative References 553 Internet-drafts are works in progress available from 554 http://www.ietf.org/internet-drafts/ 556 10. Informative References 558 Internet-drafts are works in progress available from 559 http://www.ietf.org/internet-drafts/ 561 BASE Atlas, A., "Basic Specification for IP 562 Fast-Reroute: Loop-free Alternates", 563 draft-ietf-rtgwg-ipfrr-spec-base-01.txt, 564 (work in progress) 566 BFD Katz, D. and Ward, D., "Bidirectional 567 Forwarding Detection", 568 draft-ietf-bfd-base-00.txt, (work in 569 progress). 571 MPLSFRR Pan, P. et al, "Fast Reroute Extensions to 572 RSVP-TE for LSP Tunnels", 573 draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt 575 MICROLOOP Bryant, S. and Shand, M., "A Framework for 576 Loop-free Convergence", 577 draft-bryant-shand-lf-conv-frmwk-00.txt, 578 (work in progress). 580 TUNNELS Bryant, S. et al, "IP Fast Reroute using 581 tunnels", draft-bryant-ipfrr-tunnels-01.txt, 582 (work in progress). 584 U-TURNS Atlas, A. et al, "IP/LDP Local Protection", 585 draft-atlas-ip-local-protect-01.txt, (work in 586 progress). 588 ZININ Zinin, A., "Analysis and Minimization of 589 Microloops in Link-state Routing Protocols", 590 draft-zinin-microloop-analysis-00.txt, (work 591 in progress). 593 11. Author's Address 595 Mike Shand 596 Cisco Systems, 597 250, Longwater Avenue, 598 Green Park, 599 Reading, RG2 6GB, 600 United Kingdom. Email: mshand@cisco.com 602 Full copyright statement 604 Copyright (C) The Internet Society (2004). This document is subject 605 to the rights, licenses and restrictions contained in BCP 78, and 606 except as set forth therein, the authors retain all their rights. 608 This document and the information contained herein are provided on an 609 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 610 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 611 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 612 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 613 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 614 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.