Per-Router vs Centralized Control

Per-router control plane:

• individual routing algorithm components exist in each and every router. They interact in the control plane to compute forwarding tables.

Why should we use a logically centralized control plane?

• it's like how we switched from mainframe to PC revolution (independent app, OS, and microprocessor)

Traffic engineering is difficult in traditional routing; with a centralized controller you can be very specific.

The SDN Controller

• interface, abstractions for network control apps
  • e.g., network graph, RESTful API, ..., intent
• Network-wide distributed robust state management
  • e.g., statistics, flow tables, link-state info, host info, switch info, etc.
• Communication to/from controlled devices
  • e.g., openflow, SNMP...

OpenFlow protocol: is between controller and switch

Consistent Network Updates

Controller comes up with a set of forwarding table, puts it into the different switches, so the network configurations changes (different traffic pattern), computes different forwarding tables, and puts this in the switches

• some of the switches will have new sets and old sets of rules so this can cause a problem

One solution: if a packet was forwarded via a version 1 rule, and then use version 1 rule.

If one of our switches get a packet that was forwarded using the old rules, then only forward to routers that have that version.

• problem: packets could be dropped for consistency. 10-20% downgrade.
• Packet drops are unavoidable for any on-the-fly consistent methods.
• Each version cannot use results from an earlier version.

Causal update algorithm:

• there is a control packet called marker. this is sent to an initial set of nodes, and then it updates nodes along its route. any packet received from an un-updated / red node / are dropped.
• each node starts in a red state, and is done with all packets are green.

Network update problems:

• new and old forwarding rules coexist
• one approach: keep both sets of rules