idnits 2.17.1 draft-torvi-mpls-rsvp-ingress-protection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The abstract seems to contain references ([RFC4090]), 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 and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 9, 2012) is 4281 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) == Unused Reference: 'RFC2119' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 415, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group A. Atlas 3 Internet-Draft R. Torvi 4 Intended status: Standards Track M. Jork 5 Expires: January 10, 2013 Juniper Networks 6 July 9, 2012 8 Ingress Protection for RSVP-TE p2p and p2mp LSPs 9 draft-torvi-mpls-rsvp-ingress-protection-00 11 Abstract 13 Protection against node failure is important for RSVP-TE LSPs, 14 whether point-to-point or point-to-multipoint. While [RFC4090] 15 provides a mechanism for node protection, it does not specify how to 16 protect against failure of the ingress node. This document specifies 17 the RSVP extensions to support ingress node protection and describes 18 the necessary processing behavior. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 10, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Failure Detection Issues and Solution . . . . . . . . . . . . 4 56 3. Description of Behavior . . . . . . . . . . . . . . . . . . . 5 57 3.1. Ingress Node . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1.1. Required Configuration Information . . . . . . . . . . 5 59 3.1.2. Signaling Behavior . . . . . . . . . . . . . . . . . . 6 60 3.2. Backup Node . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2.1. Behavior for On-Forwarding-Path Backup Node . . . . . 7 62 3.2.2. Behavior for Off-Forwarding-Path Backup Node . . . . . 7 63 3.3. Merge Node . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.4. Global Repair . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. Ingress Revival and Administrative Switching . . . . . . . 9 66 4. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. INGRESS-PROTECTION object . . . . . . . . . . . . . . . . 9 68 5. Normative References . . . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 It is desirable to protect RSVP-TE LSPs, whether p2p or p2mp, against 74 ingress failure. To do this, a backup node must be pre-identified 75 and prepared with the necessary state so that it can forward traffic 76 when necessary. 78 Conceptually, a proxy ingress node is created that starts the RSVP 79 signaling. The explicit path of the LSP goes from the proxy ingress 80 node to the backup node and then to the real ingress node. The 81 behavior and signaling for the proxy ingress node is done by the real 82 ingress node. 84 The backup node must be only one logical hop away from the ingress, 85 whether that be via a direct link or a tunnel. 87 [ traffic source ] 88 | | 89 | | 90 | | 91 [ proxy ingress ] [ backup ] 92 [ & ingress ] | 93 | | 94 |----[ MP ]----| 96 Figure 1: Example Protected LSP with Proxy Ingress Node 98 There are three different scenarios that this document addresses for 99 ingress protection. All three can be handled using the same set of 100 signaling defined in this document. 102 A. Traffic Source detects failure The traffic source(s) can rapidly 103 determine that the ingress has failed and switch over to sending 104 traffic to the backup node. When this mode is specified, the 105 backup node will forward any appropriately received traffic along 106 its bypass tunnel to the merge point(s). 108 B. MP detects failure The traffic source(s) always send traffic to 109 both the ingress and backup nodes. The backup node always 110 forwards traffic along its bypass tunnel to the merge point(s). 111 Each MP determines whether the ingress node has failed and, if so, 112 switches over to accepting the traffic from the backup node. 114 C. Backup detects failure The traffic source(s) always send traffic 115 to both the ingress and backup nodes. The backup node does not 116 forward the received traffic from the traffic source under normal 117 conditions. When the backup node determines that the ingress node 118 has failed, the backup node starts forwarding the traffic alongs 119 its bypass tunnel(s) to the merge point(s). 121 For all three scenarios, it is necessary for the backup node to know 122 the merge point(s) and associated MPLS labels. This is accomplished 123 by having the RSVP Path and RESV messages go through the backup node, 124 although the forwarding path need not go through the backup node. 125 There are two cases of interest - on-forwarding-path and off- 126 forwarding-path. In the on-forwarding-path case, the backup node is 127 already the immediate node after the ingress node for the LSP. In 128 the off-forwarding-path, the backup node is not the immediate node 129 after the ingress node for all asociated sub-LSPs. 131 For ingress protection to be functional, the backup node must have 132 access and knowledge of the appropriate traffic to send into the 133 protected LSP. The ingress node must be capable of describing the 134 traffic to the backup node. 136 Once the backup node has the necessary state for the LSP, including 137 the set of merge points, the backup node can use bypass tunnels as 138 described in [RFC4090]. If the LSP is a point-to-multipoint, then 139 the backup node has the option of choosing to use a bypass p2mp 140 tunnel for protection. 142 Finally, an assumption of local protection is that a global repair 143 mechanism will occur to replace the patched LSP with a new fully 144 functional one. To do this, it is necessary that the backup node be 145 able to enact a global repair that still allows sharing of bandwidth 146 resources between the old and new LSPs. 148 2. Failure Detection Issues and Solution 150 For each of the different scenarios, the details of detecting an 151 ingress node failure can vary. This document does not specify the 152 details of how to do so, but it is possible using either approriately 153 routed BFD sessions or direct link information. 155 For traffic-source detection and fail-over, the traffic source can 156 merely monitor the state of the direct links over which traffic is 157 sent to the ingress. 159 For MP detection, the MP can be configured with the appropriate BFD 160 discriminators used on the BFD sessions. It is desirable for the MP 161 to know that the ingress can't send traffic to the MP or downstream 162 (for when the ingress is protecting against the MP failure). The 163 appropriate BFD discriminators will vary by MP; they are not signaled 164 in the RSVP extensions described in this draft. 166 For backup node detection, the backup node can be configured with the 167 appropriate BFD discriminators used on the BFD sessions. Again, they 168 are not signaled in the RSVP extensions described in this draft. 170 3. Description of Behavior 172 3.1. Ingress Node 174 3.1.1. Required Configuration Information 176 The ingress node must be configured with four pieces of information 177 for these extensions to work. 179 Backup Node Address The ingress node must know an IP address for the 180 backup node that can be included in the ERO. 182 Protection Scenario The ingress node must know whether the traffic 183 source, backup node, or merge point(s) will be responsible for 184 handling fail-over. 186 Ingress-Protector-Context-Id The Ingress-Protector-Context-Id is 187 used for the Extended Session ID in ingress-protected LSPs instead 188 of using the ingress node's loopback address. The Ingress- 189 Protector-Context-Id should not be the same as another address 190 associated with a router that may signal TE LSPs. By having an 191 Ingress-Protector-Context-Id, the backup node can perform global 192 repair. 194 Application Traffic Identifier The ingress and backup node must both 195 know what application traffic should be directed into the LSP. A 196 commonly understood Application Traffic Identifier is sent between 197 the ingress and backup nodes in RSVP signaling. The exact meaning 198 of the identifier should be configured similarly at both the 199 ingress and backup nodes. The Application Traffic Identifier is 200 understood within the unique context of the Ingress-Protector- 201 Context-Id. 203 With this additional information, the ingress node can create and 204 signal the necessary RSVP extensions to support ingress protection. 206 3.1.2. Signaling Behavior 208 The ingress node is responsible for starting the RSVP signaling for 209 the proxy-ingress node. To do this, the following is done for the 210 RSVP Path message. 212 1. Compute the EROs for the LSP as normal for the ingress. 214 2. If the selected backup node is not the first node on the path 215 (for all sub-LSPs), then insert at the beginning of the ERO first 216 the backup node and then the ingress node. 218 3. Change the IPv4 tunnel sender address in the Sender Template 219 Object to be that of the Ingress-Protector-Context-Id. 221 4. In the Path RRO, instead of recording the ingress node's address, 222 replace it with the Ingress-Protector-Context-Id. 224 5. Leave the HOP object populated as usual with information for the 225 ingress-node. 227 6. Add the INGRESS-PROTECTION object to the Path message. Allocate 228 a second LSP-ID to be used in the INGRESS-PROTECTION object. 230 7. The RSVP Path message is sent to the backup node as normal. 231 Since the backup node must be only one logical hop away from the 232 ingress, normal RSVP signaling can be used. 234 When the backup node is off the forwarding path, there are additional 235 behaviors for the ingress node to do when it is handling the 236 associated PATH and RESV messages. 238 When the ingress node receives an RSVP Path message with an INGRESS- 239 PROTECTION object and the object specifies that node as the ingress 240 node and the PHOP as the backup node, the ingress node SHOULD check 241 the Failure Scenario specified in the INGRESS-PROTECTION object and, 242 if it is not the "MP detects failure" scenario, then the ingress node 243 SHOULD remove the INGRESS-PROTECTION object from the PATH message 244 before sending it out. Additionally, the ingress node must store 245 that it will install ingress forwarding state for the LSP rather than 246 midpoint forwarding. 248 When an RSVP RESV message is received by the ingress, it uses the 249 NHOP to determine whether the message is received from the backup 250 node or from a different node. The stored associated PATH message 251 contains an INGRESS-PROTECTION object that identifies the backup 252 node. If the RESV message is not from the backup node, then ingress 253 forwarding state should be set up, and the INGRESS-PROTECTION object 254 MUST be added to the RESV before it is sent to the NHOP, which should 255 be the backup node. If the RESV message is from the backup node, 256 then the LSP should be considered available for use. 258 If the backup node is on the forwarding path, then a RESV is received 259 with an INGRESS-PROTECTION object and an NHOP that matches the backup 260 node. In this case, the ingress node's address will not appear after 261 the backup node in the RRO. The ingress node should set up ingress 262 forwarding state, just as is done if the LSP weren't ingress-node 263 protected. 265 3.2. Backup Node 267 An LER determines that the LSP is ingress-protected based upon the 268 presence of the INGRESS-PROTECTION object in the PATH message. An 269 LER can further determine that it is the backup node if one of its 270 addresses is listed as the backup node in the INGRESS-PROTECTION 271 object. 273 3.2.1. Behavior for On-Forwarding-Path Backup Node 275 If the backup node is on the forwarding path, then the backup node 276 MUST remove the INGRESS-PROTECTION object from the PATH message 277 before forwarding it. 279 If the failure scenario is either "MP-detected" or "Backup-detected", 280 then the backup node is responsible for determining if the ingress 281 node has failed and forwarding the identified traffic from the 282 traffic source(s) to the next-hop(s) on the LSP instead of forwarding 283 the traffic from the ingress node. 285 When the backup node receives a RESV message, it should add back in 286 the INGRESS-PROTECTION object before forwarding it. 288 3.2.2. Behavior for Off-Forwarding-Path Backup Node 290 When the backup node receives a PATH message with the INGRESS- 291 PROTECTION object, the backup node examines the INGRESS-PROTECTION 292 object to learn what traffic associated with the LSP and what failure 293 scenario is being used. The backup node forwards the PATH message to 294 the ingress node with the normal RSVP changes. 296 When the backup node receives a RESV message with the INGRESS- 297 PROTECTION object, the backup node records an IMPLICIT-NULL label in 298 the RRO. The backup node creates the appropriate forwarding state 299 for the failure scenario specified. For the "MP-detected" and 300 "traffic-source-detected", this means that backup node forwards any 301 received identified traffic into the bypass tunnel(s) to the merge 302 point(s). For the "backup-detected", this means that the backup node 303 creates state to quickly determine the ingress has failed and switch 304 to sending any received identified traffic into the bypass tunnel(s) 305 to the merge point(s). Then the backup node forwards the RESV 306 message to the ingress node, which is acting for the proxy ingress. 308 If the backup node doesn't have a bypass tunnel to a merge point, 309 then the backup node can wait to send the RESV until such has been 310 created or it can send a Path Err with an Error Code of "Routing 311 Problem (24)" and a new Error Value sub-code of "No Bypass Tunnel to 312 Merge Point (TBD)". 314 3.3. Merge Node 316 An LSR that is serving as a Merge Node may need to support the 317 INGRESS-PROTECTION object and functionality defined in this 318 specification if the LSP is ingress-protected where the failure 319 scenario is "MP-detected". An LSR can determine that it must be a 320 merge point by examining the INGRESS-PROTECTION object and 321 determining that it is neither the ingress node nor the backup node 322 and the PHOP is the ingress node. 324 In that case, when the LSR receives a PATH message with an INGRESS- 325 PROTECTION object, the LSR MUST remove the INGRESS-PROTECTION object 326 before forwarding on the PATH message. 328 If the failure scenario specified is "MP-detected", the MP must 329 connect up the fast-failure detection (as configured) to accepting 330 backup traffic received from the backup node. There are a number of 331 different ways that the MP can enforce not forwarding traffic 332 normally received from the backup node. For instance, first, any 333 LSPs set up from the backup node should not be signaled with an 334 IMPLICIT NULL label and second, the associated label for the ingress- 335 protected LSP could be set to normally discard inside that context. 337 When the MP receives a RESV message whose matching PATH state had an 338 INGRESS-PROTECTION object, the MP SHOULD add the INGRESS-PROTECTION 339 object to the RESV message before forwarding it. 341 3.4. Global Repair 343 When the backup node learns the ingress node has failed (e.g. via the 344 IGP), then the backup node can compute new ERO(s) and signal the new 345 LSP so that it no longer relies upon local repair. To do this, the 346 backup node uses the same Ingress-Protector-Context-Id as the Ipv4 347 tunnel sender address in the Sender Template Object and uses the 348 previously allocated second LSP-ID signaled in the INGRESS-PROTECTION 349 object. This allows the new LSP to share resources with the old LSP. 351 3.5. Ingress Revival and Administrative Switching 353 In a future version, it is intended to describe the behavior when the 354 ingress node comes back and how to handle management-triggered 355 switches from ingress to backup node and vice versa. 357 4. RSVP Extensions 359 4.1. INGRESS-PROTECTION object 361 Class-Num = TBD 362 C-Type = TBD 364 0 1 2 3 365 +-------------+-------------+-------------+-------------+ 366 | Length (bytes) | Class-Num | C-Type | 367 +-------------+-------------+-------------+-------------+ 368 | Backup Node Address | 369 +-------------+-------------+-------------+-------------+ 370 | Ingress Node Address | 371 +-------------+-------------+-------------+-------------+ 372 | Application Traffic Identifier | 373 +-------------+-------------+-------------+-------------+ 374 | Secondary LSP ID | Protection | Flags | 375 | | Scenario | | 376 +-------------+-------------+-------------+-------------+ 378 Figure 2: INGRESS-PROTECTION object 380 Backup Node Address 382 Ingress Node Address 384 Application Traffic Identifier 386 Ingress-Protector-Context-Id 388 Secondary LSP ID 390 Protection Scenario Indicates if (1) traffic source(s), (2) backup 391 node, (3) or merge point(s) will handle the fail-over. 393 Control Flags Backup sent flags: (0x01)Ingress-Protection in-use, 394 (0x02)Ingress Detected Down, (0x04)Admin Override caused Ingress- 395 Protection-in-use. Ingress sent flags: (0x08)Revert Control to 396 Ingress, (0x10)Force control to Backup 398 5. Normative References 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 404 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 405 Functional Specification", RFC 2205, September 1997. 407 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 408 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 409 Tunnels", RFC 3209, December 2001. 411 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 412 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 413 May 2005. 415 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 416 "Extensions to Resource Reservation Protocol - Traffic 417 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 418 Switched Paths (LSPs)", RFC 4875, May 2007. 420 Authors' Addresses 422 Alia Atlas 423 Juniper Networks 424 10 Technology Park Drive 425 Westford, MA 01886 426 USA 428 Email: akatlas@juniper.net 430 Raveendra Torvi 431 Juniper Networks 432 10 Technology Park Drive 433 Westford, MA 01886 434 USA 436 Email: rtorvi@juniper.net 437 Markus Jork 438 Juniper Networks 439 10 Technology Park Drive 440 Westford, MA 01886 441 USA 443 Email: mjork@juniper.net