SDN: Week4: Control plane nuts and bolts

[gdt]

Control plane basics

OpenFlow controller communicates with switch over secure channel. Message format is OpenFlow Protocol. Logic executed at controller. Flow table updated on switch.

Switch components
Flow table. All packets examined for a match. Then action.
Secure channel. Communication to external controller.

Matching
Parse header fields.
Check for match in table 0, then apply actions, then exit.
Check for match in table 1, then apply actions, then exit.
Check for match in table n, then apply actions, then exit.
If no match, then send packet to controller over secure channel.

For scalability, match as many packets in the switch as possible.

Match fields in OpenFlow 1.0: ingress port, eth src, eth dst, eth type, eth vlan, eth pri, ip src, ip dst, ip tos, ip proto, tcp src port, tcp dst port.

Actions in flow tables
Forward (mandatory to implement): ALL (out all bar ingress interface), CONTROLLER (encapsulate and send to controller), LOCAL (send to switch control plane), TABLE (run flow table's actions), IN PORT (out ingress port). Optional to implement: normal forwarding, spanning tree.
Drop (mandatory to implement). If there is no action then drop the packet.
Modify (optional). Alter packet headers.
Enqueue (optional). Send to an output port queue, for QoS.

Can talk to switch using OpenFlow protocol with dpctl. Can inspect and modify flow table entries.
"dpctl show tcp:127.0.0.1:6634".
"dpctl dump-flows tcp:127.0.0.1:6634". Display flow table.
"dpctl add-flow". Alter flow table, For example, "dpctl add-flow tcp:127.0.0.1:6634 in_port=1,actions=output:2"

OpenFlow 1.3 enhancements.
Action sets. Multipe actions on each packet.
Group. List of action sets. Can execute all the action sets in a group, nice way to do multicast. Indirect group, execute the something on all packets (decrementing TTL, MPLS tagging, QoS)
Each table can add to header fields, and alter headers.
The white papers are good.

Other SDN control architectures than OpenFlow
- Juniper Contrail. XMPP control plane. Can implement L2 and L3 virtual networks. "Open Daylight" is open source implementations of SDN controllers.
- Cisco Open Network Environment. Centralised controller, programmable data plane, can implement virtual overlay networks.

OpenFlow protocol is evolving. OpenSwitch doesn't include newer protocol options.

The controller

Lots of SDN controllers ("almost as many SDN controllers as SDNs :-)")

A quick list:
NOX/POX
Ryu
Floodlight
Pyretic
Frenetic (OCAML)
Procera
RouteFlow (for SDNs interested in inter-domain routing)

Considerations
Programming language. Comfort and performance.
Learning curve.
Active community. Community serves as base of support.
Areas of focus. Southbound or northbound ("policy layer") API. Support for OpenStack. Education, Research or Production.

NOX.
The first OpenFlow controller. Open source, stable, widely used.
"NOX-classic": C++ and Python, no longer supported.
"New NOX": C++, fast, well written, maintained and supported.
Users write in C++.
Programming model is that programmers write event handlers.
Supports OpenFlow 1.0 ("CPqD" fork supports 1.1, 1.2, 1.3)
When to use NOX: you know C++, willing to use low-level facilities (eg, meddle with southbound API), you need performance.

POX.
NOX in Python.
Supports OpenFlow 1.0 only
Widely used, maintained, supported.
Relatively easy to read and write code.
Poorer performance.
When to use POX: rapid prototyping, and thus research, demos, learning SDN concepts.

Ryu.
Python
OpenFlow 1.0, 1.2, 1.3, Nicera
Works with OpenStack. A could operating system.
Poorer performance.
Moderate learning curve.

Floodlight.
Java
OpenFlow 1.0
Fork of "beacon" maintained by Big Switch Networks.
Good documentation. REST API. Production performance. OpenStack integration.
Disadvantages: steep learning curve.
When to use Floodlight: production performance, you know Java, REST API

Summary
Critera for choice: OpenFlow versions, Language, Performance, OpenStack integration, Learning curve.

Control plane - switching

Use mininet to set up topology

sudo mn --topo single,3 --mac --switch osk --controller remote

Note that pings fail, as there is no controller running.

Can use dpctl to add flow entries

Aside: hub: ingress packet is flooded out all ports bar ingress port.
Have a look at hub.py. The method launch() adds a listener for new OpenFlow switches.
pox.py forwarding.hub
You can see OpenVSwitch connect to POX. You can type "net" at mininet and see "c0".

Upon a connection up event our controller sends a message to flood packets out all ports:

msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))

