SNAP: Stateful Network-Wide Abstractions for Packet Processing. Collaboration of Princeton University & Pomona College

Transcription

1 SNAP: Stateful Network-Wide Abstractions for Packet Processing Collaboration of Princeton University & Pomona College

2 Brief Overview: Motivation Introduction to SNAP/Example(s) of SNAP SNAP Syntax Overview Compilation Phases Contributions Evaluation Extending SNAP/The Future

3 Motivation <<...these systems [early SDN implementations] were partitioned into (1) a stateless packet-processing part that could be analyzed statically, compiled, and installed on OpenFlow switches, and (2) a general stateful component that ran on the controller.>>

4 Motivation cont d <<...emerging hardware and software switches offer much more sophisticated support for persistent state in the data plane, without involving a central controller.>>

5 Motivation cont d <<...programming distributed collections of stateful devices is typically one of the most difficult kinds of programming problems. We need new languages and abstractions to help us manage the complexity and optimize resource utilization effectively.>>

6 What is SNAP? A new language <<SNAP offers a simpler centralized stateful programming model, by allowing programmers to develop programs on top of one big switch rather than many.>> <<The SNAP compiler relieves programmers of having to worry about how to distribute, place, and optimize access to these stateful arrays [global, persistent arrays of network states] by doing it all for them.>>

7 SNAP Paradigms: The Network is one big Switch

8 SNAP Paradigms: The Network is one big Switch <<Programmers can allocate persistent arrays on that OBS, and do not have to worry about where or how such arrays are stored in the physical network.>>

9 SNAP Paradigms: The Network is one big Switch <<Moreover, if multiple arrays must be updated simultaneously, we provide a form of network transaction to ensure such updates occur atomically.>>

10 SNAP: An SDN Programming Language Let s get to know SNAP!

11 SNAP Overview: An example DNS tunnel detection

12 REFRESH: DNS (Domain Name System) End user DNS Server ask for corresponding IP look up IP and return it (has its own DNS cache)

13 A little more detail Resolver (from ISP) End user Root Server TLD Server Name Server 7

14 DNS Tunneling By using DNS tunneling, a user will be able to access a website even though the proxy is blocking the website. Normally, when you consider a proxy server, all the HTTP traffic will be received by a proxy server, but no DNS traffic will fall on a proxy server. So exploiting this DNS traffic will allow us to use all blocked websites as well.

15 How to detect DNS tunneling? 1. For each client, keep track of the IP addresses resolved by DNS responses. 2. For each DNS response, increment a counter. This counter tracks the number of resolved IP addresses that a client does not use. 3. When a client sends a packet to a resolved IP address, decrement the counter for the client. 4. Report tunneling for clients that exceed a threshold for resolved, but unused IP addresses.

16 SNAP Example 1. For each client, keep track of the IP addresses resolved by DNS responses. 2. For each DNS response, increment a counter. This counter tracks the number of resolved IP addresses that a client does not use. 3. When a client sends a packet to a resolved IP address, decrement the counter for the client. 4. Report tunneling for clients that exceed a threshold for resolved, but unused IP addresses.

17 Routing in SNAP

18 SNAP Syntax

19 SNAP Predicates <<Predicates have a constrained semantics: they never update the state (but may read from it), and either return the empty set or the singleton set containing the input packet.>>

20 SNAP Predicates id drop f=v s[e1] = e2 -> pass the input package -> drop the input package -> pass pkt if pkt.f = v (field = value) -> pass if eval(e1) = eval(e2)

21 SNAP Policies <<Policies can modify packets and the state. Every predicate is a policy - it simply makes no modifications.>>

22 SNAP Policies f <-v s[e1]<-e2 s[e]++ p+q atomic(p) -> new packet pkt s.t. pkt.f = v -> pass input packet while updating state -> increment/decrement state -> run p and q in parallel -> ensure atomicity Possible data race, compile error

23 Realizing Programs on the Data Plane Questions: 1. Where to place state variables (orphan, susp-client, and blacklist in the previous example) (state dependency analysis) 2. How to route the packets across the physical network Demands: 1. Packets must pass through devices storing all state variables they need. 2. The order of the states has to be correct. (read-write dependencies)

24 Back to the Example Order matters! First those Than this

25 Program Analysis Transform program to an intermediate representation! (To receive the needed information)

26 Intermediate Representation: xfdd

27 Packet-State Mapping <<Traversing from d s [an xfdd] root down to the action sets at d s leaves, we can gather information associating each flow with the set of state variables read or written.>> And...

28 Packet-State Mapping <<...the operators can give hints to the compiler by specifying their network assumptions in a separate policy: >>

29 State Placement and Routing: MILP (great acronym) Input: concrete network topology, state dependency graph G, packet-state mapping Output: routing and state placement

30 State Placement Strategies: (i) Keep each state variable at one location (ii) Keep multiple copies of states on different switches Not possible to provide strong consistency guarantees

31 MILP <<It [the compiler] uses a mixed-integer linear program (MILP) that solves an extension of the multi-commodity flow problem to jointly decide state placement and routing while minimizing network congestion.>>

32 Multi-commodity flow problem Essentially, given a graph with edges/vertices and edge weights (a network), fulfilling certain flow demands. Kind of similar to the max flow problem, just that you have some flow constraints that have to be met.

33 Compilation: Recap Two critical details: 1. traffic routing 2. state placement

34 Compilation: a simple example <<If two flows (with different input and output ports) both need some state variable s, we should select routes for the two flows such that they pass through a common location where we place s.>>

35 Compilation: A general diagram

36 Contributions A stateful and compositional SDN programming language: SNAP A compiler to translate SNAP programs into low-level switch mechanics Implementation and evaluation of about 20 applications

37 Evaluation

38 Evaluation TCP State machine policy added

39 Evaluation

40 Evaluation <<We believe that our compilation techniques meet the requirements of enterprise networks and medium-size ISPs.>>

41 Evaluation <<Our current prototype composes xfdds in the same order as the programs themselves are composed and leaves finding the optimal order to compose xfdds to future work.>>

42 Extending SNAP/The Future Sharing State Variables Fault-Tolerance!!! Modifying fields with state variables Deep packet inspection (DPI) Resource constraints Cross-packet fields Queue-based policies

43

44 Appendix: xfdd compositions