1 Link Forwarding, Network Control Functions and Software Defined Networking Y. Richard Yang 4/25/2016

2 Admin r Project status

3 Recap: Look Inside a Router Two key router functions: r run routing algorithms/protocol (RIP, OSPF, BGP) r switching datagrams from incoming to outgoing ports

4 Recap: Link Layer Services  Framing  Multiplexing/demultiplexing  Media access control  Forwarding/switching with a link-layer (Layer 2) domain  Reliable delivery between adjacent nodes (including padding) 4 Ethernet Frame

5 Recap: Random Media Access r Slotted Aloha protocol m Time is divided into equal size slots (= pkt trans. time) m Node with pkt: transmit at beginning of next slot with probability p m Optimal value p = 1/n, with success rate only 1/e Success (S) Collision (C) Empty (E)

6 Summary of Problems of Aloha Protocols r Problems m slotted Aloha has better efficiency than pure Aloha but clock synchronization is hard to achieve m Aloha protocols have low efficiency due to collision or empty slots when offered load is optimal (p = 1/N), the goodput is only about 37% when the offered load is not optimal, the goodput is even lower m undesirable steady state at a fixed transmission rate, when the number of backlogged stations varies r Ethernet design: address the problems: m approximate slotted Aloha without clock synchronization m reduce the penalty of collision or empty slots m infer optimal transmission rate

7 The Basic MAC Mechanisms of Ethernet get a packet from upper layer; K := 0; n := 0; // K: control wait time; n: no. of collisions repeat: wait for K * 512 bit-time; while (network busy) wait; // sync clock wait for 96 bit-time after detecting no signal; transmit and detect collision; // not waste the whole if detect collision stop and transmit a 48-bit jam signal; // not waste the whole n ++; // adapt p m:= min(n, 10), where n is the number of collisions choose K randomly from {0, 1, 2, …, 2 m -1}. if n < 16 goto repeat else give up

8 MAC Protocols Goals r efficient, fair, decentralized, simple Three broad classes: r Non-partitioning m random access allow collisions m “taking-turns” a token coordinates shared access to avoid collisions r channel partitioning m divide channel into smaller “pieces” (time slot, frequency, code)

9 Example Channel Partitioning: CDMA CDMA (Code Division Multiple Access) r Used mostly in wireless broadcast channels (cellular, satellite, etc) r A spread-spectrum technique History: Examples: Sprint and Verizon, WCDMA

10 CDMA: Encoding r All users share same frequency, but each user m has its own unique “chipping” sequence (i.e., code) c m to encode data, i.e., code set partitioning m e.g. c m = r Assume original data are represented by 1 and -1 r Encoded signal = (original data) modulated by (chipping sequence) m assume c m = m if data is d, send d c m, if data d is 1, send c m if data d is -1 send -c m

CDMA: Encoding 11 user data d(t) chipping sequence c(t) resulting signal X = tbtb tctc t b : bit period t c : chip period

12 CDMA: Decoding r Inner-product (summation of bit-by-bit product) of encoded signal and chipping sequence m if inner-product > 0, the data is 1; else -1

13 CDMA Encode/Decode Code of user m c m : The number of bits of each chipping sequence is M Encode Decode

14 CDMA: Deal with Multiple-User Interference r Two codes C i and C j are orthogonal, if m, where we use “.” to denote inner product, e.g. r If codes are orthogonal, multiple users can “coexist” and transmit simultaneously with minimal interference: C 1 : C 2 : C 1. C 2 = 1 +(-1) (-1) (-1)+(-1)=0 Analogy: Speak in different languages!

15 CDMA: Two-Sender Interference Code 1: Code 2:

16 Generating Orthogonal Codes r The most commonly used orthogonal codes in current CDMA implementation are the Walsh Codes