Can also implement a learning switch.
- use srcmac and ingress port to update (dstmac, egress port) table
- drop BPDUs and LLDP
- if multicast (dstmac) then FLOOD
- if dstmac not in table then FLOOD
- if egress port same as ingress port then DROP (avoid loops)
- install flow table modification entry to OpenFlow switch, to send (ingress, dstmac) to egress.

pox.py forwarding.l2_learning
launch() method registers for callback.
for each connecting OpenFlow switch, instantiate a learning switch object and pass it the connection
the learning switch sets up a table, installs a packet listener, and then implements the learning switch algorithm and sends flow table modifications.

Control plane - firewalls

Extend the L2 learning switch to add firewall rules. Illustrating how easy it is to make significant functional changes with small amounts of code.

L2 switching just uses dst mac addr.  OpenFlow switching has many more header fields available. In our example, the src mac addr.

Augment the controller to check the src mac addr by adding another step to check the src mac addr. Add a hash table (switch, mac) which returns True to pass a packet, False or not existent to drop a packet.

Add this code:

if self.CheckRule(dpidstr, packet.src) == False:
    drop()
    return

What is CheckRule()

self.firewall = {}
def AddRule(self, dpidstr, src=0, drop=True):
    self.firewall = [(dpidstr, src)] = value

CheckRule sees if there is a entry in the hash table.

def CheckRule(self, dpidstr, src=0):
    try:
        return self.firewall[(dpidstr, src)]
    except KeyError:
        return False

To allow a MAC address to communicate:

self.AddRule('00-00-00-00-00-01', EthAddr('00:00:00:00:00:01'))
self.AddRule('00-00-00-00-00-01', EthAddr('00:00:00:00:00:02'))

Performance: cache decisions at switch using the flowtable in the switch
- limits traffic to controller, which has high latency

Summary
- customising control is easy
- performance benefit of caching decisions at switch

Programmable data plane (module 5)

Data plane operation
- ingress packet
- get dst addr
- look up dst addr in forwarding table, returning egress interface
- modify header, lowering TTL, and altering checksum
- queue and egress packet

The lookup for IP forwarding is simple: longest prefix match. Compare that with OpenFlow's match:action list.

Richer actions in data plane.
- data plane is streaming algorithms that match on packets
- wide range of functions: forwarding, ACLs, mapping headers, traffic monitoring, buffering, marking, shaping, scheduling, DPI.

Motivation for software data plane
- network devices are diverse
- difficult to alter
- can we extend current data plane: flexible, extensible, clean interfaces

Click modular router, a customisable data plane
- elements are the building block: switching, lookup, classification, dropping, etc
- these elements are clicked together into a pipeline
<pre>FromDevice(eth0) -> Print(ok) -> Discard;</pre>
<pre>click -f config.cfg</pre>
Can build up NATs, tunnels, etc. Can build an entire IP router.

Summary
- data plane needs to be programmable
- Click. open, extensible, configurable
- complex data plane functions can be built from simple building blocks
- performance is acceptable (0.9 of native speed on Linux)

Scaling programmable data planes - making software faster

Want the flexibility of software but speed of hardware, so:
- make software perform better
- make hardware more programmable

Need a platform for developing new protocols
- high speed
- multiple data planes in parallel (for various experiments)

Approaches:
1. Custom software. Flexible, easy to program. Low forwarding speeds.
2. Modules in custom hardware. Long development cycles, rigid.
3. Programmable hardware. Flexible and fast, but programming can be difficult.

Typical routers, N linecards, running at R, switch fabric running at NxR.

