Software Defined Networking COMS 6998-10, Fall 2014

Software Defined NetworkingCOMS 6998-10, Fall 2014

Instructor: Li Erran Li ([email protected])

http://www.cs.columbia.edu/~lierranli/coms6998-10SDNFall2014/

9/29/2014: SDN Programming Language



Software Defined Networking (COMS 6998-10) 2

Outline

• Announcements– Homework 2 will be posted on Thursday, due in 18 days

• Review of previous lecture• Project ideas on scalable controller for cellular

WAN• SDN programming language– Maple: generic programming language syntax such as

Java, Python– NetKAT: domain specific programming language

9/29/14


Review of Previous Lecture

• How do we design scalable software defined networks?– Design scalable controllers– Offload control plane processing to switches

• How do we design scalable controllers? – Flat structure multiple controllers – Recursive controller design– Hierarchical controller design

9/29/14


Review of Previous Lecture (Cont’d)

• How to offload control plane processing to switches?– Offload to switch control plane

• Controller proactively generates the rules and distributes them to authority switches

• Authority switches keep packets always in the data plane and ingress switches reactively cache rules

– Offload to switch data plane• Try to stay in data-plane, by default• Provide enough visibility: for significant flows & sec-sensitive

flows; Otherwise, aggregate or approximate statistics

9/29/14



How do we divide tasks among controller instances?• Partition– Controller instances with different computations

tasks– Controller instances have only subsets of the NIB– Switches connect to a subset of controller instances

• Aggregation– Reduce fidelity of information

9/29/14



• How to maintain network information base (NIB)?– Replicated transactions (SQL) storage for strong

consistency (more static information)– One-hop memory-based DHT for weak consistency

(more dynamic information)

9/29/14


Following packets


Ingress Switch

Authority Switch

Egress Switch

First packet Redirect

Forward

Feedback:

Cache rules

Hit cached rules and forward

Offload to switch control plane

Source: Minlan Yu9/29/14

Review of Previous Lecture (Cont’d)• Rule cloning– ASIC clones a wildcard rule as an exact match rule for new

microflows– Timeout or output port by probability

89/29/14 Software Defined Networking (COMS 6998-10)

Review of Previous Lecture (Cont’d)• Local actions– Rapid re-routing: fallback paths predefined

Recover almost immediately– Multipath support: based on probability dist.

Adjusted by link capacity or loads



Outline




Java, Python– Frenetic: domain specific programming language

9/29/14

LTE Cellular Network Architecture

access core

Packet Data Network Gateway

Serving Gateway

InternetServing Gateway

Base Station (BS)

User Equipment (UE)

139/29/14Software Defined Networking (COMS 6998-10)

Current Mobile WANs• Organized into rigid and very large

regions• Minimal interactions among regions • Centralized policy enforcement at

PGWs

Two Regions14


Mobile WANs Problems• Suboptimal routing in large carriers– Lack of sufficiently close PGW is a major

cause of path inflation

• Scalability and reliability– The sheer amount of traffic and centralized

policy enforcement

• Ill-suited to adapt to the rise of new applications– E.g., machine-to-machine– All users’ outgoing traffic traverses a PGW to

the Internet, even for reaching a user served by a close base station in a neighbor region 159/29/14 Software Defined Networking (COMS

6998-10)

SoftMoW MotivationQuestion: How to make the packet core scalable, simple, and flexible for hundreds of thousands of base stations and hundreds of millions of mobile users? • Mobile networks should have fully connected core

topology, small logical regions, and more egress points • Operators should leverage SDN to manage the whole

network with a logically-centralized controller:– Directs traffic through efficient network paths that

might cross region boundaries– Handles high amount of intra-region signaling load

from mobile users– Supports seamless inter-region mobility and

optimizes its performance– Performs network-wide application-based such as

region optimization 169/29/14 Software Defined Networking (COMS 6998-10)

SoftMoW Solution• Hierarchically builds up a network-wide control plane

– Lies in the family of recursive SDN designs (e.g. XBAR, ONS’13)

• In each level, abstracts both control and data planes and exposes a set of “dynamically-defined” logical components to the control plane of the level above.– Virtual Base stations (VBS), Gigantic Switches (GS), and

Virtual Middleboxes (VMB)

17Core Net

GS

Latency Matrix

RadioAccess Network

VBS

Union of Coverage

Policy

VMB