17 Walsh Codes 1 1,1 1,-1 1,1,1,1 1,1,-1,-1 X X,X X,-X 1,-1,1,-1 1,-1,-1,1 1,-1,-1,1,1,-1,-1,1 1,-1,-1,1,-1,1,1,-1 1,-1,1,-1,1,-1,1,-1 1,-1,1,-1,-1,1,-1,1 1,1,-1,-1,1,1,-1,-1 1,1,-1,-1,-1,-1,1,1 1,1,1,1,1,1,1,1 1,1,1,1,-1,-1,-1, n 2n...

18 Orthogonal Variable Spreading Factor (OSVF) r Variable codes: Different users use different lengths spreading codes r Orthogonal: diff. users’ codes are orthogonal 1 1,1 1,-1 1,1,1,1 1,1,-1,-1 X X,X X,-X 1,-1,1,-1 1,-1,-1,1 1,-1,-1,1,1,-1,-1,1 1,-1,-1,1,-1,1,1,-1 1,-1,1,-1,1,-1,1,-1 1,-1,1,-1,-1,1,-1,1 1,1,-1,-1,1,1,-1,-1 1,1,-1,-1,-1,-1,1,1 1,1,1,1,1,1,1,1 1,1,1,1,-1,-1,-1,-1 SF=1SF=2SF=4SF=8 SF=nSF=2n... If user 1 is given code [1,1], what orthogonal codes can we give to other users?

19 WCDMA Orthognal Variable Spreading Factor (OSVF) r Flexible code (spreading factor) allocation m up link SF: 4 – 256 m down link SF: WCDMA downlink

20 Combined Random Access + Channel Partition: GSM Logical Channels and Request r Control channels m Broadcast control channel (BCCH) from base station, announces cell identifier, synchronization m Common control channels (CCCH) paging channel (PCH): b ase transceiver station (BTS) pages a mobile host (MS) random access channel (RACH): MSs for initial access, slotted Aloha access grant channel (AGCH): BTS informs an MS its allocation m Dedicated control channels standalone dedicated control channel (SDCCH): signaling and short message between MS and an MS r Traffic channels (TCH) r call setup from an MS BTS MS RACH (request signaling channel) AGCH (assign signaling channel) SDCCH (request call setup) SDCCH (assign TCH) SDCCH message exchange Communication

Discussions r Advantages of channel partitioning over random access r Advantages of random access over channel partitioning 21

22 Summary: Link Layer  Several other important concepts o Flooding and self learning switch o VLAN

23 Recap: The Hourglass Architecture of the Internet IP EthernetFDDIWireless TCP UDP Telnet FTPWWW ADSL CableDOCSIS

24 Outline  Admin and recap  Link layer o Overview o Random access o Channel partition link layer  Software defined networking o Motivation: from simple forwarding to network functions

25 Simple Forwarding to Network Control Functions: Network Address Translation local network (e.g., home network) /24 rest of Internet All datagrams leaving local network cannot use private address use source address. NAT gateway replaces source address with NAT IP address (e.g., ) different source port numbers  A local network uses just one public IP address as far as outside world is concerned  Each device on the local network is assigned a private IP address

Private IP 26

27 NAT: Network Address Translation Implementation: NAT router must: m outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #)... remote clients/servers will respond using (NAT IP address, new port #) as destination addr. m remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair m incoming datagrams: replace (NAT IP address, new port #) in dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table

28 NAT: Network Address Translation S: , 3345 D: , : host sends datagram to , 80 NAT translation table WAN side addr LAN side addr , , 3345 …… S: , 80 D: , S: , 5001 D: , : NAT router changes datagram source addr from , 3345 to , 5001, updates table S: , 80 D: , : Reply arrives dest. address: , : NAT router changes datagram dest addr from , 5001 to ,

29 Network Address Translation: Advantages r No need to be allocated range of addresses from ISP: - just one public IP address is used for all devices m 16-bit port-number field allows 60,000 simultaneous connections with a single LAN-side address ! m can change ISP without changing addresses of devices in local network m can change addresses of devices in local network without notifying outside world r Devices inside local net not explicitly addressable, visible by outside world (a security plus)

