Logically centralized?: state distribution trade-offs in software defined networks
Assumption behind paper is that control plane is decentralised but logically centralised. Physically centralised dismissed as impossible due to:
Controller component choices:
Strongly consistent – controller components always operate on the same world view. Imposes delay and overhead.
Eventually consistent – controller components incorporate information as it becomes available but may make decisions on different world views.
Problem formulation – physical layer contains FIBs. State management layer contains NIB (Network Information Base) – each controller in has its own view of NIB.
Uncoordinated changes could give routing loops, sub-optimal balancing. Coordinated changes mean more coordination messages and slower responsiveness.
Application logic is simpler if information is unaware of potential “staleness” of information but application aware of information problems may give better decision.
Example application is a load-balancer, two types:
Link Balance Controller (LBC) – Global network view of paths and utilisations presented to controllers. Simple software assigns new flows to path with lowest max link utilisation.
Separate State Link Balancer Controller (SSLBC) – Fresh intra-domain network state kept separate from inter domain info. Logic ensures convergence of load balancing. Shifts only new flows not existing flows to minimise max link utilisation.
Simulation is released as an open-source tool. Initial experiments use simple topology with two domains and two controllers. Metric measured is RMSE of max link utilisation over all paths – 0 if all paths have same max link utilisation. Flow arrivals are governed by a sin function with different workloads to cover different utilisations. Most “realistic” workflow has exponential flow inter arrival times with rate governed by sin and Weibull flow durations. Simulation has timesteps (64 timesteps to one sin wave cycle). Controller info “staleness” varied. LBC performance decreases as info is more “stale” but SSLBC less so.
Key tradeoffs identified are:
Staleness versus optimality – fresh info obviously better and more optimal but requires more resources.
Application complexity versus robustness to inconsistency – more complex applications are necessary to cope with inconsistency.
Page generated 2014-01-07 11:24:57 GMT, by jemdoc.