idnits 2.17.1 draft-bryant-shand-ipfrr-notvia-addresses-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 571. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 3) being 62 lines 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 (Mar 2005) is 6982 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: 'RFC2119' is mentioned on line 47, but not defined == Missing Reference: 'IPIP' is mentioned on line 482, but not defined == Missing Reference: 'RFC1701' is mentioned on line 532, but not defined == Missing Reference: 'L2TPv3' is mentioned on line 532, but not defined == Unused Reference: 'IPFRR' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'LDP' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'MPLS-TE' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'TUNNEL' is defined on line 633, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bryant 2 Internet Draft M. Shand 3 Expiration Date: Sep 2005 Cisco Systems 5 Mar 2005 7 IP Fast Reroute Using Notvia Addresses 8 10 Status of this Memo 12 By submitting this Internet-Draft, we certify that any applicable 13 patent or other IPR claims of which we are aware have been 14 disclosed, or will be disclosed, and any of which we become aware 15 will be disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 35 This draft describes a mechanism that provides fast reroute in an 36 IP network through encapsulation to "notvia" addresses. A single 37 level of encapsulation is used. The mechanism protects unicast, 38 multicast and LDP traffic against link, router and shared risk 39 group failure, regardless of network topology and metrics. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in RFC 2119 46 [RFC2119]. 48 Table of Contents 49 1. Introduction........................................................3 51 2. Overview of Notvia Repairs..........................................3 53 3. Repair Computation..................................................4 55 4. How a repairing node repairs........................................5 56 4.1 Node Failure.....................................................5 57 4.2 Link Failure.....................................................5 58 4.3 Multi-homed Prefix...............................................6 59 4.4 Shared Risk Groups...............................................7 60 4.5 Multicast........................................................7 61 4.6 Fast Reroute in an MPLS LDP Network..............................7 62 5. Local Area Networks.................................................8 64 6. Loop Free Alternatives.............................................10 66 7. Equal Cost Multi-Path..............................................10 68 8. Encapsulation......................................................10 70 9. Routing Extensions.................................................11 72 10. Incremental Deployment............................................11 74 11. IANA considerations...............................................11 76 12. Security Considerations...........................................11 77 1. Introduction 79 When a link or a router fails, only the neighbors of the failure 80 are initially aware that the failure has occurred. In a network 81 operating IP fast reroute (IPFRR), the routers that are the 82 neighbors of the failure repair the failure. These repairing 83 routers have to steer packets to their destinations despite the 84 fact that most other routers in the network are unaware of the 85 nature and location of the failure. 87 A common limitation in most IPFRR mechanisms is an inability to 88 steer the repaired packet round an identified failure. The extent 89 to which this limitation affects the repair coverage is topology 90 dependent. The mechanism proposed here is to encapsulate the packet 91 to an address that explicitly identifies the network component that 92 the repair must avoid. This produces a repair mechanism, which, 93 provided the network in not partitioned by the failure, will always 94 achieve a repair. 96 2. Overview of Notvia Repairs 98 The purpose of a repair is to deliver packets to their destination 99 without traversing a known failure in the network, i.e. to deliver 100 the packet not via the failure. In its simplest form, this repair 101 mechanism works by assigning an additional address to each 102 interface in the network. This additional address is called the 103 notvia address. The semantics of a notvia address are that a packet 104 addressed to a notvia address must be delivered to the router with 105 that address, not via the neighboring router on the interface to 106 which that address is assigned. 108 To repair a failure, the repairing router encapsulates the packet 109 to the notvia address of the router interface on the far side of 110 the failure. The routers on the repair path then know to which 111 router they must deliver the packet, and which network component 112 they must avoid. The network fragment shown in Figure 1 illustrates 113 this. 115 A 116 |Ap Bp is the address to use to get 117 | a packet to B notvia P 118 Sp Pa|Pb 119 S----------P----------B 120 Ps|Pc Bp 121 | 122 Cp| 123 C 125 Figure 1: Notvia Addresses 127 Assume that S has a packet for some destination D that it would 128 normally send via P and B, and that S suspects that P has failed. S 129 encapsulates the packet to Bp. The path from S to Bp is the 130 shortest path from S to B not going via P. If the network contains 131 a path from S to B that does not transit router P, then the packet 132 will be successfully delivered to B. When the packet addressed to 133 Bp arrives at B, B removes the encapsulation and forwards the 134 repaired packet towards its final destination. 136 Note that a packet may back track after the encapsulation is 137 removed. However, because the decapsulating router is always closer 138 to the packet destination than the encapsulating router, the packet 139 will not loop. 141 3. Repair Computation 143 The notvia repair mechanism requires that all routers on the path 144 from S to B (Figure 1) have a route to Bp. They can calculate this 145 by failing node P, running an SPF, and finding the shortest route 146 to B. 148 A router has no simple way of knowing whether it is on the shortest 149 path for any particular repair. It is therefore necessary for every 150 router to calculate the path it would use in the event of any 151 possible router failure. Each router therefore fails every router 152 in the network, one at a time, and calculates it own best route to 153 each of the neighbors of that router. In other words, again with 154 reference to Figure 1, some router X will consider each router in 155 turn to be P, fail P, and then calculate its own route to each of 156 the notvia P addresses advertised by the neighbors of P. i.e. X 157 calculates its route to Sp, Ap, Bp, and Cp, in each case, not via 158 P. 160 To calculate the repair paths a router has to calculate n-1 SPFs 161 where n is the number of routers in the network. This is expensive 162 to compute. However the problem is amenable to a solution in which 163 each router (X) proceeds as follows. X first calculates the base 164 topology with all routers functional and determines its normal path 165 to all notvia addresses. X then fails some router P and performs an 166 incremental SPF. This incremental calculation is terminated when 167 all of the notvia P addresses are attached to the SPT. X then 168 reverts to the base topology and repeats the process failing each 169 router P in turn. 171 This algorithm is significantly less expensive than a set of full 172 SPFs. Thus, although a router has to calculate the repair paths for 173 n-1 failures, the computational effort is much less than n-1 SPFs. 175 Experiments on a selection of real world network topologies with 176 between 40 and 400 nodes suggest that the worst case computational 177 complexity using the above optimizations is equivalent to 178 performing between 5 and 13 full SPFs. 180 4. How a repairing node repairs 182 This section explains the operation of each type of repair 183 necessary in the network. 185 4.1 Node Failure 187 When router P fails (Figure 1) S encapsulates any packet that it 188 would send to B via P to Bp, and then sends the encapsulated packet 189 on the shortest path to Bp. S follows the same procedure for 190 routers A, and C in Figure 1. The packet is decapsulated at the 191 repair target (A, B or C) and then forwarded normally to its 192 destination. 194 Notice that with this technique only one level of encapsulation is 195 needed, and that it is possible to repair ANY failure regardless of 196 link metrics and any asymmetry that may be present in the network. 197 The only exception to this is where the failure was a single point 198 of failure that partitioned the network, in which case ANY repair 199 is clearly impossible. 201 4.2 Link Failure 203 The normal mode of operation of the network would be to assume 204 router failure. However, where some destinations are only reachable 205 through the failed router, it is desirable that an attempt be made 206 to repair to those destinations by assuming that only a link 207 failure has occurred. 209 To perform a link repair, S encapsulates to Ps (i.e. it instructs 210 the network to deliver the packet to P notvia S). All of the 211 neighbors of S will have calculated a path to Ps in case S itself 212 had failed. S could therefore give the packet to any of its 213 neighbors (except, of course, P). However, S should preferably send 214 the encapsulated packet on the shortest available path to P. This 215 path is calculated by running an SPF with the link SP failed. Note 216 that this may again be an incremental calculation which can 217 terminate when address Ps has been reattached. 219 It is necessary to consider the behavior of IPFRR solutions when a 220 link repair is attempted in the presence of node failure. The 221 notvia IPFRR solution prevents the formation of loops forming as a 222 result of mutual repair, by never providing a repair path for a 223 notvia address. Referring to Figure 1, if A was the neighbor of P 224 that was on the link repair path from S to P, and P itself had 225 failed, the repaired packet from S would arrive at A encapsulated 226 to Ps. A would have detected that the AP link had failed and would 227 normally attempt to repair the packet. However, no repair path is 228 provided for any notvia address, and so A would be forced to drop 229 the packet, thus preventing the formation of loop. 231 4.3 Multi-homed Prefix 233 A multi-homed Prefix (MHP) is reachable via more than one router in 234 the network. When IPFRR router S (Figure 2) discovers that P has 235 failed, it needs to send MHP packets addressed to X, which are 236 normally reachable through P, to an alternate router, which is 237 still able to reach X. 239 X X X 240 | | | 241 | | | 242 | Sp |Pb | 243 Z...............S----------P----------B...............Y 244 Ps|Pc Bp 245 | 246 Cp| 247 C 249 Figure 2: Multi-home Prefixes 251 S should choose the closest router that can reach X during the 252 failure as the alternate router. S determines which router to use 253 as the alternate while running the SPF with P failed. This is 254 accomplished by continuing to run the incremental SPF with P failed 255 until all of P's notvia addresses and MHPs (X) are attached. 257 Assume that the alternate router is Z, which S can reach without 258 using the failed router P. S cannot just send the packet towards Z, 259 because the other routers in the network will not be aware of the 260 failure of P, and may loop the packet back to S. S therefore 261 encapsulates the packet to Z (using a normal address for Z). Z 262 removes the encapsulation and forwards the packet to X. 264 Now assume that the alternate router is Y, which S reaches via P 265 and B. To reach Y, S must first repair the packet to B using the 266 normal notvia repair mechanism. To do this S encapsulates the 267 packet for X to Bp. B removes the encapsulation and discovers that 268 the packet is intended for MHP X. B then follows the algorithm 269 above and B encapsulates the packet to Y (using a normal address 270 for Y). Y removes the encapsulation and forwards the packet to X. 272 It may be that the cost of reaching X using local delivery from the 273 alternate router is greater than the cost of reaching X via P. 274 Under those circumstances the alternate router would normally 275 forward to X via P, which would cause the IPFRR repair to loop. To 276 prevent the repair from looping the alternate router must locally 277 deliver a packet received via a repair encapsulation. 279 Notice that using the notvia approach, only one level of 280 encapsulation was needed to repair MHPs to the alternate router. 282 4.4 Shared Risk Groups 284 When the network contains a shared risk group (SRG), it must be 285 assumed that all members of the SRG fail simultaneously. When 286 undertaking SRG repair the scope of the notvia address therefore 287 changes from notvia a particular router to notvia the whole SRG. 288 All routers calculate a route to each of the notvia addresses of 289 the interfaces that connect the SRG to the rest of the network. 290 This calculation is made by simultaneously failing all members of 291 the SRG in the incremental SPF. 293 When a router that is adjacent to an SRG member makes a repair, it 294 encapsulates the packet to the notvia address of the router that 295 has the lowest cost from the SRG to the destination (i.e. the 296 egress point of the SRG prior to the failure). 298 Asrg Fsrg 299 S----------P------P'--------A----P''------F--------G 300 | | | 301 |Csrg |Dsrg | 302 C D E 303 | | | 304 | | | 305 H J K 307 Figure 3: Shared Risk Group 309 Thus in Figure 3, S would encapsulate to Csrg to reach H, to Dsrg 310 to reach J, to Asrg to reach K and to Fsrg to reach G. 312 4.5 Multicast 314 Multicast traffic is repaired in a similar way to unicast, however 315 the multicast forwarder is able to use the notvia address to which 316 the multicast packet was addressed as an indication of the expected 317 receive interface and hence to correctly run the required RPF 318 check. 320 A more complete description of multicast operation will be provided 321 in the next version of this draft. 323 4.6 Fast Reroute in an MPLS LDP Network. 325 Notvia addresses are IP addresses and LDP will distribute labels 326 for them in the usual way. The notvia repair mechanism may 327 therefore be used to provide fast re-route in an MPLS network by 328 first pushing the label which the repair endpoint uses to forward 329 the packet, and then pushing the label corresponding to the notvia 330 address needed to effect the repair. Referring once again to Figure 331 1, if S has a packet destined for D that it must reach via P and B, 332 S first pushes B's label for D. S then pushes the label that its 333 next hop to Bp needs to reach Bp. 335 Note that in an MPLS LDP network it is necessary for S to have the 336 repair endpoint's label for the destination. When S is effecting a 337 link repair it already has this. In the case of a node repair, S 338 either needs to set up a directed LDP session with each of its 339 neighbor's neighbors, or it needs to use the next-next hop label 340 distribution mechanism proposed in [NNHL]. Where an extended SRG is 341 being repaired, S must determine which routers its traffic would 342 traverse on egress form the SRG, and then establish directed LDP 343 sessions with each of those routers. 345 5. Local Area Networks 347 LANs are a special type of SRG and are solved using the SRG 348 mechanisms outlined above. With all SRGs there is a trade-off 349 between the sophistication of the fault detection and the size of 350 the SRG. 352 +--------------P'-------C 353 | 354 | 355 | 356 A--------S--------+ 357 (N) 358 +--------------P--------B 359 | 360 | 361 | 362 +--------------P''------D 364 Figure 4 Local Area Networks 366 Consider the LAN shown in Figure 4. For connectivity purposes, we 367 consider that the LAN is represented by the pseudonode (N). To 368 provide IPFRR protection, S must run a connectivity check to each 369 of its protected LAN adjacencies P, P', and P'', using, for example 370 BFD [BFD]. 372 When S discovers that it has lost connectivity to P, it is unsure 373 whether the failure is: 375 . its own interface to the LAN, 377 . the LAN itself, 379 . the LAN interface of P 381 . or the node P. 383 With no further diagnostics S must repair traffic sent through P 384 and B, to B notvia P,N (i.e. not via P and not via N), on the 385 conservative assumption that both the entire LAN and P have failed. 386 Destinations for which P is a single point of failure must as usual 387 be sent to P using an address which avoids the interface by which P 388 is reached from S, i.e. to P notvia N. Similarly for routers P' and 389 P''. 391 Notice that each router that is connected to a LAN must, as usual, 392 advertise one notvia address for each neighbor. In addition, each 393 router on the LAN must advertise an extra address not via the 394 pseudonode (N). 396 Notice also that each neighbor of a router connected to a LAN must 397 advertise two notvia addresses, the usual one not via the neighbor 398 and an additional one, not via either the neighbor or the 399 pseudonode. The required set of LAN address assignments is shown in 400 figure 5 below. Each router on the LAN, and each of its neighbors, 401 is advertising exactly one address more than it would otherwise 402 have advertised if this degree of connectivity had been achieved 403 through the use of point to point links. 405 P's P'p P'c Cp'n 406 +--------------P'-------C 407 | P'p''Pn Cp' 408 | 409 Asn Sa Pp Pp' | 410 A--------S--------+ Ps Pp' Pb Bpn 411 As P''Pn +--------------P--------B 412 | Pp''Pn Bp 413 | 414 | Ps Pp Pd Dp''n 415 +--------------P''------D 416 Pp' Pn Dp'' 418 Figure 5 Local Area Networks 420 To explicitly diagnose the failed network component S correlates 421 the connectivity reports from P and one or more of the other 422 routers on the LAN, in this case, P' and P''. If it lost 423 connectivity to P alone, it could deduce that the LAN was still 424 functioning and that the fault lay with either P, or the interface 425 connecting P to the LAN. It would then repair to B not via P (and P 426 notvia N for destinations for which P is a signal point of failure) 427 in the usual way. If S lost connectivity to more than one router on 428 the LAN, it could conclude that the fault lay only with the LAN, 429 and could repair to P, P' and P'' notvia N, again in the usual way. 431 Now we need to consider what happens if S fails. Router A needs to 432 be able to repair to every router on the LAN notvia S which it does 433 in the usual way using the set of notvia S addresses. 435 An alternative approach that provides less post-failure 436 connectivity, but uses less addresses is to consider the LAN and 437 all of its connected routers as a single SRG. Thus the address P 438 not via the LAN (Pl) would require P to be reached notvia any 439 router connected to the LAN. This is shown in Figure 6. 441 P'l Cl 442 +--------------P'-------C 443 | P'c 444 | 445 As Sl | 446 A--------S--------+ Pl Bl 447 Sa +--------------P--------B 448 | Pb 449 | 450 | P''l Dl 451 +--------------P''------D 452 P''d 454 Figure 6 Local Area Networks - LAN SRG 456 In this case when S detected that P had failed it would send 457 traffic reached via P and B to B notvia the LAN or any router 458 attached to the LAN (i.e. to Bl). Any destination only reachable 459 through P would be addressed to P notvia the LAN or any router 460 attached to the LAN (except of course P). 462 6. Loop Free Alternatives 464 The use of loop free alternates (LFA) as a repair mechanism has 465 been studied [LFA]. Where an LFA exists, S may use this in place of 466 the notvia repair mechanism for unicast packets (including MHP 467 alternate routers). Multicast traffic requires the use of a repair 468 encapsulation so that the router at the repair endpoint can make 469 the necessary RPF check. 471 7. Equal Cost Multi-Path 473 A router can use an equal cost multi-path (ECMP) repair in place of 474 a notvia repair for unicast packets. 476 A router computing a notvia repair path MAY subject the repair to 477 ECMP. 479 8. Encapsulation 481 Any IETF specified IP in IP encapsulation may be used to carry a 482 notvia repair. IP in IP [IPIP], GRE [RFC1701] and L2TPv3 [L2TPv3], 483 all have the necessary and sufficient properties. The requirement 484 is that both the encapsulating router and the router to which the 485 encapsulated packet is addressed have a common ability to process 486 the chose encapsulation type. 488 9. Routing Extensions 490 IPFRR requires IGP extensions. Each IPFRR router that is directly 491 connected to a protected network component must advertise a notvia 492 address for that component. This must be advertised in such a way 493 that the association between the protected component (router or 494 SRG) and the notvia address can be determined by the other routers 495 in the network. 497 It is necessary that notvia capable routers advertise in the IGP 498 that they will calculate notvia routes. 500 It is necessary for routers to advertise the type of encapsulation 501 that they support (LDP, GRE [RFC1701], L2TPv3 etc). However the 502 deployment of mixed IP encapsulation types within a network is 503 deprecated. 505 10. Incremental Deployment 507 Incremental deployment is supported by excluding routers that are 508 not calculating notvia routes from the base topology. In that way 509 repairs may be steered around island of routers that are not IPFRR 510 capable. 512 Routers that are protecting a network component need to have the 513 capability to encapsulate and decapsulate packets. However, routers 514 that are on the repair path only need to be capable of calculating 515 notvia paths and including the notvia addresses in their FIB i.e. 516 these routers do not need any changes to their forwarding 517 mechanism. 519 11. IANA considerations 521 There are no IANA considerations that arise from this draft. 523 12. Security Considerations 525 The repair endpoints present vulnerability in that they might be 526 used as a method of disguising the delivery of a packet to a point 527 in the network. The primary method of protection should be through 528 the use of a private address space for the notvia addresses. These 529 addresses MUST NOT be advertised outside the area, and SHOULD be 530 filtered at the network entry points. In addition a mechanism might 531 be developed that allowed the use of the mild security available 532 through the use of a key [RFC1701] [L2TPv3]. With the deployment of 533 such mechanisms, the repair endpoints would not increase the 534 security risk beyond that of existing IP tunnel mechanisms. 536 An attacker may attempt to overload a router by addressing an 537 excessive traffic load to the decapsulation endpoint. Typically 538 routers take a 50% performance penalty in decapsulating a packet. 539 The attacker could not be certain that the router would be 540 impacted, and the extremely high volume of traffic needed, would 541 easily be detected as an anomaly. 543 If an attacker were able to influence the availability of a link, 544 they could cause the network to invoke the notvia repair mechanism. 545 A network protected by notvia IPFRR is less vulnerable to such an 546 attack than a network that undertook a full convergence in response 547 to a link up/down event. 549 Intellectual Property Statement 551 The IETF takes no position regarding the validity or scope of any 552 Intellectual Property Rights or other rights that might be claimed 553 to pertain to the implementation or use of the technology described 554 in this document or the extent to which any license under such 555 rights might or might not be available; nor does it represent that 556 it has made any independent effort to identify any such rights. 557 Information on the procedures with respect to rights in RFC 558 documents can be found in BCP 78 and BCP 79. 560 Copies of IPR disclosures made to the IETF Secretariat and any 561 assurances of licenses to be made available, or the result of an 562 attempt made to obtain a general license or permission for the use 563 of such proprietary rights by implementers or users of this 564 specification can be obtained from the IETF on-line IPR repository 565 at http://www.ietf.org/ipr. 567 The IETF invites any interested party to bring to its attention any 568 copyrights, patents or patent applications, or other proprietary 569 rights that may cover technology that may be required to implement 570 this standard. Please address the information to the IETF at 571 ietf-ipr@ietf.org. 573 Full copyright statement 575 Copyright (C) The Internet Society (2004). This document is subject 576 to the rights, licenses and restrictions contained in BCP 78, and 577 except as set forth therein, the authors retain all their rights. 579 This document and the information contained herein are provided on 580 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 581 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 582 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 583 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 584 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 585 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 586 PARTICULAR PURPOSE. 588 Normative References 590 There are no normative references. 592 Informative References 594 Internet-drafts are works in progress available from 595 597 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding 598 Detection", < draft-katz-ward-bfd-02.txt>, May 599 2004, (work in progress). 601 RFC1701 RFC 1701, Generic Routing Encapsulation (GRE). 602 S. Hanks, T. Li, D. Farinacci, P. Traina. 603 October 1994. 605 [IPFRR] Shand, M., "IP Fast-reroute Framework", , June 2004, 607 (work in progress). 609 [l2TPV3] J. Lau, Ed., et al., "Layer Two Tunneling 610 Protocol - Version 3 (L2TPv3)" , December 2004, 612 (work in progress) 614 [LFA] A. Atlas, Ed, "Basic Specification for IP Fast- 615 Reroute: Loop-free Alternates", , January 2005, 617 (work in progress). 619 [LDP] Andersson, L., Doolan, P., Feldman, N., 620 Fredette, A. and B. Thomas, "LDP 621 Specification", RFC 3036, 622 January 2001. 624 [NNHL] Shen, N., et al "Discovering LDP Next-Nexthop 625 Labels", , July 2004, (work in progress) 628 [MPLS-TE] Ping Pan, et al, "Fast Reroute Extensions to 629 RSVP-TE for LSP Tunnels", 630 , 631 (work in progress). 633 [TUNNEL] Bryant, S., Shand, M., "IP Fast Reroute using 634 tunnels", , 635 May 2004 (work in progress). 637 Authors' Addresses 639 Stewart Bryant 640 Cisco Systems, 641 250, Longwater, 642 Green Park, 643 Reading, RG2 6GB, 644 United Kingdom. Email: stbryant@cisco.com 646 Mike Shand 647 Cisco Systems, 648 250, Longwater, 649 Green Park, 650 Reading, RG2 6GB, 651 United Kingdom. Email: mshand@cisco.com