30 Network Address Translation: Problems r If both hosts are behind NAT, they will have difficulty establishing connection r NAT is controversial: m routers should process up to only layer 3 m violates end-to-end argument NAT possibility must be taken into account by app designers, e.g., P2P applications m address shortage should instead be solved by having more addresses --- IPv6 !

31 Implication of Implementing NAT S: , 3345 D: , NAT translation table WAN side addr LAN side addr , , 3345 …… S: , 80 D: , S: , 5001 D: , 80 2 S: , 80 D: , Routing table no longer looks up by dest. IP, but also dest. Port -Network needs to conduct packet transformation, beyond simple lookup

32 Simple Forwarding to Network Functions: Enterprise Networks r Modern networks contain diverse types of equipment beyond simple routing/forwarding Source: [Sherry, et. al SIGCOMM’12] Small: = 100k Enterprise networks

tier-1 Enterprise/Cloud Structure 33 Intern et CE Tier-1 F 1 (Firewall) S1S1 LB 1 (Load balancer) IPS 1 (Intrusion prevention) F2F2 S2S2 LB 2 IPS 2 S3S3 S4S4 VLAN 300 VLAN 400 Tier-2 VLAN 100 R1R1 S5S5 IPS 3 S6S6 VLAN 200 Tier-3 Logger

r OpenStack using OVS 34 Simple Forwarding to Network Functions

35 Simple Forwarding to Network Control Functions: Mobile Networks r Modern networks contain diverse types of equipment beyond simple routing/forwarding LTE Architecture

36 Outline  Admin and recap  Link layer  Software defined networking o Motivation: from simple forwarding to network functions o Design overview

37 Alternative Design: Software Defined Networking b a c i e f g h d Instead of distributed computing, setting up the state of network selected devices. Instead of distributed computing, directly setting up the state of network devices. Discussion: key components of the architecture?

SDN Data Path Designs 38 Datapath Datapath Control Datapath SDN Datapath model: - OpenFlow1.x - OFDPA - P4 - POF… OpenFlow NetConf RestConf SNMP Forces …

SDN Use Cases Source: Neela Jacques, July

40 Outline  Admin and recap  Link layer  Software defined networking o Motivation: from simple forwarding to network functions o Design overview o Data path (OpenFlow)

port 4 port 3 port 2 port OpenFlow Datapath Ethernet Switch

Controller PC Hardware Layer Software Layer Flow Table OpenFlow Firmware port 4 port 3 port 2 port OpenFlow Datapath

43 Datapath Model: OpenFlow

Controller PC Hardware Layer Software Layer Flow Table MAC src MAC dst IP Src IP Dst TCP sport TCP dport Action OpenFlow Firmware ** ***port 1 port 4port 3 port 2 port OpenFlow Datapath: Example

OpenFlow Datapath: Examples Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * 00:1f:.. *******port6 Flow Switching port3 Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action 00:20..00:1f..0800vlan port6 Firewall * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Forward ********22drop

OpenFlow Datapath: Examples Routing * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action ***** ***port6 VLAN Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action ** vlan1 ***** port6, port7, port9 00:1f..

OpenFlowSwitch.org Controller OpenFlow Switch PC OpenFlow Message Flows: Reactive Mode (pkt miss) OpenFlow Switch OpenFlow Switch OpenFlow Protocol pkt miss msg pkt RuleActionStatisticsRuleActionStatisticsRuleActionStatistics flowtable lookup miss

OpenFlowSwitch.org Controller OpenFlow Switch PC OpenFlow Message Flows: Reactive Mode (flow mod) OpenFlow Switch OpenFlow Switch pkt RuleActionStatisticsRuleActionStatisticsRuleActionStatistics OpenFlow Protocol flow_mod pkt_miss handler

OpenFlowSwitch.org Controller OpenFlow Switch PC OpenFlow Message Flows: Reactive Mode (forward) OpenFlow Switch OpenFlow Switch pkt RuleActionStatisticsRuleActionStatisticsRuleActionStatistics

50 Outline  Admin and recap  Link layer  Software defined networking o Motivation: from simple forwarding to network functions o Design overview o Data path (OpenFlow) o Control path (programming model)