Sum of capacities


• New Dynamic Feature: In each level, the control logic can modify its logical components for optimization purposes– E.g., merge/spilt and move operations

18

SoftMoW Solution

Move and SplitMerge/Split


First Level-SoftMoW Architecture

• Replace inflexible and expensive hardware devices (i.e., PGW, SGW) with SDN switches

• Perform distributed policy enforcement using middle-box instances• Partition the network into independent and dynamic logical regions • A child controller manages the data plane of each regions

Bootstrapping phase:

based on location and processing

capabilities of child controllers


Second Level-SoftMoW Architecture

• A parent runs a global link discovery protocol– Inter-region links are not detected by BDDP and LLDP

• A parent participates in the inter-domain routing protocol • A parent builds virtual middlebox chains and egress-

point policies, and dictates to GSs


Hierarchical Traffic Engineering

Latency (P1,E2)=300

Latency (P1,E4)=100

WebVoice GS

Rules

21

• A parent pushes a global label into each traffic group

• Child controllers perform label swappingo Ingress point: pop the global label and push some local labels for

intra-region pathso Egress point: pop the local labels and push back the global label

Push W Pop W

Push W

Push W

Push W2Push W1

Pop W2

Pop W

Pop W1


Time-of-day Handover Optimization

Handover graph

22

Q: How can an operator reduce inter-region handovers in peak hours?

Abstraction update

GS Rule:Move Border VBS1

coordination


Project Ideas

• Implement a G-switch driver/agent: acts as a shim to allow a G-switch to act like an actual OF switch. – This driver helps to connect any OF controller as a G-switch

to its parent OF controller. In this way, installing rule-actions into G-switches and setting up paths on abstract topology becomes like the physical topology.

– Driver should translate the messages or states received from the parent OF controller to the underlying topology and periodically pulls states from the local NIB to expose to the parent.

• Implement HazelCast on a single controller – Show performance improvement on various applications

such as traffic engineering, routing, and failure recovery over the standard in-memory data structures for a single controller. 239/29/14 Software Defined Networking (COMS

6998-10)

Project Ideas (Cont’d)

• Implement recursive link discovery protocol and the necessary translations in the shim.

• Implement RamCloud on a single controller– Show performance improvement on various applications

such as traffic engineering, routing, and failure recovery compared with the standard NIB.

• Implement an orchestration layer to provide global network view – Use ZooKeeper to dynamically assign controllers to data

plane switches as the network becomes larger on top of a single/flat controller.

• Implement the hierarchical control plane 249/29/14 Software Defined Networking (COMS 6998-10)


Outline




Java, Python– Frenetic: domain specific programming language

9/29/14


A Key Source of Complexity in Openflow Controllers

• onPacketIn(p):

examine p and decide what to do with p.Step 1

construct and install OF rules so that similar packets are processed at switches with same action.

Step 2

Source: Andreas Voellmy, Yale9/29/14


Simple, generic solution using exact matches

• onPacketIn(p):

examine p and decide what to do with p.Step 1

insert rule with “exact match” for p, i.e. match on ALL attributes, with action determined above.

Step 2

Every flow incurs flow setup delay.



Step 1 Step 2

p.TcpDst=22?

dropmatch:{TcpDst=22} action:drop

send to next hop for p.EthDst

match:{EthDst=p.EthDst} action:nextHop(p)

yes

no

priority:HIGH

priority:LOW

tcpDst!=22



EthDst:A,TcpDst:80

Controller

Switch

EthDst:A,TcpDst:22

Low EthDst:A Port 1

If p.TcpDst=22:

insert rule

{prio:HIGH, match:{TcpDst=22}, action:drop }

Else:

insert rule

