1
Q
The OpenFlow API does not provide…
A
Specific guarantees about the level of consistency that packets along an end-to-end path can experience
2
Q
What are 2 consistency problems with SDNs?
A
Packet-level consistency problems
Flow-level consistency problems
3
Q
Packet-level consistency problem
A
Updates to multiple switches along a path in a network that occur at different times may result in problems such as forwarding loops
4
Q
Flow-level consistency problem
A
If updates to switches along an end-to-end path occur in the middle of a flow, packets from the same flow may be subjected to 2 different network states
5
Q
3 steps of SDN program
A
- Controller needs to read/monitor network state as well as various events that may be occurring in the network
* Events may include failures, topology changes, security events, etc. - Compute policy based on the state that the controller sees from the network
* Roughly the role of the decision plane, deciding the behavior of the network in response to various events - Write policy back to the switches by installing the appropriate flow table state into the switches
- Consistency problems can arise in steps 1 and 3:
* In step 1: Controller may read state from network switches at different times, resulting in an inconsistent view of the network-wide state
* In step 3: Controller may be writing policy as traffic is actively flowing through the network, which can disrupt packets along an end-to-end path or packets that should be treated consistently because they’re part of the same flow
Reading and writing network state can be challenging because OpenFlow rules are simple match-action predicates, so it can be difficult to express complex logic. Need more sophisticated predicates.
6
Q
3 approaches to help guarantee consistency in reading state
A
Predicates
Rule unfolding
Suppression
7
Q
Reasons a controller might want to write policy to change state in network
A
- Maintenance
* Unexpected failure
* Traffic engineering
*** These all require updating state in the network switches
8
Q
When writing policy changes, we want to make sure forwarding remains…
A
correct and consistent
9
Q
When writing policy changes, we’d like to maintain the following invariants…
A
- No forwarding loops
* No black holes (a router or switch receives a packet and doesn’t know what to do with it)
* No security violations (traffic is going where it shouldn’t be allowed to go)
10
Q
What can happen if policies are written in an inconsistent fashion?
A
- You could have a forwarding loop.
* If rules are installed out of order, packets may reach a switch before the new rules do.
* We need atomic updates to the entire configuration.
11
Q
Solution to inconsistent policy writing?
A
- Use a two-phase commit:
- Packets are either subjected to the old config on all switches, or the new config on all switches. Not a mix.
- Idea: tag the packet on ingress such that the switches maintain copies of both P1 and P2 for some time.
- Once all switches receive rules corresponding to the new policy, then incoming packets can be tagged with P2.
- Once we know that no more packets of P1 are being forwarded through the network, we can only then remove the rules corresponding to policy P1.
- Naive version of 2-phase commit requires doing this on all switches at once, which essentially doubles the rule space requirements.
- We can limit the scope/optimize by only applying this mechanism on switches that involve the affected portions of the traffic or the affected portions of the topology.
12
Q
What problems can arise from inconsistent “writes” of network state?
- Inability to respond to failures
- Forwarding loops
- A flood of traffic at the controller
- Security policy violations
A
- Forwarding loops
- A flood of traffic at the controller
- Security policy violations
13
Q
How do you cope with inconsistency?
- Different controllers for different switches
- Keeping a “hot spare” replica
- Keeping the old and new state on the routers/switches
- Resolving conflicts on the routers
A
-Keeping the old and new state on the routers/switches
14
Q
What is network virtualization?
A
- An application of SDN
- One example is Mininet
- An abstraction of the physical network where multiple logical networks can be run on the same underlying physical substrate
- Each logical network has its own view, even though it may share nodes with other logical networks, as if it were running its own private version of the network.
* Nodes need to be shared or sliced. They are typically virtual machines (VMs)
* A single link in a logical topology might actually map to multiple links in the physical topology. The mechanism to achieve these virtual links is typically through tunneling. For example, a packet from A->B in the logical topology below might be encapsulated as a packet that goes from A->X->B in the physical topology.
15
Q
In network virtualization, a single link in a logical topology might actually map to multiple links in the physical topology. The mechanism to achieve these virtual links is typically through:
A
tunneling
For example, a packet from A->B in the logical topology in the lecture might be encapsulated as a packet that goes from A->X->B in the physical topology.
16
Q
Network virtualization can also be thought of as an analogy to…
A
virtual machines
- In VMs, a hypervisor arbitrates access to the underlying physical resources, providing to each virtual machine the illusion that it’s operating on its own dedicated version of the hardware.
- Similarly, with virtual networking, a network hypervisor of sorts arbitrates to the underlying physical network to multiple virtual networks.
17
Q
Why use network virtualization?
A
- One of the main motivations: the ossification of Internet architecture
* In particular, because IP so pervasive, makes it difficult to make fundamental changes to the underlying internet architecture and how it operates.
* Lots of work done in the early 2000s on network overlays, but 1-size fits all architectures very difficult to deploy. So, rather than trying to replace existing network architectures, network virtualization was intended to allow for easier evolution.- Network virtualization enables evolution by letting multiple architectures exist in parallel. We didn’t have to pick a winner for a replacement for IP.
- In practice, network virtualization has really taken off in multi-tenant data centers, where there may be multiple tenants/applications running on a shared cluster of servers. Well-known examples of this include Amazon’s EC2, Rackspace, and things like Google App Engine.
- Service providers such as Google, Yahoo, and so forth also use network virtualization to adjust the resources devoted to any particular service at a given time.
18
Q
Network virtualization has really taken off in…
A
Multi-tenant data centers where there may be multiple tenants/applications running on a shared cluster of servers. Well-known examples of this include Amazon’s EC2, Rackspace, and things like Google App Engine.
19
Q
Motivation for virtual networking?
- Easier troubleshooting
- Facilitating research/evolution by allowing coexistence
- Better forwarding performance
- Adjusting resources to demand
A
- Facilitating research/evolution by allowing coexistence
- Adjusting resources to demand
20
Q
Promised benefits of network virtualization
A
- More rapid innovation, since innovation can proceed at the rate at which software evolves, rather than on hardware development cycles
- Allowing for new forms of network control
- Potentially simpler programming
21
Q
Important to make a distinction between SDN and Network Virtualization
A
- Network Virtualization is arguably one of the first killer applications for SDN, and in some sense SDN is a tool for implementing network virtualization, but they are not the same thing.
- Defining tenant of SDN is separation of data and control planes
- Defining tenant of network virtualization is separation of underlying physical network from logical networks that lie on top of it.
- SDN can be used to simplify many aspects of network virtualization, but it does not inherently abstract the details of the underlying physical network
22
Q
Which are characteristics of network virtualization?
- Allowing multiple tenants to share underlying physical topology
- Controlling behavior from a centralized controller
- Separating logical and physical networks
- Separating data and control planes
A
- Allowing multiple tenants to share underlying physical topology
- Separating logical and physical networks
*** The 2 other answers below are defining characteristics of SDN but not of network virtualization
23
Q
What are the various design goals of virtual networks?
A
- Flexible: support different topologies, routing and forwarding architectures, and independent configurations
- Manageable: separate the policy that a network operator is trying to specify form the mechanisms of how those policies are implemented
- Scalable: maximize the number of coexisting virtual networks
- Secure: isolating different logical networks from one another
- Programmable
- Heterogeneous: support different technologies
24
Q
2 components of virtual networks
A
- Nodes: physical nodes are virtualized. One possible way is a VM.
* A more lightweight way of virtualizing a node is using a virtual environment, such as a V-server or a Jail
* Examples of node virtualization include virtual machine environments such as Xen, VMWare, or what’s called OS-level virtualization or virtual environments, such as Linux Vservers. - Edges: Each virtual machine or virtual environment has its own view of the network stack, and we may want to provide the appearance that these nodes are connected to one another over a layer 2 topology, even if they are in fact separated by multiple IP hops.
* One way of doing that is to encapsulate the ethernet packet as it leaves the VM on the left in an IP packet. The IP packet can then be destined for the IP address of the machine on the right, and when it arrives, the host can decapsulate the packet and pass the original ethernet packet to the VM or the virtual environment that’s residing on that physical node.
* Each physical host may host multiple virtual machines or virtual environments, which creates the need for a virtual switch which resides on a host.
* Virtual switch provides the function of networking virtual machines together over a virtual layer 2 topology.
* Example of a software switch that can perform this type of function is the Linux Bridge. Another example is Open VSwitch (http://openvswitch.org)
25
Virtual networks facilitate...
agile development, by enabling rapid innovation at the pace of software, vendor independence, and scale.
26
What makes SDN programming hard?
* Unfortunately, programming OpenFlow is NOT easy.
* It offers a very low level of abstraction in the form of match-action rules
* The controller only sees events that switches don’t know how to handle
* There can be race conditions if switch-level rules are not installed properly (like we saw in the lesson on consistent updates)
27
Solution to the difficulties of SDN programming
* Provide some kind of “Northbound” API, which is a programming interface that allows applications or other orchestration systems to program the network
* Apps and Orchestration systems are used to perform more sophisticated tasks, such as path computation, loop avoidance, and so forth
* Need a higher level programming interface that enables these applications to talk to the controller, without worrying about low-level things like whether the rules are being installed in a consistent and correct fashion
* Various people may write these applications, including network operators, service providers, researchers, and anyone who wants to develop capabilities on top of OpenFlow
28
Benefits of a northbound API
* Vendor independence
* Ability to quickly modify/customize control through various popular programming languages
* Examples of such applications include:
* Implementation of a large virtual switch abstraction
* Security applications
* Services that may need to integrate traffic processing with middle boxes
* Currently, the standard for the southbound API is OpenFlow, but there is currently no standard for the northbound API
29
Frenetic
* One example of a programming language that sits on top of a northbound API is Frenetic, which is a SQL-like query language
* For example, it can allow a programmer to count the number of bytes grouped by destination MAC address and report the updates to these counters every 60 seconds (see example below)
* WHERE allows restrictions to only count certain traffic (from a server, coming in on a particular port)
* More info at frenetic-lang.org
* We’ll be using Pyretic which is based on the same underlying theory as Frenetic except that it’s embedded in Python
30
Composition operators
Ways that specify how individual modules can be combined or composed into a single coherent application
This helps prevent the issues of overlapping network policies: issue with programming at higher level of abstraction -- an operator might write multiple modules, each of which affects the same traffic (e.g., one module for each of the green topics in the slide below)
31
Composing Network Policies with Pyretic
* One way of composing policies is to perform both operations simultaneously/in parallel.
* For example: counting and forwarding traffic at the same time.
* Another way is in sequence (perform one operation, then the next, etc.)
* For example: perform firewall, and whatever traffic makes it through the firewall then is subjected to the switching policy
32
What's an example of sequential composition
Load balancer
* Re-route half the traffic to one server replica, and the other half of the traffic to another replica
* Then, need a routing module to forward the traffic out the appropriate port on the switch
* Sequentially apply a routing policy that forwards the traffic out the appropriate port depending on the resulting destination IP address after the rewrite has taken place
* Notice we can use predicates to specify which traffic traverses which modules. They can apply specific actions based on things like the input port and packet header fields.
* This leaves some flexibility so that one module can implement a small part of the network function, leaving functions for others. This also allows for modular re-use.
33
Pyretic language
* Pyretic is an SDN language and runtime that implements some of the composition operators that we discussed in the last lesson.
* Language: a way of expressing these policies
* Runtime: provides the function of compiling these policies to the Openflow rules that eventually are installed on the switches
34
What is a key abstraction in Pyretic?
The notion of “located” packets
* Idea that we can apply a policy based on a packet and its location in the network (i.e. the switch at which the packet is located, or the port on which it arrives)
35
Features offered by Pyretic
- Network policy as a function: Ability to take packet as input and return packets at different locations in the network.
* Contrasts with OpenFlow style, where policies are simply bit patterns (match statements), which are difficult to reason about. In contrast, Pyretic policies are functions that map packets to other packets. Some example functions in Pyretic include:
* Identity: returns original packet
* none or drop: returns the empty set
* match(f=v): returns identity if the field f matches the value v, and returns none/drop otherwise
* mod(f=v) returns the same packet with the field f set to v
* fwd(a): simply syntactic sugar on mod, allows output port yielding the packet should be modified to the parameter specified
* flood(): returns 1 packet for each port on the network spanning tree
* In OpenFlow, packets either match on a rule or simply fall through to the next rule, so OR, NOT, etc. are tough to reason about
* Pyretic also offers the notion of virtual packet header fields, which is a unified way of representing metadata.
* In Pyretic, a packet is nothing more than a dictionary that maps a field name (such as destination IP address) to a value. They can correspond to fields in an actual packet header, and they can also be virtual.
- Boolean predicates: unlike OpenFlow rules which do not permit simple conjunctions such as and/or or negations like NOT, Pyretic allows the expressions of policies interns of these predicates
- Notion of virtual packet header fields: allows programmer to refer to packet locations and tag packets so that specific functions can be applied at different portions of the program.
- Composition operators such as parallel land sequential composition
- Traffic monitoring functionality as a policy.
- Dynmic Policies
- Topology Abstraction - apply policy functions to an abstract view of the underlying network.
36
Pyretic enables _____ and _____ composition
Parallel and sequential
37
How do you express sequential composition in Pyretic?
>>
38
How do you express parallel composition in Pyretic?
+
39
Pyretic callbacks
Functions that are registered on packet streams. They are are invoked to handle each new packet that arrives for that query
40
What are dynamic policies in Pyretic?
* Dynamic Policies are policies whose forwarding behavior can change
* Represented as a time series of static policies
* Current value of the policy at any time is self.policy
41
Common programming idiom in Pyretic is to
1. Set a default policy
| 2. Register a callback that updates that policy
42
What 4 capabilities does Pyretic allow?
- Network policy as a function
- Predicates on packets
- Virtual packet headers
- Policy composition
- Topology abstraction
43
What is the appropriate Pyretic rule for sending traffic form source IP address 10.0.0.1 to destination IP address 10.1.2.3 and traffic from source IP address 10.0.0.2 to destination IP address 10.2.3.4?
(match(srcip=10.0.0.1) >> mod(dstip=10.1.2.3)) + (match(srcip=10.0.0.2) >> mod(dstip=10.2.3.4))
44
Flow switching behavior
* OpenFlow makes modifying forwarding behavior easy because forwarding decisions are based on matches on the OpenFlow 10-tuple
* If all of the fields are specified for forwarding out of a particular output port, then we have flow switching behavior
* If all of the flow specifications are wild carded except for, say, the source MAC address, then we have a firewall.
45
What is the basic abstraction that NOX supports?
Switch control
* OpenFlow is the prevailing protocol. Control is defined at the granularity of flows, specified in a 10-tuple. Flow = {srcport = “”, dstport = “”, etc….}
* Flow is defined by header (10-tuple), counter, and actions to be performed (forwarding, dropping, sending to controller, etc.)
* Counter = # packets that belong to that flow
* Controller can process different types of events
* CPQD supports OF 1.1-1.3. NOX supports 1.0
CS6520 Test 3 Timothy
flashcards
Decks in class (6)
# Cards