SDN Programming Model Network State Datapath Model Service/ Policy Datapath Model 51 Program Logic

An Example: A Simple SDN Controller badPort = 22 // policy hostTbl = {A:1,B:2, C:3,D:4} // net view def onPacketIn(p): if badPort == p.tcp_dst: drop else: forward([hostTbl(p.eth_dst)]) 52 C D A B Assume only packets to A,B,C,D can appear.

Controller Program with Flow Table Management hostTbl = {A:1,B:2,C:3,D:4} def onPacketIn(p): if 22 == p.tcp_dst: drop installRule({‘match':{'tcp_dst':22}, ‘action’:[]}) else: forward([hostTbl(p.eth_dst)]) installRule({‘match’: {‘eth_dst’:p.eth_dst, ’tcp_dst’!=22}, ‘action’:[hostTbl(p.eth_dst)]}) 53 match does not support logic negation

Controller Program with Flow Table Management hostTbl = {A:1,B:2,C:3,D:4} def onPacketIn(p): if 22 == p.tcp_dst: drop installRule({‘priority’:1, ‘match’:{'tcp_dst':22}, ‘action’:[]}) else: forward([hostTbl(p.eth_dst)]) installRule({‘priority’:0, ‘match’: {‘eth_dst’:p.eth_dst}, ‘action’:[hostTbl(p.eth_dst)]}) 54

Controller Switch def onPacketIn(p): if 22 == p.tcp_dst: drop installRule({`priority`:1,’match’:{‘tcp_dst':22},'action':[]}) else: installRule({`priority`:0,’match’:{‘eth_dst’:p.eth_dst}, 'action':[hostTbl(p.eth_dst)]}) forward([hostTbl(p.eth_dst)]) Does the Program Work? EthDst:A, TcpDst:80 {`priority`:0,’match’:{‘eth_dst’:A},'action':[1]} EthDst:A, TcpDst:22 55 A security bug!

OVS Approach: Using Exact Match hostTbl = {A:1,B:2,C:3,D:4} def onPacketIn(p): if 22 == p.tcp_dst: drop installRule({‘priority’:1, ‘match’:exactMatch(p), ‘action’:[]}) else: forward([hostTbl(p.eth_dst)]) installRule({‘priority’:0, ‘match’:exactMatch(p), ‘action’:[hostTbl(p.eth_dst)]}) 56

Problems of OVS Approach Each new TCP flow delayed for flow setup ( ms) Number of flow table rules may exceed capacity (typically a few thousands) 57

Outline  Admin and recap  Link layer  Software defined networking o Motivation: from simple forwarding to network functions o Design overview o Data path (OpenFlow) o Control path (programming model) o Problems o Algorithmic network programming 58

Goal of SDN Programming Let programmers write the most obvious (=> data path independent) code: Design a system that can automatically generate correct, highly-optimized data path. def onPacketIn(p) if 22 == p.tcp_dst: drop else: forward([hostTbl(p.eth_dst)]) 59

Algorithmic SDN Programming Abstraction: Programmer’s View Conceptually programmer’s network control function f is invoked on every packet entering the network. f expressed in an existing, general purpose language (e.g., Java, Python), describing how a packet should be routed, not how data path flow tables are configured 60 f: packet route

Example Algorithmic Policy in Java Route f(Packet p) { if (p.tcpDstIs(22)) return null(); else { Location sloc = hostTable(p.ethSrc()); Location dloc = hostTable(p.ethDst()); Route path = myRoutingAlg(topology(), sloc,dloc); return path; } Route myRoutingAlg(Topology topo, Location sLoc, Location dloc) { if ( isSensitive(sLoc) || isSensitive(dLoc) ) return secureRoutingAlg(topo, sloc, dloc); else return standardRoutingAlg(topo, sloc, dloc); } Does not specify anything on flow tables! 61

More Complex Example: ACL+Routing void insert(ACLItem acl, int pos, List acls) { acls.add(pos, acl); } void delete(int pos, List acls) { acls.remove(pos); } 62 List acls; Route f(Packet p) { if ( ! permit(p, acls) ) { return null(); } Location sloc = hostTable(p.ethSrc()); Location dloc = hostTable(p.ethDst()); Route path = myRoutingAlg(topology(),sloc,dloc); return path; } boolean permit(Packet p, List acls) { for (ACLItem item : acls) { if ( match(p, item) ) { return item.action == PERMIT; } } return false; }

Challenge and Basic Idea Challenge: How to derive datapath (flow-tables) from a datapath-oblivious SDN controller function f? Basic idea of handling the challenge w/o a compiler: –There are two representations of computation A sequence of instructions (whitebox) Memorization tables (blackbox) –Although the decision function f does not specify how flow tables are configured, if for a given decision (e.g., drop), one know the dependency of the decision, one can construct the flow tables (aka, memorization tables). 63

Basic Idea Only requirement: Program f uses a simple library to access pkt attributes: Library provides both convenience and more importantly, decision dependency! 64

Dynamic Tracing: Abstraction to Flow Tables 1. Observes decision dependency of f on pkt attributes. 2. Builds a trace tree (TT), a universal (general), partial decision tree representation of any f. 3. Compile trace tree to generate flow tables (FTs). 65

Route f(Packet p) { if (p.tcpDstIs(22)) return null(); else { Location sloc = hostTable(p.ethSrc()); Location dloc = hostTable(p.ethDst()); Route path = myRoutingAlg( topology(),sloc,dloc); return path; } EthSrc:1, EthDst:2, TcpDst:80 Assert: TcpDst==22 false Read: EthSrc Read: EthDst 1 2 Policy 66 path1

EthDst:1, TcpDst:22 null true Assert: TcpDst==22 Policy Trace Tree 1 2 ? truefalse Read: EthSrc Read: EthDst path1 Assert: TcpDst==22 67 Route f(Packet p) { if (p.tcpDstIs(22)) return null(); else { Location sloc = hostTable(p.ethSrc()); Location dloc = hostTable(p.ethDst()); Route path = myRoutingAlg( topology(),sloc,dloc); return path; }

EthDst:1, TcpDst:22 null true Assert: TcpDst==22 Policy Trace Tree 1 2 null truefalse Read: EthSrc Read: EthDst path1 Assert: TcpDst==22 68 Route f(Packet p) { if (p.tcpDstIs(22)) return null(); else { Location sloc = hostTable(p.ethSrc()); Location dloc = hostTable(p.ethDst()); Route path = myRoutingAlg( topology(),sloc,dloc); return path; }

Trace Tree Formal Spec A tree w/ 4 types of nodes T node: assertion on packet attributes V node: multi-way branching on a packet attribute L node: leaf node labeled w/ action ? node: unknown TT search: traverse tree for a given packet to determine action or no answer TT correctness: if TT records an answer for a given packet, the answer is the same as the original algorithm 1 2 ? truefalse Read: EthSrc Read: EthDst path1 Assert: TcpDst==22 69

Trace Tree => Flow Table tcpDst ==22 False ethDst 2 drop 4 port 30 ethSrc 6 drop True match:{tcpDst!=22, ethDst:4,ethSrc:6} match:{tcpDst!=22, ethDst:2} match:{tcpDst==22} 70

Trace Tree => Flow Table tcpDst ==22 False ethDst 2 drop 4 port 30 ethSrc 6 drop True match:{tcpDst!=22, ethDst:4,ethSrc:6} Priority match:{tcpDst==22} action:ToController barrier rule: match:{tcpDst!=22, ethDst:2} match:{tcpDst==22} 71

tcpDst ==22 False ethDst 2 drop 4 port 30 ethSrc 6 drop True match:{tcpDst!=22, ethDst:4,ethSrc:6} match:{tcpDst==22} action:ToController barrier rule: match:{tcpDst!=22, ethDst:2} Simple, classical in-order tree traversal generates flow table rules! 72 match:{tcpDst==22} Priority Trace Tree => Flow Table