1. 1 Link Forwarding, Network Control Functions and Software Defined Networking Y. Richard Yang http://zoo.cs.yale.edu/classes/cs433/ 4/25/2016

2. 2 Admin r Project status

3. 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. 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 8 66 2 46-1500 (including padding) 4 Ethernet Frame

5. 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. 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. 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. 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. 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: http://people.seas.harvard.edu/~jones/cscie129/nu_lectures/lecture7/hedy/lemarr.htm Examples: Sprint and Verizon, WCDMA

10. 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 = 1 1 1 -1 1 -1 -1 -1 r Assume original data are represented by 1 and -1 r Encoded signal = (original data) modulated by (chipping sequence) m assume c m = 1 1 1 -1 1 -1 -1 -1 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

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

12. 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. 13 CDMA Encode/Decode Code of user m c m : 1 1 1 -1 1 -1 -1 -1 - The number of bits of each chipping sequence is M Encode Decode

14. 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 : 1 1 1 -1 1 -1 -1 -1 C 2 : 1 -1 1 1 1 -1 1 1 ----------------------------------------- C 1. C 2 = 1 +(-1) + 1 + (-1) +1 + 1+ (-1)+(-1)=0 Analogy: Speak in different languages!

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

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

17. 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,-1 1 2 4 8 n 2n...

18. 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. 19 WCDMA Orthognal Variable Spreading Factor (OSVF) r Flexible code (spreading factor) allocation m up link SF: 4 – 256 m down link SF: 4 - 512 WCDMA downlink

20. 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

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

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

23. 23 Recap: The Hourglass Architecture of the Internet IP EthernetFDDIWireless TCP UDP TelnetEmailFTPWWW ADSL CableDOCSIS

24. 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. 25 Simple Forwarding to Network Control Functions: Network Address Translation 192.168.1.2 192.168.1.3 192.168.1.4 192.168.1.1 138.76.29.7 local network (e.g., home network) 192.168.1.0/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., 138.76.29.7) 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

26. Private IP 26

27. 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. 28 NAT: Network Address Translation 192.168.1.2 S: 192.168.1.2, 3345 D: 128.119.40.186, 80 1 192.168.1.1 138.76.29.7 1: host 192.168.1.2 sends datagram to 128.119.40.186, 80 NAT translation table WAN side addr LAN side addr 138.76.29.7, 5001 192.168.1.2, 3345 …… S: 128.119.40.186, 80 D: 192.168.1.2, 3345 4 S: 138.76.29.7, 5001 D: 128.119.40.186, 80 2 2: NAT router changes datagram source addr from 192.168.1.2, 3345 to 138.76.29.7, 5001, updates table S: 128.119.40.186, 80 D: 138.76.29.7, 5001 3 3: Reply arrives dest. address: 138.76.29.7, 5001 4: NAT router changes datagram dest addr from 138.76.29.7, 5001 to 192.168.1.2, 3345 192.168.1.3 192.168.1.4

29. 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. 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. 31 Implication of Implementing NAT 192.168.1.2 S: 192.168.1.2, 3345 D: 128.119.40.186, 80 1 192.168.1.1 138.76.29.7 NAT translation table WAN side addr LAN side addr 138.76.29.7, 5001 192.168.1.2, 3345 …… S: 128.119.40.186, 80 D: 192.168.1.2, 3345 4 S: 138.76.29.7, 5001 D: 128.119.40.186, 80 2 S: 128.119.40.186, 80 D: 138.76.29.7, 5001 3 192.168.1.3 192.168.1.4 -Routing table no longer looks up by dest. IP, but also dest. Port -Network needs to conduct packet transformation, beyond simple lookup

32. 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

33. 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

34. r OpenStack using OVS 34 Simple Forwarding to Network Functions

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

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

37. 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?

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

39. SDN Use Cases Source: Neela Jacques, July 2015. 39

40. 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)

41. port 4 port 3 port 2 port 1 1.2.3.45.6.7.8 OpenFlow Datapath Ethernet Switch

42. Controller PC Hardware Layer Software Layer Flow Table OpenFlow Firmware port 4 port 3 port 2 port 1 1.2.3.45.6.7.8 OpenFlow Datapath

43. 43 Datapath Model: OpenFlow

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

45. 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..0800vlan11.2.3.45.6.7.841726480port6 Firewall * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Forward ********22drop

46. 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 *****5.6.7.8***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..

47. 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

48. 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

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

50. 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)

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

52. 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 1 2 3 4 Assume only packets to A,B,C,D can appear.

53. 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

54. 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

55. 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!

56. 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

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

58. 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

59. 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

60. 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

61. 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

62. 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; }

63. 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

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

65. 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

66. 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

67. 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; }

68. 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; }

69. 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

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} match:{tcpDst!=22, ethDst:2} match:{tcpDst==22} 70

71. 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

72. 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: 1 2 3 match:{tcpDst!=22, ethDst:2} Simple, classical in-order tree traversal generates flow table rules! 72 match:{tcpDst==22} Priority Trace Tree => Flow Table