> For the complete documentation index, see [llms.txt](https://sliu583.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sliu583.gitbook.io/blog/networking/index/cs-268-adv-network/sdn/how-sdn-will-shape-networking.md).

# How SDN will shape networking

### SDN: An Industry Change 

* 1980s 
  * Specialized applications, specialized OS, specialized hardware 
  * Vertically integrated, closed, proprietary 
* Then 
  * Open interface, rapid innovation, huge industry 
* Availability of merchant switching chips 
  * On top of there: multiple control planes 
  * ![](/files/hMPrDjmiBhY1p8AIeFhI)
* SDN
  * ![](/files/WyB7X0DnZmmqwCIz8lvi)
* Example 
  * Interesting comparisons across OSPF (245 pages), Distributed System (101 pages), Dijkstra's Algorithm (4 pages) 
  * Start by building a distributed system! 
    * ![](/files/YmJuF1gM80veJdDapPvZ)
    * Replication comes at a cost (complexity, not elegant) 
    * Instead 
      * ![](/files/cyqgElkg0SSK4jvMLDIU)
      * Being refactored through different abstractions and different interfaces; make it easier to introduce new functionalities over time 
* **Openflow Forwarding Abstraction** 
  * Standardization have the benefits to give abstractions (but in a pragmatic way; perfection is not the goal here) 
  * ![](/files/g2OCQHj5cgWBCB7fxFrV)
  * Match Action Table 
    * ![](/files/jlD43GJba9w64nEW4mD3)
    * Actually all layers of the network is doing this 
    * As general as possible to match any header that you define 
    * How to use minimal sets of actions (meaningful set of primitives); leaving rooms for chip vendors to be able to implement it in hardware, and box vendors to differentiate by adding additional features / capabilities 
  * Protocol independent 
  * Backward compatible 
  * Technology independent 
    * Switches, routers, WiFi APs 
* SDN in development 
  * ![](/files/EX9a0AegJUrx1KX6ZO8r)

### How SDN will shape networking

#### 1. Empower network owners / operators 

* <mark style="color:green;">Customize networks to local needs</mark>
  * e.g. Add distributed load balancing&#x20;
    * What if we can jointly optimize path and server?&#x20;
    * Easy for testing&#x20;
* Eliminate unneeded features
  * Features not needed in the network, can increase reliability&#x20;
* Creation of virtual, isolated networks&#x20;
  * Isolate sets of users, multi-tenancy

#### 2. Increase the pace of innovations&#x20;

* <mark style="color:green;">Innovation at software speed</mark>&#x20;
  * Define the operations in software&#x20;
  * Can start doing much of the testing in software&#x20;
  * E.g. Mininet: Rapid for prototyping&#x20;
    * Light weight emulation; take any of these pieces, move them over machines and cores&#x20;
    * ![](/files/bZbI1oCGYV2qlZ6A6R7T)
    * Fast
      * Emulate network with 10s of switches on one laptop
      * Emulate network with 1000s of switches in server rack&#x20;
    * Rapid transfer&#x20;
      * Deploy unmodified code directly into live network
* Standards (if any) will follow software development&#x20;
* Technology exchange with partners&#x20;
  * Across boundaries, combine the boundaries use BGP etc.&#x20;
* Technology transfer from universities&#x20;

#### 3.  Diversify the supply chain

* A variety of software suppliers&#x20;
* Common hardware abstraction, with extensions&#x20;

#### 4. Build a robust foundation&#x20;

* Standardized forwarding abstraction
* Provable network properties at every step&#x20;
  * E.g. header space analysis: static checking&#x20;
  * Network transfer function: set of Bollean expressions&#x20;
  * Only relies on \<match, action>
  * Can prove reachability&#x20;