idnits 2.17.1 draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1619 has weird spacing: '...for the purpo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - When setting up one-to-one protection using the path-specific method, a detour MUST not traverse the upstream links of the protected LSP in the same direction. This prevents the possibility of early merging of the detour into the protected LSP. When setting up one-to-one protection using the sender-template-specific method, a detour should not traverse the upstream links of the protected LSP in the same direction; this prevents sharing the bandwidth between a protected LSP and its backup upstream of the failure where the bandwidth would be used twice in the event of a failure. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The PLR MUST not mix the messages for the protected and the detour LSPs. When a PLR receives Resv, ResvTear and PathErr messages from the downstream detour destination, the messages MUST not be forwarded upstream. Similarly, when a PLR receives ResvErr and ResvConf messages from a protected LSP, it MUST not propagate them onto the associated detour LSP. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: During error conditions, the LSRs may send ResvTear messages to fix problems on the failing path. When a PLR node receives the ResvTear messages from downstream for a protected LSP, as long as a detour is up, the ResvTear messages MUST not be sent further upstream. PathErrs should be treated similiarly. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'R4-R5' is mentioned on line 333, but not defined == Missing Reference: 'R8' is mentioned on line 353, but not defined == Missing Reference: 'R6' is mentioned on line 357, but not defined == Missing Reference: 'R7' is mentioned on line 357, but not defined == Missing Reference: 'R9' is mentioned on line 357, but not defined == Missing Reference: 'R3' is mentioned on line 367, but not defined == Missing Reference: 'RSVP- TE' is mentioned on line 1140, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3029 (ref. 'RSVP-TE') ** Obsolete normative reference: RFC 2434 (ref. 'RFC-IANA') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'ENT' Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Ping Pan, Ed (Ciena Corp) 2 Expires: February 2005 George Swallow, Ed (Cisco Systems) 3 Alia Atlas, Ed (Avici Systems) 5 Fast Reroute Extensions to RSVP-TE for LSP Tunnels 7 draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document defines extensions to and describes the use of RSVP to 33 establish backup label-switched path (LSP) tunnels for local repair 34 of LSP tunnels. These mechanisms enable the re-direction of traffic 35 onto backup LSP tunnels in 10s of milliseconds in the event of a 36 failure. 38 Two methods are defined here. The one-to-one backup method creates 39 detour LSPs for each protected LSP at each potential point of local 40 repair. The facility backup method creates a bypass tunnel to 41 protect a potential failure point; by taking advantage of MPLS label 42 stacking, this bypass tunnel can protect a set of protected LSPs that 43 have similar backup constraints. Both methods can be used to protect 44 links and nodes during network failure. The described behavior and 45 extensions to RSVP allow nodes to implement either or both methods 46 and to interoperate in a mixed network. 48 Contents 50 1 Authors .................................................. 3 51 2 Introduction ............................................. 3 52 2.1 Background ........................................... 4 53 3 Terminology ............................................... 5 54 4 Local Repair Techniques ................................... 7 55 4.1 One-to-one Backup ..................................... 7 56 4.2 Facility Backup ....................................... 8 57 5 RSVP Extensions ........................................... 9 58 5.1 FAST_REROUTE Object ................................... 9 59 5.2 DETOUR Object ......................................... 12 60 5.2.1 DETOUR object for IPv4 address .................... 12 61 5.2.2 DETOUR object for IPv6 address .................... 13 62 5.3 SESSION_ATTRIBUTE Flags ............................... 14 63 5.4 RRO IPv4/IPv6 Sub-Object Flags ........................ 15 64 6 Head-End Behavior ......................................... 16 65 7 Point of Local Repair Behavior ............................ 17 66 7.1 Signaling a Backup Path ............................... 18 67 7.1.1 Backup Path Identification: Sender-Template Specific 19 68 7.1.2 Backup Path Identification: Path-Specific ......... 20 69 7.2 Procedures for Backup Path Computation ................ 20 70 7.3 Signaling Backups for One-To-One Protection ........... 22 71 7.3.1 Make-Before-Break with Detour LSPs ................ 23 72 7.3.2 Message Handling .................................. 23 73 7.3.3 Local Reroute of Traffic Onto Detour LSP ........... 24 74 7.4 Signaling for Facility Protection ..................... 25 75 7.4.1 Discovering Downstream Labels ..................... 25 76 7.4.2 Procedures for the PLR before Local Repair ........ 25 77 7.4.3 Procedures for the PLR during Local Repair ........ 25 78 7.4.4 Processing backup tunnel's ERO .................... 26 79 7.5 PLR Procedures During Local Repair ..................... 27 80 7.5.1 Notification of local repair ...................... 27 81 7.5.2 Revertive Behavior ................................ 28 82 8 Merge Node Behavior ....................................... 29 83 8.1 Handling Backup Path Messages Before Failure .......... 29 84 8.1.1 Merging Backup Paths using the Sender-Template 85 Specific Method ................................... 30 86 8.1.2 Merging Detours using Path-Specific Method ........ 30 87 8.1.2.1 An Example on Path Message Merging ............ 31 88 8.1.3 Message Handling for Merged Detours ............... 32 89 8.2 Handling Failures ..................................... 32 90 9 Behavior of all LSRs ...................................... 33 91 9.1 Merging Detours in Path-Specific Method ............... 33 92 10 Security Considerations ................................... 34 93 11 IANA Guidelines ........................................... 34 94 12 Intellectual Property Considerations ...................... 34 95 13 Full Copyright Statement .................................. 35 96 14 Acknowledgments ........................................... 35 97 15 Normative References ...................................... 36 98 16 Editor Information ........................................ 36 100 1. Authors 102 This document was written by George Swallow, Ping Pan, Alia Atlas, 103 Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper. 105 Jean Philippe Vasseur 106 Cisco Systems, Inc. 107 300 Beaver Brook Road 108 Boxborough, MA 01719 109 USA 110 email: jpv@cisco.com 111 phone: +1 978 497 6238 113 Markus Jork 114 Avici Systems 115 101 Billerica Avenue 116 N. Billerica, MA 01862 117 USA 118 email: mjork@avici.com 119 phone: +1 978 964 2142 121 Der-Hwa Gan 122 Juniper Networks 123 1194 N.Mathilda Ave 124 Sunnyvale, CA 94089 125 USA 126 e-mail: dhg@juniper.net 127 phone: +1 408 745 2074 129 Dave Cooper 130 Global Crossing 131 960 Hamlin Court 132 Sunnyvale, CA 94089 133 USA 134 email: dcooper@gblx.net 135 phone: +1 916 415 0437 137 2. Introduction 139 This document extends RSVP [RSVP] to establish backup LSP tunnels 140 for the local repair of LSP tunnels. This technique is presented 141 to meet the needs of real-time applications, such as voice over IP, 142 for which it is highly desirable to be able to re-direct user 143 traffic onto backup LSP tunnels in 10s of milliseconds. This 144 timing requirement can be satisfied by computing and signaling 145 backup LSP tunnels in advance of failure and by re-directing 146 traffic as close to failure point as possible. In this way, the 147 time for the redirection does not include any path computation or 148 signaling delays, including delays to propagate failure 149 notification between LSRs. The speed of repair made possible by 150 the techniques and extensions described herein is the primary 151 advantage of this method. We use the term local repair when 152 referring to techniques which accomplish this, and refer to an 153 explicitly routed LSP which is provided with such protection as a 154 protected LSP. These techniques are applicable only to explicitly 155 routed LSPs; Application of the techniques discussed herein to LSPs 156 which dynamically change their routes such as those used in unicast 157 IGP routing is beyond the scope of this document. 159 Section 3 covers new terminology used in this document. The two 160 basic strategies for creating backup LSPs are described in Section 161 4. In Section 5, the protocol extensions to RSVP to support local 162 protection are described. In Section 6, the behavior of an LER 163 which wishes to request local protection for an LSP is presented. 164 The behavior of a potential point of local repair (PLR) is given in 165 Section 7; this describes how to determine the appropriate strategy 166 to use for protecting an LSP and how to implement each of the 167 strategies. The behavior of a merge node, the LSR where a 168 protected LSP and its backup LSP rejoin, is described in Section 8. 169 Finally, the required behavior of other nodes in the network is 170 discussed in Section 9. 172 For the techniques discussed in this document to function properly, 173 there are three assumptions which must be made. First, an LSR 174 which is on the path of a protected LSP SHOULD always assume that 175 it is a merge point; this is necessary because the facility backup 176 method does not signal backups through a bypass tunnel before 177 failure. Second, if the one-to-one backup method is used and a 178 DETOUR object is included, the LSRs in the traffic-engineered 179 network should support the DETOUR object; this is necessary so that 180 the Path message containing the DETOUR object is not rejected. 181 Third, understanding of the DETOUR object is required to support 182 the path-specific method which requires that LSRs in the 183 traffic-engineered network be capable of merging detours. 185 2.1 Background 187 Several years before work began on this draft, operational networks 188 had deployed two independent methods of doing fast reroute, called 189 herein one-to-one backup and facility backup. Vendors trying to 190 support both methods were experiencing incompatiblity problems in 191 attempting to produce a single implementation capable of 192 interoperating with both. There are technical tradeoffs between 193 the methods. However these tradeoffs are so topologically 194 dependent, that the community has not converged on a single 195 approach. 197 This draft rationalizes the RSVP signaling for both methods such 198 that any implementation can recognize all FRR requests and clearly 199 respond, either positively if they are capable of performing the 200 method, or with a clear error such that requester is informed and 201 can seek alternate means of backup. This draft also allows a 202 single implementation to support both methods, thereby providing a 203 range of capabilities. Thus the described behavior and extensions 204 to RSVP allow LERs and LSRs to implement either or both methods. 206 While the two methods could in principle be used in a single 207 network, it is expected that operators will continue to choose to 208 deploy either one or the other. The goal of this draft is to 209 standardize the RSVP signaling such that either a network with LSRs 210 that implement both methods or an network composed of some LSRs 211 that support one method and others that support both, can properly 212 signal among those LSRs to achieve fast restoration through the 213 chosen method. 215 3. Terminology 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in RFC2119 [RFC-WORDS]. 221 The reader is assumed to be familiar with the terminology in [RSVP] 222 and [RSVP-TE]. 224 LSR - Label Switch Router 226 LSP - An MPLS Label Switched Path. In this document, an LSP 227 will always refer to an explicitly routed LSP. 229 Local Repair - Techniques used to repair LSP tunnels quickly 230 when a node or link along the LSPs path fails. 232 PLR - Point of Local Repair. The head-end LSR of a backup tunnel 233 or a detour LSP. 235 One-to-one Backup - A local repair technique where a backup LSP 236 is separately created for each protected LSP at a PLR. 238 Facility Backup - A local repair technique where a bypass tunnel 239 is used to protect one or more protected LSPs which 240 traverse the PLR, the resource being protected and the 241 Merge Point in that order. 243 Protected LSP - An LSP is said to be protected at a given hop if 244 it has one or multiple associated backup tunnels originating 245 at that hop. 247 Detour LSP - The LSP that is used to re-route traffic around 248 a failure in one-to-one backup. 250 Bypass Tunnel - An LSP that is used to protect a set of LSPs 251 passing over a common facility. 253 Backup Tunnel - The LSP that is used to backup up one of the many 254 LSPs in many-to-one backup. 256 NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel 257 which bypasses a single link of the protected LSP. 259 NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup 260 tunnel which bypasses a single node of the protected LSP. 262 Backup Path - The LSP that is responsible for backing up one 263 protection LSP. A backup path refers to either a detour LSP 264 or a backup tunnel. 266 MP - Merge Point. The LSR where one or more backup tunnels rejoin 267 the path of the protected LSP, downstream of the potential 268 failure. The same LSR may be both an MP and a PLR 269 simultaneously. 271 DMP - Detour Merge Point. In the case of one-to-one backup, 272 this is an LSR where multiple detours converge and only one 273 detour is signaled beyond that LSR. 275 Reroutable LSP - Any LSP for which the head-end LSR requests 276 local protection. See Section 10.1 for more detail. 278 CSPF - Constraint-based Shortest Path First. 280 SRLG Disjoint - A path is considered to be SRLG disjoint from a 281 given link or node if the path does not use any links or 282 nodes which belong to the same SRLG as that given link or 283 node. 285 4. Local Repair Techniques 287 Two different techniques for local protection are presented here. 288 The one-to-one backup technique has a PLR compute a separate backup 289 LSP, called a detour LSP, for each LSP which the PLR protects using 290 this technique. With the facility backup technique, the PLR creates 291 a single bypass tunnel which can be used to protect multiple LSPs. 293 4.1. One-to-one backup 295 In the one-to-one technique, a label switched path is established 296 which intersects the original LSP somewhere downstream of the point 297 of link or node failure. For each LSP which is backed up, a 298 separate backup LSP is established. 300 [R1]---[R2]-----[R3]----[R4]---[R5] 301 \ \ \ / \ / 302 [R6]---[R7]-------[R8]----[R9] 304 Protected LSP: [R1->R2->R3->R4->R5] 305 R1's Backup: [R1->R6->R7->R8->R3] 306 R2's Backup: [R2->R7->R8->R4] 307 R3's Backup: [R3->R8->R9->R5] 308 R4's Backup: [R4->R9->R5] 310 Example 1: One-to-One Backup Technique 312 In the simple topology shown above in Example 1, the protected LSP 313 runs from R1 to R5. R2 can provide user traffic protection by 314 creating a partial backup LSP which merges with the protected LSP 315 at R4. We refer to a partial one-to-one backup LSP 316 [R2->R7->R8->R4] as a detour. 318 To fully protect an LSP that traverses N nodes, there could be as 319 many as (N - 1) detours. The paths for the detours necessary to 320 fully protect the LSP in Example 1 are given there. To minimize 321 the number of LSPs in the network, it is desirable to merge a 322 detour back to its protected LSP when feasible. When a detour LSP 323 intersects its protected LSP at an LSR with the same outgoing 324 interface, it will be merged. 326 When a failure occurs along the protected LSP, the PLR redirects 327 traffic onto the local detour. For instance, if the link [R2->R3] 328 fails in Example 1, R2 will switch traffic received from R1 onto 329 the protected LSP along link [R2->R7] using the label received when 330 R2 created the detour. When R4 receives traffic with the label 331 provided for R2's detour, R4 will switch that traffic onto link 333 [R4-R5] using the label received from R5 for the protected LSP. At 334 no point does the depth of the label stack increase as a result of 335 taking the detour. While R2 is using its detour, traffic will take 336 the path [R1->R2->R7->R8->R4->R5]. 338 4.2. Facility backup 340 The facility backup technique takes advantage of the MPLS label 341 stack. Instead of creating a separate LSP for every backed-up LSP, a 342 single LSP is created which serves to backup up a set of LSPs. We 343 call such an LSP tunnel a bypass tunnel. 345 The bypass tunnel must intersect the path of the original LSP(s) 346 somewhere downstream of the PLR. Naturally, this constrains the 347 set of LSPs being backed-up via that bypass tunnel to those that 348 pass through some common downstream node. All LSPs which pass 349 through the point of local repair and through this common node 350 which do not also use the facilities involved in the bypass tunnel 351 are candidates for this set of LSPs. 353 [R8] 354 \ 355 [R1]---[R2]----[R3]----[R4]---[R5] 356 \ / \ 357 [R6]===[R7] [R9] 359 Protected LSP 1: [R1->R2->R3->R4->R5] 360 Protected LSP 2: [R8->R2->R3->R4] 361 Protected LSP 3: [R2->R3->R4->R9] 362 Bypass LSP Tunnel: [R2->R6->R7->R4] 364 Example 2: Facility Backup Technique 366 In Example 2, R2 has built a bypass tunnel which protects against the 367 failure of link [R2->R3] and node [R3]. The doubled lines represent 368 this tunnel. The scalability improvement this technique provides is 369 that the same bypass tunnel can also be used to protect LSPs from any 370 of R1, R2 or R8 to any of R4, R5 or R9. Example 2 describes three 371 different protected LSPs which are using the same bypass tunnel for 372 protection. 374 As with the one-to-one technique, to fully protect an LSP that 375 traverses N nodes, there could be as many as (N-1) bypass tunnels. 376 However, each of those bypass tunnels could protected a set of 377 LSPs. 379 When a failure occurs along a protected LSP, the PLR redirects 380 traffic into the appropriate bypass tunnel. For instance, if link 381 [R2->R3] fails in Example 2, R2 will switch traffic received from 382 R1 on the protected LSP onto link [R2->R6]; the label will be 383 switched for one which will be understood by R4 to indicate the 384 protected LSP and then the bypass tunnel's label will be pushed 385 onto the label-stack of the redirected packets. If 386 penultimate-hop-popping is used, then the merge point in Example 2, 387 R4, will receive the redirected packet with a label indicating the 388 protected LSP that the packet is to follow. If 389 penultimate-hop-popping is not used, then R4 will pop the bypass 390 tunnel's label and examine the label underneath to determine the 391 protected LSP that the packet is to follow. When R2 is using the 392 bypass tunnel for protected LSP 1, the traffic takes the path 393 [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection 394 between R2 and R4. 396 5. RSVP Extensions 398 We propose two additional objects, FAST_REROUTE and DETOUR, to 399 extend RSVP-TE for fast-reroute signaling. These new objects are 400 backward compatible with LSRs that do not recognize them (see 401 section 3.10 in [RSVP]). Both objects can only be carried in RSVP 402 Path messages. 404 The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to 405 support bandwidth and node protection features. 407 5.1. FAST_REROUTE Object 409 The FAST-REROUTE object is used to control the backup used for the 410 protected LSP. This specifies the setup and hold priorities, the 411 session attribute filters, and bandwidth to be used for protection. 412 It also allows a specific local protection technique to be requested. 413 This object MUST only be inserted into the PATH message by the 414 head-end LER and MUST NOT be changed by downstream LSRs. The 415 FAST-REROUTE object has the following format: 417 Class-Num = 205 418 C-Type = 1 420 0 1 2 3 421 +-------------+-------------+-------------+-------------+ 422 | Length (bytes) | Class-Num | C-Type | 423 +-------------+-------------+-------------+-------------+ 424 | Setup Prio | Hold Prio | Hop-limit | Flags | 425 +-------------+-------------+-------------+-------------+ 426 | Bandwidth | 427 +-------------+-------------+-------------+-------------+ 428 | Include-any | 429 +-------------+-------------+-------------+-------------+ 430 | Exclude-any | 431 +-------------+-------------+-------------+-------------+ 432 | Include-all | 433 +-------------+-------------+-------------+-------------+ 435 Setup Priority 437 The priority of the backup path with respect to taking 438 resources, in the range of 0 to 7. The value 0 is the highest 439 priority. Setup Priority is used in deciding whether 440 this session can preempt another session. See [RSVP-TE] for 441 the usage on priority. 443 Holding Priority 445 The priority of the backup path with respect to holding 446 resources, in the range of 0 to 7. The value 0 is the highest 447 priority. Holding Priority is used in deciding whether this 448 session can be preempted by another session. See [RSVP-TE] for 449 the usage on priority. 451 Hop-limit 453 The maximum number of extra hops the backup path is allowed 454 to take, from current node (a PLR) to a MP, with PLR and MP 455 excluded in counting. For example, hop-limit of 0 means only 456 direct links between PLR and MP can be considered. 458 Flags 460 0x01 One-to-one Backup Desired 462 Indicates that protection via the one-to-one backup 463 technique is desired. 465 0x02 Facility Backup Desired 467 Indicates that protection via the facility backup 468 technique is desired. 470 Bandwidth 472 Bandwidth estimate (32-bit IEEE floating point integer) in 473 bytes-per-second. 475 Exclude-any 477 A 32-bit vector representing a set of attribute filters 478 associated with a backup path any of which renders a link 479 unacceptable. 481 Include-any 483 A 32-bit vector representing a set of attribute filters 484 associated with a backup path any of which renders a link 485 acceptable (with respect to this test). A null set (all bits 486 set to zero) automatically passes. 488 Include-all 490 A 32-bit vector representing a set of attribute filters 491 associated with a backup path all of which must be present for 492 a link to be acceptable (with respect to this test). A null set 493 (all bits set to zero) automatically passes. 495 The two high-order bits of the Class-Num (11) indicate that nodes 496 that do not understand the object should ignore it and pass if 497 forward unchanged. 499 For informational purposes, a different C-type value and format for 500 the FAST_REROUTE object are specified below. This is used by 501 legacy implementations. The meaning of the fields is the same as 502 described for C-Type 1. 504 C-Type = 7 506 0 1 2 3 507 +-------------+-------------+-------------+-------------+ 508 | Length (bytes) | Class-Num | C-Type | 509 +-------------+-------------+-------------+-------------+ 510 | Setup Prio | Hold Prio | Hop-limit | Reserved | 511 +-------------+-------------+-------------+-------------+ 512 | Bandwidth | 513 +-------------+-------------+-------------+-------------+ 514 | Include-any | 515 +-------------+-------------+-------------+-------------+ 516 | Exclude-any | 517 +-------------+-------------+-------------+-------------+ 519 Unknown C-types should be treated as specified in [RSVP] Section 520 3.10. 522 5.2. DETOUR Object 524 The DETOUR object is used in one-to-one backup to identify detour 525 LSPs. It has the following format: 527 Class-Num = 63 529 5.2.1 DETOUR object for IPv4 address 531 C-Type = 7 533 0 1 2 3 534 +-------------+-------------+-------------+-------------+ 535 | Length (bytes) | Class-Num | C-Type | 536 +-------------+-------------+-------------+-------------+ 537 | PLR ID 1 | 538 +-------------+-------------+-------------+-------------+ 539 | Avoid Node ID 1 | 540 +-------------+-------------+-------------+-------------+ 541 // .... // 542 +-------------+-------------+-------------+-------------+ 543 | PLR ID n | 544 +-------------+-------------+-------------+-------------+ 545 | Avoid Node ID n | 546 +-------------+-------------+-------------+-------------+ 548 PLR ID (1 - n) 549 IPv4 address identifying the beginning point of detour which is 550 a PLR. Any local address on the PLR can be used. 552 Avoid Node ID (1 - n) 554 IPv4 address identifying the immediate downstream node that 555 the PLR is trying to avoid. Any local address of the downstream 556 node can be used. This field is mandatory, and is used by 557 the MP for merging rules discussed below. 559 5.2.2 DETOUR object for IPv6 address 561 C-Type = 8 563 0 1 2 3 564 +-------------+-------------+-------------+-------------+ 565 | Length (bytes) | Class-Num | C-Type | 566 +-------------+-------------+-------------+-------------+ 567 | PLR ID 1 | 568 +-------------+-------------+-------------+-------------+ 569 | PLR ID 1 (continued) | 570 +-------------+-------------+-------------+-------------+ 571 | PLR ID 1 (continued) | 572 +-------------+-------------+-------------+-------------+ 573 | PLR ID 1 (continued) | 574 +-------------+-------------+-------------+-------------+ 575 | Avoid Node ID 1 | 576 +-------------+-------------+-------------+-------------+ 577 | Avoid Node ID 1 (continued) | 578 +-------------+-------------+-------------+-------------+ 579 | Avoid Node ID 1 (continued) | 580 +-------------+-------------+-------------+-------------+ 581 | Avoid Node ID 1 (continued) | 582 +-------------+-------------+-------------+-------------+ 583 // .... // 584 +-------------+-------------+-------------+-------------+ 586 PLR ID (1 - n) 588 An IPv6 128-bit unicast host address identifying the beginning 589 point of detour which is a PLR. Any local address on the PLR 590 can be used. 592 Avoid Node ID (1 - n) 594 An IPv6 128-bit unicast host address identifying the immediate 595 downstream node that the PLR is trying to avoid. Any local 596 address on the downstream node can be used. This field is 597 mandatory, and is used by the MP for merging rules discussed 598 below. 600 There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in 601 a DETOUR object. If detour merging is desired, after each merging 602 operation, the Detour Merge Point should combine all the merged 603 detours in the subsequent Path messages. 605 The high-order bit of the C-Class is zero; LSRs that do not support 606 the DETOUR objects MUST reject any Path message containing a DETOUR 607 object and send a PathErr to notify the PLR. This PathErr SHOULD 608 be generated as specified in [RSVP] for unknown objects with a 609 class-num of the form "0bbbbbbb". 611 Unknown C-types should be treated as specified in [RSVP] Section 612 3.10. 614 5.3. SESSION_ATTRIBUTE Flags 616 To explicitly request bandwidth and node protection, two new flags 617 are defined in the SESSION_ATTRIBUTE object. 619 For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has 620 the following flags defined: 622 Local protection desired: 0x01 624 This flag permits transit routers to use a local repair 625 mechanism which may result in violation of the explicit route 626 object. When a fault is detected on an adjacent downstream link 627 or node, a transit node may reroute traffic for fast service 628 restoration. 630 Label recording desired: 0x02 632 This flag indicates that label information should be included 633 when doing a route record. 635 SE Style desired: 0x04 637 This flag indicates that the tunnel ingress node may choose to 638 reroute this tunnel without tearing it down. A tunnel egress 639 node SHOULD use the SE Style when responding with a Resv 640 message. When requesting fast reroute, the head-end LSR 641 SHOULD set this flag; this is not necessary for the 642 path-specific method of the one-to-one backup technique. 644 The following new flags are defined: 646 Bandwidth protection desired: 0x08 648 This flag indicates to the PLRs along the protected LSP path 649 that a backup path with a bandwidth guarantee is desired. 650 The bandwidth to be guaranteed is that of the protected 651 LSP, if no FAST_REROUTE object is included in the PATH message; 652 if a FAST_REROUTE object is in the PATH message, then the 653 bandwidth specified therein is that to be guaranteed. 655 Node protection desired: 0x10 657 This flag indicates to the PLRs along a protected LSP path 658 that a backup path which bypasses at least the next node of 659 the protected LSP is desired. 661 5.4. RRO IPv4/IPv6 Sub-Object Flags 663 To report whether bandwidth and/or node protection are provided as 664 requested, we define two news flags in the RRO IPv4 sub-object. 666 RRO IPv4 and IPv6 sub-object address: 668 These two sub-objects currently have the following flags defined: 670 Local protection available: 0x01 672 Indicates that the link downstream of this node is protected 673 via a local repair mechanism, which can be either one-to-one 674 or facility backup. 676 Local protection in use: 0x02 678 Indicates that a local repair mechanism is in use to maintain 679 this tunnel (usually in the face of an outage of the link it 680 was previously routed over, or an outage of the neighboring 681 node). 683 Two new flags are defined: 685 Bandwidth protection: 0x04 687 The PLR will set this when the protected LSP has a backup path 688 which is guaranteed to provide the desired bandwidth specified 689 in the FAST_REROUTE object or the bandwidth of the protected 690 LSP, if no FAST_REROUTE object was included. The PLR may set 691 this whenever the desired bandwidth is guaranteed; the PLR 692 MUST set this flag when the desired bandwidth is guaranteed 693 and the "bandwidth protection desired" flag was set in the 694 SESSION_ATTRIBUTE object. If the requested bandwidth is not 695 guaranteed, the PLR MUST NOT set this flag. 697 Node protection: 0x08 699 The PLR will set this when the protected LSP has a backup path 700 which provides protection against a failure of the next LSR 701 along the protected LSP. The PLR may set this whenever node 702 protection is provided by the protected LSP's backup path; the 703 PLR MUST set this flag when the node protection is provided 704 and the "node protection desired" flag was set in the 705 SESSION_ATTRIBUTE object. If node protection is not provided, 706 the PLR MUST NOT set this flag. Thus, if a PLR could only 707 setup a link-protection backup path, the "Local protection 708 available" bit will be set but the "Node protection" bit will 709 be cleared. 711 6. Head-End Behavior 713 The head-end of an LSP determines whether local protection should 714 be requested for that LSP and which local protection technique is 715 desired for the protected LSP. The head-end also determines what 716 constraints should be requested for the backup paths of a protected 717 LSP. 719 To indicate that an LSP should be locally protected, the head-end 720 LSR MUST either set the "Local protection desired" flag in the 721 SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the 722 PATH message or both. It is recommended that the "local protection 723 desired" flag in the SESSION_ATTRIBUTE object always be set. If a 724 head-end LSR signals a FAST_REROUTE object, it MUST be stored for 725 Path refreshes. 727 The head-end LSR of a protected LSP MUST set the "label recording 728 desired" flag in the SESSION_ATTRIBUTE object. This facilitates 729 the use of the facility backup technique. If node protection is 730 desired, the head-end LSR should set the "node protection desired" 731 flag in the SESSION_ATTRIBUTE object; otherwise this flag should be 732 cleared. Similarly, if a guarantee of bandwidth protection is 733 desired, then the "bandwidth protection desired" flag in the 734 SESSION_ATTRIBUTE object should be set; otherwise, this flag should 735 be cleared. 737 If the head-end LSR determines that control of the backup paths for 738 the protected LSP is desired, then the LSR should include the 739 FAST_REROUTE object. The attribute filters, bandwidth, hop-limit 740 and priorities will be used by the PLRs when determining the backup 741 paths. 743 If the head-end LSR desires that the protected LSP be protected via 744 the one-to-one backup technique, then head-end LSR should include a 745 FAST_REROUTE object and set the "one-to-one backup desired" flag. 746 If the head-end LSR desires that the protected LSP be protected via 747 the facility backup technique, then the head-end LSR should include 748 a FAST_REROUTE object and set the "facility backup desired" flag. 749 The lack of a FAST_REROUTE object, or having both these flags 750 clear should be treated by PLRs as a lack of preference. If 751 both flags are set a PLR may use either method or both. 753 The head-end LSR of a protected LSP MUST support the additional 754 flags defined in Section 5.4 being set or clear in the RRO IPv4 and 755 IPv6 sub-objects. The head-end LSR of a protected LSP MUST support 756 the RRO Label sub-object. 758 If the head-end LSR of an LSP determines that local protection is 759 newly desired, this should be signaled via make-before-break. 761 7. Point of Local Repair Behavior 763 Every LSR along a protected LSP (except the egress) MUST follow the 764 PLR behavior described in this document. 766 A PLR SHOULD support the FAST_REROUTE object, the "local protection 767 desired", "label recording desired", "node protection desired" and 768 "bandwidth protection desired" flags in the SESSION_ATTRIBUTE 769 object, and the "local protection available", "local protection in 770 use", "bandwidth protection", and "node protection" flags in the 771 RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR 772 object. 774 A PLR MUST consider an LSP as having asked for local protection if 775 the "local protection desired" flag is set in the SESSION_ATTRIBUTE 776 object and/or the FAST_REROUTE object is included. If the 777 FAST_REROUTE object is included, a PLR SHOULD consider providing 778 one-to-one protection if the "one-to-one desired" is set and SHOULD 779 consider providing facility backup if the "facility backup desired" 780 flag is set when determining whether to provide local protection 781 and which technique to use to provide that local protection. If 782 the "node protection desired" flag is set, the PLR SHOULD try to 783 provide node protection; if this is not feasible, the PLR SHOULD 784 then try to provide link protection. If the "bandwidth protection 785 guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth 786 guarantee; if this is not feasible, the PLR SHOULD then try to 787 provide a backup without a guarantee of the full bandwidth. 789 The following treatment for the RRO IPv4 or IPv6 sub-object's flags 790 must be followed if an RRO is included in the protected LSP's RESV 791 message. Based on this additional information the head-end may 792 take appropriate actions. 794 - Until a PLR has a backup path available, the PLR MUST clear the 795 relevant four flags in the corresponding RRO IPv4 or IPv6 796 sub-object. 798 - Whenever the PLR has a backup path available, the PLR MUST set 799 the "local protection available" flag. If no established 800 one-to-one backup LSP or bypass tunnel exists, or the one-to-one 801 LSP and the bypass tunnel is in "DOWN" state, the PLR MUST clear 802 the "local protection available" flag in its IPv4 (or IPv6) 803 address subobject of the RRO and SHOULD send the updated RESV. 805 - The PLR MUST clear the "local protection in use" flag unless it 806 is actively redirecting traffic into the backup path instead of 807 along the protected LSP. 809 - The PLR SHOULD also set the "node protection" flag if the backup 810 path protects against the failure of the immediate downstream 811 node and, if not, the PLR SHOULD clear the "node protection" 812 flag. This MUST be done if the "node protection desired" flag 813 was set in the SESSION_ATTRIBUTE object. 815 - The PLR SHOULD set the "bandwidth protection" if the backup path 816 offers a bandwidth guarantee and, if not, SHOULD clear the 817 "bandwidth protection" flag. This MUST be done if the "bandwidth 818 protection desired" flag was set in the SESSION_ATTRIBUTE 819 object. 821 7.1 Signaling a Backup Path 823 A number of objectives must be met to obtain a satisfactory signaling 824 solution. These are summarized as follows: 826 1. Unambiguously and uniquely identify backup paths 827 2. Unambiguously associate protected LSPs with their backup paths 828 3. Work with both global and non-global label spaces 829 4. Allow for merging of backup paths 830 5. Maintain RSVP state during and after fail-over. 832 LSP tunnels are identified by a combination of the SESSION and 833 SENDER_TEMPLATE objects. The relevant fields are as follows. 835 IPv4 (or IPv6) tunnel end point address 837 IPv4 (or IPv6) address of the egress node for the tunnel. 839 Tunnel ID 841 A 16-bit identifier used in the SESSION that remains constant 842 over the life of the tunnel. 844 Extended Tunnel ID 846 A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION 847 that remains constant over the life of the tunnel. Normally set 848 to all zeros. Ingress nodes that wish to narrow the scope of a 849 SESSION to the ingress-egress pair may place their IP address 850 here as a globally unique identifier. 852 IPv4 (or IPv6) tunnel sender address 854 IPv4 (or IPv6) address for a sender node 856 LSP ID 858 A 16-bit identifier used in the SENDER_TEMPLATE and the 859 FILTER_SPEC that can be changed to allow a sender to share 860 resources with itself. 862 The first three of these are in the SESSION object and are the basic 863 identification of the tunnel. Setting the "Extended Tunnel ID" to 864 an IP address of the head-end LSR allows the scope of the SESSION 865 to be narrowed to only LSPs sent by that LSR. A backup LSP is 866 considered to be part of the same session as its protected LSP; 867 therefore these three cannot be varied. 869 The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same 870 SESSION may be protected and take different routes; this is common 871 when rerouting a tunnel using make-before-break. It is necessary 872 that a backup path be clearly identified with its protected LSP, so 873 that correct merging and state treatment can be done. Therefore, a 874 backup path must inherit its LSP ID from the associated protected 875 LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE 876 objects which could be varied between a backup path and a protected 877 LSP is the "IPv4 (or IPv6) tunnel sender address" in the 878 SENDER_TEMPLATE. 880 There are two different methods to uniquely identify a backup 881 path. These are described below. 883 7.1.1. Backup Path Identification: Sender-Template-Specific 885 In this approach, the SESSION object and the LSP_ID are copied from 886 the protected LSP. The "IPv4 tunnel sender address" is set to an 887 address of the PLR. If the head-end of a tunnel is also acting as 888 the PLR, it MUST choose an IP address different from the one used 889 in the SENDER_TEMPLATE of the original LSP tunnel. 891 When using the sender-template-specific approach, the protected 892 LSPs and the backup paths SHOULD use the Shared Explicit (SE) 893 style. This allows bandwidth sharing between multiple backup 894 paths. The backup paths and the protected LSP MAY be merged by the 895 Detour Merge Points, when the ERO from the MP to the egress is the 896 same on each LSP to be merged, as specified in [RSVP-TE]. 898 7.1.2. Backup Path Identification: Path-Specific 900 In this approach, rather than varying the SESSION or 901 SENDER_TEMPLATE objects, a new object, the DETOUR object, is used 902 to distinguish between PATH messages for a backup path and the 903 protected LSP. 905 Thus, the backup paths use the same SESSION and SENDER_TEMPLATE 906 objects as the ones used in the protected LSP. The presence of 907 DETOUR object in Path messages signifies a backup path; the 908 presence of FAST_REROUTE object and/or the "local protection 909 requested" flag in the SESSION_ATTRIBUTE object indicates a 910 protected LSP. 912 In the path-message-specific approach, when an LSR receives 913 multiple Path messages which have the same SESSION and 914 SENDER_TEMPLATE objects and also have the same next-hop, that LSR 915 MUST merge the Path messages. Without this behavior, the multiple 916 RESV messages received back would not be distinguishable as to 917 which backup path each belongs to. This merging behavior does 918 reduce the total number of RSVP states inside the network at the 919 expense of merging LSPs with different EROs. 921 7.2 Procedures for Backup Path Computation 923 Before a PLR can create a detour or a bypass tunnel, the desired 924 explicit route must be determined. This can be done using a CSPF. 926 Before CSPF computation, the following information should be 927 collected at a PLR: 929 - The list of downstream nodes that the protected LSP passes 930 through. This information is readily available from the 931 RECORD_ROUTE objects during LSP setup. This information is also 932 available from the ERO. However, if the ERO contains loose 933 sub-objects, the ERO may not provide adequate information. 935 - The downstream links/nodes that we want to protect against. Once 936 again, this information is learned from the RECORD_ROUTE 937 objects. Whether node protection is desired is determined by 938 the "node protection" flag in the SESSION_ATTRIBUTE object and 939 local policy. 941 - The upstream uni-directional links that the protected LSP 942 passes through. This information is learned from the 943 RECORD_ROUTE objects; it is only needed for setting up 944 one-to-one protection. In the path-specific method, it is 945 necessary to avoid the detour and the protected LSP sharing 946 a common next-hop upstream of the failure. In the 947 sender-template-specific mode, this same restriction is 948 necessary to avoid sharing bandwidth between the detour and 949 its protected LSP, where that bandwidth has only been reserved 950 once. 952 - The link attribute filters to be applied. These are derived 953 from the FAST_REROUTE object, if included in the PATH message, 954 and the SESSION_ATTRIBUTE object otherwise. 956 - The bandwidth to be used is found in the FAST_REROUTE object, 957 if included in the PATH message, and in the SESSION_ATTRIBUTE 958 object otherwise. Local policy may modify the bandwidth to be 959 reserved. 961 - The hop-limit, if a FAST_REROUTE object was included in the 962 PATH message. 964 When applying a CSPF algorithm to compute the backup route, the 965 following constraints should be satisfied: 967 - For detour LSPs, the destination MUST be the tail-end of the 968 protected LSP; for bypass tunnels (Section 7), the destination 969 MUST be the address of the MP. 971 - When setting up one-to-one protection using the path-specific 972 method, a detour MUST not traverse the upstream links of the 973 protected LSP in the same direction. This prevents the 974 possibility of early merging of the detour into the protected 975 LSP. When setting up one-to-one protection using the 976 sender-template-specific method, a detour should not traverse 977 the upstream links of the protected LSP in the same direction; 978 this prevents sharing the bandwidth between a protected LSP 979 and its backup upstream of the failure where the bandwidth 980 would be used twice in the event of a failure. 982 - The backup LSP cannot traverse the downstream node and/or link 983 whose failure is being protected against. Note that if the 984 PLR is the penultimate hop, node protection is not possible 985 and only the downstream link can be avoided. The backup path 986 may be computed to be SRLG disjoint from the downstream node 987 and/or link being avoided. 989 - The backup path must satisfy the resource requirements of the 990 protected LSP. This includes the link attribute filters, 991 bandwidth, and hop limits determined from the FAST_REROUTE 992 object and SESSION_ATTRIBUTE object. 994 If such computation succeeds, the PLR should attempt to establish a 995 backup path. The PLR may schedule a re-computation at a later time 996 to discover better paths that may have emerged. If for any reason, 997 the PLR is unable to bring up a backup path, it must schedule a 998 retry at a later time. 1000 7.3 Signaling Backups for One-To-One Protection 1002 Once a PLR has decided to locally protect an LSP with one-to-one 1003 backup, and has identified the desired path, it takes the following 1004 steps to signal the detour. 1006 The following describes the transformation to be performed upon the 1007 protected LSP's PATH message to create the detour LSP's PATH 1008 message. 1010 - If the sender-template specific method is to be used, then the 1011 PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the 1012 SENDER_TEMPLATE to an address belonging to the PLR that is not 1013 the same as was used for the protected LSP. Additionally, the 1014 DETOUR object MAY be added to the PATH message. 1016 - If the path-specific method is to be used, then the PLR MUST add 1017 a DETOUR object to the PATH message. 1019 - The SESSION_ATTRIBUTE flags "Local protection desired", 1020 "Bandwidth protection desired" and "Node protection desired" MUST 1021 be cleared. The "Label recording desired" flag MAY be modified. 1022 If the Path Message contained a FAST_REROUTE object, and the ERO 1023 is not completely strict, the Include-any, Exclude-any, and 1024 Include-all fields of the FAST_REROUTE object SHOULD be copied to 1025 the corresponding fields of the SESSION_ATTRIBUTE object. 1027 - If the protected LSP's Path message contained a FAST_REROUTE 1028 object, this MUST be removed from the detour LSP's PATH message. 1030 - The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. 1031 First, the PLR must remove all sub-objects preceding the first 1032 address belonging to the Merge Point. Then the PLR SHOULD add 1033 sub-objects corresponding to the desired backup path between the 1034 PLR and the MP. 1036 - The SENDER_TSPEC object SHOULD contain the bandwidth information 1037 from the received FAST_REROUTE object, if included in the 1038 protected LSP's PATH message. 1040 - The RSVP_HOP object containing one of the PLR's IP address. 1042 - The detour LSPs MUST use the same reservation style as the 1043 protected LSP. This must be correctly reflected in the 1044 SESSION_ATTRIBUTE object. 1046 Detour LSPs are regular LSPs in operation. Once a detour path is 1047 successfully computed and the detour LSP is established, the PLR 1048 need not compute detour routes again, unless (1) the contents of 1049 FAST_REROUTE have changed, or (2) the downstream interface and/or 1050 the nexthop router for a protected LSP have changed. The PLR may 1051 recompute detour routes at any time. 1053 7.3.1 Make-Before-Break with Detour LSPs 1055 If the sender-template specific method is used, it is possible to 1056 do make-before-break with detour LSPs. This is done by using two 1057 different IP addresses belonging to the PLR (which were not used in 1058 the SENDER_TEMPLATE of the protected LSP). If the current detour 1059 LSP uses the first IP address in its SENDER_TEMPLATE, then the new 1060 detour LSP should be signaled using the second IP address in its 1061 SENDER_TEMPLATE. Once the new detour LSP has been created, the 1062 current detour LSP can be torn down. By alternating the use of 1063 these IP addresses, the current and new detour LSPs will have 1064 different SENDER_TEMPLATES and, thus, different state in the 1065 downstream LSRs. 1067 This make-before-break mechanism, changing the PLR IP address in 1068 the DETOUR object instead, is not feasible with the path-specific 1069 method because the PATH messages for new and current detour LSPs 1070 may be merged if they share a common next-hop. 1072 7.3.2 Message Handling 1074 LSRs must process the detour LSPs independent of the protected LSPs 1075 to avoid triggering the LSP loop detection procedure described in 1076 [RSVP-TE]. 1078 The PLR MUST not mix the messages for the protected and the detour 1079 LSPs. When a PLR receives Resv, ResvTear and PathErr messages from 1080 the downstream detour destination, the messages MUST not be forwarded 1081 upstream. Similarly, when a PLR receives ResvErr and ResvConf 1082 messages from a protected LSP, it MUST not propagate them onto the 1083 associated detour LSP. 1085 A session tear-down request is normally originated by the sender via 1086 PathTear messages. When a PLR node receives a PathTear message from 1087 upstream, it MUST delete both the protected and the detour LSPs. The 1088 PathTear messages MUST propagate to both protected and detour LSPs. 1090 During error conditions, the LSRs may send ResvTear messages to fix 1091 problems on the failing path. When a PLR node receives the ResvTear 1092 messages from downstream for a protected LSP, as long as a detour is 1093 up, the ResvTear messages MUST not be sent further upstream. 1094 PathErrs should be treated similiarly. 1096 7.3.3 Local Reroute of Traffic onto Detour LSP 1098 When the PLR detects a failure on the protected LSP, the PLR MUST 1099 rapidly switch packets to the protected LSP's backup LSP instead of 1100 the protected LSP's normal out-segment. The goal of this technique 1101 is to effect the redirection within 10s of milliseconds. 1103 L32 L33 L34 L35 1104 R1-------R2-------R3-------R4-------R5 1105 | | 1106 L46 | L47 | L44 1107 R6---------------R7 1109 Protected LSP: [R1->R2->R3->R4->R5] 1110 Detour LSP: [R2->R6->R7->R4] 1112 Example 3: Redirect to Detour 1114 In Example 3 above, if the link [R2->R3] fails, then R2 would do 1115 the following. Any traffic received on link [R1->R2] with label 1116 L32 would be sent out link [R2->R6] with label L46 (along the 1117 detour LSP) instead of out link [R3->R4] with lable L34 (along the 1118 protected LSP). The Merge Point, R4, would recognize that packets 1119 received on link [R7->R4] with label L44 should be sent out link 1120 [R4->R5] with label L35, and thus merged with the protected LSP. 1122 7.4 Signaling for Facility Protection 1124 A PLR may use one or more bypass tunnels to protect against the 1125 failure of a link and/or a node. These bypass tunnels may be 1126 setup in advance or may be dynamically created as new protected 1127 LSPs are signaled. 1129 7.4.1. Discovering Downstream Labels 1131 To support facility backup, it is necessary for the PLR to 1132 determine a label which will indicate to the MP that packets 1133 received with that label should be switched along the protected 1134 LSP. This can be done without explicitly signaling the backup path 1135 if the MP uses a label space global to that LSR. 1137 As described in Section 6, the head-end LSR MUST set the "label 1138 recording requested" flag in the SESSION_ATTRIBUTE object for LSPs 1139 requesting local protection. This will cause (as specified in 1140 [RSVP- TE]) all LSRs to record their INBOUND labels and to note via 1141 a flag if the label is global to the LSR. Thus, when a protected 1142 LSP is first signaled through a PLR, the PLR can examine the RRO in 1143 the Resv message and learn about the incoming labels that are used 1144 by all downstream nodes for this LSP. 1146 When MPs use per-interface-label spaces, the PLR must send Path 1147 messages (for each protected LSP using a bypass tunnel) via that 1148 bypass tunnel prior to the failure in order to discover the 1149 appropriate MP label. The signaling procedures for this are in 1150 Section 7.4.3 below. 1152 7.4.2. Procedures for the PLR before Local Repair 1154 A PLR which determines to use facility-backup to protect a given 1155 LSP should select a bypass tunnel to use taking into account 1156 whether node protection is to be provided, what bandwidth was 1157 requested and whether a bandwidth guarantee is desired, and what 1158 link attribute filters were specified in the FAST_REROUTE object. 1160 The selection of a bypass tunnel for a protected LSP is performed 1161 by the PLR when the LSP is first setup. 1163 7.4.3. Procedures for the PLR during Local Repair 1165 When the PLR detects a link or/and node failure condition, it needs 1166 to reroute the data traffic onto the bypass tunnel and to start 1167 sending the control traffic for the protected LSP onto the bypass 1168 tunnel. 1170 The backup tunnel is identified using the sender-template-specific 1171 method. The procedures to follow are similar to those described in 1172 Section 7.3. 1174 - The SESSION is unchanged. 1176 - The SESSION_ATTRIBUTE is unchanged except as follows: 1177 The "Local protection desired", "Bandwidth protection desired", 1178 and "Node protection desired" flags SHOULD be cleared. 1179 The "Label recording desired" MAY be modified. 1181 - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE 1182 is set to an address belonging to the PLR. 1184 - The RSVP_HOP object MUST contain an IP source address 1185 belonging to the PLR. Consequently, the MP will send messages 1186 back to the PLR using as a destination that IP address. 1188 - The PLR MUST generate an EXPLICIT_ROUTE object toward the 1189 egress. Detailed ERO processing is described below. 1191 - The RRO object may need to be updated, as described in Section 1192 7.5. 1194 The PLR sends Path, PathTear, and ResvConf messages via the backup 1195 tunnel. The MP sends Resv, ResvTear, and PathErr messages by 1196 directly addressing them to the address in the RSVP_HOP object 1197 contents as specified in [RSVP]. 1199 If it is necessary to signal the backup prior to failure to 1200 determine the MP label to use, then the same Path message is sent. 1201 In this case, the PLR SHOULD continue to send Path messages for the 1202 protected LSP along the normal route. PathTear messages should be 1203 duplicated, with one sent along the normal route and one sent thru 1204 the bypass tunnel. The MP should duplicate the Resv and ResvTear 1205 messages and sent them to both the PLR and the LSR indicated by the 1206 protected LSP's RSVP_HOP object. 1208 7.4.4. Processing backup tunnel's ERO 1210 Procedures for ERO processing are described in [RSVP-TE]. This 1211 section describes additional ERO update procedures for Path messages 1212 which are sent over bypass tunnels. If normal ERO processing rules 1213 were followed, the Merge Point would examine the first sub-object and 1214 likely reject it (Bad initial sub-object). This is because the 1215 unmodified ERO might contain the IP address of a bypassed node (in 1216 the case of a NNHOP Backup Tunnel), or of an interface which is 1217 currently down (in the case of a NHOP Backup Tunnel). For this 1218 reason, the PLR invoke the following ERO procedures before sending a 1219 Path message via a bypass tunnel. 1221 Sub-objects belonging to abstract nodes which precede the Merge Point 1222 are removed, along with the first sub-object belonging to the MP. A 1223 sub-object identifying the Backup Tunnel destination is then added. 1225 More specifically, the PLR MUST: 1227 - remove all the sub-objects proceeding the first address belonging 1228 to the MP. 1230 - replace this first MP address with an IP address of the MP. 1231 (Note that this could be same address that was just removed.) 1233 7.5. PLR Procedures During Local Repair 1235 In addition to the technique specific signaling and packet 1236 treatment, there is common signaling which should be followed. 1238 During fast reroute, for each protected LSP containing an RRO 1239 object, the PLR obtains the RRO from the protected LSP's stored 1240 RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted 1241 into the RRO by setting the "Local protection in use" and "Local 1242 Protection Available" flags. 1244 7.5.1. Notification of local repair 1246 In many situations, the route used during a Local Repair will be less 1247 than optimal. The purpose of Local Repair is to keep high priority 1248 and loss sensitive traffic flowing while a more optimal re-routing of 1249 the tunnel can be effected by the head-end of the tunnel. Thus the 1250 head-end needs to know of the failure so it may re-signal an LSP 1251 which is optimal. 1253 To provide this notification, the PLR SHOULD send a Path Error 1254 message with error code of "Notify" (Error code =25) and an error 1255 value field of ss00 cccc cccc cccc where ss=00 and the sub-code = 3 1256 ("Tunnel locally repaired") (see [RSVP-TE]) 1258 Additionally a head-end may also detect that an LSP needs to be moved 1259 to a more optimal path by noticing failures reported via the IGP. 1260 Note that in the case of inter-area TE LSP (TE LSP spanning areas), 1261 the head-end LSR will need to rely exclusively on Path Error messages 1262 to be informed of failures in another area. 1264 7.5.2 Revertive Behavior 1266 Upon a failure event, a protected TE LSP is locally repaired by the 1267 PLR. There are two basic strategies for restoring the TE LSP to a 1268 full working path. 1270 - Global revertive mode: The head-end LSR of each tunnel is 1271 responsible for reoptimizing the TE LSPs that used the failed 1272 resource. There are several potential reoptimization triggers - 1273 RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and 1274 timers. Note that this re-optimization process may proceed as 1275 soon as the failure is detected. It is not tied to the 1276 restoration of the failed resource. 1278 - Local revertive mode: Upon detecting that the resource is 1279 restored, the PLR re-signals each of TE LSPs that used to be 1280 routed over the restored resource. Every TE LSP successfully 1281 resignaled along the restored resource is switched back. 1283 There are several circumstances where a local revertive mode might 1284 not be desirable. In the case of resource flapping (not an uncommon 1285 failure type), this could generate multiple traffic disruptions. 1286 Therefore, in the local revertive mode, the PLR should implement a 1287 means to dampen the re-signaling process in order to limit 1288 potential disruptions due to flapping. 1290 In the local revertive mode, any TE LSP will be switched back, 1291 without any distinction, as opposed to the global revertive mode 1292 where the decision to reuse the restored resource is taken by the 1293 head-end LSR based on the TE LSP attributes. When the head-end 1294 learns of the failure, it may reoptimize the protected LSP tunnel 1295 along a different and more optimal path, because it has a more 1296 complete view of the resources and TE LSP constraints; this means 1297 that the old LSP which has been reverted to may not be optimal any 1298 longer. Note that in the case of inter-area LSP, where the TE LSP 1299 path computation might be done on some Path Computation Server, the 1300 reoptimization process can still be triggered on the Head-End 1301 LSP. The local revertive mode is optional. 1303 However, there are circumstances where the Head-end does not have 1304 the ability to reroute the TE LSP (e.g if the protected LSP is 1305 pinned down, as may be desirable if the paths are determined using 1306 an off-line optimization tool) or if Head-end does not have the 1307 complete TE topology information (depending on the path computation 1308 scenario). In those cases, the local revertive might be a 1309 interesting option. 1311 It is recommended that one always use the globally revertive mode. 1312 Note that a link or node "failure" may be due to the facility being 1313 permanently taken out of service. Local revertive mode is 1314 optional. When used in combination, the global mode may rely 1315 solely on timers to do the reoptimization. When local revertive 1316 mode is not used, head-end LSRs SHOULD react to RSVP error messages 1317 and/or IGP indications in order to make a timely response. 1319 Interoperability: If a PLR is configured with the local revertive 1320 mode but the MP is not, any attempt from the PLR to resignal the TE 1321 LSP over the restored resource would fail as the MP will not send 1322 any Resv message. The PLR will still refresh the TE LSP over the 1323 backup tunnel. The TE LSP will not revert to the restored resource; 1324 instead it will continue to use the backup until it is 1325 re-optimized. 1327 8. Merge Node Behavior 1329 An LSR is a Merge Point if it receives the Path message for a 1330 protected LSP and one or more messages for a backup LSP which is 1331 merged into that protected LSP. In the one-to-one backup 1332 technique, the LSR is aware that it is a merge node prior to 1333 failure. In the facility backup technique, the LSR may not know 1334 that it is a Merge Point until a failure occurs and it receives a 1335 backup LSP's Path message. Therefore, an LSR which is on the path 1336 of a protected LSP SHOULD always assume that it is a merge point. 1338 When a MP receives a backup LSP's Path message thru a bypass 1339 tunnel, the Send_TTL in the Common Header may not match the TTL of 1340 the IP packet within which the Path message was transported. This 1341 is expected behavior. 1343 8.1. Handling Backup Path Messages Before Failure 1345 There are two circumstances where a Merge Point will receive Path 1346 messages for a backup path prior to failure. In the first case, if 1347 a PLR is providing local protection via the one-to-one backup 1348 technique, the detour will be signaled and must be properly handled 1349 by the MP. In this case, the backup LSP may be signaled via the 1350 sender-template-specific method or via the path-specific method. 1352 In the second case, if the Merge Point does not provide labels 1353 global to the MP and record them in a Label sub-object of the RRO 1354 or if the PLR does not use such recorded information, the PLR may 1355 signal the backup path, as described above in Section 7.4.1, to 1356 determine the label to use if the PLR is providing protection 1357 according to the facility backup technique. In this case, the 1358 backup LSP is signaled via the sender-template-specific method. 1360 The reception of a backup LSP's path message does not indicate that 1361 a failure has occured and the incoming protected LSP will no longer 1362 be used. 1364 8.1.1. Merginging Backup Paths using the Sender-Template Specific Method 1366 An LSR may receive multiple Path messages for one or more backup 1367 LSPs and, possibly, the protected LSP. Each of these Path messages 1368 will have a different SENDER_TEMPLATE. The protected LSP can be 1369 recognized because it will either include the FAST_REROUTE object, 1370 have the "local protection desired" flag set in the 1371 SESSION_ATTRIBUTE object or both. 1373 If the outgoing interface and next-hop LSR are the same, then the 1374 Path messages are eligible for merging. Similar to that specified 1375 in [RSVP-TE] for merging of RESV messages, only those Path messages 1376 whose ERO from that LSR to the egress is the same can be merged. 1377 If merging occurs and one of the Path messages merged was for the 1378 protected LSP, then the final Path message to be sent MUST be that 1379 of the protected LSP. This merges the backup LSPs into the 1380 protected LSP at that LSR. Once the final Path message has been 1381 identified, the MP MUST start to refresh it downstream 1382 periodically. 1384 If merging occurs and all the Path messages were for backup LSPs, 1385 then the DETOUR object, if any, should be altered as specified in 1386 Section 9.1 1388 8.1.2. Merging Detours using the Path-Specific Method 1390 An LSR (that is, an MP) may receive multiple Path messages from 1391 different interfaces with identical SESSION and SENDER_TEMPLATE 1392 objects. In this case, Path state merging is REQUIRED. 1394 The merging rule is the following: 1396 For all Path messages that do not have either a FAST_REROUTE or a 1397 DETOUR object, or the MP is the egress of the LSP, no merging is 1398 required. The messages are processed according to [RSVP-TE]. 1400 Otherwise, the MP MUST record the Path state as well as their 1401 incoming interface. If the Path messages do not share outgoing 1402 interface and next-hop LSR, the MP MUST consider them as independent 1403 LSPs, and MUST NOT merge them. 1405 For all the Path messages that share the same outgoing interface and 1406 next-hop LSR, the MP runs the following procedure to a Path message 1407 to forward downstream. 1409 1. If one or more of the Path messages is for the protected LSP 1410 (a protected LSP is one originated from this node, or with 1411 the FAST_REROUTE object, or without the DETOUR object), 1412 one of these must become the chosen Path message. There could 1413 be more than one; in that case, it is a local decision to choose 1414 which one to forward. Quit. 1416 2. From the remaining set of Detour Path messages, eliminate from 1417 consideration, those that traverse nodes which others want to 1418 avoid. 1420 3. If several still remain, it is a local decision to choose which 1421 one to forward. If none remain, then the MP may try and find a 1422 new route that does avoid all nodes that all merging Detour 1423 Paths want to avoid and forward a Path message with that ERO. 1425 Once the final Path message has been identified, the MP MUST start to 1426 refresh it downstream periodically. Other LSPs are considered merged 1427 at this node. For bandwidth reservation on the outgoing link, any 1428 merging should be considered to have occured before bandwidth is 1429 reserved. Thus, even though Fixed Filter is specified, multiple 1430 detours and/or their protected LSP which are to be merged due to 1431 sharing an outgoing interface and next-hop LSR will reserve only 1432 the bandwidth of the final Path message on that outgoing 1433 interface. 1435 If no merged Path message can be constructed then the MP SHOULD send 1436 a PathErr in response to the most recently received detour Path 1437 message. If a protected Path is chosen to be forwarded, but it 1438 traverses nodes that some detours want to avoid, PathErrs should be 1439 sent in response to those detour Paths which cannot merge. 1441 8.1.2.1. An Example on Path Message Merging 1443 R7---R8---R9-\ 1444 | | | \ 1445 R1---R2---R3---R4---R5---R6 1447 Protected LSP: [R1->R2->R3->R4->R5->R6] 1448 R2's Detour: [R2->R7->R8->R9->R4->R5->R6] 1449 R3's Detour: [R3->R8->R9->R5->R6] 1451 Example 4: Path Message Merging 1453 In Example 4 above, R8 will receive Path messages that have the 1454 same SESSION and SENDER_TEMPLATE from detours for R2 and R3. 1455 During merging at R8 since detour R3 has a shorter ERO path length 1456 (that is, ERO is [R9->R5->R6], and path length is 3), R8 will 1457 select it as the final LSP, and only propagate its Path messages 1458 downstream. Upon receiving a Resv (or a ResvTear) message, R8 must 1459 relay on the messages toward both R2 and R3. 1461 R5 needs to merge as well, and will select the main LSP, since it 1462 has the FAST_REROUTE object. Thus, the detour LSP terminates at 1463 R5. 1465 8.1.3. Message Handling for Merged Detours 1467 When an LSR receives a ResvTear for an LSP, the LSR must determine 1468 whether it has an alternate associated LSP. For instance, if the 1469 ResvTear was received for a protected LSP, but an associated backup 1470 LSP has not received a ResvTear, then the LSR has an alternate 1471 associated LSP. If the LSR does not have an alternate associated 1472 LSP, then the MP MUST propogate the ResvTear toward the LSP's 1473 ingress and, for each backup LSP merged into that LSP at this LSR, 1474 the ResvTear SHOULD also be propogated along the backup LSP. 1476 The MP may receive PathTear messages for some of the merging LSPs. 1477 PathTear messages SHOULD NOT be propagated downstream until the MP 1478 has received PathTear messages for each of the merged LSPs. 1479 However, the fact that one or more of the merged LSPs has been torn 1480 down should be reflected in the downstream message, such as by 1481 changing the DETOUR object, if any. 1483 8.2. Handling Failures 1485 When a downstream LSR detects a local link failure, for any 1486 protected LSPs routed over the failed link, Path and Resv state 1487 MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be 1488 sent immediately; if this is not the case, then the facility backup 1489 technique will not work. Further a downstream LSR SHOULD reset the 1490 refresh timers for these LSPs as if they had just been refreshed. 1491 This is to allow time for the PLR to begin refreshing state via the 1492 bypass tunnel. State MUST be removed if it has not been refreshed 1493 before the refresh timer expires. This allows the facility backup 1494 technique to work without requiring that it signal backup paths 1495 thru the bypass tunnel before failure. 1497 After a failure has occured, the MP must still send Resv messages 1498 for the backup LSPs associated with the protected LSPs which have 1499 failed. If the backup LSP was sent through a bypass tunnel, then 1500 the PHOP object in its Path message will have the IP address of the 1501 associated PLR. This will ensure that Resv state is refreshed. 1503 Once the local link has recovered, the MP may or may not accept 1504 Path messages for existing protected LSPs which had failed over to 1505 their backup. 1507 9. Behavior of all LSRs 1509 The objects defined and the techniques defined in this document 1510 require behavior from all LSRs in the traffic-engineered network, 1511 even if that LSR is not along the path of a protected LSP. 1513 First, if a DETOUR object is included in the backup LSP's path 1514 message for the sender-template-specific method, the LSRs in the 1515 traffic-engineered network should support the DETOUR object. 1517 Second, if the Path-Specific Method is to be supported for 1518 the one-to-one backup technique, it is necessary that the LSRs in 1519 the traffic-engineered network be capable of merging detours as 1520 specified below in Section 9.1. 1522 It is possible to avoid specific LSRs which do not support this 1523 behavior by assigning an link attribute to all the links of those 1524 LSPs and then requesting that backup paths exclude that link 1525 attribute. 1527 9.1. Merging Detours in Path-Specific Method 1529 If multiple Path Messages for different detours are received with 1530 the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop 1531 LSR, then the LSR must function as a Detour Merge Point and merge 1532 the detour Path Messages. This merging should occur as specified 1533 in Section 8.1.2 and shown in Example 4. 1535 In addition, it is necessary to update the DETOUR object to reflect 1536 the merging which has taken place. This is done using the 1537 following algorithm to format the outgoing DETOUR object for the 1538 final LSP: 1540 - Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the 1541 DETOUR objects of all merged LSPs, and create a new object with 1542 all listed. Ordering is insignificant. 1544 10. Security Considerations 1546 This document does not introduce new security issues. The security 1547 considerations pertaining to the original RSVP protocol [RSVP] remain 1548 relevant. 1550 It should be noted that the facility backup technique requires that 1551 a PLR and its selected Merge Point will trust RSVP messages 1552 received from each other. 1554 11. IANA Section 1556 IANA [RFC-IANA] will assign RSVP Class Number 205 for the 1557 FAST_REROUTE and RSVP Class Number 63 for the DETOUR object. This 1558 matches the current usage in production networks. 1560 IANA will assign C-Type 1 for the standard FAST_REROUTE object 1561 format defined in section 5.1 and list C-Type 7 as reserved as it 1562 is still used by pre-standard implementations. Future C-Types 1563 will be assigned using the following guidelines: 1565 C-Types 0 through 127 are assigned by Standards Action. 1566 C-Types 128 through 191 are assigned by Expert Review. 1567 C-Types 192 through 255 are reserved for Vendor Private Use. 1569 For C-Types in the range 192 through 255, the first four octets of 1570 the FAST_REROUTE object after the C-Type MUST be the Vendor's SMI 1571 Network Management Private Enterprise Code (see [ENT]) in network 1572 byte order. 1574 IANA will assign C-Types 7 and 8 to the IPv4 and IPv6 DETOUR object 1575 formats as defined in section 5.2. Future C-Types will be 1576 assigned using the following guidelines: 1578 C-Types 0 through 127 are assigned by Standards Action. 1579 C-Types 128 through 191 are assigned by Expert Review. 1580 C-Types 192 through 255 are reserved for Vendor Private Use. 1582 For C-Types in the range 192 through 255, the first four octets of 1583 the DETOUR object after the C-Type MUST be the Vendor's SMI Network 1584 Management Private Enterprise Code (see [ENT]) in network byte order. 1586 12. Intellectual Property Considerations 1588 The IETF takes no position regarding the validity or scope of any 1589 intellectual property or other rights that might be claimed to 1590 pertain to the implementation or use of the technology described in 1591 this document or the extent to which any license under such rights 1592 might or might not be available; neither does it represent that it 1593 has made any effort to identify any such rights. Information on the 1594 IETF's procedures with respect to rights in standards-track and 1595 standards-related documentation can be found in BCP-11. Copies of 1596 claims of rights made available for publication and any assurances of 1597 licenses to be made available, or the result of an attempt made to 1598 obtain a general license or permission for the use of such 1599 proprietary rights by implementors or users of this specification can 1600 be obtained from the IETF Secretariat. 1602 The IETF has been notified of intellectual property rights 1603 claimed in regard to some or all of the specification contained 1604 in this document. For more information consult the online list 1605 of claimed rights. 1607 13. Full Copyright Statement 1609 Copyright (C) The Internet Society (2002). All Rights Reserved. 1611 This document and translations of it may be copied and furnished to 1612 others, and derivative works that comment on or otherwise explain it 1613 or assist in its implementation may be prepared, copied, published 1614 and distributed, in whole or in part, without restriction of any 1615 kind, provided that the above copyright notice and this paragraph are 1616 included on all such copies and derivative works. However, this 1617 document itself may not be modified in any way, such as by removing 1618 the copyright notice or references to the Internet Society or other 1619 Internet organizations, except as needed for the purpose of 1620 developing Internet standards in which case the procedures for 1621 copyrights defined in the Internet Standards process must be 1622 followed, or as required to translate it into languages other than 1623 English. 1625 The limited permissions granted above are perpetual and will not be 1626 revoked by the Internet Society or its successors or assigns. 1628 This document and the information contained herein is provided on an 1629 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1630 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1631 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1632 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1633 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1635 14. Acknowledgments 1637 We would like to acknowledge input and helpful comments from Rob 1638 Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, 1639 we thank those, who have been involved in interoperability testing 1640 and field trails, and provided invaluable ideas and suggestions. 1641 They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, 1642 Richard Southern, and Bijan Jabbari. 1644 15. Normative References 1646 [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) 1647 -- version 1 functional specification," RFC2205, September 1997. 1649 [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 1650 tunnels", RFC3029, December 2001. 1652 [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate 1653 Requirement Levels", RFC 2119, March 1997. 1655 [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an 1656 IANA Considerations Section in RFCs", RFC 2434. 1658 [ENT] IANA PRIVATE ENTERPRISE NUMBERS, 1659 http://www.iana.org/assignments/enterprise-numbers 1661 16. Editor Information 1663 George Swallow 1664 Cisco Systems, Inc. 1665 300 Beaver Brook Road 1666 Boxborough, MA 01719 1667 USA 1668 email: swallow@cisco.com 1669 phone: +1 978 244 8143 1670 Ping Pan 1671 640 Clyde Court 1672 Mountain View, CA 94043 1673 USA 1674 e-mail: ppan@hammerheadsystems.com 1676 Alia Atlas 1677 Avici Systems 1678 101 Billerica Avenue 1679 N. Billerica, MA 01862 1680 USA 1681 email: aatlas@avici.com 1682 phone: +1 978 964 2070