idnits 2.17.1 draft-haskin-mpls-fast-reroute-05.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 68 lines 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 345 has weird spacing: '... backed up. I...' -- 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 2000) is 8534 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: '1' is defined on line 411, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 414, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '2') Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Dimitry Haskin 3 Internet Draft Ram Krishnan 4 Expires: May 2001 Axiowave Networks 6 November 2000 8 A Method for Setting an Alternative Label Switched Paths 9 to Handle Fast Reroute 11 draft-haskin-mpls-fast-reroute-05.txt 13 Status 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes a method for setting up an alternative label 38 switched path to handle fast reroute of traffic upon a failure in a 39 primary label switched path in Multi-protocol Label Switching (MPLS) 40 network. 42 Table of Contents 44 1. Introduction.....................................................2 45 2. Alternative Path Arrangement.....................................3 46 3. 1:1 protection...................................................6 47 4. 1:N protection...................................................6 48 5. Restoration Shortcuts............................................7 49 6. Elementary link level protection scheme..........................8 50 7. Bandwidth Reservation Considerations.............................8 51 8. Intellectual Property Considerations.............................9 52 9. Acknowledgments..................................................9 53 10. References.......................................................9 54 11. Authors' Addresses...............................................9 56 1. Introduction 58 The ability to quickly reroute traffic around a failure or 59 congestion in a label switched path (LSP) can be important in 60 mission critical MPLS networks. When an established label switched 61 path becomes unusable (e.g. due to a physical link or switch 62 failure) data may need to be re-routed over an alternative path. 63 Such an alternative path can be established after a primary path 64 failure is detected or, alternatively, it can be established 65 beforehand in order to reduce the path switchover time. 67 Pre-established alternative paths are essential where packet loss 68 due to an LSP failure is undesirable. Since it may take a 69 significant time for a device on a label switched path to detect a 70 distant link failure, it may continue sending packets along the 71 primary path. As soon as such packets reach a switch that is aware 72 of the failure, packets must be immediately rerouted by the switch 73 to an alternative path away from the failure if loss of data is to 74 be avoided. Since it is impossible to predict where failure may 75 occur along an LSP tunnel, it might involve complex computations and 76 extensive signaling to establish alternative paths to protect the 77 entire tunnel. In the extreme, to fully protect an LSP tunnel, 78 alternative paths might be established at each intermediate switch 79 along the primary LSP. 81 This document defines a method for setting alternative label 82 switched paths with the objective to provide a single failure 83 protection in such a manner that facilitates quick restoration 84 comparable to 50 milliseconds provided in SONET self-healing rings 85 and at the same time minimizes alternative path computation 86 complexity and signaling requirements. It also can provide in-band 87 means for quick detection of link and switch failures or congestion 88 along a primary path without resorting to an out of band signaling 89 mechanism. Both one-to-one (1:1) protection and many-to-one (1:N) 90 protection can be achieved with the proposed approach as described 91 in this document. 93 In order for the presented method to work, it is important that 94 network topology and policy allow the establishment of a backup LSP 95 between the endpoint switches of the protected LSP tunnel such that, 96 with the exception of the tunnel endpoint switches, the backup LSP 97 does not share any resources with the path that it intends to 98 protect. 100 The fast reroute support can be facilitated with additional 101 extensions incorporated in the MPLS signaling protocols such as RSVP 102 or CR-LDP. These extensions are not defined in this document. 104 2. Alternative Path Arrangement 106 The main idea behind the presented method is to reverse traffic at 107 the point of failure of the protected LSP back to the source switch 108 of the protected LSP such that the traffic flow can be then 109 redirected via a parallel LSP between source and destination 110 switches of the protected LSP tunnel. 112 Referring to Figure 1, there is an MPLS network consisting of 7 113 interconnected switches. 115 Figure 1: 117 +--------+ 24 +--------+ 46 +--------+ 118 +-->| Switch |------->| Switch |------->| Switch |---+ 119 : | 2 |--------| 4 |--------| 6 | : 120 : | | | | | | : 121 12 : +--------+ +--------+ +--------+ : 67 122 : / / / \ : 123 : / / / \ V 124 +--------+ 31 +--------+ 53 +--------+ 75 +--------+ 125 | Switch |<-------| Switch |<-------| Switch |<......| Switch | 126 | 1 |--------| 3 |--------| 5 |-------| 7 | 127 =>| |=======>| |=======>| |======>| |=> 128 +--------+ 13 +--------+ 35 +--------+ 57 +--------+ 130 The following terminology is used for purpose of describing the 131 method: 133 A portion of a label switched path that is to be protected by an 134 alternative path is referred as 'protected path segment'. Only 135 failures within the protected path segment, which may include the 136 entire primary path, are subject to fast reroute to the alternative 137 path. A primary LSP between switches 1 and 7 is shown by a double- 138 dashed links labeled 13, 35, and 57. Arrows indicate direction of 139 the data traffic. 141 The switch at the ingress endpoint of the protected path segment is 142 referred as 'the source switch'. Switch 1 in Figure 1 is the source 143 switch in our example of a protected path. 145 The switch at the egress endpoint of the protected path segment is 146 referred as 'the destination switch'. Switch 7 in Figure 1 is the 147 destination switch in our example of a protected path. 149 The switches between the source switch and the destination switch 150 along the protected path are referred as protected switches. 152 The switch immediately preceding the destination switch along the 153 protected path segment is referred as the last hop switch. Switch 5 154 in Figure 1 is the last hop switch for the protected path. 156 The essence of the presented method is that an alternative 157 unidirectional label switched path is established in the following 158 way: 160 The initial segment of the alternative LSP runs between the last 161 hop switch and the source switch in the reverse direction of the 162 protected path traversing through every protected switch between 163 the last hop switch and the source switch. The dashed line between 164 switches 5 and 1 illustrates such a segment of the alternative 165 path. Alternatively, the initial LSP segment can be set from the 166 destination switch to the source switch in the reverse direction 167 of the protected path traversing through every protected switch 168 between the destination switch and the source switch. The dashed 169 line between switches 7 and 1 illustrates the initial path segment 170 that is set in this way. 172 The second and final segment of the alternative path is set 173 between the source switch and the destination switch along a 174 transmission path that does not utilize any protected switches. It 175 is not an intention of this document to specify procedures for 176 calculating such a path. The dashed line between Switches 1 and 7 177 through Switches 2, 4, and 6 illustrates the final segment of the 178 alternative path. 180 The initial and final segments of the alternative path are linked to 181 form an entire alternative path from the last hop switch to the 182 destination switch. In Figure 1 the entire alternative path consists 183 of the LSP links labeled 53, 31, 12, 24, 46, and 67 if the 184 alternative path originates at the last hop switch. Alternatively, 185 the entire alternative path consists of the LSP links labeled 75, 186 53, 31, 12, 24, 46, and 67 if the alternative path originates at the 187 destination switch of the primary path. 189 As soon as a failure along the protected path is detected, an 190 operational switch at the ingress of the failed link reroutes 191 incoming traffic around the failure or congestion by redirecting 192 this traffic into the alternative LSP traversing the switch in the 193 reverse direction of the primary LSP according to the procedures 194 described in the following sections of the document. 196 The presented method of setting the alternative label switched path 197 has the following benefits: 199 - Path computation complexity is greatly reduced. Only a single 200 additional path between the source and destination switches of 201 the protected path segment needs to be calculated. Moreover, 202 both primary and alternative path computations can be localized 203 at a single switch avoiding problems that can arise when 204 computations are distributed among multiple switches. 206 - The amount of LSP setup signaling is minimized. With small 207 extensions to RSVP or LDP (described in separated documents), a 208 single switch at ingress of the protected path can initiate 209 label allocations for both primary and alternative paths. 211 - Optionally, presence of traffic on the alternative path segment 212 that runs in the reverse direction of the primary path can be 213 used as an indication of a failure or congestion of a downstream 214 link along the primary path. As soon as the source switch 215 detects the reverse traffic flow, it may stop sending traffic 216 downstream of the primary path and start sending data traffic 217 directly along the final alternative path segment. 219 It is fair to note that this technique increases the likelihood 220 of data packet reordering during the path rerouting process. 221 Therefore benefits of the reducing the alternative path latency 222 should be weighed against possible problems associated with 223 short term packet reordering. On a positive side, if multiple 224 microflows are aggregated in a single protected LSP tunnel, only 225 a very limited number of microflows may be affected by such 226 packet reordering. Additionally, the impact of reordering on any 227 single microflow may be minimal. 229 The described in-band signaling of an LSP failure to the source 230 switch does not exclude other methods of propagating an error 231 condition back to the source. 233 It also can be noted that if the alternative label switched path is 234 originated at the destination switch of the primary path, it forms a 235 'loop-back' LSP that originates and terminates at this switch. 236 Therefore in this case it is possible to verify integrity of the 237 entire alternative path by simply sending a probe packet from the 238 destination switch along the alternative path and asserting that the 239 packet arrives back to the destination switch. When this technique 240 is used to assert the path integrity, the care must be taken that 241 the limited diagnostic traffic is not interpreted as an indication 242 of a primary path failure that triggers data rerouting at the source 243 switch. 245 3. 1:1 protection 247 If the 1:1 path protection is desired, an individual backup LSP is 248 set for each LSP that needs to be protected as described in section 249 2. When a switch detects that a downstream link has failed, it 250 simply splices the traffic onto the alternative LSP. Referring to 251 Figure 1, if the link between the Switch 3 and Switch 5 fails, 252 Switch 3 accomplishes the fast reroute by swapping the incoming MPLS 253 label 13 of the primary path with the outgoing MPLS label 31 of the 254 alternative path. In this example the primary and alternative paths 255 are linked at Switch 3 forming the following label switched path for 256 the traffic flow: 13->31->12->24->46->67. 258 4. 1:N protection 260 In the case of the 1:N protection a single alternative path can be 261 used for protection of more than one LSP between the same source and 262 destination switches. The difference in rerouting LSPs the 1:N 263 protection case is that, rather than splicing protected traffic into 264 the alternative LSP, it may be necessary to use the MPLS label 265 stacking to tunnel protected traffic via the backup LSP to the 266 destination switch as described below. 268 A switch detecting failure of a downstream link, first swaps the 269 incoming MPLS label of each protected LSP with the respective 270 incoming label that identifies that LSP at the destination switch 271 and then pushes the outgoing label of the backup LSP to the top of 272 the forwarded MPLS packets. In essence, the protected MPLS packets 273 are encapsulated inside of the backup LSP and emerge at the backup 274 tunnel tail at the egress switch with their respective labels known 275 to that switch. 277 Referring to Figure 1 and assuming that global label space is used 278 at the destination switch, if the link between the Switch 3 and 279 Switch 5 fails, Switch 3 swaps incoming MPLS label 13 of the 280 protected LSP with label 57 (incoming label at Switch 7) and then 281 encapsulates the resulting packet into the backup tunnel by pushing 282 label 31 to the top of the forwarded MPLS packets. 284 Needless to say in order for this scheme to work, each router in the 285 protected path must be aware what labels are used at the egress LSR 286 for each protected LSP. Such knowledge can be propagated with the 287 appropriate extensions incorporated into signaling protocols such as 288 RSVP or CR-LDP. 290 A single segment of a tunnel between source and destination switches 291 can be used to protect multiple LSP segments that originate and 292 terminate on these switches as long as this segment of the backup 293 tunnel is completely disjoint from each protected LSP segment except 294 for the source and destination switches. In such a case the reverse 295 segments of backup path merge into the disjoint segment of the 296 backup path at the source switch of the protected LSPs as 297 illustrated in Figure 2. In Figure 2, dashed lines represent 298 protected LSPs and double-dashed lines represent backup LSP tunnels. 300 Figure 2: 302 +--+ +---+ +--+ 303 | |=======>|LSR|========>|D | 304 | | +---+ |E | 305 | | +---+ +---+ |S | 306 | S|<===| |<===| |<===|T | 307 | O|--->|LSR|---> LSR|--->|I | 308 | U| +---+ +---+ |N | 309 | R| |A | 310 | C| +---+ +---+ |T | 311 | E|<===| |<===| |<===|I | 312 | |--->|LSR|--->|LSR|--->|O | 313 | | +---+ +---+ |N | 314 +--+ +--+ 316 5. Restoration Shortcuts 318 Some types of applications require bounded end-to-end transmission 319 delays to deliver useful services. A notable example is the Voice 320 over IP (VoIP) service which requires end-to-end delays that do not 321 exceed 400 ms for an acceptable level of service. VoIP is also a 322 prime candidate for the fast reroute services. Since most of the 323 voice codecs in use today operate in the range of 20-50 ms latency, 324 the network component is left with around 300 ms of the end-to-end 325 delay limit. 327 Given the above considerations, it is important that, when 328 restoration provisions are made for a delay sensitive service, 329 transmission delays over an alternative path would not exceed an 330 acceptable limit. Since a number of the current network providers 331 are capable to guarantee network transport delay that do not exceed 332 80 ms on their backbone, it appears that in some cases it will be 333 possible to use the proposed restoration technique with a single 334 alternative path. It allows for at most 200 ms round trip delay over 335 a reverse path segment plus at most 100 ms delay over a disjoint 336 backup path segment. However in other cases it may be necessary to 337 introduce restoration shortcuts as described below to satisfy the 338 VoIP latency requirement during restoration. 340 Restoration shortcuts are achieved by allowing selected transit 341 routers in the primary LSP to establish one or more 'shortcut' 342 alternative LSPs to the egress router as illustrated in Figure 3. In 343 this illustration, primary link failures that may occur downstream 344 of LSR B are rerouted over the shortcut LSP from LSR B to the 345 destination of LSP being backed up. In illustrated example the 346 shortcut LSP merges into the backup LSP at LSR D. 348 Figure 3: 350 +--+ +---+ +--+ 351 | |------------>|LSR|------------>|D | 352 | | | D | |E | 353 | S| +---+ |S | 354 | O| ^ |T | 355 | U| | |I | 356 | R| | |N | 357 | C| +---+ +---+ +---+ |A | 358 | E|<---|LSR|<---|LSR|<---|LSR|<---|T | 359 | |===>| A |===>| B |===>| C |===>|I | 360 | | +---+ +---+ +---+ |O | 361 | | |N | 362 +--+ +--+ 364 6. Elementary link level protection scheme 366 If only link-level protection is desired, an alternative path 367 between link endpoints can be set up to protect each link. Such a 368 scheme can be viewed as a degenerate case of this proposal in which 369 the link endpoints constitute the source and destination endpoints 370 in the described approach. 372 7. Bandwidth Reservation Considerations 374 Generally there is no need to exclusively allocate bandwidth 375 resources to the alternate LSP. The holding priority of the primary 376 LSP can be used as traffic-triggered resource preemption priority 377 for the alternate LSP in case the primary LSP fails and traffic is 378 switched to the alternate LSP as described in this document. What we 379 call here the traffic-triggered priority is the preemption priority 380 assigned to an LSP that is utilized only when there is traffic 381 present on that LSP. When there is no traffic, other LSPs sharing 382 the interface should get full access to bandwidth and other system 383 resources. Consequently, if the traffic-triggered priority of the 384 alternative LSP is greater than the holding priorities of the other 385 LSPs using an interface in the alternate path, the alternate LSP can 386 preempt bandwidth and other system resources as soon as traffic gets 387 rerouted via the alternate LSP. This enables high-priority LSPs, 388 which are being rerouted, to preempt resources from lower priority 389 LSPs without explicit bandwidth reservation for the alternate path. 390 Of course, if bandwidth efficiency is not an issue, bandwidth 391 resources can be explicitly reserved for the alternate LSP also. 393 An extension to existing signaling protocols such as RSVP and LDP 394 may be needed to indicate that traffic-triggered resource preemption 395 is requested for a particular LSP as opposed to the setup priority 396 preemption. 398 8. Intellectual Property Considerations 400 IETF has been informed of possible intellectual property protection 401 for some or all of the technologies disclosed in this document. 403 9. Acknowledgments 405 This document has benefited from discussions with Jim Boyle, Robert 406 Boyd, and Alan Hannan. We also thank Ken Schroder, Jeff Parker and 407 Yanhe Fan for their comments on the document. 409 10. References 411 [1] Rosen, E. et al., "Multiprotocol Label Switching Architecture", 412 Internet Draft, draft-ietf-mpls-arch-07.txt, July 2000. 414 [2] Awduche, D. et al., "Requirements for Traffic Engineering over 415 MPLS", RFC-2702. 417 11. Authors' Addresses 419 Dimitry Haskin 420 Axiowave Networks, Inc. 421 100 Nickerson Road 422 Marlborough, MA 01752 423 E-mail: dhaskin@axiowave.com 425 Ram Krishnan 426 Axiowave Networks, Inc. 427 100 Nickerson Road 428 Marlborough, MA 01752 429 E-mail: ram@axiowave.com