OSPF Flooding Process Optimization

1
OSPF Flooding Process Optimization

• Mikko Pitkanen, Marko Luoma

High Performance Switching and Routing, 2005.
HPSR.
2
Outline

• Introduction
• Related work
• Flooding Process
• Impact of router setting on flooding procedure
• Result
• Conclusion

3
Introduction

• Link state routing protocols such as OSPF are
  commonly used for intra-domain routing in modern
  networks.
• The routers describe their local environment by
  advertising the state of their local links and
  neighboring routers with the associated costs.
  The descriptions, call link state advertisements
  (LSA).
• The routers in the domain then maintain a
  distributed database of collected advertisements.

4
Introduction (cont.)

• The failure detection mechanism in the link state
  routing protocols is base on the sending of the
  periodic Hello messages.
• The delay timers are in routers because of the
  heavy tasks used in the flooding procedure and it
  prevent the routing process from overloading the
  routers CPU but may lead to an increase in the
  convergence time.

5
Related work(1/2)

• OSPF recovery time from failure
• The failure detection time
• The LSA flooding time
• The time to carry out the SPF calculations and
  FIB update

SPF Shortest Path First FIB Forwarding
Information Base)
6
Related work(2/2)

• Failure detection time
• HelloInterval can be reduced to the millisecond
  range in order to achieve faster failure
  detection. i.e. 250ms
• LSA Flooding time
• flooding process optimization
• Propagation delay
• SPF calculations and FIB update time
• SPF calculation time depends on the size of the
  network and routing table update time on the
  router's architecture

7
Flooding Process (1/2)

• Heaviest task in OSPF
• stable network operation is ensured by using
  delays between heavy tasks, PacingDelay,
  MinLSInterval, MinLSArrival, etc...
• Delays may slow down the network recovery time,
  are they necessary?
• Simulations are run to characterize the flooding
  behavior

8
Flooding Process (2/2)

• LSAs are added to LS retransmission list, minimum
  time between sending LSAs to a link is defined by
  PacingDelay
• Received LS Acknowledgement removes LSAs from LS
  retransmission List
• Too small PacingDelay --gt duplicate LSA traffic

9
Impact of router settings on flooding procedure

• A number of different OSPF parameter
  configurations
• HelloInterval
• Time spent between sending Hello packets
• Standard 10 sec
• RouterDeadInterval
• Time before declaring adjacency down if Hello
  packets are not received
• Standard 40 sec

10
Impact of router settings on flooding procedure

• MinLSInterval
• Minimum time between origination subsequent LSAs
• Standard 5 sec
• MinLSArrival
• Router does not accept new copy of an LSA if this
  time has no elapsed since last installation
• Standard 1 sec
• RxmtInterval
• Retransmission time in case of lost packet
• Standard 5 sec

11
Impact of router settings on flooding procedure

• LSRefreshInterval
• Period between re-originating unchanged LSAs
• Standard 30 min
• SpfDelay
• Time between new/changed LSA and SPF calculation
• Standard 5 sec
• SpfHoldTime
• Minimum time between two successive SPF
  calculations in a router
• Standard 10 sec
• PacingDelay
• Time between sending LS Updates out to an
  interface
• Standard 33 ms

12
Impact of router settings on flooding procedure

• We use three different measures that characterize
  the flooding procedure in networks
• LSA propagation during a period of heavy LSA
  traffic
• Amount of the incoming routing traffic in the
  bottleneck router
• CPU utilization in the bottleneck router

13
Impact of router settings on flooding procedure

• Simulated network has 65 nodes and 108 links
• Configuration
• HelloInterval 1 sec / RouterDeadInterval 4 sec
• MinLSInterval 50 ms (also 0 ms was used but
  caused congestion)
• MinLSArrival 0 ms
• RxmtInterval 2 sec
• SpfDelay 5 sec / SpfHoldTime 10 sec
• Various values for PacingDelay 0 100 ms

14
LSA Propagation
20
40
10
100
33
0
15
Routing Traffic in Bottleneck
16
CPU Utilization in Bottleneck
17
Convergence Time
18
Result

• Non-zero PacingDelay is recommended, optimal
  value depends on the number of LSAs
  simultaneously in transit.
• Number of LSAs in transit depends on
• Topology of the network
• Failure model of the network
• MinLSInterval should also be non-zero,
• value 50ms was used instead of default 5 seconds
  --gt good behavior

19
Conclusions

• The operation of an OSPF network can be
  substantially improved by using aggressive
  configurations
• In a simulated network with 26 nodes the
  convergence time after a link failure dropped
  from 45 seconds to 22 second.
• OSPF delays are essential in order to guarantee
  stable operation of the network