{prio:LOW, match:{EthDst=p.EthDst},action:nextHop(p.EthDst)

9/29/14


OF Switches

User Level

Under the hood

OF Controller Library

Step 1. Make Decisions

Step 2. Generate Rules



Algorithmic Policy

OF Switches

OF Controller Library

Step 1. Make Decisions

Step 2. Generate Rules

User Level

Under the hood



Algorithmic Policies

• Function in a general purpose language that describes how a packet should be routed, not how flow tables are configured.

• Conceptually invoked on every packet entering the network; may also access network environment state; hence it has the form:

• Written in a familiar language such as Java, Python, or Haskell



Example Algorithmic Policy in Java

Route f(Packet p, Env e) { if (p.tcpDstIs(22)) return null(); else { Location sloc = e.location(p.ethSrc()); Location dloc = e.location(p.ethDst()); Path path = shortestPath(e.links(), sloc,dloc);

if (p.ethDstIs(2) return null(); else return unicast(sloc,dloc,path);

}}

Does not specify flow table configutation



How to implement algorithmic policies?

• Naive solutions -- process every packet at controller or use only exact match rules -- perform poorly

• Static analysis to determine layout of flow tables is possible, but has drawbacks:– Static analysis of program in general-purpose

language is hard and is typically conservative– System becomes source-language dependent



Maple’s approach: runtime tracing

Prio Match Action

1 tcpDst:22ToControll

er

0 ethDst:2 discard

0ethDst:4, ethSrc:6

port 30

Prio Match Action


er

0 ethDst:2 discard

0ethDst:4, ethSrc:6

port 30Prio Match Action


er

0 ethDst:2 discard

0ethDst:4, ethSrc:6

port 30

1. Maple observes the dependency of f on packet data.

2. Build a trace tree (TT), a partial decision tree for f.3. Compile flow

tables (FTs) from a trace tree.



Route f(Packet p, Env e) {

if (p.tcpDstIs(22))

return null();

else {

Location dloc = e.location(p.ethDst());

Location sloc = e.location(p.ethSrc());

Path path = shortestPath( e.links(),sloc,dloc);

if (p.ethDstIs(2) return null();

else return unicast(sloc,dloc,path); }}

EthDest:1,TcpDst:80

Assert(TcpDst,22)

false

Read(EthDst)

Read(EthSrc)

path1

4

6

Policy



EthDst:1,TcpDst:22

4

6

?

true

null

true

Assert(TcpDst,22)

Policy Trace Tree

false

Route f(Packet p, Env e) {

if (p.tcpDstIs(22))

return null();

else { Location dloc = e.location(p.ethDst());

Location sloc = e.location(p.ethSrc());

Path path = shortestPath( e.links(),sloc,dloc);

if (p.ethDstIs(2) return null();

else return unicast(sloc,dloc,path); }}

Assert(TcpDst,22)

Read(EthDst)

Read(EthSrc)

path1



Compile recorded executions into flow table

tcpDst==22

False

ethDst

2

drop

4

port 30

ethSrc

6

drop

True

match:{tcpDst==22}

action:ToController

match:{ethDst:4,ethSrc:6}action:[port 30]

Priority

barrier rule:

1

2

3



Basic compilation: in-order traversal & barrier rules

accumulated match: {}

{tcpDst:22}

(prio:3,{tcpDst:22},action:drop)

{}

{ethDst:2}{ethDst:4}

{ethDst:4,ethSrc:6}

(prio:0,{ethDst:4, ethSrc:6},action:[port 30])

(prio:1,{ethDst:2},action:drop)

(prio:2,{tcpDst:22},action:ToController)

Priority := 0Priority := 1Priority := 2Priority := 3

barrier rule:

tcpDst==22

ethDst

2

null

4

port 30

6

null

True

ethSrc

False



Basic compilation example result

• Trace tree method converts arbitrary algorithmic policies into correct forwarding tables that effectively use wildcard rules.

• Deficiencies:– More priorities levels than necessary– More rules than necessary

• Annotate TT nodes with extra information to improve compilation




(prio:2,{tcpDst:22},action:ToController) No effect

Can use priority 0



Optimization 1: Annotate TT nodes with completeness

tcpDst==22

False

ethDst

2

drop

4

port 30

ethSrc

6

drop

True

{}

{tcpDst:22}


{}

{ethDst:2} {ethDst:4}

{ethDst:4, ethSrc:6}



no barrier

complete

complete

complete



Optimization 2: Annotate nodes with priority dependencies

tcpDst==22

False

ethDst

2

drop

4

port 30

ethSrc

6

drop

True

{}

{tcpDst:22}


{}

{ethDst:2} {ethDst:4}

{ethDst:4, ethSrc:6}



1



Improved compilation result






Maple Status

• Maple has been implemented in Haskell using the McNettle Openflow controller, which implements Openflow 1.0.

• The implementation includes several other features: – Incremental TT compilation, to avoid full recompilation on

every update.– Trace reduction, to ensure traces and trace trees do not

contain redundant nodes.– Automatic and user-specified invalidation, to support

removing and updating TT and FT when network state changes.



Summary: Contributions

• Algorithmic policies provide a simple, expressive programming model for SDN, eliminating a key source of errors and performance problems.

• Maple provides a scalable implementation of algorithmic policies through several novel techniques, including:– runtime tracing of algorithmic policies,– maintaining a trace tree and compiling TT to flow tables to

distribute processing to switches;– using TT annotations to implement compiler optimizations

such as rule and priority reductions.



Outline

• Announcements– Homework 2 posted due in 18 days – Next lecture: first half by Josh Reich from

Princeton on Pyretic• Review of previous lecture• SDN programming language– Maple: generic programming language syntax such

as Java, Python– Frenetic: domain specific programming language

9/29/14


Key questions:

•What are the right abstractions for programming software-defined networks?

•How can we engineer trustworthy implementations that provide assurance?

Source: Nate Foster, Cornell9/29/14


Modular Abstractions



Combining Functionality

Challenges:•Writing, testing, and debugging programs•Reusing code across applications•Porting applications to new platforms

Controller Platform

Monitor + Route + Load Balance + Firewall

One monolithicapplication



RoutePattern Actions

dstip=10.0.0.1 Fwd 1


Pattern Actionssrcip=1.2.3.4 CountMonitor+

Pattern Actionssrcip=1.2.3.4, dstip=10.0.0.1 Fwd 1, Count

srcip=1.2.3.4, dstip=10.0.0.2 Fwd 2, Count

srcip=1.2.3.4 Count



Route+ Monitor



+



srcip=1.2.3.4 Count



Route+ Monitor

Pattern Actionstcpdst = 22 Drop

* Fwd ?

Firewall

Pattern Actionssrcip=1.2.3.4, tcpdst = 22 Count, Drop



srcip=1.2.3.4 Count

tcpdst = 22 Drop



RouteMonitorFirewall

++



Modular Applications

Controller PlatformMonitor Route Load Balance Firewall

Benefits:•Easier to write, test, and debug programs•Can reuse modules across applications•Possible to port applications to new platforms

One module for each task



Beyond Multi-Tenancy

Relatively straightforward to split rule, bandwidth, and network events across these modules

Slice 1 Slice 2 Slice 3 Slice N...

Controller Platform

Each module controls a different portion of the traffic



Modules Affect the Same Traffic

How should we combine a collection of such modules into a single application?

Controller Platform

Monitor Route Load Balance Firewall

Each module partially specifieshandling of all traffic



Language-Based Approach

Design languages based on modular programming abstractions, and engineer efficient implementations using a compiler and run-time system

Compiler + Run-Time System

Controller Platform

Monitor Route Load Balance Firewall



Language Constructs[POPL ’12, NSDI ’13]



Parallel Composition

Controller Platform

Monitor Route

Pattern Actionsdstip=3.4.5.6 Fwd 1

dstip=6.7.8.9 Fwd 2

Pattern Actionssrcip=1.2.3.4 Count

+



srcip=1.2.3.4 Count

dstip=3.4.5.6 Fwd 1

dstip=6.7.8.9 Fwd 2



Sequential Composition

Controller Platform

Load Balance Route

Pattern Actionsdstip=10.0.0.1 Fwd 1


Pattern Actionssrcip=*0 dstip:=10.0.0.1

srcip=*1 dstip:=10.0.0.2

;

Pattern Actions

srcip=*0 dstip:=10.0.0.1, Fwd 1

srcip=*1 dstip:=10.0.0.2, Fwd 2



Dividing Traffic Over Modules

Load Balance Route;

Monitor Route+

if then

else if then

dstport=80

dstport=22

elseDrop

Predicates specify which packets traverse which modules, using ingress port and packet-header fields



Example NetKAT Programopen NetKAT.Std

(* a simple repeater *)let repeater : policy = <:netkat< if port = 1 then port := 2 + port := 3 + port := 4 else if port = 2 then port := 1 + port := 3 + port := 4 else if port = 3 then port := 1 + port := 2 + port := 4 else if port = 4 then port := 1 + port := 2 + port := 3 else drop >>

let _ = run_static repeater

9/29/14


Example NetKAT Program (Cont’d)

open NetKAT.Std

let forwarding : policy = <:netkat< if ip4Dst = 10.0.0.1 then port := 1 else if (* destination is 10.0.0.2, forward out port 2, etc. *) ... else drop >>9/29/14


Example NetKAT Program (Cont’d)

open NetKAT.Stdopen Forwarding

let firewall : policy = <:netkat< if (ip4Src = 10.0.0.1 && ip4Dst = 10.0.0.2 && tcpSrcPort = 80 || ip4Src = 10.0.0.2 && ip4Dst = 10.0.0.1 && tcpDstPort = 80) then $forwarding else drop9/29/14


Example: Topology Abstraction

Abstract topologyPhysical topology

It is often useful to write programs in terms of a simplified abstract network topology

Benefits:•Information hiding: limit what each module sees•Protection: limit what each module does•Reuse: write code for appropriate interface

Example: load balancer



• Simplest example of topology abstraction• Can be used in many applications, including access

control, load balancing, distributed middleboxes, etc.

Abstract Network

Physical Network

Example: “One Big Switch”

(ingress; raise; application; lower; fabric; egress)

Implementation:



Formal Reasoning



Program Equivalence

A B

Given a program and a topology:

Formally, does the following equivalence hold?

(filter switch = A ; firewall; routing + filter switch = B; routing) ~ (filter switch = A ; routing + filter switch = B; firewall; routing)

Want to be able to answer questions like:“Will my network behave the same if I put the firewall rules on A, or on switch B (or both)?”



NetKAT Equational Theory

Boolean Algebraa | (b & c) ~ (a | b) & (a | c)

a | true ~ true

a | ! a ~ true

a & b ~ b & a

a & !a ~ false

a & a ~ a

Packet Algebraf := n; f’ := n’ ~ f’ := n’ ; f := n if f ≠ f’

f := n; f’ = n’ ~ f’ = n’; f := n if f ≠ f’

f := n; f = n ~ f := n

f = n; f := n ~ f = n

f := n; f’ = n’ ~ f := n’

f = n; f = n’ ~ filter drop if n ≠ n’

Kleene Algebrap + (q + r) ~ (p + q) + rp + q ~ q + pp + filter false ~ pp + p ~ pp ; (q ; r) ~ (p ; q) ; rp; (q + r) ~ p ; q + p ; r(p + q) ; r ~ p ; r + q ; r

filter true ; p ~ p ~ p ; filter truefilter false ; p ~ filter false p ; filter false ~ filter falsefilter true + p ; p* ~ p*

filter true + p* ; p ~ p*

p + q ; r + r ~ r ⟹ p* ; q + r ~ rp + q ; r + q ~ q ⟹ p ; r* + q ~q



NetKAT and Kleene Algebras

Theorems• Soundness: programs related by the axioms are equivalent• Completeness: equivalent programs are related by the axioms• Decidabilty: program equivalence is decidable (PSPACE)

Its foundations rest upon canonical mathematical structure:• Regular operators (+, ;, and *) encode paths through topology• Boolean operators (&, |, and !) encode switch tables

The design of NetKAT is not an accident!

This is called a Kleene Algebra with Tests [Kozen ’96]



NetKAT Verification

•Model programs and topologies in the Z3 SMT solver•Encode network-wide function as the transitive closure of

the sequential composition of the program and topology•Verify reachability properties automatically



Machine-Verified Controllers



Inductive pred : Type := | OnSwitch : Switch -> pred | InPort : Port -> pred | DlSrc : EthernetAddress -> pred | DlDst : EthernetAddress -> pred | DlVlan : option VLAN -> pred | ... | And : pred -> pred -> pred | Or : pred -> pred -> pred | Not : pred -> pred | All : pred | None : pred

Inductive act : Type := | ForwardMod : Mod -> PseudoPort -> act | ...

Inductive pol : Type := | Policy : pred -> list act -> pol | Union : pol -> pol -> pol | Restrict : pol -> pred -> pol | ...

Certified Software Systems

Recent Successes•seL4 [SOSP ’09]•CompCert [CACM ’09]•F* [ICFP ’11, POPL ’12, ’13]

Tools

Textbooks

Certified Programming with Dependent Types

Write code

Lemma inter_wildcard_other : forall x, Wildcard_inter WildcardAll x = x. Proof. intros; destruct x; auto. Qed. Lemma inter_wildcard_other1 : forall x, Wildcard_inter x WildcardAll = x. Proof. intros; destruct x; auto. Qed. Lemma inter_exact_same : forall x, Wildcard_inter (WildcardExact x) (WildcardExact x) = WildcardExact x. Proof. intros. unfold Wildcard_inter. destruct (eqdec x x); intuition. Qed.

Prove correct

Extract code

(** val handle_event : event -> unit Monad.m **) let handle_event = function | SwitchConnected swId -> handle_switch_connected swId | SwitchDisconnected swId -> handle_switch_disconnected swId | SwitchMessage (swId, xid0, msg) -> (match msg with | PacketInMsg pktIn -> handle_packet_in swId pktIn | _ -> Monad.ret ()) (** val main : unit Monad.m **) let main = Monad.forever (Monad.bind Monad.recv (fun evt -> handle_event evt))

Certifiedbinary



NetKAT

Flow tables

OpenFlow messages

Compiler

Run-time system

Optimizer

•Each level of abstraction formalized in Coq

•Machine-checked proofs that the transformations between levels preserve semantics

•Code extracted to OCaml and deployed with real switch hardware

Certified NetKAT Controller



NetKAT Compiler

Correctness Theorem

Overview•Compiler: maps NetKAT programs to flow tables

•Optimizer: eliminates “empty” and “shadowed” rules

Formalization Highlights

•Library of algebraic properties of flow tables

•New tactic for proving equalities on bags

•Key invariant: all packet patterns “natural”

Theorem compile_correct : forall opt pol sw pt pk bufId, SemanticsPreserving opt -> netcore_eval pol sw pt pk bufId = flowtable_eval (compile pol sw) sw pt pk bufId.



OpenFlow 1.0 Specification42 pages...

...of informal prose

...and C struct definitions

...diagrams and flow charts



Featherweight OpenFlowSyntax Semantics

Key Features:•Models all features related to packet forwarding and all essential asynchrony•Supports arbitrary controllers



Forwarding

Definition Pattern_inter (p p':Pattern) := let dlSrc := Wildcard_inter EthernetAddress.eqdec (ptrnDlSrc p) (ptrnDlSrc p') in let dlDst := Wildcard_inter EthernetAddress.eqdec (ptrnDlDst p) (ptrnDlDst p') in let dlType := Wildcard_inter Word16.eqdec (ptrnDlType p) (ptrnDlType p') in let dlVlan := Wildcard_inter Word16.eqdec (ptrnDlVlan p) (ptrnDlVlan p') in let dlVlanPcp := Wildcard_inter Word8.eqdec (ptrnDlVlanPcp p) (ptrnDlVlanPcp p') in let nwSrc := Wildcard_inter Word32.eqdec (ptrnNwSrc p) (ptrnNwSrc p') in let nwDst := Wildcard_inter Word32.eqdec (ptrnNwDst p) (ptrnNwDst p') in let nwProto := Wildcard_inter Word8.eqdec (ptrnNwProto p) (ptrnNwProto p') in let nwTos := Wildcard_inter Word8.eqdec (ptrnNwTos p) (ptrnNwTos p') in let tpSrc := Wildcard_inter Word16.eqdec (ptrnTpSrc p) (ptrnTpSrc p') in let tpDst := Wildcard_inter Word16.eqdec (ptrnTpDst p) (ptrnTpDst p') in let inPort := Wildcard_inter Word16.eqdec (ptrnInPort p) (ptrnInPort p') in MkPattern dlSrc dlDst dlType dlVlan dlVlanPcp nwSrc nwDst nwProto nwTos tpSrc tpDst inPort.Definition exact_pattern (pk : Packet) (pt : Word16.T) : Pattern := MkPattern (WildcardExact (pktDlSrc pk)) (WildcardExact (pktDlDst pk)) (WildcardExact (pktDlTyp pk)) (WildcardExact (pktDlVlan pk)) (WildcardExact (pktDlVlanPcp pk)) (WildcardExact (pktNwSrc pk)) (WildcardExact (pktNwDst pk)) (WildcardExact (pktNwProto pk)) (WildcardExact (pktNwTos pk)) (Wildcard_of_option (pktTpSrc pk)) (Wildcard_of_option (pktTpDst pk)) (WildcardExact pt).Definition match_packet (pt : Word16.T) (pk : Packet) (pat : Pattern) : bool := negb (Pattern_is_empty (Pattern_inter (exact_pattern pk pt) pat)).

/* Fields to match against flows */struct ofp_match { uint32_t wildcards; /* Wildcard fields. */ uint16_t in_port; /* Input switch port. */ uint8_t dl_src[OFP_ETH_ALEN]; /* Ethernet source address. */ uint8_t dl_dst[OFP_ETH_ALEN]; /* Ethernet destination address. */ uint16_t dl_vlan; /* Input VLAN. */ uint8_t dl_vlan_pcp; /* Input VLAN priority. */ uint8_t pad1[1]; /* Align to 64-bits. */ uint16_5 dl_type; /* Ethernet frame type. */ uint8_t nw_tos; /* IP ToS (DSCP field, 6 bits). */ uint8_t nw_proto; /* IP protocol or lower 8 bits of ARP opcode. */ uint8_t pad2[2]; /* Align to 64-bits. */ uint32_t nw_src; /* IP source address. */ uint32_t nw_dst; /* IP destination address. */ uint16_t tp_src; /* TCP/UDP source port. */ uint16_t tp_dst; /* TCP/UDP destination port. */};OFP_ASSERT(sizeof(struct ofp_match) == 40);

Record Pattern : Type := MkPattern { dlSrc : Wildcard EthernetAddress; dlDst : Wildcard EthernetAddress; dlType : Wildcard EthernetType; dlVlan : Wildcard VLAN; dlVlanPcp : Wildcard VLANPriority; nwSrc : Wildcard IPAddress; nwDst : Wildcard IPAddress; nwProto : Wildcard IPProtocol; nwTos : Wildcard IPTypeOfService; tpSrc : Wildcard TransportPort; tpDst : Wildcard TransportPort; inPort : Wildcard Port}.

Detailed model of matching, forwarding, and flow table update



Asynchrony“In the absence of barrier messages, switches may arbitrarily reorder messages to maximize performance.”

“There is no packet output ordering guaranteed within a port.”

Definition InBuf := Bag Packet. Definition OutBuf := Bag Packet. Definition OFInBuf := Bag SwitchMsg. Definition OFOutBuf := Bag CtrlMsg.

Essential asynchrony: packet buffers, message reordering, and barriers



Priority Predicate Action


10 SSH Drop

5 dst_ip = H1 Fwd 1

5 dst_ip = H2 Fwd 2


5 dst_ip = H1 Fwd 1


5 dst_ip = H1 Fwd 1

5 dst_ip = H2 Fwd 2

update re-ordering


10 SSH Drop


10 SSH Drop

5 dst_ip = H1 Fwd 1

⊆

⊆

⊆

Distributed Programming:non-atomic table updates

Asynchrony (Cont’d)



Controllers

: abstract type of controller statefin :

fout :

Controller Parameters

Ultimately we want to prove theorems about controllers that implement the NetKAT run-time system...

...but we didn’t want to bake specific controllers into Featherweight OpenFlow!

Controller model: fully abstract



(H1, ) (S1,pt1, ) (S2,pt1, ) (H2, )

≈ ≈

≈

≈

≈

≈≈ ≈

add rules

add

rule

s

Weak Bisimulation

Theorem fwof_abst_weak_bisim : weak_bisimulation concreteStep abstractStep bisim_relation.



Frenetic

OX

implemented usingOCaml embedding• predicates and policies• queries

OCaml OpenFlow Platform• similar to Nox, Pox, Floodlight, etc.

predicatespoliciesqueries

stream of snapshots over time



Frenetic

Ox

The System



Frenetic DSL

Frenetic

OX

implemented using

implemented using

Domain-specific language• predicates and policies• monitoring• mac learning• network address translation

OCaml embedding• predicates and policies• queries

OCaml OpenFlow Platform• similar to Nox, Pox, Floodlight, etc.

Frenetic

Ox

The System



ConclusionModularity is a key concern in the design of any language

NetKAT provides rich abstractions for building modular network programs, including parallel and sequential composition operators

By leveraging recent advances in formal methods, can build trustworthy compilers, run-time systems, and verification tools

Implementation status:•Stand-alone controller platform implemented in OCaml•Sophisticated, proactive compiler for OpenFlow rules•Large parts of the system formally verified in Coq•Experimental support for OpenFlow 1.3



Questions?

9/29/14

Software Defined Networking COMS 6998-10, Fall 2014

Documents

Transcript of Software Defined Networking COMS 6998-10, Fall 2014