9.1 - Programming SDNs Flashcards
SDN Programming: Three Steps
1. Read/monitor State
Includes:
-Failures
- topology changes
- security events
- Compute policy based on the state that the controller sees from the network.
- Write policy back to the switches by installing the appropriate flow table state into the switches.
What if more packets arrive before a rule is installed?
Solution:
- Programmer specifies “Limit(1)”, indicates that the application should only see the first packet of the flow
- Runtime system hides extra events
Solutions in order to help guarantee consistency when reading state
- predicates
- unfolding
- suppresion
Reasons a controller might want to write policy to change the state and the network switches
- Maintenance
- Unexpected failure
- Traffic engineering
Ensuring forwarding remains correct and consistent
- No forwarding loops
- No “black holes”
- No security violations
What problems can arise from inconsistent “writes” of network state?
- Forwarding loops
- Security policy violations
What are some ways of coping with inconsistency?
Keeping the old and new state on the routers/switches
What is network virtualization
Abstraction of physical network
-> multiple logical networks on shared physical substrate
Nodes: VMs
Links: Tunnels
Why Virtual Networking?
“Ossification” of Internet architecture
-> Network virtualization enables evolution by letting multiple architectures exist in parallel
Motivation for virtual networking?
- Facilitating research/evolution by allowing coexistence
- Adjusting resources to demand
Promise of Network Virtualization
- Rapid innovation (software speed)
- New forms of network control
- (Potentially) simpler programming
SDN vs Network Virtualization
SDN: Separate data and control
Network Virtualization: separate logical and physical
Characteristics of network virtualization
- Allowing multiple tenants to share underlying physical infrastructure
- Separating logical and physical networks
Various Design Goals of Virtual Networks
- Flexible
- Manageable
- Scalable
- Secure
- Programmable
- Able to support different technologies
Two Components of Virtual Networks
Nodes: VMs (or virtual environments)
examples: Xen, VMWare, Vservers
Edges: Tunnels
Programming OpenFlow not easy. Why?
- Low level of abstraction
- controller only sees events that switches do not know how to handle
- race conditions if switch-level rules not installed properly
Solution to programming OpenFlow?
Solution: “Northbound” API
A programming interface that allows applications and other kinds of orchestration systems to program the network
Need a higher level programming interface that allows these applications to talk to the controller so the application isn’t writing low-level OpenFlow rules, but rather is expressing what it wants to have happen in terms of higher-level behaviors.
Frenetic Language
SQL-Like Query Language
Example: select (bytes) where (in:2 & srcport :80) groupBy(dstMAC) every(60)
Parallel (Policy Composition)
Perform both operations simultaneously
eg., counting + fowarding
Sequential (Policy Composition)
Perform one operation, then the next
e.g., firewall, then switch
Example of Sequential Composition
Load Balance
A policy might take some traffic coming from half of the source IP addresses and rewrite that to one
Pyretic
SDN Language and Runtime
Language: express policies
Runtime: compiling these policies to OpenFlow rules
Key abstraction: “located” packets
Pyretic Features
- Network policy as function
- Boolean predicates (not possible in OpenFlow)
- Virtual packet header fields
- Composition
OpenFlow: bit patterns
Pyretic: functions
packets -> other packets
identity -> original packet none -> o (drop) match(f=v) mod(f=v) fwd(a) -> mod (outport=a) flood()
