idnits 2.17.1 draft-bryant-ipfrr-tunnels-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1150. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1163. ** 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (Apr 2005) is 6944 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: 'FRMWK' is mentioned on line 93, but not defined == Missing Reference: 'L' is mentioned on line 764, but not defined == Missing Reference: 'D' is mentioned on line 764, but not defined == Missing Reference: 'S' is mentioned on line 877, but not defined == Missing Reference: 'E' is mentioned on line 881, but not defined == Missing Reference: 'X' is mentioned on line 881, but not defined == Missing Reference: 'Y' is mentioned on line 881, but not defined == Missing Reference: 'Z' is mentioned on line 881, but not defined == Missing Reference: 'LVCONV' is mentioned on line 1062, but not defined == Unused Reference: 'LFCONV' is defined on line 1208, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) Summary: 3 errors (**), 0 flaws (~~), 13 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 C. Filsfils 3 Expiration Date: Oct 2005 S. Previdi 4 M. Shand 5 Cisco Systems 7 Apr 2005 9 IP Fast Reroute using tunnels 11 draft-bryant-ipfrr-tunnels-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This draft describes an IP fast re-route mechanism that provides 40 backup connectivity in the event of a link or router failure. In 41 the absence of single points of failure and asymmetric costs, the 42 mechanism provides complete protection against any single failure. 43 If perfect repair is not possible, the identity of all the 44 unprotected links and routers is known in advance. 46 Table of Contents 47 1. Introduction......................................................4 48 2. Goals, non-goals, limitations and constraints.....................4 49 2.1. Goals.........................................................4 50 2.2. Non-Goals.....................................................5 51 2.3. Limitations...................................................5 52 2.4. Constraints...................................................5 53 3. Repair Paths......................................................6 54 3.1. Tunnels as Repair Paths.......................................6 55 3.2. Tunnel Requirements...........................................9 56 3.2.1. Setup.....................................................9 57 3.2.2. Multipoint................................................9 58 3.2.3. Directed forwarding.......................................9 59 3.2.4. Security..................................................9 60 4. Construction of Repair Paths.....................................10 61 4.1. Identifying Repair Path Targets..............................10 62 4.2. Determining Tunneled Repair Paths............................10 63 4.2.1. Computing Repair Paths...................................11 64 4.2.2. Extended F-space.........................................12 65 4.2.3. Loop-free Alternates.....................................12 66 4.2.4. Selecting Repair Paths...................................12 67 4.3. Assigning Traffic to Repair Paths............................13 68 4.4. When no Repair Path is Possible..............................13 69 4.4.1. Unreachable Target.......................................14 70 4.4.2. Asymmetric Link Costs....................................14 71 4.4.3. Interference Between Potential Node Repair Paths.........14 72 4.5. Multi-homed Prefixes.........................................17 73 4.6. LANs and pseudo-nodes........................................18 74 4.6.1. The Link between Routers S and E is a LAN................19 75 4.6.1.1. Case 1...............................................19 76 4.6.1.2. Case 2...............................................19 77 4.6.1.3. Simplified LAN repair................................20 78 4.6.2. A LAN exists at the release point........................20 79 4.6.3. A LAN between E and its neighbors........................20 80 4.6.4. The LAN is a Transit Subnet..............................21 81 5. Failure Detection and Repair Path Activation.....................21 82 5.1. Failure Detection............................................21 83 5.2. Repair Path Activation.......................................21 84 5.3. Node Failure Detection Mechanism.............................21 85 6. Loop Free Transition.............................................22 86 7. IPFRR Capability.................................................22 87 8. Enhancements to routing protocols................................23 88 9. IANA considerations..............................................23 89 10. Security Considerations...............Error! Bookmark not defined. 91 Terminology 93 This draft uses the terms defined in [FRMWK]. This section defines 94 additional words, acronyms, and actions used in this draft. 96 Directed The ability of the repairing router (S) to 97 forwarding specify the next hop (G) on exit from a 98 tunnel end-point (F) 100 Extended F- The union of the F-space of the neighbors of 101 space a specific router with respect to a common 102 component. 104 Extended F-space does not include the 105 additional space reachable though directed 106 forwarding. 108 F The router in F-space to which a packet is 109 tunneled for repair. 111 FG A router that is in both F and G space and 112 hence does not need directed forwarding. 114 F-space F-space is the set of routers reachable from 115 a specific router without any path 116 (including equal cost path splits) 117 transiting a specified component. 119 For example, the F-space of S, is the set of 120 routers that S can reach without using E 121 (router failure case) or the S-E link 122 failure case). 124 G The router in G space, to which the packet 125 is directed by router F on exit from the 126 repair tunnel. G will always be adjacent to 127 F, or F itself. 129 G-space G-space is the set of routers from which a 130 specific router can be reached without any 131 path (including equal cost path splits) 132 transiting a specified component. 134 Interference The condition where the network costs are 135 such that a repairing router cannot tunnel a 136 packet sufficiently far from a failed node 137 such that it is not attracted back to the 138 failed node via another of that node's 139 neighbors. 141 1. Introduction 143 When a link or node failure occurs in a routed network, there is 144 inevitably a period of disruption to the delivery of traffic until 145 the network re-converges on the new topology. Packets for 146 destinations which were previously reached by traversing the failed 147 component may be dropped or may suffer looping. Traditionally such 148 disruptions have lasted for periods of at least several seconds, 149 and most applications have been constructed to tolerate such a 150 quality of service. 152 Recent advances in routers have reduced this interval to under a 153 second for carefully configured networks using link state IGPs. 154 However, new Internet services are emerging which may be sensitive 155 to periods of traffic loss which are orders of magnitude shorter 156 than this. 158 Addressing these issues is difficult because the distributed nature 159 of the network imposes an intrinsic limit on the minimum 160 convergence time which can be achieved. 162 However, there is an alternative approach, which is to compute 163 backup routes that allow the failure to be repaired locally by the 164 router(s) detecting the failure without the immediate need to 165 inform other routers of the failure. In this case, the disruption 166 time can be limited to the small time taken to detect the adjacent 167 failure and invoke the backup routes. This is analogous to the 168 technique employed by MPLS Fast Reroute [MPLSFRR], but the 169 mechanisms employed for the backup routes in pure IP networks are 170 necessarily very different. 172 A framework for IP Fast Reroute [IPFRR] provides a summary of the 173 proposed IPFRR solutions, and a partial solution using equal cost 174 multi-path and loop-free alternate case is described in [BASIC]. 176 This draft describes extensions to the basic repair mechanism in 177 which we propose the use of tunnels to provide additional logical 178 downstream paths. These mechanisms provide almost 100% repair 179 connectivity in practical networks. 181 2. Goals, non-goals, limitations and constraints 183 2.1. Goals 185 The following are the goals of IPFRR: 187 o Protect against any link or router failure in the network. 189 o No constraints on the network topology or link costs. 191 o Never worse than the existing routing convergence 192 mechanism. 194 o Co-existence with non-IP fast-reroute capable routers in 195 the network. 197 2.2. Non-Goals 199 The following are non-goals of IPFRR: 201 o Protection of a single point of failure. 203 o To provide protection in the presence of multiple 204 concurrent failures other than those that occur due to the 205 failure of a single router. 207 o Shared risk group protection. 209 o Complete fault coverage in networks that make use of 210 asymmetric costs. 212 2.3. Limitations 214 The following limitations apply to IPFRR: 216 o Because the mechanisms described here rely on complete 217 topological information from the link state routing 218 protocol, they will only work within a single link state 219 flooding domain. 221 o Reverse Path Forwarding (RPF) checks cannot be used in 222 conjunction with IPFRR. This is because the use of tunnels 223 may result in packets arriving over different interfaces 224 than expected. 226 2.4. Constraints 228 The following constraints are assumed: 230 o Following a failure, only the routers adjacent to the 231 failure have any knowledge of the failure. 233 o There is insufficient time following a failure to compute a 234 repair strategy based on knowledge of the specific failure 235 that has occurred. 237 o Multiple concurrent failures may not be protected. 239 3. Repair Paths 241 When a router detects an adjacent failure, it uses a set of repair 242 paths in place of the failed component, and continues to use this 243 until the completion of the routing transition. Only routers 244 adjacent to the failed component are aware of the nature of the 245 failure. Once the routing transition has been completed, the router 246 will have no further use for the repair paths since all routers in 247 the network will have revised their forwarding data and the failed 248 link will have been eliminated from this computation. 250 Repair paths are pre-computed in anticipation of later failures so 251 they can be promptly activated when a failure is detected. 253 Three types of repair path are used to achieve the repair: 255 1. Equal cost path-split. 257 2. Loop-free Alternate. 259 3. Tunnel. 261 The operation of equal cost path-split and loop-free alternate is 262 described in [BASIC]. A tunneled repair path tunnels traffic to 263 some staging point from which it will travel to its destination 264 using normal forwarding without looping back. The repair path can 265 be thought of as providing a virtual link, originating at a router 266 adjacent to a failure, and diverting traffic around the failure. 267 This is equivalent to providing a virtual loop-free alternate to 268 supplement the physical loop-free alternates. 270 3.1. Tunnels as Repair Paths 272 The repair strategies described in this draft operate on the basis 273 that if a packet can somehow be sent to the other side of the 274 failure, it will subsequently proceed towards its destination 275 exactly as if it had traversed the failed component. See Figure 1. 277 Repair Path from S to E 278 +-----------+ 279 | | 280 | v 281 ---->[S]---//----[E]-----> 283 Figure 1 Simple Link Repair 285 Creating a repair path from S to E may require a packet to traverse 286 an unnatural route. If a suitable natural path starts at a neighbor 287 (i.e. it is a loop-free alternate), then S can force the packet 288 directly there. If this is not the case, then S may create one by 289 using a tunnel to carry the packet to a point in the network where 290 there is a real loop-free alternate. Note that the tunnel does not 291 have to go from S to E. The tunnel can terminate at any router in 292 the network, provided that S can be sure that the packet will 293 proceed correctly to its destination from that router. 295 A repair path computed for a link failure may not however work 296 satisfactorily when the neighboring router has, itself, failed. 297 This is illustrated in Figure 2. 299 Repair path from S to E 300 +-------------------------+ 301 | | 302 | <------------+ 303 --->[S]---//----[E]----//-----[S1]--> 304 +----------> | 305 | | 306 +-------------------------+ 307 Repair Path from S1 to E 309 Figure 2 Looping Link Repair when Router Fails 311 Consider the case of a router E with just two neighbors S and S1. 312 When router E fails, both S and S1 will observe the failure of 313 their local link to E, but will have no immediate knowledge that E 314 itself has failed. If they were both to attempt to repair traffic 315 around their local link, they would invoke mutual repairs which 316 would loop. 318 Since it is not easy for a router to immediately distinguish 319 between a link failure and the failure of its neighbor, repair 320 paths are calculated in anticipation of adjacent router failure. 321 Thus, for each of its protected links, router S (Figure 3) 322 pre-computes a set of tunneled repair paths, one for each of the 323 neighbors (S1, S2 and S3) of its neighbor E on the S-E link. The 324 set of destinations that are normally assigned to link S-E will be 325 assigned to a repair path based on the neighbor of E through which 326 router E would have forwarded traffic to them. 328 Repair S-S1 329 +----------->[S1] 330 | | 331 | | 332 | | 333 ----->[S]----//-----[E]---------[S2] 334 || | ^ 335 || | | 336 ||Repair S-S3 | | 337 |+---------->[S3] | 338 | | 339 +-------------------------+ 340 Repair S-S2 342 Figure 3: Repair paths in anticipation of a router failure 344 The set of repair paths in Figure 3 will function correctly in the 345 case of link and router failure. However, in some network 346 topologies they may not provide a means for traffic to reach router 347 E itself. This is important in cases where E is a single point of 348 failure and E is still functional (i.e. the failure was actually a 349 failure of the S-E link). Hence, in addition to computing repair 350 paths for the neighbors of its neighbor on a protected link, a 351 router also calculates a repair path for the neighbor itself. This 352 is illustrated in Figure 4. 354 Repair S-E 355 +----------------+ 356 | | 357 | Repair S-S1 | 358 |+---------->[S1]| 359 || | / 360 || | / 361 || |/ 362 ----->[S]----//-----[E]---------[S2] 363 || | ^ 364 || | | 365 ||Repair S-S3 | | 366 |+---------->[S3] | 367 | | 368 +-------------------------+ 369 Repair S-S2 371 Figure 4 The full set of S-E repair paths. 373 In the event of a failure, the only traffic that is assigned to the 374 link repair path (the S-E repair) is that traffic which has no 375 other path to its destination except via E. As we have already 376 seen, there is a danger that traffic assigned to this link repair 377 path may loop if E has failed, therefore, when the repair paths are 378 invoked, a loop detection mechanism is used which promptly detects 379 the loop and, upon detection, withdraws the link (S-E) repair path 380 from service. 382 3.2. Tunnel Requirements 384 There are a number of IP in IP tunnel mechanisms that may be used 385 to fulfill the requirements of this design. Suitable candidates 386 include IP-in-IP [RFC1853], GRE [RFC1701] and L2TPv3 [L2TPv3]. The 387 selection of the specific tunneling mechanism (and any necessary 388 enhancements) used to provide a repair path is outside the scope of 389 this document. However the following sections describe the 390 requirements for the tunneling mechanism. 392 3.2.1. Setup. 394 When a failure is detected, it is necessary to immediately redirect 395 traffic to the repair paths. Consequently, the tunnels used must be 396 provisioned beforehand in anticipation of the failure. IP fast 397 re-route will determine which tunnels it requires. It must 398 therefore be possible to establish tunnels automatically, without 399 management action, and without the need to manually establish 400 context at the tunnel endpoint. 402 3.2.2. Multipoint 404 To reduce the number of tunnel endpoints in the network the tunnels 405 should be multi-point tunnels capable of receiving repair traffic 406 from any IPFRR router in the network. 408 3.2.3. Directed forwarding. 410 Directed forwarding must be supported such that the router at the 411 tunnel endpoint (F) can be directed by the router at the tunnel 412 source (S) to forward the packet directly to a specific neighbor. 413 Specification of the directed forwarding mechanism is outside the 414 scope of this document. Directed forwarding might be provided using 415 an enhancement to the IP tunneling encapsulation, or it might be 416 provided through the use of a single MPLS label stack entry 417 [RFC3032] interposed between the IP tunnel header and the packet 418 being repaired. 420 3.2.4. Security 422 A lightweight security mechanism should be supported to prevent the 423 abuse of the repair tunnels by an attacker. This is discussed in 424 more detail in Section 10. 426 4. Construction of Repair Paths 428 4.1. Identifying Repair Path Targets 430 To establish protection for a link or node it is necessary to 431 determine which neighbors of the neighboring node should be targets 432 of repair paths. Normally all neighbors will be used as repair path 433 targets. However, in some topologies, not all neighbors will be 434 needed as targets because, prior to the failure, no traffic was 435 being forwarded through them by the repairing router. This can be 436 determined by examining the normal shortest path tree (SPT) 437 computed by the repairing router. 439 In addition, the neighboring router E will also be the target of a 440 repair path for any destinations for which E is a single point of 441 failure. 443 4.2. Determining Tunneled Repair Paths 445 The objective of each tunneled repair path is to deliver traffic to 446 a target router when a link is observed to have failed. However, it 447 is seldom possible to use the target router itself as the tunnel 448 endpoint because other routers on the repair path, that have not 449 learned of the failure, will forward traffic addressed to it using 450 their least cost path which may be via the failed link. This is 451 illustrated in Figure 5 in which all link costs are one in both 452 directions. Router S's intended repair path for traffic to D when 453 link S-E fails is the path W-X-Y-Z-S1. However, if router S makes 454 S1 be the tunnel endpoint and forwards the packet to router W, 455 router W will immediately return it to S because its least cost 456 path to S1 is S-E-S1 (cost 3 versus cost 4) and has no knowledge of 457 the failure of link S-E. 459 [S]--//--[E]-----[S1] 460 | | 461 | | 462 [W]---[X]---[Y]---[Z] 464 Figure 5. Repair path to target router S1. 466 Thus the tunnel endpoint needs to be somewhere on the repair path 467 such that packets addressed to the tunnel end point will not loop 468 back towards router S. In addition, the release point needs to be 469 somewhere such that when packets are released from the tunnel they 470 will flow towards the target router (or their actual destination) 471 without being attracted back to the failed link. By inspection, in 472 Figure 5, suitable tunnel endpoints are routers X, Y, and Z. 474 Note that it is not essential that traffic assigned to a repair 475 path actually traverse the target router for which the repair path 476 was created. If, for example, in Figure 5, if a packet's 477 destination were normally reached via the path S-E-S1-Z-?-?-?, once 478 it was released at any of the possible tunnel endpoints, it would 479 arrive at its destination by the best available route without 480 traversing S1. 482 In general, the properties that are required of tunnel endpoints 483 are: 485 o the end point must be reachable from the tunnel source 486 without traversing the failed link; and 488 o when released, tunneled packets will proceed towards their 489 destination without being attracted back over the failed 490 link or node. 492 Provided both of these conditions are met, packets forwarded on the 493 repair path will not loop. 495 In some topologies it will not be possible to find a tunnel 496 endpoint that exhibits both the required properties. For example, 497 in Figure 5, if the cost of link X-Y were increased from one to 498 four in both directions, there is no longer a viable endpoint 499 within the fragment of the topology shown. 501 To solve this problem we introduce the concept of directed 502 forwarding from the tunnel endpoint. Directed forwarding allows the 503 originator of a tunneled packet to instruct that, when it is 504 decapsulated at the end of the tunnel, it be forwarded via a 505 specific adjacency, and not be subjected to the normal forwarding 506 decision process. This effectively allows the tunnel to be extended 507 by one hop. So, for example, in Figure 5 with the cost of link X-Y 508 set to four, it would be possible to select X as the tunnel 509 endpoint with the directive that X always forward the packets it 510 decapsulates via the adjacency to Y. Thus, router X is reached 511 from S using normal forwarding, and directed forwarding is then 512 used to force packets to router Y, from where S1 can be reached 513 using normal forwarding. 515 Provided link costs are symmetrical, it can be proved that it is 516 always possible to compute a tunneled repair path (possibly using 517 directed forwarding) around a link failure, and that the tunnel 518 endpoint (F) and the release point (G) will be coincident, or may 519 be separated by at most one hop. 521 4.2.1. Computing Repair Paths 523 For a router S, determining tunneled repair paths around a 524 neighboring router E, the set of potential tunnel end points 525 includes all the routers that can be reached from S using normal 526 forwarding without traversing the failed link S-E. This is termed 527 the "F-space" of S with respect to the failure of E. Any router 528 that is on an equal cost path split via the failed link is excluded 529 from this set. 531 The resulting set defines all the possible tunnel end points that 532 could be used in repair paths originating at router S for the 533 failure of link S-E. This set can be obtained by computing an SPT 534 rooted at S and excising the sub-tree reached via the S-E link. 536 The set of possible release points can be determined by computing 537 the set of routers that can reach the repair path target without 538 traversing the failed link. This is termed the "G-space" of the 539 target with respect to the failure. The G-space can be obtained by 540 computing a reverse shortest path tree (rSPT) rooted at the repair 541 path target, with the sub-tree which traverses the failed link (or 542 node) excised. The rSPT uses the cost towards the root rather than 543 from it and yields the best paths towards the root from other nodes 544 in the network. 546 The intersection of the target's G-space with S's F-space includes 547 all the possible release points for any repair path not employing 548 directed forwarding. Where there is no intersection, but there 549 exist a pair of routers, F in S's F-space and G in the target's 550 G-space, router F can be used as the tunnel endpoint with directed 551 forwarding to the release point G. 553 4.2.2. Extended F-space 555 The description in section 4.2.1 calculated router S's F-space 556 rooted at S itself. However, since router S will only use a repair 557 path when it has detected the failure of the link S-E, the initial 558 hop of the repair path need not be subject to S's normal forwarding 559 decision process. Thus we introduce the concept of extended F- 560 space. Router S's extended F-space is the union of the F-spaces of 561 each of S's neighbors. The use of extended F-space may allow router 562 S to repair to targets that were otherwise unreachable. 564 4.2.3. Loop-free Alternates 566 When a loop-free alternate exists, no tunneling is required. 568 4.2.4. Selecting Repair Paths 570 The mechanisms described above will identify all the possible 571 release points that can be used to reach each particular target. 572 (The circumstances when no release points exist are described in 573 section 4.4.) In a well-connected network there are likely to be 574 multiple possible release points for each target, and all will work 575 correctly. For simplicity, one release point per target is chosen. 576 All will deliver the packets correctly so, arguably, it does not 577 matter which is chosen. However, one release point may be preferred 578 over the others on the basis of path cost or some other criteria. 580 It is an implementation matter as to how the release point is 581 selected. 583 4.3. Assigning Traffic to Repair Paths 585 Once the repair path for each target has been selected, it is 586 necessary to determine which of the destinations normally reached 587 via the protected link should be assigned to which of the repair 588 paths when the link fails. 590 This is achieved by recording which neighbor of E would be used to 591 reach each destination reachable over S-E when running the original 592 SPF. Traffic assignment is then simply a matter of assigning the 593 traffic which E would have forwarded via each neighbor to the 594 repair path which has that neighbor as its target. 596 Although the repair paths are calculated based on traffic addressed 597 to specific targets, it can be proved that the traffic assignment 598 algorithm guarantees that the repair path can be used for any 599 traffic assigned to it. 601 Where E would normally split the traffic to a particular 602 destination via two or more of its neighbors, it is an 603 implementation decision whether the repaired traffic should be 604 split across the corresponding set of repair paths. 606 The repair path to E itself is normally used just for traffic 607 destined for E and any prefixes advertised by E. However, under 608 some circumstances, it may be impossible to compute a repair path 609 to one or more of E's neighbors, for example, because E is a single 610 point of failure. In this case traffic for the destinations served 611 by the otherwise irreparable targets is assigned to the repair path 612 with E as its target, in the optimistic assumption that router E is 613 still functioning. If router E is indeed still functioning, this 614 will ensure delivery of the traffic. If, however, router E has 615 failed, the traffic on this repair path will loop as previously 616 shown in section 3.1. The way this is detected, and the course of 617 action when it is detected, is described in section 5.3. 619 4.4. When no Repair Path is Possible 621 Under some circumstances, it will not be possible to identify a 622 repair path to one or more of the targets. This can occur for the 623 following reasons: 625 o The neighboring router that is presumed to have failed 626 constitutes a single point of failure in the network. 628 o Severely asymmetric link costs may cause an otherwise 629 viable physical repair path to be unusable. 631 o Interference may occur between the repair paths of 632 individual targets. 634 In practice, these cases are unlikely to be encountered frequently. 635 Networks that will benefit from the mechanisms described here will 636 usually exhibit considerable redundancy and are normally operated 637 with largely symmetric link costs. Note that a router's inability 638 to compute a full set of repair paths for one of its links does not 639 necessarily affect its ability to do so for its other links. 641 Example topologies illustrating each of the three cases above are 642 described in the following subsections. 644 4.4.1. Unreachable Target 646 If the failure of a neighboring router makes one or more of its 647 neighbors genuinely unreachable, clearly it will not be possible to 648 establish a repair path to such targets. Such single points of 649 failure are not expected to be encountered frequently in properly 650 designed networks, and will probably occur only when the network 651 has previously suffered other failures that have reduced its 652 connectivity. 654 4.4.2. Asymmetric Link Costs 656 When link costs have been set asymmetrically, it is possible that a 657 repair path cannot be constructed even using directed forwarding. 659 Although it is trivial to construct a network fragment with this 660 property, this should not be regarded as a major problem. Firstly, 661 asymmetric link costs are seldom used deliberately. And, secondly, 662 even when an asymmetric link cost prevents one potential repair 663 path being used, there will normally be other ones available. 665 4.4.3. Interference Between Potential Node Repair Paths 667 Under some circumstances the existence of one neighbor may 668 interfere with a potential repair path to another. Consider the 669 topology shown in Figure 6, in which all links have a symmetrical 670 cost of one, with the exception of that between H and I, which has 671 a cost of 3. In this example, the fact that router J is a neighbor 672 of E prevents the discovery of a repair path from router S to 673 router S1 despite the existence of an apparently suitable path. 675 [S]---//---[E]-------[S1] 676 | | | 677 | | | 678 [H]-3-[I]--[J]--[K]--[L] 680 Figure 6. Interference between repair paths 682 A repair path from router S to J can use J itself as the release 683 point by employing directed forwarding from I. However, it is not 684 possible to identify a suitable release point for a repair path to 685 router S1 within the topology shown since there is nowhere that 686 router S can reach that will subsequently forward traffic to 687 router S1 except via the forbidden link E-S1 (J's least cost path 688 to S1 is J-E-S1). This is because the extended F-space of router S 689 is separated by more than one hop from the G-space of router S1. 691 Since the topology shown in Figure 6 will typically form part of a 692 much larger topology, a different, and possibly more circuitous 693 repair path from S to S1, that does not go via J, may be 694 discovered. This is illustrated in Figure 7. In this enhanced 695 topology, a repair path to S1 using Y as the release point can be 696 used. 698 [S]---//---[B]-------[S1] 699 | | | 700 | | | 701 [H]-3-[I]--[J]--[K]--[L] 702 | | 703 | | 704 [X]--[Y]--[Z] 706 Figure 7. Resolving interference in a larger network 708 Note that, in Figure 6, if the traffic for S1 were assigned to the 709 repair path for J, it would correctly reach S1 because J would 710 assign it to its repair path to S1. That is, packets from S to S1 711 would travel via two successive tunnels. Consequently, this is 712 referred to as a "secondary repair path". However, it is not always 713 the case that interference can be handled in this fashion and it is 714 possible to create looping repair paths. 716 One possibility of looping repair paths is illustrated in Figure 8. 717 All links have a symmetrical cost of one with the exception of H-I, 718 which is cost 3 in both directions, and K-L and L-S1 which are cost 719 5 in the indicated direction and cost 1 in the other. 721 [S]---//---[E]--------[S1] 722 | | |^ 723 | | |5 724 [H]-3-[I]--[J]--[K]---[L] 725 5> 727 Figure 8 Looping secondary repair paths 729 In this topology, S can establish a repair path to J, but cannot 730 establish a repair path to S1 because of interference. Router S 731 might assign traffic intended for S1 onto its repair path to J 732 expecting it to undergo a secondary repair towards S1. However, 733 because of the asymmetrical link costs, J is unable to establish a 734 repair path to S1. It is only able to establish a repair path to S. 735 If J, like S, elected to forward repaired traffic to S1 using its 736 (only) repair path to S, similarly expecting a secondary repair to 737 get it to its destination, traffic for S1 would loop between S 738 and J. Thus when interference occurs, the possibility of a 739 secondary repair path cannot be relied upon to ensure that traffic 740 reaches its destination. 742 In order to determine the viability of secondary repair paths, it 743 is necessary for each router to take into account the repair paths 744 which the other neighbors of router E can achieve. These can be 745 computed locally by running the repair path computation algorithms 746 rooted at each of those neighbors. It is only necessary to compute 747 the repair paths from the routers to which router S can establish 748 repair paths, with targets of those routers to which repair paths 749 have not yet been established. 751 It is then possible to determine whether all routers can now be 752 reached by invoking secondary (or if necessary tertiary, etc.) 753 repair paths, and if so, to which primary repair path traffic for 754 each target should be assigned. 756 There is another, more subtle, possibility of loops arising when 757 secondary repair paths are used. This is illustrated in Figure 9, 758 where all links are cost 1 with the exception of L-K which has a 759 cost 5 in that direction and cost 1 in the direction K-L. 761 [S]---//---[E]--------[S1] 762 | | | 763 | | | 764 [L] | [D] 765 5| | | 766 v| | | 767 [K]---[J]--[I]---[H]--[E] 769 Figure 9 Example of an apparently non-looping secondary repair path 770 which results in a loop. 772 Router S has a primary repair path to I (with a release point 773 of K), and I has a primary repair path to S1 (with a release point 774 of E). It would appear that these form a non-looping secondary 775 repair path from S to S1. As usual, the primary repair path from S 776 to I has been computed on the basis of destinations normally 777 reachable through E-I. However, when making use of the secondary 778 repair path, the traffic inserted in the repair path from S to I 779 will be destined not for one of the routers normally reachable via 780 E-I, but for S1. Hence this repair path is not necessary valid for 781 such traffic and in this example it will have a 50% probability of 782 being forwarded back along the path K-L-S-E-S1, and hence looping. 784 This problem can in general be avoided by choosing a release point 785 for the initial primary repair with the property that traffic for 786 the secondary target (S1) is guaranteed to traverse the primary 787 target (I). This can be achieved by computing the rSTF rooted at 788 the secondary target (S1) and examining the sub-tree which 789 traverses the primary target. It can be proved that in the absence 790 of asymmetric link costs, such a release point will always exist. 791 Where asymmetric link costs prevent this, the traffic can be 792 encapsulated to the intermediate router (I), which may require the 793 use of double encapsulation. On reaching router I, the traffic for 794 S1 is decapsulated and then forwarded in I's primary repair path to 795 S1 (via router E, in the example). 797 4.5. Multi-homed Prefixes 799 Up to this point, it has been assumed that any particular prefix is 800 "attached" to exactly one router in the network, and consequently 801 only the routers in the network need be considered when 802 constructing repair paths, etc. However, in many cases the same 803 prefix will be attached to two or more routers. Common cases are: 805 o The subnet present on a link is advertised from both ends 806 of the link. 808 o Prefixes are propagated from one routing domain to another 809 by multiple routers. 811 o Prefixes are advertised from multiple routers to provide 812 resilience in the event of the failure of one of the 813 routers. 815 In general, this causes no particular problems, and the shortest 816 route to each prefix (and hence which of the routers to which it is 817 attached should be used to reach it) is resolved by the normal SPF 818 process. However, in the particular case where one of the instances 819 of a prefix is attached to router E, or to a router for which 820 router E is a single point of failure, the situation is more 821 complicated. 823 P 824 | 825 | 826 [S]---//---[E]--------[S1] 827 | | p 828 | | | 829 [W]-----[X]----[Y]----[Z]-[I]-[J]-[K]-[L]-[M]-[N] 831 Figure 10 A multi-homed prefix p 833 Consider a prefix p, which is attached to router E and some other 834 router N as illustrated in Figure 10. Before the failure of the 835 link S-E, p is reachable from S via S-E. After the failure it 836 cannot be assumed that E is still reachable. If traffic to p is 837 assigned to a link repair path to E (as it would be if p were 838 attached only to E), and router E has failed, then it would loop 839 and subsequently be dropped. Traffic for p cannot simply be 840 assigned to whatever repair path would be used for traffic to N, 841 because other routers, which are not yet aware of any failure, may 842 direct the traffic back towards E, since the instance of p attached 843 to E is closer. 845 A solution is to treat p itself as a neighbor of E, and compute a 846 repair path with p as a target. However, although correct, this 847 solution may be infeasible where there are a very large number of 848 such prefixes, which would result in an unacceptably large 849 computational overhead. 851 Some simplification is possible where there exist a large number of 852 multi-homed prefixes which all share the same connectivity and 853 metrics. These may be treated as a single router and a single 854 repair path computed for the entire set of prefixes. 856 An alternative solution is to tunnel the traffic for a multi-homed 857 prefix to the router N where it is also attached (see Figure 10). 858 If this involves a repair path that was already tunneled, then this 859 requires double encapsulation. 861 4.6. LANs and pseudo-nodes 863 In link state protocols a LAN is represented by a construct known 864 as a pseudo-node in IS-IS and a network LSA in OSPF. 866 In order to deal correctly with this representation of LANs, the 867 algorithms described in this draft require certain modifications. 868 There are four cases which require consideration. These are 869 described in the following subsections. 871 4.6.1. The Link between Routers S and E is a LAN 873 In this case, the link which is being protected is a LAN, and the 874 router E which has potentially failed is reachable over the LAN. 875 This is illustrated in Figure 11. 877 [S] 878 | 879 ===================== 880 | | | | 881 [E] [X] [Y] [Z] 883 Figure 11 The link between routers S and E is a LAN 885 There are two possible failure modes in this case. 887 4.6.1.1. Case 1 889 Router E or its interface to the LAN may have failed independently 890 of the rest of the LAN. In this case the remaining routers on the 891 LAN (routers X, Y and Z) will remain reachable from router S. These 892 routers do not appear as direct neighbors of router E in the link 893 state database and are not treated as neighbors of router E for the 894 purposes of this specification because no traffic from router S 895 would be directed through router E to any of these routers. 896 However, each of these neighboring routers will have router E as a 897 neighbor and they will initiate their own repair paths in the event 898 of the failure of router E or its LAN interface. 900 Repair paths are computed with the non-LAN neighbors of E as 901 targets, and also E itself (the "link-failure" repair path). Note 902 that since the remaining neighbors of S on the LAN are assumed to 903 be still reachable when the link to E has failed, these repair 904 paths may traverse the LAN. 906 A separate set of repair paths is required in anticipation of the 907 potential failure of each router on the LAN. 909 4.6.1.2. Case 2 911 Router S's interface to the LAN may have failed (or the entire LAN 912 may have failed). In either event, simultaneous failures will be 913 observed from router S to all the remaining routers on the LAN 914 (routers E, X, Y and Z). In this case, the pseudo-node itself can 915 be treated as the "adjacent" router (i.e. the router normally 916 referred to as "router E"), and repairs constructed using the 917 normal mechanisms with all the neighbors of the pseudo-node 918 (routers E, X, Y and Z) as repair path targets. If one or more of 919 the routers had failed in addition to the LAN connectivity, 920 treating it as a repair path target would not be viable, but this 921 would be a case of multiple simultaneous failures which is out of 922 scope of this specification. 924 The entire sub-tree over S's LAN interface is the failed component 925 and is excised from the SPT when computing S's extended F-space. 926 For the G-spaces of the targets, the sub-tree over the LAN 927 interface of the target is excised. 929 4.6.1.3. Simplified LAN repair 931 A simpler alternative strategy is to always consider the LAN and 932 all routers attached to it as failing as a single unit. In this 933 case, a single set of repair paths is computed with targets being 934 the entire set of non-LAN neighbors of all the routers on the LAN, 935 together with "link-repair" paths with all the routers on the LAN 936 as targets. Any failure of one or more LAN adjacencies results in 937 these repair paths being invoked for all neighbors on the LAN. 938 These repair paths must not traverse the LAN, and so must be 939 computed by excising the entire sub-tree reachable over S's LAN 940 interface from S's SPT (i.e. the entire LAN is the failed 941 component). The G-spaces are computed as normal, with the LAN 942 neighbors or their interface to the LAN being excised as 943 appropriate. This is simpler than the approach proposed above, but 944 will fail to make use of possible repair paths (or even path 945 splits) over the LAN. In particular, if the only viable repair 946 paths involve the LAN, it will prevent any repair being possible. 948 4.6.2. A LAN exists at the release point 950 When computing the viable release points, it may be that one or 951 more of the leaf nodes are actually pseudo-nodes. In this case, the 952 release point is deemed to be any of the parent nodes on the LAN by 953 which the pseudo-node had been reached, and when computing the 954 extended set of release points (reachable by directed forwarding), 955 all the remaining routers on the LAN may be included. 957 4.6.3. A LAN between E and its neighbors 959 If there is a LAN between router E and one or more of E's neighbors 960 (other than router S), then rather than treating each of those 961 neighbors as a separate target to which a repair path must be 962 computed, the pseudo-node itself can be treated as a single target 963 for which a repair path can be computed. If there are other 964 neighbors of E which are directly attached to E, including those 965 which may also be attached to the LAN, they must still be treated 966 as an individual repair path target. 968 Normally a repair path with the pseudo-node as its target will have 969 a release point before the pseudo-node. However it is possible that 970 the release point would be computed as the pseudo-node itself. This 971 will occur if the rSPT rooted at the pseudo-node includes no 972 routers other than itself. In this case a single repair with the 973 pseudo-node as target is not possible, and it is necessary to 974 compute individual repair paths whose target are each of the 975 neighbors of E on the LAN. 977 4.6.4. The LAN is a Transit Subnet. 979 This is the most common case, where a LAN is traversed by a repair 980 path, but is not in any of the special positions described above. 981 In this case no special treatment is required, and the normal SPF 982 mechanisms are applicable. 984 5. Failure Detection and Repair Path Activation 986 The details of repair path activation are inherently 987 implementation-dependent and must be addressed by individual design 988 specifications. This section describes the implementation 989 independent aspects of the failover to the repair path. 991 5.1. Failure Detection 993 The failure detection mechanism must provide timely detection of 994 the failure and activation of the repair paths. The failure 995 detection mechanisms may be media specific (for example loss of 996 light), or may be generic (for example BFD). Multiple detection 997 mechanisms may be used in order to improve detection latency. Note 998 that in the case of a LAN it may be necessary to monitor 999 connectivity to all of the adjacent routers on the LAN. 1001 5.2. Repair Path Activation 1003 The mechanism used by the router to activate the repair path 1004 following failure will be implementation specific. 1006 An implementation that is capable of withdrawing the repair may 1007 delay the start of network convergence in order to minimize network 1008 disruption in the event that the failure was a transient. 1010 5.3. Node Failure Detection Mechanism 1012 When router S detects a failure of the S-E link, it will invoke the 1013 link repair path from itself to router S. This S-E link repair is 1014 always invoked because even if all other traffic can be re-routed, 1015 E is always a single point of failure to itself. If router E has 1016 failed, the S-E link repair can result in a forwarding loop. A node 1017 failure detection mechanism is therefore needed. A suitable 1018 mechanism might be to run BFD [BFD] between S and E, over the S-E 1019 link repair path. 1021 When the node failure detection mechanism has determined that 1022 router E has failed it withdraws the S-E link repair path. The node 1023 failure detection and revocation of the S-E link repair needs to be 1024 expedited, in order to minimize the duration of collateral damage 1025 to the network cause by packets looping around the S-E link repair 1026 path. 1028 If E is a single point of failure to some destinations, then 1029 withdrawing the S-E link repair has no impact on network 1030 connectivity, because those destinations will have been rendered 1031 unreachable by the failure of router E. 1033 If E is not a single point of failure, but traffic to some 1034 destinations is being repaired via the S-E link because of the 1035 inability to provide suitable repair paths, then there are 1036 destinations that are rendered temporarily unreachable by IPFRR. 1037 The IPFRR loop free convergence mechanism delays normal convergence 1038 of the network. Consideration therefore has to be given to the 1039 relative importance of the traffic being protected and the traffic 1040 being black-holed. Depending on the outcome of that consideration, 1041 the IPFRR loop-free strategy may need to be abandoned. 1043 6. Loop Free Transition 1045 Once the repair paths have been activated, data will again be 1046 forwarded correctly. At this stage only the routers directly 1047 adjacent to the failure will be aware of the failure because no 1048 routing information concerning the failure has yet been propagated 1049 to other routers. The network now has to be transitioned to normal 1050 operation using the available components. 1052 During network transition inconsistent state may lead to the 1053 formation of micro-loops. During this period, packets may be 1054 prevented from reaching the repair path, may expire due to 1055 transiting an excessive number of hops, may be subject to excessive 1056 delay, and the resultant congestion may disrupt the passage of 1057 other packets through the network. A loop free transition technique 1058 which allows the network to re-converge without packet loss or 1059 disruption is therefore required. 1061 A number of suitable loop-free convergence techniques are described 1062 in [LVCONV]. 1064 7. IPFRR Capability 1066 In the previous sections it has been assumed that all routers in 1067 the network are capable of acting as IPFRR routers, performing such 1068 tasks as tunnel termination and directed forwarding. In practice 1069 this is unlikely to be the case, partially because of the 1070 heterogeneous nature of a practical network, and partially because 1071 of the need to progressively deploy such capability. IPFRR 1072 therefore needs to support some form of capability announcement, 1073 and the algorithms need to take these capabilities into account 1074 when calculating their path repair strategies. For example, the 1075 ability of routers to function as tunnel end points and perform 1076 directed forwarding will influence the choice of repair path. 1077 However, routers which are simply traversed by repair paths 1078 (tunneled or not) do not need to be IPFRR capable in order to 1079 guarantee correct operation of the repair paths. 1081 8. Enhancements to routing protocols 1083 It will be seen from the above that a number of enhancements to the 1084 appropriate routing protocols are needed to support IPFRR. The 1085 following possible enhancements have been identified: 1087 o The ability to advertise IPFRR capability 1089 o The ability to advertise tunnel endpoint capability 1091 o The ability to advertise directed forwarding identifiers 1093 o The ability to announce the start of a loop-free 1094 transition, and to abort a loop-free transition. 1096 o The ability to signal transition completion status to 1097 neighbors. 1099 o The ability to advertise that a link is protected. 1101 Capability advertisement should make use of existing capability 1102 mechanisms in the routing protocols. The exact set of enhancements 1103 will depend on specific IPFRR design choices. 1105 9. IANA Considerations 1107 There are no IANA considerations that arise from this architectural 1108 description of IPFRR. However there will be changes to the IGPs to 1109 support IPFRR in which there will be IANA considerations. 1111 10. Security Considerations 1113 Changes to the IGPs to support IPFRR do not introduce any 1114 additional security risks. 1116 The security implications of the increased convergence time due to 1117 the loop avoidance strategy depend on the approach to multiple 1118 failures. If the presence of multiple failures results in the 1119 network aborting the loop free strategy, then the convergence time 1120 will be similar to that of a conventional network. On the other 1121 hand, an attacker in a position to disrupt part of a network might 1122 use this to disrupt the repair of a critical path. 1124 The tunnel endpoints need to be secured to prevent their use as a 1125 facility by an attacker. Performance considerations indicate that 1126 tunnels cannot be secured by IPsec [IPSEC]. A system of packet 1127 address policing, both at the tunnel endpoints and at the edges of 1128 the network would prevent an attacker's packet arriving at a tunnel 1129 endpoint and would seem to be the best strategy. 1131 When a fast re-route is in progress, there may be an unacceptable 1132 increase in traffic load over the repair path. Network operators 1133 need to examine the computed repair paths and ensure that they have 1134 sufficient capacity. 1136 Acknowledgments 1138 The authors acknowledge the significant technical contributions 1139 made to this work by their colleagues: John Harper and Kevin Miles. 1141 Intellectual Property Statement 1143 The IETF takes no position regarding the validity or scope of any 1144 Intellectual Property Rights or other rights that might be claimed 1145 to pertain to the implementation or use of the technology described 1146 in this document or the extent to which any license under such 1147 rights might or might not be available; nor does it represent that 1148 it has made any independent effort to identify any such rights. 1149 Information on the procedures with respect to rights in RFC 1150 documents can be found in BCP 78 and BCP 79. 1152 Copies of IPR disclosures made to the IETF Secretariat and any 1153 assurances of licenses to be made available, or the result of an 1154 attempt made to obtain a general license or permission for the use 1155 of such proprietary rights by implementers or users of this 1156 specification can be obtained from the IETF on-line IPR repository 1157 at http://www.ietf.org/ipr. 1159 The IETF invites any interested party to bring to its attention any 1160 copyrights, patents or patent applications, or other proprietary 1161 rights that may cover technology that may be required to implement 1162 this standard. Please address the information to the IETF at 1163 ietf-ipr@ietf.org. 1165 Full copyright statement 1166 Copyright (C) The Internet Society (2004). This document is subject 1167 to the rights, licenses and restrictions contained in BCP 78, and 1168 except as set forth therein, the authors retain all their rights. 1170 This document and the information contained herein are provided on 1171 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1172 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1173 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1174 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1175 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1176 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1177 PARTICULAR PURPOSE. 1179 Normative References 1181 There are no normative references. 1183 Informative References 1185 Internet-drafts are works in progress available from 1186 http://www.ietf.org/internet-drafts/ 1188 [BASIC] Alia Atlas, Ed., et al., "Basic Specification 1189 for IP Fast-Reroute: Loop-free Alternates", 1190 , 1191 October 2004, (work in progress). 1193 [BFD] Katz, D., and Ward, D., "Bidirectional 1194 Forwarding Detection", , August 2003 (work in progress). 1197 [IPFRR] Shand, M., "IP Fast-reroute Framework", 1198 , 1199 October 2004, (work in progress). 1201 [IPSEC] Kent, S., Atkinson, R., "Security Architecture 1202 for the Internet Protocol", RFC 2401 1204 [L2TPv3] J. et al., "Layer Two Tunneling Protocol 1205 (Version 3)", , June 2004, (work in progress). 1208 [LFCONV] Bryant, S., Shand, M., "A Framework for Loop- 1209 free Convergence", , October 2004,(work in progress). 1212 [MPLSFRR] Pan, P. et al, "Fast Reroute Extensions to 1213 RSVP-TE for LSP Tunnels", (work in 1215 progress). 1217 [RFC1701] S. Hanks. et al.,RFC-1701,"Generic Routing 1218 Encapsulation (GRE)". October 1994. 1220 [RFC1853] Simpson, W., RFC-1853, "IP in IP Tunneling". 1221 October 1995. 1223 [RFC3032] Rosen E., et al., RFC-3032, "MPLS Label Stack 1224 Encoding", January 2001. 1226 Authors' Addresses 1228 Stewart Bryant 1229 Cisco Systems, 1230 250, Longwater Avenue, 1231 Green Park, 1232 Reading, RG2 6GB, 1233 United Kingdom. Email: stbryant@cisco.com 1235 Clarence Filsfils 1236 Cisco Systems, 1237 De Kleetlaan 6a, 1238 1831 Diegem, 1239 Belgium Email: cfilsfil@cisco.com 1241 Stefano Previdi 1242 Cisco Systems, 1243 Via Del Serafico 200 1244 00142 Roma, 1245 Italy Email: sprevidi@cisco.com 1247 Mike Shand 1248 Cisco Systems, 1249 250, Longwater Avenue, 1250 Green Park, 1251 Reading, RG2 6GB, 1252 United Kingdom. Email: mshand@cisco.com