SDN: Week 6: Future: Module 8.2: Open problems and challenges

This is some highlights

1. Northbound API and applications
- wide area netowrking and interdomain routing
- programming and debugging

2. Control plane
- security, data leak prevention
- combining big data and network mgnt
- orchestration - coordination of increasingly diverse network devices

3. Data plane
- moving beyond (match, action)

New applications and services
- SDN is a tool, not a killer application

Wide area networking
- brittle
- indirect mechanisms
- dst prefix
- influence only neighbour ASs
- use of SDN in IX might be disruptive
- business relationships are coarse-grained, SDNs allows more subtlety.

Programming and debugging
- getting easier
- but still difficult
- composition between controllers is hard
- making debugging and testing easier

Security
- currently no accountability
- security properties are difficult to verify and enforce
- data leaks common

Big data
- no existing technology takes advantage of huge amount of data about networks
- aim is intelligent network controllers

Orchestration and beyond (match, action)
- SDN is any controller controlling multiple data plane units
- still need a unifying control frameork for coordination of increasingly diverse network devices.

Summary: open problems
- northbound API: programming, new applications
- control plane: orchestration
- data plane: beyond (match, action)

SDN: Week 6: Future: Module 8.1: A broader vision of SDN

SDN paradigm is switches performing (match, action), both match and action are limited
- no payload examination
- no advanced actions

Expanding this requires a practical approach
- extending OpenFlow
- implementing a richer data plane in the controller: flexible, but performance
- send traffic through custom devices: middleboxes, custom hardware

Middlebox orchestration -- "Slick"
- installs code on middleboxes
- if the middleboxes raise events then Slick handles them
- installs OpenFlow rules on switches to divert desired traffic through the middleboxes

Slick elements
- arbitrary code. Functions implement Slick API. Raises trigger at controller.
- self-describing manifest: hardware requirements (so only placed on a middlebox which can run the element), triggers, network requirements (eg, seeing both directions of traffic, or all traffic to a host, etc)

Slick application
- implements network policies: which elements to run on which traffic, how to react to changes in network conditions
- controller abstracts policy away from the application (where to place elements, how traffic should be routed)

Slick controller
- manages and configures a network of middleboxes. Resource discovery. Deploys elements. Ensures element availability in the face of failure.
- implements policies for the application. Where to place elements. How to steer traffic to elements.

Eg: Dynamic redirection
- inspect all DNS traffic with a DPI device
- if suspicious lookup, send to traffic scubber

Custom data plane orchestration
- put Custom Packet Processors in network
- use a device abstraction layer to allow programming of the Processors (individually, and as a fabric)

Applications
- big data
- encryption, transcoding, classification
- selective DPI

Summary:
- SDN is broader than OpenFlow and (match, action)
- SDN is about separating data plane and control place
- That allows orchestration

SDN: Week 6: Module 7.4: Home networks

Two challenges
1. Visibility of usage and problems
2. Controls to better manages resources, usage caps, etc

Home network configuration is complex and low level. Too much complexity is exposed to user. But still no visiblity or controll "how much data on quota", "which application is using my bandwidth", "how is using the bandwidth".

Use SDN to centralise control
- controller outside the home, monitoring the home router
- build GUIs on to of the controller

Example
- based on resonance
- tracks usage caps by device, shift hungry devices from normal to capped state

Eg 1: Home network management
- outsource home mgnt
- key problem is usage control
- users don't understand how different devices use the cap
- UCAP -- users can see how different devices contribute. Users can the control and cap devices' use. All implemented by resonance.

Eg 2: Slicing home netowrk
- allow SPs (phone, video, etc) direct access to home infrastructure
- use flowspace concept to allocate network resources.

SDN: Week 6: Module 7.3: Google backbone B4

Google has two backbones: user and inter-data centre.

Google has many WAN-intensive applications. The cost per bit doesn't decrease as network size increases.
- complexity of pairwise interactions
- manual management
- non-standard vendor APIs

