# 50.012 Lecture 16
Textbook Section 4.4, 5.5
# Software-Defined Networking
Historically, control plane has been implemented in a distributed, per-router manner.
In the center of the network, there are different "middleboxes" for different network layer functions: firewalls, load balances, NAT boxes, etc.
In ~2005, there was a renewed interest in rethinking network control plane.

The idea behind SDN was to shift the computation complexity from each router to a centralized remote controller.

An important consideration for SDN is that under SDN, if someone were to implement a new routing protocol, there is no need to convince the industry giant who controls the routing protocol.

## Motivation: Pain Points in Traditional Routing Protocol
### Control over Intra-Network Traffic Routing
Motivation question: What if network operator wants u-to-z traffic to flow along uvwz, x-to-z traffic to flow xwyz?

In traditional routers, each router is very capable and is able to compute its own forwarding table.

Operator will need to then redefine link weights so traffic routing algorithm could compute routes accordingly (or they need a new routing algorithm).
This is wrong. :<

### Load Balancing
Motivation question: What if network operator wants to split u-to-z traffic along uvwz and uxyz (load balancing)?

There is no way to do it without SDN.
Each router can only have one path to go from source to destination.

## Logically Centralized Control Plane
There are multiple reasons to centralize the control plane:
* Easier network management: avoid router misconfigurations, greater flexibility of traffic flows.
* Forwarding rules is generalized so that it's not only based on destinations (extend to include more fields).
* Table-based forwarding allows routers to be "programmed".
* Centralized "programming" is easier: tables are computed centrally and are distributed.
* Distributed "programming" is more difficult, as the tables computed are results of distributed algorithm implemented in each router.
* Non-proprietary implementation of control plane.

## SDN Implementation
Each layer can now be developed independently, and APIs will be used to communicate between layers.

### Data Plane Switches
Fast, simple, commodity switches that implement generalized data-plane forwarding in hardware.
Switch flow table is computed and installed by the controller.

An important protocol between the middle layer and the data plane is OpenFlow (Southbound API). It defines what is controllable and what is not.

### SDN Controller (Network OS)
It maintains the network state information.
It interacts with network control applications "above" via northbound API.
It interacts with network switches "below" via southbound API.
It is implemented as distributed system for performance, scalability, fault-tolerance, robustness.

### Network-Control Apps
We want more innovative applications to be supported by this infrastructure.

This layer is the "brains" of the network control: it implements control functions using lower-level services, API provided by SDN controller.

It can be provided by 3rd party: distinct from routing vendor or SDN controller.

### Components of SDN Controller

### OpenFlow Protocol


It operates between controller and switch, and uses TCP to exchange messages. The default port used is 6653.

There are 3 main classes of OpenFlow messages:
* controller-to-switch
* asynchronous (switch-to-controller)
* symmetric (misc)

#### Controller-to-switch
Key controller-to-switch messages:
* Configuration: controller queries/sets switch configuration parameters
* Modify-state: add, delete, modify flow entries in the OpenFlow tables.
* Read-state: collect statistics and counter values from the flow table and ports
* Send-packet: sends a specific packet (in its payload) out of a specific switch port.

#### Asynchronous
Key switch-to-controller messages:
* Packet in: transfer packet (and its control) to controller. Since the switch does not know how to deal with this packet, the control (instructions) will also be sent along with the packet so that the switch will know what to do with the packet.
* Flow-removed: flow table entry deleted at switch. Sometimes a flow may have TTL / expiry. Once expired, the switch will inform the controller that this flow has expired.
* Port status: informs controller of a change in port.

Network operators are not required to "program" switches by creating/sending OpenFlow messages directly. Instead, a higher-level abstraction is used at the controller.

### Example of Control/Data Plane Interaction

# Generalized Forwarding
## Generalized Forwarding and SDN

Each router contains a flow table that is computed and distributed by a logically centralized routing controller.

Together with SDN, there is a movement to generalize the forwarding data plane to allow it to be more flexible.
Forwarding table is now called a flow table.
### OpenFlow Data Plane Abstraction

Flow is defined by a header fields.
Once a flow matches (according to its pattern), we can start to do actions for the matched packets.

There are a few of simple packet-handling rules:
* Pattern: match values in packet header fields.
* Actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller.
* Priority: disambiguate overlapping patterns (for QoS)
* Counters: #bytes and #packets.

Flow table in a router (computed and distributed by controller) define router's match + action rules.

Examples of patterns:

### Flow Table Entries

The reason behind having separate counters for packet and byte is because each packet can have varying number of bytes.

Examples (Network layer)

Examples (Link layer)

### OpenFlow Abstraction
match+action: unifies different kinds of devices.

### OpenFlow Example
The argument inside the forward() action refers to the port number that is used to forward the packet.

Ingress port is used to specify the rule (matching criteria) to only do the action when incoming packet is from that particular port.