9.1 - Programming SDNs

Question 1

SDN Programming: Three Steps

Answer 1

1. Read/monitor State
   Includes:
     -Failures
     - topology changes
     - security events

2. Compute policy based on the state that the controller sees from the network.
3. Write policy back to the switches by installing the appropriate flow table state into the switches.

Question 2

What if more packets arrive before a rule is installed?

Answer 2

Solution:

1. Programmer specifies “Limit(1)”, indicates that the application should only see the first packet of the flow
2. Runtime system hides extra events

Question 3

Solutions in order to help guarantee consistency when reading state

Answer 3

• predicates
• unfolding
• suppresion

Question 4

Reasons a controller might want to write policy to change the state and the network switches

Answer 4

• Maintenance
• Unexpected failure
• Traffic engineering

Question 5

Ensuring forwarding remains correct and consistent

Answer 5

• No forwarding loops
• No “black holes”
• No security violations

Question 6

What problems can arise from inconsistent “writes” of network state?

Answer 6

• Forwarding loops

- Security policy violations

Question 7

What are some ways of coping with inconsistency?

Answer 7

Keeping the old and new state on the routers/switches

Question 8

What is network virtualization

Answer 8

Abstraction of physical network
-> multiple logical networks on shared physical substrate

Nodes: VMs
Links: Tunnels

Question 9

Why Virtual Networking?

Answer 9

“Ossification” of Internet architecture

-> Network virtualization enables evolution by letting multiple architectures exist in parallel

Question 10

Motivation for virtual networking?

Answer 10

• Facilitating research/evolution by allowing coexistence

- Adjusting resources to demand

Question 11

Promise of Network Virtualization

Answer 11

1. Rapid innovation (software speed)
2. New forms of network control
3. (Potentially) simpler programming

SDN vs Network Virtualization

SDN: Separate data and control
Network Virtualization: separate logical and physical

Question 12

Characteristics of network virtualization

Answer 12

• Allowing multiple tenants to share underlying physical infrastructure
• Separating logical and physical networks

Question 13

Various Design Goals of Virtual Networks

Answer 13

• Flexible
• Manageable
• Scalable
• Secure
• Programmable
• Able to support different technologies

Question 14

Two Components of Virtual Networks

Answer 14

Nodes: VMs (or virtual environments)
examples: Xen, VMWare, Vservers

Edges: Tunnels

Question 15

Programming OpenFlow not easy. Why?

Answer 15

• 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

Question 16

Solution to programming OpenFlow?

Answer 16

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.

Question 17

Frenetic Language

Answer 17

SQL-Like Query Language

Example:
select (bytes)
where (in:2 & srcport :80)
groupBy(dstMAC)
every(60)

Question 18

Parallel (Policy Composition)

Answer 18

Perform both operations simultaneously

eg., counting + fowarding

Question 19

Sequential (Policy Composition)

Answer 19

Perform one operation, then the next

e.g., firewall, then switch

Question 20

Example of Sequential Composition

Answer 20

Load Balance

A policy might take some traffic coming from half of the source IP addresses and rewrite that to one

Question 21

Pyretic

Answer 21

SDN Language and Runtime

Language: express policies
Runtime: compiling these policies to OpenFlow rules

Key abstraction: “located” packets

Question 22

Pyretic Features

Answer 22

• 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()