idnits 2.17.1 draft-cao-mpls-te-p2mp-head-protection-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 731. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC4090], [P2MP-TE-Bypass], [TE-FRR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 17, 2007) is 6004 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: 'RFC4090' is mentioned on line 36, but not defined == Missing Reference: 'P2MP-TE-Bypass' is mentioned on line 121, but not defined == Missing Reference: 'FRR' is mentioned on line 119, but not defined == Missing Reference: 'S1' is mentioned on line 195, but not defined == Missing Reference: 'Rx' is mentioned on line 164, but not defined == Missing Reference: 'Lx' is mentioned on line 164, but not defined == Missing Reference: 'R1' is mentioned on line 293, but not defined == Missing Reference: 'R4' is mentioned on line 291, but not defined == Missing Reference: 'L1' is mentioned on line 196, but not defined == Missing Reference: 'L2' is mentioned on line 196, but not defined == Missing Reference: 'ReceiverA' is mentioned on line 169, but not defined == Missing Reference: 'ReceiverB' is mentioned on line 169, but not defined == Missing Reference: 'R5' is mentioned on line 278, but not defined == Missing Reference: 'R6' is mentioned on line 171, but not defined == Missing Reference: 'R2' is mentioned on line 278, but not defined == Missing Reference: 'R3' is mentioned on line 172, but not defined == Missing Reference: 'S2' is mentioned on line 195, but not defined == Missing Reference: 'RFC2746' is mentioned on line 362, but not defined == Missing Reference: 'P2MP-TE' is mentioned on line 634, but not defined == Missing Reference: 'RSVP-TE-FRR' is mentioned on line 649, but not defined == Unused Reference: 'RFC2119' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RSVP-P2MP' is defined on line 692, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4461 Summary: 4 errors (**), 0 flaws (~~), 25 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Wei.Cao 2 Internet Draft Mach. Chen 3 Expires: May 2008 Huawei Co,.LTD 4 Category: Standards Track November 17, 2007 6 Head Node Protection Extensions to RSVP-TE for LSP Tunnels 7 draft-cao-mpls-te-p2mp-head-protection-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on May 17, 2008. 34 Abstract 36 Protection methods for RSVP-TE P2MP LSP have been described in [TE- 37 FRR]([RFC4090]) and [P2MP-TE-Bypass], but there are no solutions to 38 protect an RSVP-TE P2MP head node. This document discusses the 39 scenario for RSVP-TE P2MP LSP head node failure protection and 40 describes the protection procedures. RSVP-TE extensions for such 41 protection are also described. 43 To protect the head node, a backup head node is appointed which 44 forwards traffic to downstream LSRs of the LSP when the protected 45 head node fails. The backup head node is not on the path of protected 46 LSP. Similar to [TE-FRR] there are two methods that can apply: one- 47 to-one backup and facility backup. Only one-to-one backup is 48 described in detail here, facility backup will be discussed in a 49 future version of this draft. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119. 57 Table of Contents 59 1. Terminology.................................................3 60 2. Introduction................................................3 61 2.1. Motivation.............................................3 62 2.2. Head Node Protection Scenario...........................4 63 2.2.1. Solution Overview..................................5 64 2.3. Applicability Statement and Implementation Considerations7 65 2.3.1. Topology Limitation................................7 66 2.3.2. Implementation Consideration.......................8 67 3. Extensions to RSVP-TE........................................8 68 3.1. HEAD_PROTECTION Object..................................8 69 3.1.1. HEAD_PROTECTION for IPv4 address...................8 70 3.1.2. HEAD_PROTECTION for IPv6 address...................9 71 3.1.3. SESSION_ATTRIBUTE Flags...........................11 72 4. Behavior of MHN and BHN.....................................11 73 4.1. Behavior of MHN........................................11 74 4.1.1. Signaling BHN for Head Protection.................11 75 4.1.2. Revert back to MHN from BHN Behavior..............12 76 4.2. Behavior of BHN........................................13 77 4.2.1. Signaling BHN-Detour and Protection Procedures.....13 78 4.2.2. Revertive Procedures for BHN......................14 79 4.3. Protection Teardown....................................14 80 4.3.1. Protection Teardown...............................14 81 5. Behavior of Merge Nodes.....................................15 82 6. Behavior of All Other LSRs..................................15 83 7. Security Considerations.....................................15 84 8. IANA Considerations........................................15 85 9. Conclusions................................................15 86 10. Acknowledgments...........................................15 87 11. References................................................16 88 11.1. Normative References..................................16 89 Author's Addresses............................................16 90 Intellectual Property Statement................................16 91 Disclaimer of Validity........................................17 92 Copyright Statement...........................................17 94 1. Terminology 96 LSR: Label-Switch Router. In this document all LSRs should support 97 RSVP-TE extensions for P2MP LSP. 99 LSP: An MPLS Label-Switched Path. In this document, an LSP will 100 always be an explicitly routed LSP. 102 MHN: Major Head Node. MHN is the head node of the protected RSVP-TE 103 P2MP LSP . 105 BHN: Backup Head Node. BHN is the head-end of the backup LSP. When 106 there is a node failure in MHN, BHN will take the charge of 107 forwarding packets on the backup up LSP protecting the traffic. 109 MP: Merge Point. In this document a MP is generally the one hop 110 downstream neighbour to the MHN. 112 PLR: Point of local repair 114 2. Introduction 116 RSVP-TE P2MP LSP has been deployed and many real-time applications 117 are running over such LSPs, so there is motivation to improve their 118 reliability. Much work has already been done to provide protection in 119 RSVP-TE P2MP. Fast Reroute [FRR] has been an important mechanism to 120 improve network resiliency. But the methods proposed in [TE-FRR] and 121 [P2MP-TE-Bypass] do not provide a mechanism for protecting an LSP's 122 head node which is a key element for high availability. This document 123 discusses the scenario for RSVP-TE P2MP LSP head node failure 124 protection and describes procedures and RSVP-TE extensions for such 125 protection. This work requires that the procedures defined in 126 [RSVP](RFC2205), [RSVP-TE](RFC3209),[TE-FRR]and [RSVP-P2MP](RFC4985) 127 MUST be followed. 129 2.1. Motivation 131 Traditional protection methods use a backup LSP or bypass tunnel to 132 forward the traffic. In the event of protected LSP failure, including 133 link or node failure, PLR will take action to detour the packets from 134 PLR to MP through a backup LSP or bypass tunnel. This requires PLR 135 must be a node on the path of the protected LSP and must be upstream 136 of the failure point. Such mechanisms work well for protecting 137 transit links and transit LSRs but have no ability to protect the 138 head node of the LSP because it has no upstream node. In real 139 applications, head node failure will cause serious outages and 140 consequently there is a strong motivation for reducing and providing 141 protection from that risk. One possible solution today is 1+1 142 protection: deploying another P2MP tree from a different LSR to all 143 receivers. Obviously this is not an efficient method; it will double 144 bandwidth usage and require maintaining twice the forwarding states 145 in the devices. So it is highly desirable to find another solution to 146 this problem. 148 2.2. Head Node Protection Scenario 150 When real-time applications are deployed, service providers (SP) 151 always try to avoid service interruption. Failures are not 152 predictable so backup is a necessary and effective solution. It is 153 common for SP to deploy multiple servers (traffic sources) and/or 154 multi-home the application servers to multiple edge routers. Below is 155 a typical topology for such applications: 157 +---[R1]--[R2]--[R3]---[L1]----[ReceiverA] 158 [S1]-| \/ | \/ 159 | /\ | /\ 160 +---[R4]--[R5]--[R6]---[L2]----[ReceiverB] 162 Figure 1. Source Multi-homing 164 In Figure 1, [S1] is an application server; [Rx] and [Lx] are RSVP-TE 165 P2MP LSP capable devices. [S1] is multi-homed to LSR [R1] and [R4]. 166 If multicast packets are sent by [S1]they need to be transmitted to 167 [L1] and [L2], a P2MP LSP (LSP1)starting at [R1] can be created with 168 two sub-LSPs: [R1]->[R2]->[R3]-[L1] and [R1]->[R5]->[R6]->[L2]. Thus 169 packets from [S1] can be received by [ReceiverA] and [ReceiverB]. If 170 the SP wants to improve robustness, another P2MP LSP (LSP2) starting 171 from [R4] can be created with two sub-LSPs: [R4]->[R5]->[R6]->[L2] 172 and [R4]->[R2]->[R3]-[L1]. Packets from [S1] can reach [R1] and [R4] 173 at the same time and be forwarded to L1 and L2 separately through 174 LSP1 and LSP2. [L1] and [L2] may choose one LSP (Suppose it is LSP1) 175 as the major path and the other one (LSP2) as a backup one. Only 176 traffic from LSP1 will be forwarded to receivers and traffic from 177 LSP2 will be dropped. In case of [R1] failure, [L1] and [L2] detect 178 the failure of LSP1 and then begin to accept packets received from 179 LSP2. 181 There may be some variations from Figure 1. The SP may want to 182 protect against LSR and application server failure. A common solution 183 is to deploy two application servers separately connected to two LSRs. 184 This is shown in Figure 2 below: 186 [S1]-|---[R1]--[R2]--[R3]---[L1]----[ReceiverA] 187 \/ | \/ 188 /\ | /\ 189 [S2]-|---[R4]--[R5]--[R6]---[L2]----[ReceiverB] 191 Figure 2. Separate Sources 193 [S1] and [S2] are connected to [R1] and [R2] respectively, and both 194 application servers generate the same traffic stream to receivers. 195 Packets from [S1] will go through LSP1 and packets from [S2] will go 196 through LSP2. [L1] and [L2] may accept the packets from LSP1 and drop 197 the packets from LSP2. The protection procedure is similar to the 198 case depicted in Figure 1. 200 The above methods work but are inefficient. The protection bandwidth 201 is wasted most of time. LSRs have to maintain as much as twice amount 202 of P2MP LSP state. In addition all leaves have to deal with 203 duplicated traffic and monitor the LSP state to determine which LSP 204 is the active one. Comparing the two P2MP LSPs in above cases, it is 205 easy to be noticed that the only differences between them are the 206 head nodes; LSP1 starts from [R1] and LSP2 starts from [R4], the 207 transit nodes and leaves are same. So in such a topology if [R1] and 208 [R4] cooperate together with one acting as a backup node for the 209 other, then it is possible to build only one P2MP LSP while gaining 210 head node protection. 212 2.2.1. Solution Overview 214 Similar to FRR defined in [TE-FRR], the head node protection method 215 described in this document also relies on backup LSPs. Since there is 216 no "upstream neighbour" of the head node to detour the traffic around 217 it, an LSR has to be assigned as a backup head node in the event of 218 head node failure. We call the head node of protected LSP as MHN 219 (major head node) and the backup one BHN (backup head node). A backup 220 LSP or bypass tunnel to protect MHN will be built from BHN to all 221 NHOP LSRs of MHN. These NHOP LSRs are merge points (MP) for the LSPs. 222 To ensure all branches receive the traffic the MP set SHOULD include 223 ALL NHOP LSRs of MHN. 225 Multicast packets from the source arrive at both MHN and BHN. Under 226 normal operating conditions MHN forwards this traffic while BHN drops 227 it; there is no traffic on backup LSP or bypass tunnels to MPs. When 228 BHN detects there is a failure of MHN it will begin to forward 229 packets to the MPs. The MPs will recognize which LSP the packets 230 belong to and forward the packets along the rest of the protected LSP. 232 The precise mechanism used to discover the node failure of MHN is 233 outside the scope of this document. One possible method is to use 234 multiple, diversely routed, BFD connections between MHN and BHN. If 235 all these BFD sessions are lost, BHN can reasonably infer that MHN 236 has failed. 238 A LSR eligible to be a BHN MUST satisy the follow conditions: 240 - Traffic to be protected can be received by it from the source 241 without transiting MHN; 243 - BHN can build traffic tunnels to all MPs. That means BHN must on 244 the "upstream side" of all MPs. Ideally BHN should have direct 245 connection links to all MPs. 247 - BHN should have the ability to discover MHN's node failure and 248 discover the recovery of MHN from node failure. (How to detect the 249 node failure is outside the scope of this document) 251 - BHN SHOULD NOT be on the path of protected LSP. 253 In Figure1, if the head node of LSP1 is to be protected, [R1] is the 254 MHN and [R4] can be assigned as BHN. The MP set includes LSR [R2] and 255 [R5]. 257 The backup LSP against MHN failure starts from BHN to MPs. 258 Theoretically the backup LSP can use unicast LSPs or P2MP TE LSPs. 259 Consequently there are two options for building backup LSPs: 261 - Rely on one or multiple unicast LSPs from BHN to the set of merge 262 points. 264 - Rely on single P2MP TE LSP from BHN to the set of merge points. 266 There is a constraint on the routing of the backup LSP(s): the backup 267 LSP(s) MUST NOT transit the MHN. 269 Since the BHN has to send traffic to all downstream MPs, a P2MP TE 270 LSP is a natural choice and is the approach discussed in this 271 document. In figure 1 the backup P2MP TE LSP is composed of two sub- 272 LSPs: [R4]->[R2] and [R4]->[R5]. The backup P2MP TE LSP is referred 273 to as a LSP BHN-Detour. 275 When a failure occurs in the MHN ([R1]), the BHN ([R4]) detects the 276 failure and begins transmitting traffic on to the BHN detour along 277 links [R4]->[R2] and [R4]->[R5], using the label received from the 278 MPs ([R2] and [R5])when it created the BHN-Detour. While [R4] is 279 using the BHN-Detour it recognizes the multicast traffic and performs 280 the MPLS encapsulation. Merge points receive the detoured traffic 281 from BHN and merge them to the protected LSP. From the view of MPs, 282 the process is the same as for link failure protection. 284 Service interruption is not only caused by failure but may be caused 285 by regular operations, such as hardware upgrade or software patch 286 installation. Such operation is planned by the SP and the outage of 287 the node can be predicted. This kind of operation is referred to as 288 Planned-Maintenance (PM). The head protection method described in 289 this document can also be used in this scenario. For example, in 290 figure1, if [R1] has to stop forwarding due to some operational 291 reason, [R1] can assign [R4] as BHN and after [R4] has built the BHN- 292 Detour R1 can be removed from service and traffic transmitted through 293 the BHN-Detour. After the maintenance of [R1] has been performed it 294 can be returned to service. Head protection is a valuable protection 295 against failure and a useful tool for normal network operation. 297 Since head protection is performed by two LSRs, there are many 298 important differences between [TE-FRR] and head protection. 300 The fundamental difference between [TE-FRR] and head-node protection 301 is how the PLR/BHN is informed of the details of the protected LSP. 302 In [TE-FRR], PLR will receive PATH message sent by the head node and 303 PLR will get all information about the protected LSP and process the 304 relevant RSVP extensions. BHN is not on the path of the Protected LSP 305 and so extra messages must be sent by MHN to BHN to convey this 306 information. 308 One other difference is that all LSRs on the path of P2MP LSP must be 309 periodically refreshed by a PATH message, in the case of MHN failure, 310 BHN must generate and send PATH messages to all downstream LSPs as if 311 these messages were sent by the MHN. 313 2.3. Applicability Statement and Implementation Considerations 315 2.3.1. Topology Limitation 317 This document describes a mechanism that works only with the topology 318 constraint that a suitable backup head node exists. A suitable backup 319 head node must satisfy the requirements listed in section 2.2.1. It 320 is common to construct the topologies discussed in 2.2 in high 321 availability environments and these constraints are not a significant 322 additional burden in the deployment of head-node protection. 324 2.3.2. Implementation Consideration 326 Head node protection should be compatible with the existing protocols 327 in so far as is possible. Some considerations/requirements are listed 328 bellow: 330 - Inherit existing protocol extensions: the new method should reuse 331 existing protocol extensions defined in [TE-FRR] as much as 332 possible; the new method should be backward compatible with 333 current mechanisms. Ideally, only MHN and BHN should be upgraded 334 and MPs and others LSR SHOULD be kept unchanged. 336 - When a protection action is taken, as few nodes as possible should 337 be affected. There should be no need to affect any nodes 338 downstream of a MP. 340 - After a protection switch has occured the BHN operates in an 341 indentical manner to the old head node; it refreshes and processes 342 all feedback from downstream LSRs which, with the exception of the 343 MP, are unaware of the change from MHN to BHN. 345 3. Extensions to RSVP-TE 347 This document defines an additional object, which is referred to as a 348 HEAD_PROTECTION object. This new object is backward compatible with 349 LSRs that do not recognize it. The new object is carried in RSVP PATH 350 and RESV messages. 352 3.1. HEAD_PROTECTION Object 354 The HEAD_PROTECTION object is used to exchange information between 355 MHN and BHN. MHN uses this object to specify which LSR is BHN and 356 advertise essential information about a protected LSP. BHN and MHN 357 MUST NOT forward this object to their downstream LSRs. 359 Ideally MHN and BHN are directly connected. If MHN is not directly 360 connected with BHN, a tunnel should be created to transmit PATH/RESV 361 message with HEAD_PROTECTION object. If tunnel is used, the 362 HEAD_PROTECTION object will be invisible to transit LSRs. [RFC2746] 363 describes transmission of RSVP messages over tunnels. 365 3.1.1. HEAD_PROTECTION for IPv4 address 367 Class-Num: TBD 368 C-Type: TBD 370 0 1 2 3 371 +-------------+-------------+-------------+-------------+ 372 | Length (bytes) | Class-Num | C-Type | 373 +-------------+-------------+-------------+-------------+ 374 | Protected_Head | 375 +-------------+-------------+-------------+-------------+ 376 | Backup_Head | 377 +-------------+-------------+-------------+-------------+ 378 | Flags | 379 +-------------+ 381 Protected_Head 383 IPv4 address identifying the RSVP-TE LSP Head node. Any stable 384 local address of the MHN can be used. 386 Backup_Head 388 IPv4 address identifying the LSR selected as BHN. Any stable local 389 address of the BHN can be used. 391 Flags 393 0x01(bit0): Head protection desired 395 0x02(bit1): Head protection available 397 Bit0 is the lowest bit of the octet. 399 3.1.2. HEAD_PROTECTION for IPv6 address 401 Class-Num TBD 403 C-Type TBD 404 0 1 2 3 405 +-------------+-------------+-------------+-------------+ 406 | Length (bytes) | Class-Num | C-Type | 407 +-------------+-------------+-------------+-------------+ 408 | Protected_Head | 409 +-------------+-------------+-------------+-------------+ 410 | Protected_Head (continued) | 411 +-------------+-------------+-------------+-------------+ 412 | Protected_Head (continued) | 413 +-------------+-------------+-------------+-------------+ 414 | Protected_Head (continued) | 415 +-------------+-------------+-------------+-------------+ 416 | Backup_Head | 417 +-------------+-------------+-------------+-------------+ 418 | Backup_Head (continued) | 419 +-------------+-------------+-------------+-------------+ 420 | Backup_Head (continued) | 421 +-------------+-------------+-------------+-------------+ 422 | Backup_Head (continued) | 423 +-------------+-------------+-------------+-------------+ 424 | Flags | 425 +-------------+ 427 Protected_Head 429 An IPv6 128bits unicast address identifying the RSVP-TE LSP Head 430 node. Any stable local address of the MHN can be used. 432 Backup_Head 434 An IPv6 128bits unicast address identifying the LSR selected as BHN. 435 Any stable local address of the BHN can be used. 437 Flags 439 0x01(bit0): Head protection desired 441 0x02(bit1): Head protection available 443 Bit0 is the lowest bit of the octet. 445 3.1.3. SESSION_ATTRIBUTE Flags 447 The current SESSION_ATTRIBUTE object has several flags defined in it 448 [RSVP_TE] and [TE_FRR]. To request head node protection the local 449 protection desired, SE style desired and node protection desired 450 flags should be set. 452 4. Behavior of MHN and BHN 454 The head-end (MHN) of an RSVP-TE P2MP LSP determines whether head 455 node protection is required and which LSR will be designated as 456 backup head node (BHN). How MHN selects an LSR as BHN is out of the 457 scope of this document. Manual configuration is an effective and 458 obvious choice. 460 MHN and BHN cooperate to setup the backup LSPs. To reduce the effect 461 on other LSRs on the path of the P2MP tunnel, from the view of MP, 462 BHN builds the backup LSP as if a link protection LSP between MHN and 463 MP is being created. 465 4.1. Behavior of MHN 467 If MHN decides to deploy head protection, all flags required for link 468 protection should be set when MHN sends PATH messages. If one-to-one 469 protection is desired, then MHN should include a FAST_REROUTE object 470 and set "one-to-one backup desired" flag. 472 There are two different procedures for MHN in head protection: 474 - Signaling BHN and building BHN-Detour. 476 - Revertive operation. After recovery from node failure, MHN should 477 re-build RSVP-TE P2MP LSPs after which revertive switching MAY 478 occur allowing MHN to assume its original role, i.e traffic is 479 again sourced from MHN onto the first segment of the protected LSP 480 and the use of BHN-Detour is discontinued. 482 4.1.1. Signaling BHN for Head Protection 484 To build a BHN-Detour to protect the MHN the BHN must get information 485 about the protected LSP. This includes: 487 - Unambiguous and unique identification of the protected LSPs 489 - Unique identification of the protected node ( MHN ) 491 - Whether bandwidth protection is desired 492 - Whether one-to-one protection or facility backup is desired. 494 - Knowledge of which LSRs are merge points (that is the second hop 495 LSRs of the P2MP LSP). 497 BHN obtains this information from MHN using a PATH message containing 498 the HEAD PROTECTION object defined in 3.1. 500 If MHN decides to deploy head protection and selects a LSR as BHN, it 501 MUST follow the behavior described bellow: 503 - MHN records each PATH message sent to its down stream LSRs. MHN 504 rebuilds PATH messages and inserts a HEAD PROTECTION object with 505 "head protection desired" flag set. MHN may merge several original 506 PATH messages into one PATH message to improve the efficiency, but 507 MHN must not the change the flags and objects in original PATH 508 messages. 510 - MHN should fill the "protected head" field in HEAD_PROTECTION 511 object with its own IP address, and fill "backup head" field with 512 BHN's IP address. 514 - MHN sends the PATH messages to BHN. If MHN and BHN are directly 515 connected, the PATH message can be directly, otherwise, it should 516 be sent through a tunnel. 518 - If a topology change changes the MP then MHN should send an update 519 PATH message to BHN immediately to indicate that fact. 521 MHN sends the PATH message containing HEAD_PROTECION object and 522 expects corresponding RESV message from BHN. After BHN has signaled 523 the backup path, a RESV message with HEAD_PROTECTION object will be 524 sent back to MHN by BHN as described in section 4.2.1. 526 4.1.2. Revert back to MHN from BHN Behavior 528 - With head protection, traffic sent from MHN will be replaced by 529 the traffic sent from BHN when MHN failure occurs. When MHN is 530 recovers from failure, MHN SHOULD be able take the charge of 531 sending traffic along the protected P2MP LSP again. The revertive 532 switch SHOULD occur after the RSVP-TE P2MP LSP has been re- 533 constructed. Some objectives are described here: 535 Objectives: 537 - All RSVP-TE P2MP LSPs being protected by BHN SHOULD be re- 538 constructed by MHN. 540 - LSPs reconstructed by MHN SHOULD have the same SESSION / 541 SESSION_TEMPLATE attributes as original LSPs. 543 - The revertive operation SHOULD be opaque to LSRs on the path of 544 RSVP-TE LSP except MHN, BHN and MPs. 546 - BHN SHOULD know the LSPs have been re-constructed and know when to 547 stop forwarding the traffic. 549 The detailed procedures will be defined in a later version of this 550 document. 552 4.2. Behavior of BHN 554 BHN is responsible for creating BHN-Detours to protect the head node 555 and play the role of head node during MHN failure. In addition the 556 BHN helps the MHN to re-construct protected LSPs after MHN recovers. 558 There are two different procedures for BHN: 560 - Signaling BHN-Detour and rerouting traffic for protection. 562 - Revertive Procedures. 564 4.2.1. Signaling BHN-Detour and Protection Procedures 566 As described in section 4.1.1, MHN periodically sends PATH messages 567 with HEAD_PROTECTION object to BHN. By processing the PATH messages 568 BHN identifies the protected P2MP LSP and calculates the backup LSP. 569 BHN must follow the behavior described bellow: 571 o Message handling: 573 - BHN MUST check the SESSION object in PATH message. If BHN receives 574 a PATH message with HEAD_PROTECTION Object from non-MHN LSR, it 575 indicates that the BHN is on the path of a protected tunnel. BHN 576 MUST discard this message and send a notification message (TBD) to 577 the sender. 579 - BHN MUST check the IP address in "backup head" in the 580 HEAD_PROTECION object. If the BHN does not have such an IP address, 581 BHN MUST send back notification to the BHN. 583 - After check the validity of PATH message, BHN processes the 584 objects in PATH message. BHN MUST record SESSION and 585 SESSION_TEMPLATE objects to identify protected LSP tunnels. BHN 586 also records all ERO/SERO and recognizes all MPs. 588 o Signaling BHN-Detour 590 - BHN can signal BHN-Detour in the way defined in [TE-FRR]. BHN can 591 use one-to-on backup or facility backup method. From the viewpoint 592 of the MPs, the backup LSP is used for link failure (MHN->MP) 593 protection. 595 - After the BHN-Detour is created, BHN send RESV message with "Head 596 protection available" flag set to MHN, which informs MHN that BHN- 597 Detour is ready. 599 o Protection action 601 - When BHN detects the MHN's node failure, BHN immediately forwards 602 packet through backup LSP to MPs. 604 - BHN MUST keep all attributes of the protected P2MP LSP. The 605 SESSION and SESSION_ATTRIBUTE objects MUST remain unchanged. 607 - BHN periodically sends PATH messages to all MPs to refresh the 608 state of protected LSP. The downstream LSRs are unaware of the 609 change. 611 4.2.2. Revertive Procedures for BHN 613 As described in 4.1.2 it SHOULD be possible for a MHN to resume its 614 normal role after recovery. Revertive switching from BHN to MHN will 615 be described in a future version of this document. 617 4.3. Protection Teardown 619 MHN can teardown head protection when necessary. 621 4.3.1. Protection Teardown 623 The teardown procedure must be initiated by MHN. 625 To initiate immediate explicit teardown MHN sends BHN a PATH Tear 626 message containing a HEAD_PROTECTION object. This PATH message may 627 contain SESSION and SESSION_TEMPLATE but no ERO/SERO objects. This 628 informs BHN that all related states of the protected LSP should be 629 removed. 631 5. Behavior of Merge Nodes 633 This document places no new requirements on MPs. MPs have the same 634 behaviors described in [TE-FRR] and [P2MP-TE]. 636 It should be noted that MPs may receive duplicate traffic during the 637 switching period from MHN to BHN (PM scenario), and vice versa. MP's 638 need to have the ability to robustly handle duplicate traffic; how 639 they do so is out of the scope of this document and is vendor 640 specific. 642 6. Behavior of All Other LSRs 644 Behavior of other LSRs should be unchanged. 646 7. Security Considerations 648 This document does not introduce new security issues. The security 649 considerations pertaining to the original [RSVP-TE-FRR] remain 650 relevant. 652 Note that the head protection method requires that MHN and selected 653 BHN trust RSVP messages received from each other. 655 8. IANA Considerations 657 TBD 659 9. Conclusions 661 Head node protection works not only for failure protection, but also 662 helps the SP with planned maintenance. Service interruption is caused 663 not only by network device failure but by administrative operation, 664 such as line card upgrade or software patch installation. With the 665 mechanisms described above, the SP can take LSP head end devices 666 offline for maintenance and provide uninterrupted service by 667 initiating a (manual) protection switch from MHN to BHN (and vice 668 versa). 670 10. Acknowledgments 672 We would like to thank Paul Doolan for his review and comments which 673 have helped to clarify this draft. 675 11. References 677 11.1. Normative References 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 [RSVP-TE] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP 683 Tunnels", RFC3209. 685 [RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to- 686 Multipoint Traffic-Engineered MPLS Label Switched Paths 687 (LSPs)", RFC4461. 689 [TE-FRR] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to 690 RSVP-TE for LSP Tunnels", RFC4090. 692 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, "Extensions to RSVP-TE 693 for Point to Multipoint TE LSPs", RFC4985. 695 Author's Addresses 697 Wei Cao 698 Huawei Technologies 699 Room 201R, Kuike building, Shangdi, 700 Haidian District of Beijing, P.R. China 701 Email: caowayne@huawei.com 703 Mach Chen 704 Huawei Technologies 705 Room 201R, Kuike building, Shangdi, 706 Haidian District of Beijing, P.R. China 707 Email: mach@huawei.com 709 Intellectual Property Statement 711 The IETF takes no position regarding the validity or scope of any 712 Intellectual Property Rights or other rights that might be claimed to 713 pertain to the implementation or use of the technology described in 714 this document or the extent to which any license under such rights 715 might or might not be available; nor does it represent that it has 716 made any independent effort to identify any such rights. Information 717 on the procedures with respect to rights in RFC documents can be 718 found in BCP 78 and BCP 79. 720 Copies of IPR disclosures made to the IETF Secretariat and any 721 assurances of licenses to be made available, or the result of an 722 attempt made to obtain a general license or permission for the use of 723 such proprietary rights by implementers or users of this 724 specification can be obtained from the IETF on-line IPR repository at 725 http://www.ietf.org/ipr. 727 The IETF invites any interested party to bring to its attention any 728 copyrights, patents or patent applications, or other proprietary 729 rights that may cover technology that may be required to implement 730 this standard. Please address the information to the IETF at 731 ietf-ipr@ietf.org. 733 Disclaimer of Validity 735 This document and the information contained herein are provided on an 736 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 737 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 738 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 739 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 740 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 741 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 743 Copyright Statement 745 Copyright (C) The IETF Trust (2007). 747 This document is subject to the rights, licenses and restrictions 748 contained in BCP 78, and except as set forth therein, the authors 749 retain all their rights.