idnits 2.17.1 draft-lu-fast-notification-framework-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4932 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) == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-ipfrr-notvia-addresses-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG W. Lu 3 Internet-Draft A. Tian 4 Intended status: Standards Track S. Kini 5 Expires: April 21, 2011 Ericsson 6 October 18, 2010 8 Fast Notification Framework 9 draft-lu-fast-notification-framework-00 11 Abstract 13 This document describes an architectural work that competes with the 14 IP Fast Re-Route (IPFRR) solution which aims to minimize the network 15 down time in the event of equipments failure. The work provides a 16 layered framework based upon which applications such as the domain- 17 wide fast convergence may be achieved through the transport layer 18 fast delivery of failure notifications. 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 April 21, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Event Framework . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Layered Structure . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Failure detection . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Notification Origination . . . . . . . . . . . . . . . . . 6 62 4.2.1. IGP PDU . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2.2. Uniform Message . . . . . . . . . . . . . . . . . . . 7 64 4.3. Fast Flooding . . . . . . . . . . . . . . . . . . . . . . 7 65 4.4. Notification Receiving and Handling . . . . . . . . . . . 8 66 4.5. Routing/Forwarding Table Update . . . . . . . . . . . . . 8 67 5. Convergence Analyses . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. Definition of Convergence Time . . . . . . . . . . . . . . 8 69 5.2. Domain Wide Convergence . . . . . . . . . . . . . . . . . 8 70 5.3. Micro-looping . . . . . . . . . . . . . . . . . . . . . . 9 71 5.4. Packet Reordering . . . . . . . . . . . . . . . . . . . . 10 72 6. Scalability Analyses . . . . . . . . . . . . . . . . . . . . . 10 73 7. Traffic Analyses . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The ability to recover rapidly from network failures is one of the 85 most sought network characteristics. Few solutions address this 86 issue to the satisfactory. 88 IPFRR [RFC5714] is one such solution. It mimics MPLS-FRR [RFC4090] 89 solution. The difference is that the MPLS-FRR is path based, or 90 source routing based in other words. This implies that the re-route 91 decision can be carried out by the PLR (point-of-local-repair) router 92 alone, with no need of cooperation of other LSRs in the network. 94 Unfortunately, IP based FRR is by nature not source routing based. 95 Its re-route decision may not be honored by other routers in the 96 network. The consequence can be very severe, either traffic outage 97 or even routing loops. 99 Many methods were proposed around IPFRR concept but none is close to 100 be satisfactory. Some methods such as LFA described in [RFC5286] 101 require lot of computation and have coverage issue. Some others such 102 as Not-Via [I-D.ietf-rtgwg-ipfrr-notvia-addresses] are extremely 103 complicated and are prohibitive to be useful. 105 The primary reason for such difficulties can be understood from the 106 following passage which is quoted from [RFC5714] first paragraph of 107 section 1: 109 However, there is an alternative approach, which is to compute backup 110 routes that allow the failure to be repaired locally by the router(s) 111 detecting the failure without the immediate need to inform other 112 routers of the failure. 114 The phrase "without the immediate need to inform other routers of the 115 failure" is against the very nature of the IP network in which the 116 domain-wide synchronization is the key. 118 In this document we propose a method which directly addresses the 119 rapid network synchronization needs. It is not IPFRR based. However 120 it can achieve the same or better result without much complexity and 121 compromise. 123 The method lays out a framework which decouples the improvement in 124 the forwarding plane from the control plane. The design also allows 125 and promotes future innovations based upon the framework. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 1.2. Acronyms 135 FRR - Fast Re-Route 137 IPFRR - IP Fast Re-Route 139 MPLS - Multi-Protocol Label Switch 141 LFA - Loop Free Alternative 143 TLV - Type Length Value tuple 145 IGP - Interior Gateway protocol 147 OSPF - Open Shortest Path First 149 IS-IS - Intermediate System to Intermediate System 151 PDU - Protocol Data Unit 153 DoS - Denial of Service 155 FNF - Fast Notification Framework 157 2. Event Framework 159 An event framework is introduced for the purpose of rapid 160 disseminating of events to all interested receivers in a network. 162 The framework is application independent. Many applications can 163 generate the events and/or register to receive the events. A TLV 164 based framework is proposed to ensure separation between application 165 and the delivery framework. 167 The event framework is also independent of the underlying delivery 168 mechanisms. Different delivery mechanisms may be introduced, each 169 with different properties suitable for different requirements. For 170 example, some delivery mechanism is solely optimized for simplicity; 171 while other may improve on reliability. 173 One of the use cases of this event framework is Fast Failure 174 Notification, which can be used to improve network convergence time. 175 When a failure occurs in a network, routers adjacent to the failure 176 can detect it and quickly disseminate the failure notifications to 177 other routers throughout the area. Routing protocols on different 178 routers can register and receive such failure notifications, then 179 quickly react to the failure to achieve fast convergence. 181 The routing protocols discussed in this work are Interior Gateway 182 Protocols (IGP) with the focus on the Link State Routing Protocols 183 such as Open Shortest Path First [RFC2328] and Intermediate System to 184 Intermediate System [RFC1195] [ISO.10589.1992]. 186 The event in the scope of this architecture is specifically the link- 187 down event or node-down event. The up events are not fast flooded 188 for the sake of network stability. 190 3. Layered Structure 192 The framework can be viewed as a layered structure in which various 193 routing functions can be rearranged. This arrangement is based on 194 the principle of separation of functions. It will facilitate the 195 innovation in various component building blocks and in the mean while 196 allow them to integrate in a systematic manner. 198 There are two layers that make the framework. One is for routing 199 protocol specific functionality. The other is the data transport 200 layer. Figure 1 depicts this concept. 202 APPLICATION |-----| |-----| |-----| 203 | | | | | | 204 |-----| |-----| |-----| 205 ^ ^ ^ 206 | | | 207 ----------------------------------------- 208 | | | 209 v v v 210 TRANSPORT |-----| |-----| |-----| 211 | |<->| |<->| | 212 |-----| |-----| |-----| 214 Figure 1: Fast Notification Architecture 216 Regular routing protocol performs the flooding in store-and-forward 217 manner. While this is reliable (retransmission) and secure 218 (adjacency check), it involves control plane operation and the 219 control plane to data plane communication. It inevitably drags the 220 network-wide convergence. 222 With the fast notification architecture, the delivery function is 223 detached from the application layer and moved onto the transport 224 layer. More precisely, the transport layer provides domain-wide fast 225 delivery platform. The normal flooding function is still kept in the 226 application layer to ensure ultimate synchronization in case the fast 227 flooding does not reach some intended routers for whatever reasons. 229 The speed of the fast flooding needs not to be faster than the data 230 traffic. As long as the messenger travels at the same speed of the 231 data traffic, it always gives the next-hop router the same amount of 232 time for processing as it gives the previous router. 234 4. Operation 236 Fast failure notification operates on following steps: 238 1. Failure detection; 240 2. Notification composing and dispatching; 242 3. Notification flooding; 244 4. Notification receiving; 246 5. Routing/forwarding table update. 248 4.1. Failure detection 250 This can be made in many ways. But it has to be fast and light- 251 weight. Layer-2 link-event monitoring and signaling is obvious an 252 option. Bidirectional Forwarding detection (BFD) is also a good 253 candidate. There may be more, or combinations of them. 255 The fast notification architecture encourages the innovation in this 256 area which can be pursued freely and independently. 258 4.2. Notification Origination 260 This part involves the message format. This document does not 261 specify or endorse a particular format. It is open to any format as 262 long as it fulfills the fast flooding purpose. The detecting router 263 is responsible for the initiation of the fast notification process. 264 Its action is the starting point of the fast flooding. 266 There are two packet formats worth of mentioning. 268 4.2.1. IGP PDU 270 The simplest approach is to use the IGP packet format directly. For 271 example, the OSPF Router-LSA packet which reflects a broken adjacency 272 (one fewer router link) can be fast-flooded to all routers without 273 special modification. 275 The benefit is that the receivers can process the packet as usual. 276 Moreover since the packet is no different than the one in normal 277 flooding, it guarantees the seamless transition when the "slow" 278 flooding catches up. Plus, there will be no duplicate effort of fast 279 and slow convergence. Flooding stops wherever a router is updated 280 (already fast flooded). 282 The drawback is that the message cannot be made uniform for multiple 283 protocols. Other protocol such as IS-IS will have to devise a 284 different format. In addition, since IS-IS PDU is not IP based, it 285 may require encapsulation in some cases. 287 Another drawback is that the normal IGP flooding uses adjacency check 288 to prevent DoS attack or PDU replay from un-trusted parties. The 289 check has to be bypassed for the fast-flooded packets to be accepted. 290 This opens door to the DoS or some other attacks. Domain-wide 291 authentication may be adopted for protection. 293 4.2.2. Uniform Message 295 This format must include essential and sufficient information about 296 the broken link. The message will be treated on the receiver router 297 as a local event. The uniformed messaging provides freedom for 298 future expansion. The format thus is recommended TLV-based. 300 Cautions must be taken in case the message is mistakenly flooded due 301 to bugs or some error conditions. Timeout machinery may be used to 302 protect against such issues. 304 The detecting router is responsible for the initiation of the fast 305 notification process. Its action is the starting point of the fast 306 flooding. 308 4.3. Fast Flooding 310 The fast flooding does not specify the fast flooding mechanism. It 311 is up to the routing society to figure out and single out good 312 solutions. The requirement is that the flooding has to be 313 a. Reliable in that it reaches all participants even after failures 314 occur; 316 b. Loop-free; 318 c. Simple; 320 d. Can be authenticated. 322 4.4. Notification Receiving and Handling 324 This involves upon the arrival of the notification message, how it is 325 forwarded to the routing protocol for further processing. If the 326 fast-flooding scheme uses specific IP destination addresses or MAC 327 addresses, the receiving router has to recognize it. 329 When the message reaches the protocol process, it may have to relax 330 its acceptance criteria. 332 If in the future, some algorithm is developed that the notification 333 handling takes very few CPU cycles, this process may be performed in 334 real-time. Therefore it is worthy of considering move the 335 notification handling into the data plane. This will cut a large 336 chunk of delay and may lead to hitless domain-wide convergence. 338 4.5. Routing/Forwarding Table Update 340 This should be the same as normal IGP decision process. It is also 341 possible to pre-download the changes to the data plane if the 342 complexity can be limited. This will improve the overall convergence 343 time dramatically. 345 5. Convergence Analyses 347 5.1. Definition of Convergence Time 349 The convergence time is measured by dividing the number of lost 350 packets with the traffic flow rate between any two routers in the 351 domain. This SHOULD equal to the domain wide network convergence 352 time if all individual routers have the same computing power and the 353 same convergence time. 355 5.2. Domain Wide Convergence 357 Due to the propagation delay, all routers do not converge at the same 358 time. The traffic loss, however, stops immediately after the first 359 router repairs. 361 This is because the data traffic has to go through the same 362 propagation delay, which exactly compensate the late starting of the 363 convergence at remote routers. 365 Take a ring topology for example, as shown in Figure 2. 367 Dest Src 368 | | 369 --- --- --- --- 370 |A|---|B|---|C|...---|N| 371 --- --- --- --- 372 | | 373 ---------------------- 375 Figure 2: Ring Topology 377 Assume all routers have same convergence time 50 milliseconds. 378 Assume the transmission delay over each hop is 20 milliseconds. 380 Upon link A-B failure, B floods its Link State Update to C. Table 1 381 shows the convergence timeline. 383 +------+-----------------+--------------------+ 384 | Node | Converge Starts | converge Completes | 385 +------+-----------------+--------------------+ 386 | B | 0 | 50ms | 387 | C | 20ms | 70ms | 388 +------+-----------------+--------------------+ 390 During the first 50 milliseconds, packets from B to A are dropped. 391 Right after 50th milliseconds, B re-routes packets toward C. Those 392 packets, after traveling 20 milliseconds, arrive C at 70th 393 milliseconds when C is just repaired. Since C and all downstream 394 routers will correct themselves one by one right before those packets 395 arrive, they will arrive at the destination via the corrected path 396 successfully. The overall convergence time is thus same as B's. 398 5.3. Micro-looping 400 If routers' convergence time is different, micro looping may form, 401 although packets will still be delivered after several loops. Still 402 use Figure 2 for example. Assume C needs 90 milliseconds to 403 converge. When B re-routes packets back to C at 70th milliseconds, C 404 has not finished its updating yet. It continues to use its old 405 forwarding table and bounces packets back to B. B in turn re-route 406 packets again to C. This time packets arrive at C at 110th 407 milliseconds. C has done updating and will forward packets 408 correctly. The packets are looped once. 410 The micro-looping does not form easily with Fast Flooding method. 411 The routers have to differ in computing speed and differ 412 significantly. 414 5.4. Packet Reordering 416 Due to the different convergence timeline, packets may be temporarily 417 forwarded in wrong direction before being placed on the right track. 418 This will not cause packet loss, but will result in packet 419 reordering. 421 Packet reordering affects TCP communication adversely in that new 422 sequence numbered packets may arrive ahead of the older ones. 424 This problem is common in IPFRR solutions, and remains an open issue. 425 Not-Via for example, may have packets reordered when it switches to 426 use the final stable routes from the temporary LFAs. On the other 427 hand, the connectionless network by nature never promises ordered 428 packet delivery. This type of problem deserves a separate topic and 429 is beyond the scope of this document. 431 6. Scalability Analyses 433 Fast Flooding scales with networks of any size and any topology. At 434 least it scales no inferior to the normal IGP flooding. 436 7. Traffic Analyses 438 Traffics that did not route through the broken link are intact. 439 Traffics that did will be successfully re-routed as soon as the 440 affected router converges (as opposed to all routers converge). 442 Upon the convergence of the affected router, Fast Flooding guarantees 443 correct routes for all affected traffics. 445 8. Acknowledgements 447 TBD 449 9. IANA Considerations 451 This memo includes no request to IANA. 453 10. Security Considerations 455 TBD 457 11. References 459 11.1. Normative References 461 [ISO.10589.1992] 462 International Organization for Standardization, 463 "Intermediate system to intermediate system intra-domain- 464 routing routine information exchange protocol for use in 465 conjunction with the protocol for providing the 466 connectionless-mode Network Service (ISO 8473)", 467 ISO Standard 10589, 1992. 469 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 470 dual environments", RFC 1195, December 1990. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 477 11.2. Informative References 479 [I-D.ietf-rtgwg-ipfrr-notvia-addresses] 480 Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute 481 Using Not-via Addresses", 482 draft-ietf-rtgwg-ipfrr-notvia-addresses-05 (work in 483 progress), March 2010. 485 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 486 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 487 May 2005. 489 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 490 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 492 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 493 RFC 5714, January 2010. 495 Authors' Addresses 497 Wenhu Lu 498 Ericsson 499 300 Holger Way 500 San Jose, California 95134 501 USA 503 Phone: 408 750-5436 504 Email: wenhu.lu@ericsson.com 506 Albert Tian 507 Ericsson 508 300 Holger Way 509 San Jose, California 95134 510 USA 512 Phone: 408 750-8739 513 Email: albert.tian@ericsson.com 515 Sriganesh Kini 516 Ericsson 517 300 Holger Way 518 San Jose, California 95134 519 USA 521 Phone: 408 750-5210 522 Email: sriganesh.kini@ericsson.com