idnits 2.17.1 draft-ietf-ospf-scalability-06.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 585 has weird spacing: '... to perta...' == Line 618 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: 'Ref4-Ref7' is mentioned on line 414, but not defined == Unused Reference: 'Ref4' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'Ref5' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'Ref6' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'Ref7' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'Ref11' is defined on line 312, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 8 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 February, 2004 5 Category: Best Current Practice August, 2003 6 draft-ietf-ospf-scalability-06.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............................................6 48 6. Informative References.........................................6 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 A large network running OSPF [Ref1] protocol may occasionally 57 experience the simultaneous or near-simultaneous update of a large 58 number of link-state-advertisements, or LSAs. This is particularly 59 true if OSPF traffic engineering extension [Ref2] is used which 60 may significantly increase the number of LSAs in the network. 61 We call this event, an LSA storm and it may be initiated by an 62 unscheduled failure or a scheduled maintenance event. 63 The failure may be hardware, software, or procedural in nature. 65 The LSA storm causes high CPU and memory utilization at the router 66 causing incoming packets to be delayed or dropped. 67 Delayed acknowledgments (beyond the retransmission timer value) 68 result in retransmissions, and delayed Hello packets (beyond the 69 router-dead interval) result in neighbor adjacencies being declared 70 down. The retransmissions and additional LSA originations result in 71 further CPU and memory usage, essentially causing a positive feedback 72 loop, which, in the extreme case, may drive the network to an 73 unstable state. 75 The default value of retransmission timer is 5 seconds and that of 76 the router-dead interval is 40 seconds. However, recently there 77 has been a lot of interest in significantly reducing OSPF convergence 78 time. As part of that plan much shorter (sub-second) Hello and 79 router-dead intervals have been proposed [Ref3]. In such a scenario 80 it will be more likely for Hello packets to be delayed beyond 81 the router-dead interval during network congestion 82 caused by an LSA storm. 84 In order to improve the scalability and stability of networks we 85 recommend steps for prioritizing critical OSPF packets and avoiding 86 congestion. The details of the recommendations are given in Section 87 2. A simulation study is reported in [Ref12] that quantifies the 88 congestion phenomenon and its impact. It also studies several of the 89 recommendations and shows that they indeed improve the scalability 90 and stability of networks using OSPF protocol. [Ref12] is available 91 on request by contacting the editor or one of the authors. 93 Appendix A explains in more detail LSA storm scenarios, 94 their impact, and points out a few real-life examples of 95 control-message storms. Appendix B provides a list of variables 96 used in the recommendations and their example values. 97 Appendix C provides some further recommendations with similar goals. 99 2. Recommendations 101 The Recommendations below are intended to improve the scalability 102 and stability of large networks using OSPF protocol. During 103 periods of network congestion they would reduce retransmissions, 104 avoid an adjacency to be declared down due to Hello packets 105 being delayed beyond the RouterDeadInterval, and take other 106 congestion avoidance steps. The recommendations are unordered 107 except that Recommendation 2 is to be implemented only if 108 Recommendation 1 is not implemented. 110 (1) Classify all OSPF packets in two classes: a "high priority" 111 class comprising of OSPF Hello packets and Link State 112 Acknowledgment packets, and a "low priority" class 113 comprising of all other packets. The classification is 114 accomplished by examining the OSPF packet header. While 115 receiving a packet from a neighbor and while transmitting 116 a packet to a neighbor, try to process a "high priority" 117 packet ahead of a "low priority" packet. 119 The prioritized processing may cause OSPF packets from a neighbor 120 to be received out of sequence. If 121 Cryptographic Authentication (AuType = 2) is used (as specified 122 in [Ref1]) then successive received valid OSPF packets from a 123 neighbor need to have a non-decreasing "Cryptographic sequence 124 number". To comply with this requirement we recommend that 125 the receiver maintain two separate sequence numbers for OSPF 126 packets belonging to the two priority classes. This will work 127 since within the same priority class, OSPF packets will be 128 received in sequence. 130 (2) If the Recommendation 1 cannot be implemented then reset the 131 inactivity timer for an adjacency whenever any OSPF unicast 132 packet or any OSPF packet sent to AllSPFRouters over a 133 point-to-point link is received over that adjacency instead of 134 resetting the inactivity timer only on receipt of the 135 Hello packet. So OSPF would declare the adjacency to be down 136 only if no OSPF unicast packets or no OSPF packets sent to 137 AllSPFRouters over a point-to-point link are received over 138 that adjacency for a period equaling or exceeding the 139 RouterDeadInterval. The reason for not recommending this 140 proposal in conjunction with Recommendation 1 is to avoid 141 potential undesirable side effects. One such effect is the 142 delay in discovering the down status of 143 an adjacency in a case where no high priority Hello packets are 144 being received but the inactivity timer is being reset by other 145 stale packets in the low priority queue. 147 (3) Use an Exponential Backoff algorithm for determining the value 148 of the LSA retransmission interval (RxmtInterval). Let R(i) 149 represent the RxmtInterval value used during the i-th 150 retransmission of an LSA. Use the following algorithm to 151 compute R(i) 153 R(1) = Rmin 154 R(i+1) = Min(KR(i),Rmax) for i>=1 156 where K, Rmin and Rmax are constants and the function 157 Min(.,.) represents the minimum value of its two arguments. 158 Example values for K, Rmin and Rmax may be 2, 5 seconds 159 and 40 seconds respectively. Note that the example value for 160 Rmin, the initial retransmission interval, is the same as the 161 sample value of RxmtInterval in [Ref1]. 163 This recommendation is motivated by the observation that during 164 a network congestion event caused by control messages, a major 165 source for sustaining the congestion is the repeated 166 retransmission of LSAs. The use of an Exponential Backoff 167 algorithm for the LSA retransmission interval reduces the rate 168 of LSA retransmissions while the network experiences 169 congestion (during which it is more likely that multiple 170 retransmissions of the same LSA would happen). This in turn 171 helps the network get out of the congested state. 173 (4) Implicit Congestion Detection and Action Based on That: 174 If there is control message congestion at a router, its 175 neighbors do not know about that explicitly. However, they 176 can implicitly detect it based on the number of unacknowledged 177 LSAs to this router. If this number exceeds a certain "high 178 water mark" then the rate at which LSAs are sent to this router 179 should be reduced progressively using an exponential backoff 180 mechanism but not below a certain minimum rate. At a future 181 time, if the number of unacknowledged LSAs to this router falls 182 below a certain "low water mark" then the rate of sending 183 LSAs to this router should be increased progressively, again 184 using an exponential backoff mechanism but not above a certain 185 maximum rate. The whole algorithm is given below. It is to be 186 noted that this algorithm is to be applied independently to each 187 neighbor and only for unicast LSAs sent to a neighbor or LSAs 188 sent to AllSPFRouters over a point-to-point link. 190 Let, 191 U(t) = Number of unacknowledged LSAs to neighbor at time t. 193 H = A high water mark (in units of number of unacknowledged LSAs) 194 L = A low water mark (in units of number of unacknowledged LSAs) 195 G(t) = Gap between sending successive LSAs to neighbor at time t. 196 F = The factor by which the above gap is to be increased during 197 congestion and decreased after coming out of congestion. 198 T = Minimum time that has to elapse before the existing gap 199 is considered for change. 200 Gmin = Minimum allowed value of gap. 201 Gmax = Maximum allowed value of gap. 203 The equation below shows how the gap is to be changed after a 204 time T has elapsed since the last change: 205 _ 206 | 207 | Min(FG(t),Gmax) if U(t+T) > H 208 G(t+T) = | G(t) if H >= U(t+T) >= L 209 | Max(G(t)/F,Gmin) if U(t+T) < L 210 |_ 212 Min(.,.) and Max(.,.) represent the minimum and maximum values 213 of the two arguments respectively. 214 Example values for the various parameters of the algorithm are 215 as follows: H = 20, L = 10, F = 2, T = 1 second, Gmin = 20 ms, 216 Gmax = 1 second. 218 Recommendations 3 and 4 both slow down LSAs to congested 219 neighbors based on implicitly detecting the congestion but 220 they have important differences. Recommendation 3 progressively 221 slows down successive retransmissions of the same LSA whereas 222 Recommendation 3 progressively slows down all LSAs (new or 223 retransmission) to a congested neighbor. 225 (5) Throttling Adjacencies to be Brought Up Simultaneously: 226 If a router tries to bring up a large number of adjacencies to 227 its neighbors simultaneously then that may cause severe 228 congestion due to database synchronization and LSA flooding 229 activities. It is recommended that during such a situation 230 no more than "n" adjacencies should be brought up 231 simultaneously. Once a subset of adjacencies have been brought 232 up successfully, newer adjacencies may be brought up as long as 233 the number of simultaneous adjacencies being brought up does not 234 exceed "n". The appropriate value of "n" would depend on the 235 router processing power, link bandwidth and propagation delay. 236 The value of "n" should be configurable. 238 In the presence of throttling, an important issue is the order 239 in which adjacencies are to be formed. We recommend a First 240 Come First Served (FCFS) policy based on the order in which the 241 request for adjacency formation arrives. Requests may either be 242 from neighbors or self-generated. Among the self-generated 243 requests a priority list may be used to decide the order in which 244 the requests are to be made. However, once an adjacency 245 formation process starts it is not to be preempted except 246 for unusual circumstances such as errors or time-outs. 248 3. Security Considerations 250 This memo creates one new security issue for the OSPF protocol. 251 Recommendation 1 in Section 2 and Recommendation 2 in Appendix C 252 proposes prioritized processing of OSPF packets which may cause 253 packets from a neighbor to be received out of sequence. 254 If Cryptographic Authentication (AuType = 2) is used (as specified 255 in [Ref1]) then successive received valid OSPF packets from a 256 neighbor need to have a non-decreasing "Cryptographic sequence 257 number". To comply with this requirement we recommend that 258 the receiver maintain separate sequence numbers for OSPF 259 packets belonging to different priority classes. This will work 260 since within the same priority class, OSPF packets will be 261 received in sequence. 263 Security considerations for the base OSPF protocol are 264 covered in [Ref1]. 266 4. Acknowledgments 268 We would like to acknowledge the support and helpful comments from 269 OSPF WG chairs Rohit Dube, Acee Lindem, John Moy and Routing Area 270 directors Alex Zinin and Bill Fenner. We acknowledge Vivek Dube, 271 Mitchell Erblich, Mike Fox, Tony Przygienda, and Krishna Rao for 272 comments on previous versions of the draft. We also acknowledge 273 Margaret Chiosi, Elie Francis, Jeff Han, Beth Munson, 274 Roshan Rao, Moshe Segal, Mike Wardlow, and Pat Wirth for 275 collaboration and encouragement in our scalability 276 improvement efforts for Link-State-Protocol based networks. 278 5. Normative Reference 280 [Ref1] J. Moy, "OSPF Version 2", RFC 2328, April, 1998. 282 6. Informative References 284 [Ref2] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering 285 Extension to OSPF Version 2," Work in Progress. 287 [Ref3] C. Alaettinoglu, V. Jacobson and H. Yu, "Towards Milli- 288 second IGP Convergence," Work in Progress. 290 [Ref4] Pappalardo, D., "AT&T, customers grapple with ATM net 291 outage," Network World, February 26, 2001. 293 [Ref5] "AT&T announces cause of frame-relay network outage," AT&T 294 Press Release, April 22, 1998. 296 [Ref6] Cholewka, K., "MCI Outage Has Domino Effect," Inter@ctive 297 Week, August 20, 1999. 299 [Ref7] Jander, M., "In Qwest Outage, ATM Takes Some Heat," Light 300 Reading, April 6, 2001. 302 [Ref8] A. Zinin and M. Shand, "Flooding Optimizations in Link-State 303 Routing Protocols," Work in Progress. 305 [Ref9] P. Pillay-Esnault, "OSPF Refresh and flooding reduction in 306 stable topologies," Work in progress. 308 [Ref10] G. Ash, G. Choudhury, V. Sapozhnikova, M. Sherif, A. 309 Maunder, V. Manral, "Congestion Avoidance & Control for OSPF 310 Networks", Work in Progress. 312 [Ref11] B. M. Waxman, "Routing of Multipoint Connections," IEEE 313 Journal on Selected Areas in Communications, 6(9):1617-1622, 1988. 315 [Ref12] G. Choudhury, G. Ash, V. Manral, A. Maunder and V. 316 Sapozhnikova, "Prioritized Treatment of Specific OSPF Packets 317 and Congestion Avoidance: Algorithms and Simulations," AT&T 318 Technical Report, August, 2003. 320 [Ref13] K. Nichols, S. Blake, F. Baker and D. Black, "Definition of 321 the Differentiated Services Field (DS Field) in the IPV4 and IPV6 322 Headers", RFC 2474, December, 1998. 324 7. Contributing Authors and their Addresses 326 In addition to the Editor, several people contributed to this 327 document. The names and contact information of all authors 328 are given below. 330 Gagan L. Choudhury Anurag S. Maunder 331 AT&T Erlang Technology 332 Room D5-3C21 2880 Scott Boulevard 333 200 Laurel Avenue Santa Clara, CA 95052 334 Middletown, NJ, 07748 USA 335 USA Phone: (408)420-7617 336 Phone: (732)420-3721 email: anuragm@erlangtech.com 337 email: gchoudhury@att.com 339 Gerald R. Ash Vera D. Sapozhnikova 340 AT&T AT&T 341 Room D5-2A01 Room C5-2C29 342 200 Laurel Avenue 200 Laurel Avenue 343 Middletown, NJ, 07748 Middletown, NJ, 07748 344 USA USA 345 Phone: (732)420-4578 Phone: (732)420-2653 346 email: gash@att.com email: sapozhnikova@att.com 348 Vishwas Manral 349 Motorola Inc. 350 189, Prashasan Nagar, 351 Road Number 72 352 Jubilee Hills, Hyderabad 353 India 354 email: vishwas@motorola.com 356 Appendix A. LSA Storm: Causes and Impact 358 An LSA storm may be initiated due to many reasons. Here 359 are some examples: 361 (a) one or more link failures due to fiber cuts, 363 (b) one or more router failures for some reason, e.g., software 364 crash or some type of disaster (including power outage) 365 in an office complex hosting many routers, 367 (c) Link/router flapping, 368 (d) requirement of taking down and later bringing back many 369 routers during a software/hardware upgrade, 371 (e) near-synchronization of the periodic 1800 second LSA refreshes 372 of a subset of LSAs, 374 (f) refresh of all LSAs in the system during a change in software 375 version, 377 (g) injecting a large number of external routes to OSPF due to 378 a procedural error, 380 (h) Router ID changes causing a large number of LSA re-originations 381 (possibly LSA purges as well depending on the implementation). 383 In addition to the LSAs originated as a direct result of link/router 384 failures, there may be other indirect LSAs as well. One example in 385 MPLS networks is traffic engineering LSAs [Ref2] originated at other 386 links as a result of significant change in reserved bandwidth 387 resulting from rerouting of Label Switched Paths (LSPs) that went 388 down during the link/router failure. 389 The LSA storm causes high CPU and memory utilization at the router 390 processor causing incoming packets to be delayed or dropped. 391 Delayed acknowledgments (beyond the retransmission timer value) 392 results in retransmissions, and delayed Hello packets (beyond the 393 Router-Dead interval) results in links being declared down. A 394 trunk-down event causes Router LSA origination by its end-point 395 routers. If traffic engineering LSAs are used for each link then 396 that type of LSAs would also be originated by the end-point routers 397 and potentially elsewhere as well due to significant changes in 398 reserved bandwidths at other links caused by the failure and reroute 399 of LSPs originally using the failed trunk. Eventually, when the 400 link recovers that would also trigger additional Router LSAs and 401 traffic engineering LSAs. 403 The retransmissions and additional LSA originations result in further 404 CPU and memory usage, essentially causing a positive feedback loop. 405 We define the LSA storm size as the number of LSAs in the original 406 storm and not counting any additional LSAs resulting from the 407 feedback loop described above. If the LSA storm is too large then 408 the positive feedback loop mentioned above may be large enough to 409 indefinitely sustain a large CPU and memory utilization at many 410 routers in the network, thereby driving the network to an unstable 411 state. In the past, network 412 outage events have been reported in IP and ATM networks using 413 link-state protocols such as OSPF, IS-IS, PNNI or some proprietary 414 variants. See for example [Ref4-Ref7]. In many of these examples, 415 large scale flooding of LSAs or other similar control messages 416 (either naturally or triggered by some bug or inappropriate 417 procedure) have been partly or fully responsible for network 418 instability and outage. 420 In [Ref12] a simulation model is used to show that there 421 is a certain LSA storm size threshold above which the 422 network may show unstable behavior caused by large number of 423 retransmissions, link failures due to missed Hello packets and 424 subsequent link recoveries. It is also shown 425 that the LSA storm size causing instability may be substantially 426 increased by providing prioritized treatment to Hello and LSA 427 Acknowledgment packets and by using an exponential backoff 428 algorithm for determining the LSA retransmission interval. 429 If it is not possible to prioritize Hello packets then resetting 430 the inactivity timer on receiving any valid OSPF packets can also 431 provide the same benefit. Furthermore, if we prioritize Hello 432 packets then even when the network operates somewhat above the 433 stability threshold, links are not declared down due to missed 434 Hellos. This implies that even though there is 435 control plane congestion due to many retransmissions, the data plane 436 stays up and no new LSAs are originated (besides the ones in the 437 original storm and the refreshes). These observations support 438 the first three recommendations in Section 2. The authors of this 439 draft have also done simulations to verify that the other 440 recommendations in Section 2 helps avoid congestion and allows a 441 graceful exit from a congested state. 443 One might argue that the scalability issue of large networks should 444 be solved solely by dividing the network hierarchically into 445 multiple areas so that flooding of LSAs remains localized within 446 areas. However, this approach increases the network management 447 and design complexity and may result in less optimal routing between 448 areas. Also, ASE LSAs are flooded throughout the AS and it may be 449 a problem if there are large numbers of them. Furthermore, 450 a large number of summary LSAs may need to be flooded across 451 Areas and their numbers would increase significantly if 452 multiple Area Border Routers are employed for the purpose of 453 reliability. Thus it is important to allow the network to grow 454 towards as large a size as possible under a single area. 456 The recommendations in the draft are synergistic with a broader set 457 of scalability and stability improvement proposals. [Ref8] proposes 458 flooding overhead reduction in case more than one interface goes to 459 the same neighbor. [Ref9] proposes a mechanism for 460 greatly reducing LSA refreshes in stable topologies. 462 [Ref10] proposes a wide range of congestion control and failure 463 recovery mechanisms (some of those ideas are covered in this 464 draft but [Ref10] has other ideas not covered here). 466 Appendix B. List of Variables and Values 468 F = The factor by which the gap between sending successive LSAs to 469 a neighbor is to be increased during congestion and decreased 470 after coming out of congestion (used in Recommendation 4). 471 Example value is 2. 473 G(t) = Gap between sending successive LSAs to a neighbor at time t 474 (used in Recommendation 4). 476 Gmax = Maximum allowed value of gap between sending successive LSAs 477 to a neighbor (used in Recommendation 4). Example value is 1 478 second. 480 Gmin = Minimum allowed value of gap between sending successive LSAs 481 to a neighbor (used in Recommendation 4). Example value is 482 20 ms. 484 H = A high water mark (in units of number of unacknowledged LSAs). 485 Exceeding this mark would trigger a potential increase in the 486 gap between sending successive LSAs to a neighbor. 487 (used in Recommendation 4). Example value is 20. 489 K = A multiplicative constant used in increasing the RxmtInterval 490 value used during successive retransmissions of the same LSA 491 (used in Recommendation 3). Example value is 2. 493 L = A low water mark (in units of number of unacknowledged LSAs) 494 Dropping below this mark would trigger a potential decrease 495 in the gap between sending successive LSAs to a neighbor. 496 (used in Recommendation 4). Example value is 10. 498 n = Upper limit on the number of adjacencies to be brought up 499 simultaneously (used in Recommendation 5). 501 R(i) = RxmtInterval value used during the i-th retransmission of 502 an LSA (used in Recommendation 3). 504 Rmax = The maximum allowed value of RxmtInterval (used in 505 Recommendation 3). Example value is 40 seconds. 507 Rmin = The minimum allowed value of RxmtInterval (used in 508 Recommendation 3). Example value is 5 seconds. 510 T = Minimum time that has to elapse before the existing gap 511 between sending successive LSAs to a neighbor 512 is considered for change (used in Recommendation 4). Example 513 value is 1 second. 515 U(t) = Number of unacknowledged LSAs to a neighbor at time t 516 (used in Recommendation 4). 518 Appendix C. Other Recommendations 520 (1) Explicit Marking: In Section 2 we recommended that OSPF packets 521 be classified to "high" and "low" priority classes based on 522 examining the OSPF packet header. In some cases (particularly 523 in the receiver) this examination may be computationally 524 costly. An alternative would be the 525 use of different TOS/Precedence field settings for the two 526 priority classes. [Ref1] recommends setting the TOS field to 0 527 and the Precedence field to 6 for all OSPF packets. We recommend 528 this same setting for the "low" priority OSPF packets and a 529 different setting for the "high" priority OSPF packets in order 530 to be able to classify them separately without having to examine 531 the OSPF packet header. Two examples are given below: 533 Example 1: For "low" priority packets set TOS field to 0 and 534 Precedence field to 6, and for "high" priority 535 packets set TOS field to 4 and Precedence field to 6. 537 Example 2: For "low" priority packets set TOS field to 0 and 538 Precedence field to 6, and for "high" priority 539 packets set TOS field to 0 and Precedence field to 7. 541 It is to be noted that the TOS/Precedence bits have been 542 redefined by Diffserv (RFC 2474, [Ref13]). It is also to be 543 noted that the different TOS/Precedence field settings suggested 544 above only need to be agreed among the systems on the link. 545 This recommendation is not needed to be followed if it is easy 546 to examine the OSPF packet header and thereby separately 547 classify "high" and "low" priority packets. 549 (2) Further Prioritization of OSPF Packets: Besides the packets 550 designated as "high" priority in Recommendation 1 of Section 2 551 there may be a need for further priority separation among the 552 "low" priority OSPF packets. We recommend the use of three 553 priority classes: "high", "medium" and "low". While 554 receiving a packet from a neighbor and while transmitting 555 a packet to a neighbor, try to process a "high priority" 556 packet ahead of "medium" and "low" priority packets and 557 a "medium" priority packet ahead of "low priority" packets. 558 The "high" priority packets are as designated in Recommendation 559 1 of Section 2. We provide below two candidate examples for 560 "medium" priority packets. All OSPF packets not designated 561 as "high" or "medium" priority are "low" priority. 563 If Cryptographic Authentication (AuType = 2) is used (as 564 specified in [Ref1]) then the receiver should maintain separate 565 sequence numbers for OSPF packets belonging to different 566 priority classes. 568 One example of "medium" priority packet is the 569 Database Description (DBD) packet from a slave (during the 570 database synchronization process) that is used as an 571 acknowledgment. 573 A second example is an LSA carrying 574 intra-area topology change information (this may trigger 575 SPF calculation and rerouting of Label Switched paths and so 576 fast processing of this packet may improve OSPF/LDP convergence 577 times). However, if the processing cost of identifying and 578 separately queueing the LSA in this example is deemed to be high 579 then the implementor may decide not to do it. 581 Intellectual Property Considerations 583 (A) The IETF takes no position regarding the validity or scope of 584 any intellectual property or other rights that might be claimed 585 to pertain to the implementation or use of the technology 586 described in this document or the extent to which any license 587 under such rights might or might not be available; neither does 588 it represent that it has made any effort to identify any such 589 rights. Information on the IETF's procedures with respect to 590 rights in standards-track and standards-related documentation 591 can be found in BCP-11. Copies of claims of rights made 592 available for publication and any assurances of licenses to 593 be made available, or the result of an attempt made 594 to obtain a general license or permission for the use of such 595 proprietary rights by implementors or users of this 596 specification can be obtained from the IETF Secretariat. 598 (B) The IETF invites any interested party to bring to its 599 attention any copyrights, patents or patent applications, or 600 other proprietary rights which may cover technology that may be 601 required to practice this standard. Please address the 602 information to the IETF Executive Director. 604 Copyright Notice 606 (C) Copyright (C) The Internet Society (date). All Rights 607 Reserved. 609 This document and translations of it may be copied and 610 furnished to others, and derivative works that comment on or 611 otherwise explain it or assist in its implementation may be 612 prepared, copied, published and distributed, in whole or in 613 part, without restriction of any kind, provided that the above 614 copyright notice and this paragraph are included on all such 615 copies and derivative works. However, this document itself may 616 not be modified in any way, such as by removing the copyright 617 notice or references to the Internet Society or other Internet 618 organizations, except as needed for the purpose of developing 619 Internet standards in which case the procedures for copyrights 620 defined in the Internet Standards process must be followed, or 621 as required to translate it into languages other than English. 623 The limited permissions granted above are perpetual and will 624 not be revoked by the Internet Society or its successors or 625 assigns. 627 This document and the information contained herein is provided 628 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 629 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 630 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 631 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 632 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 633 PARTICULAR PURPOSE.