Solution: "WAN fabrics"
- manage it as a fabric, not as individual boxes
But
- many boxes and protocols are box-centric
- distributed routing protocols aren't aware of congestion caused by each other
- want centralised traffic engineering: better network utilisation, faster convergence, more control, can specify intent, mirror prodution event streams for testing, modern server equipment for controller (about 50x faster than a router's CPU)

SDN also helps testing
- decentralised networks require full scale testbed replica of network to test new TE features
- centralised control can use the real production network as input, use a replica controller with production binaries, but virtualised switches. This is exactly what is done with mininet.

Summary
- choose hardware based on features
- choose software based on protocols
- logical centralised TE: easier mgnt, easier testing
- separates monitoring, mgnt and ops from individual boxes.

SDN: Week 6: Module 7.2: IXs

Limitations of BGP
- routing only by dst prefix (no customisation by application, sender, etc)
- influence only over immediate neighbours, not the end-to-end path
- only indirect expression of policy (med, prepend, etc)

Evolve the inter-domain routing at a IX
- lots of people connect, to lots of benefit
- IXs looking for differentiation
- new applications (eg, streaming) create need for richer peering

Opportunities for SDN at IXs:
- freedom from routing constraints: matching different packet header fields, control messages from remote networks, direct control over data plane
- challenges: no existing SDN control framework, scaling issues as thousands of customers at IXs

What IXs can't do today:
- application-specific peering (eg, for video)
- redirect subsets of traffic to middleboxes
- traffic offloading (say two ISPs connecting to same transit at IX, automatically peer those ISPs rather than trombone traffic)
- prevent free-riding (dropping ingress traffic from non-peers)
- wide area load balancing (currently done through DNS, an indirect mechanism)

SDX initial design
- controller runs switches
- it takes routes and other attributes
- route selection function per AS
- load FIB entries into switch
- rules to rewrite packet headers

1. Controller recieves routes
2. Each participant submits a function to controller to select routes, rewrite headers, etc.
3. Controller pushed those rules to IX switches

Architecture
- Pyretic
- SDX runtime
- App for each IX member, with the apps seeing only the topology for that IX member
- runtime uses composition to resolve conflicts

Virtual software IX abstraction
- ISPs with no IX relationship don't see each other
- enforced by symbolic execution (ie, tagging packets in ingress, then uses state machine to validate or determine egress port) So packets can't take non-compliant paths
- SDX runtime composes policies in order of AS traversal (egress AS, then ingress AS)

Summary
- interdomain routing plagued by security, manageability
- SDN-based exchange is a promising approach
- research, not production

SDN: Week 6: Module 7.1: Data centres

Data centres are used for cloud computing, where elastic infrastructure can be allocated as demands changes.
- software as a service
- platform as a service
- infrastructure as a service

Key enabling technology is virtualisation.
- applications run unmodified
- VMs can migrate, without knowledge of customer, depending on demand
- easier if a large layer 2 network

Requirements
- easy migration of VMs
- minimal configuration of switches
- efficient communication along forwarding paths
- loopfree
- failure detection fast effective

Pre-SDN datacentres
- core to internet via L3 router
- access switches to servers
- aggregation switches in the middle

Problems:
- core routers single point of failure
- links higher in topology may be oversubscribed
Therefore:
- multirooted fat tree

Need a large L2 topology
- minimal configuration
- scaling problems: state, avoiding flooding (ARP, etc), fast updates to addressing on a VM move

PortLand: SDN for data centre networks
- "fabric manager"
- each host has a pseudo MAC addr with heirarchical structure
- thus efficient forwarding
- need to intercept and re-write MAC addresses
- need to rewrite ARPs
- done by Fabric Manager

MAC learning
- new source MAC addresses are forwarded to Fabric Manager
- FM constructs mapping to pseudo MAC

ARP
- edge switch sends ARP to FM
- FM proxy ARPs, returning PMAC

Strong similarities to SDN.

Summary
- data centre networks have unique requirements for scaling and flexiblilty
- 10,000s servers
- minimal configuration and state
- quickly migrate VMs
- PortLand Fabric Manager is a early SDN controller for data centres
- using structured pseudo MACs and intercept-and-proxy ARP

SDN: Week 5: Programming SDNs: Module 6.4: Event-driven control

Network configuration must respond to changing network conditions
- eg: peak/offpeak, shifts in traffic load, security events
- eg: ratelimit bittorrent traffic in business hours, if host infected then send to captive portal

Dynamic-driven control domains:
- time (peak, dates)
- history (data usage, traffic rate, delay or loss)
- user (identity or policy group)
- plus the usual packet headers

Resonance: a finite state machine
- dynamic event handler listens to network events then updates state
- the state change may update the flowtable entries on switches

Example: access control for campus network
- guest portals and infection scanners want to change user VLANs, but changing a device's IP address needs a reboot
- doing this in OpenFlow can express what the host can reach in different state, the host doesn't need to readdress as the VLAN doesn't change

Can run seperate state machines and then sequentially compose them.
- eg: authentication (with states Authenticated, Unauthenticated) and instrusion detection (with states Quarantined, Clean)

Summary:
- network configuration often has to respond to events
- state machines can determine which rules to install
- composition can help keep the FSM simple