idnits 2.17.1 draft-ietf-ospf-scalability-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 631 has weird spacing: '... to perta...' == Line 664 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ref6-Ref9' is mentioned on line 448, but not defined == Unused Reference: 'Ref6' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'Ref7' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'Ref8' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'Ref9' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'Ref13' is defined on line 346, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (ref. 'Ref2') (Obsoleted by RFC 5340) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gagan L. Choudhury, Editor 3 Internet Draft AT&T 4 Expires in November, 2004 5 Category: Best Current Practice May, 2004 6 draft-ietf-ospf-scalability-07.txt 8 Prioritized Treatment of Specific OSPF 9 Packets and Congestion Avoidance 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference 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.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. 32 Abstract 34 This document recommends methods that are intended to improve the 35 scalability and stability of large networks using OSPF (Open Shortest 36 Path First) protocol. The methods include processing OSPF Hellos and 37 LSA (Link State Advertisement) Acknowledgments at a higher priority 38 compared to other OSPF packets, and other congestion avoidance 39 procedures. 41 Table of Contents 43 1. Introduction...................................................2 44 2. Recommendations................................................3 45 3. Security Considerations........................................6 46 4. Acknowledgments................................................6 47 5. Normative Reference............................................7 48 6. Informative References.........................................7 49 7. Contributing Authors and their Addresses.......................8 50 Appendix A. LSA Storm: Causes and Impact..........................8 51 Appendix B. List of Variables and Values.........................11 52 Appendix C. Other Recommendations................................12 54 1. Introduction 56 In this document as we refer to OSPF we usually mean OSPFv2 [Ref1]. 57 The scalability and stability improvement techniques described here 58 may also apply to OSPFv3 [Ref2] but that will require further study 59 and operational experience. 61 A large network running OSPF protocol may occasionally 62 experience the simultaneous or near-simultaneous update of a large 63 number of link-state-advertisements, or LSAs. This is particularly 64 true if OSPF traffic engineering extension [Ref3] is used which 65 may significantly increase the number of LSAs in the network. 66 We call this event, an LSA storm and it may be initiated by an 67 unscheduled failure or a scheduled maintenance event. 68 The failure may be hardware, software, or procedural in nature. 70 The LSA storm causes high CPU and memory utilization at the router 71 causing incoming packets to be delayed or dropped. 72 Delayed acknowledgments (beyond the retransmission timer value) 73 result in retransmissions, and delayed Hello packets (beyond the 74 router-dead interval) result in neighbor adjacencies being declared 75 down. The retransmissions and additional LSA originations result in 76 further CPU and memory usage, essentially causing a positive feedback 77 loop, which, in the extreme case, may drive the network to an 78 unstable state. 80 The default value of retransmission timer is 5 seconds and that of 81 the router-dead interval is 40 seconds. However, recently there 82 has been a lot of interest in significantly reducing OSPF convergence 83 time. As part of that plan much shorter (sub-second) Hello and 84 router-dead intervals have been proposed [Ref4]. In such a scenario 85 it will be more likely for Hello packets to be delayed beyond 86 the router-dead interval during network congestion 87 caused by an LSA storm. 89 In order to improve the scalability and stability of networks we 90 recommend steps for prioritizing critical OSPF packets and avoiding 91 congestion. The details of the recommendations are given in Section 92 2. A simulation study is reported in [Ref14] that quantifies the 93 congestion phenomenon and its impact. It also studies several of the 94 recommendations and shows that they indeed improve the scalability 95 and stability of networks using OSPF protocol. [Ref14] is available 96 on request by contacting the editor or one of the authors. 98 Appendix A explains in more detail LSA storm scenarios, 99 their impact, and points out a few real-life examples of 100 control-message storms. Appendix B provides a list of variables 101 used in the recommendations and their example values. 102 Appendix C provides some further recommendations with similar goals. 104 2. Recommendations 106 The Recommendations below are intended to improve the scalability 107 and stability of large networks using OSPF protocol. During 108 periods of network congestion they would reduce retransmissions, 109 avoid an adjacency to be declared down due to Hello packets 110 being delayed beyond the RouterDeadInterval, and take other 111 congestion avoidance steps. The recommendations are unordered 112 except that Recommendation 2 is to be implemented only if 113 Recommendation 1 is not implemented. 115 (1) Classify all OSPF packets in two classes: a "high priority" 116 class comprising of OSPF Hello packets and Link State 117 Acknowledgment packets, and a "low priority" class 118 comprising of all other packets. The classification is 119 accomplished by examining the OSPF packet header. While 120 receiving a packet from a neighbor and while transmitting 121 a packet to a neighbor, try to process a "high priority" 122 packet ahead of a "low priority" packet. 124 The prioritized processing while transmitting may cause OSPF 125 packets from a neighbor to be received out of sequence. In OSPFv2 126 if Cryptographic Authentication (AuType = 2) is used (as 127 specified in [Ref1]) then successive received valid OSPF packets 128 from a neighbor need to have a non-decreasing "Cryptographic 129 sequence number". To comply with this requirement we recommend 130 that in case Cryptographic Authentication (AuType = 2) is used 131 [Ref1], prioritized processing be done only at the receiver 132 after receiving a valid OSPF packet but no prioritized processing 133 be done at the transmitter. Another possibility is to use 134 two separate sequence number spaces, one for "high" priority 135 packets and another for "low" priority packets. In this case 136 prioritized treatment at the transmitter would also work since 137 OSPF packets within the same priority class would not get out of 138 order. This mechanism is, however, not backwards compatible and 139 so can be used only if both sides of the interface use this 140 mechanism and can signal that fact to each other explicitly or 141 implicitly. 143 (2) If the Recommendation 1 cannot be implemented then reset the 144 inactivity timer for an adjacency whenever any OSPF unicast 145 packet or any OSPF packet sent to AllSPFRouters over a 146 point-to-point link is received over that adjacency instead of 147 resetting the inactivity timer only on receipt of the 148 Hello packet. So OSPF would declare the adjacency to be down 149 only if no OSPF unicast packets or no OSPF packets sent to 150 AllSPFRouters over a point-to-point link are received over 151 that adjacency for a period equaling or exceeding the 152 RouterDeadInterval. The reason for not recommending this 153 proposal in conjunction with Recommendation 1 is to avoid 154 potential undesirable side effects. One such effect is the 155 delay in discovering the down status of 156 an adjacency in a case where no high priority Hello packets are 157 being received but the inactivity timer is being reset by other 158 stale packets in the low priority queue. 160 (3) Use an exponential backoff algorithm for determining the value 161 of the LSA retransmission interval (RxmtInterval). Let R(i) 162 represent the RxmtInterval value used during the i-th 163 retransmission of an LSA. Use the following algorithm to 164 compute R(i) 166 R(1) = Rmin 167 R(i+1) = Min(KR(i),Rmax) for i>=1 169 where K, Rmin and Rmax are constants and the function 170 Min(.,.) represents the minimum value of its two arguments. 171 Example values for K, Rmin and Rmax may be 2, 5 seconds 172 and 40 seconds respectively. Note that the example value for 173 Rmin, the initial retransmission interval, is the same as the 174 sample value of RxmtInterval in [Ref1]. 176 This recommendation is motivated by the observation that during 177 a network congestion event caused by control messages, a major 178 source for sustaining the congestion is the repeated 179 retransmission of LSAs. The use of an exponential backoff 180 algorithm for the LSA retransmission interval reduces the rate 181 of LSA retransmissions while the network experiences 182 congestion (during which it is more likely that multiple 183 retransmissions of the same LSA would happen). This in turn 184 helps the network get out of the congested state. 186 (4) Implicit Congestion Detection and Action Based on That: 187 If there is control message congestion at a router, its 188 neighbors do not know about that explicitly. However, they 189 can implicitly detect it based on the number of unacknowledged 190 LSAs to this router. If this number exceeds a certain "high 191 water mark" then the rate at which LSAs are sent to this router 192 should be reduced progressively using an exponential backoff 193 mechanism but not below a certain minimum rate. At a future 194 time, if the number of unacknowledged LSAs to this router falls 195 below a certain "low water mark" then the rate of sending 196 LSAs to this router should be increased progressively, again 197 using an exponential backoff mechanism but not above a certain 198 maximum rate. The whole algorithm is given below. It is to be 199 noted that this algorithm is to be applied independently to each 200 neighbor and only for unicast LSAs sent to a neighbor or LSAs 201 sent to AllSPFRouters over a point-to-point link. 203 Let, 204 U(t) = Number of unacknowledged LSAs to neighbor at time t. 205 H = A high water mark (in units of number of unacknowledged LSAs) 206 L = A low water mark (in units of number of unacknowledged LSAs) 207 G(t) = Gap between sending successive LSAs to neighbor at time t. 208 F = The factor by which the above gap is to be increased during 209 congestion and decreased after coming out of congestion. 210 T = Minimum time that has to elapse before the existing gap 211 is considered for change. 212 Gmin = Minimum allowed value of gap. 213 Gmax = Maximum allowed value of gap. 215 The equation below shows how the gap is to be changed after a 216 time T has elapsed since the last change: 217 _ 218 | 219 | Min(FG(t),Gmax) if U(t+T) > H 220 G(t+T) = | G(t) if H >= U(t+T) >= L 221 | Max(G(t)/F,Gmin) if U(t+T) < L 222 |_ 224 Min(.,.) and Max(.,.) represent the minimum and maximum values 225 of the two arguments respectively. 226 Example values for the various parameters of the algorithm are 227 as follows: H = 20, L = 10, F = 2, T = 1 second, Gmin = 20 ms, 228 Gmax = 1 second. 230 Recommendations 3 and 4 both slow down LSAs to congested 231 neighbors based on implicitly detecting the congestion but 232 they have important differences. Recommendation 3 progressively 233 slows down successive retransmissions of the same LSA whereas 234 Recommendation 3 progressively slows down all LSAs (new or 235 retransmission) to a congested neighbor. 237 (5) Throttling Adjacencies to be Brought Up Simultaneously: 238 If a router tries to bring up a large number of adjacencies to 239 its neighbors simultaneously then that may cause severe 240 congestion due to database synchronization and LSA flooding 241 activities. It is recommended that during such a situation 242 no more than "n" adjacencies should be brought up 243 simultaneously. Once a subset of adjacencies have been brought 244 up successfully, newer adjacencies may be brought up as long as 245 the number of simultaneous adjacencies being brought up does not 246 exceed "n". The appropriate value of "n" would depend on the 247 router processing power, link bandwidth and propagation delay. 248 The value of "n" should be configurable. 250 In the presence of throttling, an important issue is the order 251 in which adjacencies are to be formed. We recommend a First 252 Come First Served (FCFS) policy based on the order in which the 253 request for adjacency formation arrives. Requests may either be 254 from neighbors or self-generated. Among the self-generated 255 requests a priority list may be used to decide the order in which 256 the requests are to be made. However, once an adjacency 257 formation process starts it is not to be preempted except 258 for unusual circumstances such as errors or time-outs. 260 In some of the Recommendations above we refer to point-to-point links. 261 Those references should also include cases where a broadcast network 262 is to be treated as a point-to-point connection from the standpoint of 263 IP routing [Ref5] 265 3. Security Considerations 267 This memo creates one new security issue for the OSPFv2 [Ref1]. 268 Recommendation 1 in Section 2 and Recommendation 2 in Appendix C 269 proposes prioritized processing of OSPF packets. Such prioritization 270 at the receiver does not cause any issue but prioritized processing 271 while transmitting may cause OSPF 272 packets from a neighbor to be received out of sequence. In OSPFv2 273 if Cryptographic Authentication (AuType = 2) is used (as 274 specified in [Ref1]) then successive received valid OSPF packets 275 from a neighbor need to have a non-decreasing "Cryptographic 276 sequence number". To comply with this requirement we recommend 277 that in case Cryptographic Authentication (AuType = 2) is used 278 [Ref1], prioritized processing be done only at the receiver 279 after receiving a valid OSPF packet but no prioritized processing 280 be done at the transmitter. Another possibility is to use 281 two separate sequence number spaces, one for "high" priority 282 packets and another for "low" priority packets. In this case 283 prioritized treatment at the transmitter would also work since 284 OSPF packets within the same priority class would not get out of 285 order. This mechanism is, however, not backwards compatible and 286 so can be used only if both sides of the interface use this 287 mechanism and can signal that fact to each other explicitly or 288 implicitly. 290 Security considerations for the base OSPF protocol are 291 covered in [Ref1, Ref2]. 293 4. Acknowledgments 295 We would like to acknowledge the support and helpful comments from 296 OSPF WG chairs Rohit Dube, Acee Lindem, John Moy, Routing Area 297 directors Alex Zinin and Bill Fenner, and IESG reviewers. We 298 acknowledge Vivek Dube, Mitchell Erblich, Mike Fox, Tony 299 Przygienda, and Krishna Rao for comments on previous versions of 300 the draft. We also acknowledge Margaret Chiosi, Elie Francis, 301 Jeff Han, Beth Munson, Roshan Rao, Moshe Segal, Mike Wardlow, and 302 Pat Wirth for collaboration and encouragement in our scalability 303 improvement efforts for Link-State-Protocol based networks. 305 5. Normative Reference 307 [Ref1] J. Moy, "OSPF Version 2", RFC 2328, April, 1998. 309 [Ref2] R. Coltun, D. Ferguson and J. Moy, "OSPF For IPV6", 310 RFC 2740, December, 1999. 312 6. Informative References 314 [Ref3] D. Katz, K. Kompella, D. Yeung "Traffic Engineering (TE) 315 Extensions to OSPF Version 2," RFC 3630, September, 2003. 317 [Ref4] C. Alaettinoglu, V. Jacobson and H. Yu, "Towards Milli- 318 second IGP Convergence," Work in Progress. 320 [Ref5] N. Shen, A. Lindem, J. Yuan, A. Zinin, R. White and S. Previdi, 321 "Point-to-point operation over LAN in link-state routing protocols," 322 Work in Progress. 324 [Ref6] Pappalardo, D., "AT&T, customers grapple with ATM net 325 outage," Network World, February 26, 2001. 327 [Ref7] "AT&T announces cause of frame-relay network outage," AT&T 328 Press Release, April 22, 1998. 330 [Ref8] Cholewka, K., "MCI Outage Has Domino Effect," Inter@ctive 331 Week, August 20, 1999. 333 [Ref9] Jander, M., "In Qwest Outage, ATM Takes Some Heat," Light 334 Reading, April 6, 2001. 336 [Ref10] A. Zinin and M. Shand, "Flooding Optimizations in Link-State 337 Routing Protocols," Work in Progress. 339 [Ref11] P. Pillay-Esnault, "OSPF Refresh and flooding reduction in 340 stable topologies," Work in progress. 342 [Ref12] G. Ash, G. Choudhury, V. Sapozhnikova, M. Sherif, A. 343 Maunder, V. Manral, "Congestion Avoidance & Control for OSPF 344 Networks", Work in Progress. 346 [Ref13] B. M. Waxman, "Routing of Multipoint Connections," IEEE 347 Journal on Selected Areas in Communications, 6(9):1617-1622, 1988. 349 [Ref14] G. Choudhury, G. Ash, V. Manral, A. Maunder and V. 350 Sapozhnikova, "Prioritized Treatment of Specific OSPF Packets 351 and Congestion Avoidance: Algorithms and Simulations," AT&T 352 Technical Report, August, 2003. 354 [Ref15] K. Nichols, S. Blake, F. Baker and D. Black, "Definition of 355 the Differentiated Services Field (DS Field) in the IPV4 and IPV6 356 Headers", RFC 2474, December, 1998. 358 7. Contributing Authors and their Addresses 360 In addition to the Editor, several people contributed to this 361 document. The names and contact information of all authors 362 are given below. 364 Gagan L. Choudhury Anurag S. Maunder 365 AT&T Erlang Technology 366 Room D5-3C21 2880 Scott Boulevard 367 200 Laurel Avenue Santa Clara, CA 95052 368 Middletown, NJ, 07748 USA 369 USA Phone: (408)420-7617 370 Phone: (732)420-3721 email: anuragm@erlangtech.com 371 email: gchoudhury@att.com 373 Gerald R. Ash Vera D. Sapozhnikova 374 AT&T AT&T 375 Room D5-2A01 Room C5-2C29 376 200 Laurel Avenue 200 Laurel Avenue 377 Middletown, NJ, 07748 Middletown, NJ, 07748 378 USA USA 379 Phone: (732)420-4578 Phone: (732)420-2653 380 email: gash@att.com email: sapozhnikova@att.com 382 Vishwas Manral 383 Sinett Semiconductors, 384 Infantry Road, 385 Bangalore 500 081 386 India 387 email: vishwas@sinett.com 389 Appendix A. LSA Storm: Causes and Impact 391 An LSA storm may be initiated due to many reasons. Here 392 are some examples: 394 (a) one or more link failures due to fiber cuts, 396 (b) one or more router failures for some reason, e.g., software 397 crash or some type of disaster (including power outage) 398 in an office complex hosting many routers, 400 (c) Link/router flapping, 402 (d) requirement of taking down and later bringing back many 403 routers during a software/hardware upgrade, 405 (e) near-synchronization of the periodic 1800 second LSA refreshes 406 of a subset of LSAs, 408 (f) refresh of all LSAs in the system during a change in software 409 version, 411 (g) injecting a large number of external routes to OSPF due to 412 a procedural error, 414 (h) Router ID changes causing a large number of LSA re-originations 415 (possibly LSA purges as well depending on the implementation). 417 In addition to the LSAs originated as a direct result of link/router 418 failures, there may be other indirect LSAs as well. One example in 419 MPLS networks is traffic engineering LSAs [Ref3] originated at other 420 links as a result of significant change in reserved bandwidth 421 resulting from rerouting of Label Switched Paths (LSPs) that went 422 down during the link/router failure. 423 The LSA storm causes high CPU and memory utilization at the router 424 processor causing incoming packets to be delayed or dropped. 425 Delayed acknowledgments (beyond the retransmission timer value) 426 results in retransmissions, and delayed Hello packets (beyond the 427 Router-Dead interval) results in links being declared down. A 428 trunk-down event causes Router LSA origination by its end-point 429 routers. If traffic engineering LSAs are used for each link then 430 that type of LSAs would also be originated by the end-point routers 431 and potentially elsewhere as well due to significant changes in 432 reserved bandwidths at other links caused by the failure and reroute 433 of LSPs originally using the failed trunk. Eventually, when the 434 link recovers that would also trigger additional Router LSAs and 435 traffic engineering LSAs. 437 The retransmissions and additional LSA originations result in further 438 CPU and memory usage, essentially causing a positive feedback loop. 439 We define the LSA storm size as the number of LSAs in the original 440 storm and not counting any additional LSAs resulting from the 441 feedback loop described above. If the LSA storm is too large then 442 the positive feedback loop mentioned above may be large enough to 443 indefinitely sustain a large CPU and memory utilization at many 444 routers in the network, thereby driving the network to an unstable 445 state. In the past, network 446 outage events have been reported in IP and ATM networks using 447 link-state protocols such as OSPF, IS-IS, PNNI or some proprietary 448 variants. See for example [Ref6-Ref9]. In many of these examples, 449 large scale flooding of LSAs or other similar control messages 450 (either naturally or triggered by some bug or inappropriate 451 procedure) have been partly or fully responsible for network 452 instability and outage. 454 In [Ref14] a simulation model is used to show that there 455 is a certain LSA storm size threshold above which the 456 network may show unstable behavior caused by large number of 457 retransmissions, link failures due to missed Hello packets and 458 subsequent link recoveries. It is also shown 459 that the LSA storm size causing instability may be substantially 460 increased by providing prioritized treatment to Hello and LSA 461 Acknowledgment packets and by using an exponential backoff 462 algorithm for determining the LSA retransmission interval. 463 If it is not possible to prioritize Hello packets then resetting 464 the inactivity timer on receiving any valid OSPF packets can also 465 provide the same benefit. Furthermore, if we prioritize Hello 466 packets then even when the network operates somewhat above the 467 stability threshold, links are not declared down due to missed 468 Hellos. This implies that even though there is 469 control plane congestion due to many retransmissions, the data plane 470 stays up and no new LSAs are originated (besides the ones in the 471 original storm and the refreshes). These observations support 472 the first three recommendations in Section 2. The authors of this 473 draft have also done simulations to verify that the other 474 recommendations in Section 2 helps avoid congestion and allows a 475 graceful exit from a congested state. 477 One might argue that the scalability issue of large networks should 478 be solved solely by dividing the network hierarchically into 479 multiple areas so that flooding of LSAs remains localized within 480 areas. However, this approach increases the network management 481 and design complexity and may result in less optimal routing between 482 areas. Also, ASE LSAs are flooded throughout the AS and it may be 483 a problem if there are large numbers of them. Furthermore, 484 a large number of summary LSAs may need to be flooded across 485 Areas and their numbers would increase significantly if 486 multiple Area Border Routers are employed for the purpose of 487 reliability. Thus it is important to allow the network to grow 488 towards as large a size as possible under a single area. 490 The recommendations in the draft are synergistic with a broader set 491 of scalability and stability improvement proposals. [Ref10] proposes 492 flooding overhead reduction in case more than one interface goes to 493 the same neighbor. [Ref11] proposes a mechanism for 494 greatly reducing LSA refreshes in stable topologies. 496 [Ref12] proposes a wide range of congestion control and failure 497 recovery mechanisms (some of those ideas are covered in this 498 draft but [Ref12] has other ideas not covered here). 500 Appendix B. List of Variables and Values 502 F = The factor by which the gap between sending successive LSAs to 503 a neighbor is to be increased during congestion and decreased 504 after coming out of congestion (used in Recommendation 4). 505 Example value is 2. 507 G(t) = Gap between sending successive LSAs to a neighbor at time t 508 (used in Recommendation 4). 510 Gmax = Maximum allowed value of gap between sending successive LSAs 511 to a neighbor (used in Recommendation 4). Example value is 1 512 second. 514 Gmin = Minimum allowed value of gap between sending successive LSAs 515 to a neighbor (used in Recommendation 4). Example value is 516 20 ms. 518 H = A high water mark (in units of number of unacknowledged LSAs). 519 Exceeding this mark would trigger a potential increase in the 520 gap between sending successive LSAs to a neighbor. 521 (used in Recommendation 4). Example value is 20. 523 K = A multiplicative constant used in increasing the RxmtInterval 524 value used during successive retransmissions of the same LSA 525 (used in Recommendation 3). Example value is 2. 527 L = A low water mark (in units of number of unacknowledged LSAs) 528 Dropping below this mark would trigger a potential decrease 529 in the gap between sending successive LSAs to a neighbor. 530 (used in Recommendation 4). Example value is 10. 532 n = Upper limit on the number of adjacencies to be brought up 533 simultaneously (used in Recommendation 5). 535 R(i) = RxmtInterval value used during the i-th retransmission of 536 an LSA (used in Recommendation 3). 538 Rmax = The maximum allowed value of RxmtInterval (used in 539 Recommendation 3). Example value is 40 seconds. 541 Rmin = The minimum allowed value of RxmtInterval (used in 542 Recommendation 3). Example value is 5 seconds. 544 T = Minimum time that has to elapse before the existing gap 545 between sending successive LSAs to a neighbor 546 is considered for change (used in Recommendation 4). Example 547 value is 1 second. 549 U(t) = Number of unacknowledged LSAs to a neighbor at time t 550 (used in Recommendation 4). 552 Appendix C. Other Recommendations 554 (1) Explicit Marking: In Section 2 we recommended that OSPF packets 555 be classified to "high" and "low" priority classes based on 556 examining the OSPF packet header. In some cases (particularly 557 in the receiver) this examination may be computationally 558 costly. An alternative would be the 559 use of different TOS/Precedence field settings for the two 560 priority classes. [Ref1] recommends setting the TOS field to 0 561 and the Precedence field to 6 for all OSPF packets. We recommend 562 this same setting for the "low" priority OSPF packets and a 563 different setting for the "high" priority OSPF packets in order 564 to be able to classify them separately without having to examine 565 the OSPF packet header. Two examples are given below: 567 Example 1: For "low" priority packets set TOS field to 0 and 568 Precedence field to 6, and for "high" priority 569 packets set TOS field to 4 and Precedence field to 6. 571 Example 2: For "low" priority packets set TOS field to 0 and 572 Precedence field to 6, and for "high" priority 573 packets set TOS field to 0 and Precedence field to 7. 575 It is to be noted that the TOS/Precedence bits have been 576 redefined by Diffserv (RFC 2474, [Ref15]). It is also to be 577 noted that the different TOS/Precedence field settings suggested 578 above only need to be agreed among the systems on the link. 579 This recommendation is not needed to be followed if it is easy 580 to examine the OSPF packet header and thereby separately 581 classify "high" and "low" priority packets. 583 (2) Further Prioritization of OSPF Packets: Besides the packets 584 designated as "high" priority in Recommendation 1 of Section 2 585 there may be a need for further priority separation among the 586 "low" priority OSPF packets. We recommend the use of three 587 priority classes: "high", "medium" and "low". While 588 receiving a packet from a neighbor and while transmitting 589 a packet to a neighbor, try to process a "high priority" 590 packet ahead of "medium" and "low" priority packets and 591 a "medium" priority packet ahead of "low priority" packets. 592 The "high" priority packets are as designated in Recommendation 593 1 of Section 2. We provide below two candidate examples for 594 "medium" priority packets. All OSPF packets not designated 595 as "high" or "medium" priority are "low" priority. 596 If Cryptographic Authentication (AuType = 2) is used (as 597 specified in [Ref1]) then prioritized treatment is to be 598 provided only at the receiver after receiving a valid OSPF 599 packet, but not at the transmitter since that 600 may cause packets to arrive out of sequence and violate the 601 requirements of "Autype = 2". In this case the prioritized 602 treatment at the transmitter may be provided only if separate 603 sequence number spaces are used for the different classes of 604 packets, this mechanism is used at both sides of the interface, 605 and the two sides can signal this fact to each other explicitly 606 or implicitly. 608 One example of "medium" priority packet is the 609 Database Description (DBD) packet from a slave (during the 610 database synchronization process) that is used as an 611 acknowledgment. 613 A second example is an LSA carrying 614 intra-area topology change information (this may trigger 615 SPF calculation and rerouting of Label Switched paths and so 616 fast processing of this packet may improve OSPF/LDP convergence 617 times). However, if the processing cost of identifying and 618 separately queueing the LSA in this example is deemed to be high 619 then the implementer may decide not to do it. 621 (3) Processing LSA purges ahead of LSA originations: In some 622 scenarios, such as Router ID changes, large numbers of LSA 623 re-originations and LSA purges may be needed. In such a scenario 624 it is recommended that LSA purges be processed ahead of LSA 625 originations. 627 Intellectual Property Considerations 629 (A) The IETF takes no position regarding the validity or scope of 630 any intellectual property or other rights that might be claimed 631 to pertain to the implementation or use of the technology 632 described in this document or the extent to which any license 633 under such rights might or might not be available; neither does 634 it represent that it has made any effort to identify any such 635 rights. Information on the IETF's procedures with respect to 636 rights in standards-track and standards-related documentation 637 can be found in BCP-11. Copies of claims of rights made 638 available for publication and any assurances of licenses to 639 be made available, or the result of an attempt made 640 to obtain a general license or permission for the use of such 641 proprietary rights by implementers or users of this 642 specification can be obtained from the IETF Secretariat. 644 (B) The IETF invites any interested party to bring to its 645 attention any copyrights, patents or patent applications, or 646 other proprietary rights which may cover technology that may be 647 required to practice this standard. Please address the 648 information to the IETF Executive Director. 650 Copyright Notice 652 Copyright (C) The Internet Society (2004). All Rights 653 Reserved. 655 This document and translations of it may be copied and 656 furnished to others, and derivative works that comment on or 657 otherwise explain it or assist in its implementation may be 658 prepared, copied, published and distributed, in whole or in 659 part, without restriction of any kind, provided that the above 660 copyright notice and this paragraph are included on all such 661 copies and derivative works. However, this document itself may 662 not be modified in any way, such as by removing the copyright 663 notice or references to the Internet Society or other Internet 664 organizations, except as needed for the purpose of developing 665 Internet standards in which case the procedures for copyrights 666 defined in the Internet Standards process must be followed, or 667 as required to translate it into languages other than English. 669 The limited permissions granted above are perpetual and will 670 not be revoked by the Internet Society or its successors or 671 assigns. 673 This document and the information contained herein is provided 674 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 675 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 676 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 677 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 678 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 679 PARTICULAR PURPOSE.