RouteBricks
- line cards on servers
- each server must pass c x R bps
- interconnect must pass at NxR. We want internal link rates < R (if we needed a speedup then we couldn't use commodity hardware)
- we'd like the fanout to be constant, not a rising number of interior interfaces (and thus falling number of exterior interfaces) as switch becomes larger.

Challenges
- limited internal link rates
- limited per-node processing rate
- limited fanout

Strawman approach: connect everything to everything. Doesn't scale.

Valiant load balancing: intermediate servers. This reduces interconnects speeds to R/N, but servers must process traffic at 3R (2R if load is equally ballanced).

Servers must also be fast.
Problem 1. Processing packets one at a time has huge bookkeeping overhead. These can be batched, at the cost of latency and jitter.
Problem 2. Map ports to cores. Approach #1: 1 core per queue (avoids locking). Approach #2: 1 core per packet (faster).

Other speed tricks:
- large socket buffers (PacketShader)
- batch processing(PacketShader)
- ethernet GRE (tunnelling, thus avoiding lookups) (Trellis)
- avoiding lookups when bridging from VMs to physical interfaces (Trellis)

Summary
- software can be fast
- general purpose processors and hardware can be fsat, but the details do matter
- Intel Data Place Development Kit (DPDK) is a commercial effort

Making hardware more programmable

What do we want from SDN? Does current hardware provide this?
- protocol independent processing (ie, independent of STP, OSPF, etc)
- control and repurpose in the field
- fast low power ships

Current hardware constrains what can be done
- protocol dependent because of capabilities of existing chips
- OpenFlow has mapped its features onto what is available on existing chips
- quick adoption, but constrains what is in OpenFlow

There are a few primitives we want a network device to perform
- parsing and rewriting headers
- bit shifting, etc
- traffic shaping
- forwarding
- etc

Build a flexible data plane by hardware modules and ways to interconnect them.

Two examples:
- an OpenFlow chip
- a programmable, modular data plane on a FPGA

OpenFlow chip
- 64 x GE OpenFlow-optimised 28nm ASIC
- 32 stages of (match, action)
- large tables, 1M x 40b TCAM, 370Mb SRAM
- uses VLIW Action processing, very RISC-like

Match tables use TCAM and SRAM. Matches are "logical", allowing complex matches to span multiple processor stages.

Actions hit a VLIW "action processor", these are small (1mm^2) and so you can run multiple in parallel.

Can't do more complex operations (transcoding, tunnels, encryption, etc)

SwitchBlade
Modular hardware building blocks to perform a range of data-plane functions.

Enable or disable and connect these building blocks using software.

Step 1, Select Virtual Data Plane
Operations can be in parallel, including multiple data planes ("virtual data plane"). SwitchBlade puts ingress packets into a VDP, each VDP has it's own processing pipeline, lookup tables, forwarding modules.

A table maps src mac addr to VDP. This attaches a 64b "platform header" to control functions in the pipeline.

Step 2, shaping

Step 3, preprocessing

Steps: processing selector | custom processor | hasher

Processing functions are from a library of reusable modules (Path Slicing, IPv6, OpenFlow).

Hash is created from user-selected bits in header. That hash then allows customised forwarding based on arbitary bits in header.

For example, a limited OpenFlow forwarder: parse packet, extract data for tuples, this 240b "bitstream" passed to hasher, hasher outputs 32b value for controlling processing an forwarding.

New modules require Verilog programming.

Step 4, forwarding

Steps: egress port loopkup based on hash | postprocessor wrapper modules | custom postprocessor

Wrapper modules allow matching on custom packet header bits

Custom postprocessors allow other functions to be selected on the fly

Software exceptions
Throw a packet to software. The passed-up packet has VDP and Plaform Header, allowing Virtual Data Plane to continue in software.

Custom postprocessing
eg: Decrement TTL for IPv6
per-VDP.

Summary
Make hardware more programmable
There are a few primatives, allowing these to be composed gives simple hardware yet flexible software
Two examples: OpenFlow Chip, SwitchBlade.