Lesson 9 - Software Defined Networking Flashcards
3 sections of the course
1: Basic building blocks of the internet
2: How networks deal with large amounts of network traffic
3 (this one): How network operators manage their networks
3 topics of this section, which introduce us to the forefront of networking research
SDN
Traffic Engineering
Network Security
What is network management?
The process of configuring the network to achieve a variety of tasks, including:
* Balancing traffic load across the network
* Achieving various security goals
* Satisfying business relationships that may exist between the network being configured and neighboring networks, such as the network’s upstream ISP
Network configuration (very important) mistakes can lead to:
- Persistent oscillation (routers can’t agree on a route to a destination)
- Loops (packets get stuck in between 2 or more routers and never actually make it to the destination
- Partitions: the network is split into 2 or more segments that are not connected
- Black holes: Packets reach a router that does not know what to do with it, and drops it, as opposed to sending it along to its destination
SDN provides operators with what 3 things?
- Network-wide views
- Of both topology and traffic - Ability to satisfy network-level objectives, including load balancing, security, and other goals.
- Direct control, in particular:
- Rather than requiring network operators to configure each device individually with indirect configuration, SDN allows an operator to write a control program that directly affects/manipulates the data plane.
*allows a network operator to express network-level objective and direct control from a logically centralized controller.
To make network operations easier, routers should:
- Forward packets (since router hardware is specialized to forward traffic at very high rates)
- Collect measurements (such as traffic statistics and topology information
There’s no reason that a router should have to:
Compute routes. Although conventionally routing has operated as a distributed computation of forwarding tables, the computation doesn’t inherently need to run on the routers. It can be logically-centralized and be controlled from a centralized control program
What are the 2 defining features of SDN?
Logically-centralized controller
Network-wide control
SDN’s simple goal is to
Remove routing from the routers and perform that routing computation at a logically centralized controller.
*It has also evolved to incorporate a much broader range of controls than simply routing decisions
Today’s networks have 2 functions
- Data plane, whose task it is to forward packets to their ultimate destination.
- Need a “state” in each router, known as a routing table, which allow it to make decisions to forward packets.
- Control plane: job is to compute the routing tables.
* In conventional networks today, the control and data plane both run on the routers that are distributed across the network * In an SDN, the control plane runs in a logically-centralized controller. * Additionally, the controller typically controls multiple routers across the network, and often, the control program exerts control over all of the routers in the network, thus facilitating network-wide control.
The refactoring from SDN allows us to…
Move from a network where devices are vertically integrated (making it very tough to innovate), to a network where the devices have open interfaces that can be controlled by software, thus allowing for much more rapid innovation.
RCP
Routing Control Platform
Previous to 2004:
-Configuration was distributed, leading to buggy or unpredictable behavior.
Around 2004, we had the idea to control the network from a logically centralized, high-level program.
-The logically-centralized controller focused on the Border Gateway Protocol (BGP), and was called the Routing Control Platform (RCP).
2005 generalized RCP
- Decision plane: Computed the forwarding state for devices in the network
- Data plane: Forwarded traffic based on decisions made by the Decision plane
- Dissemination/discovery planes: provide the decision plane the information it needs to compute the forwarding state which ultimately gets pushed to the data plane.
OpenFlow
OpenFlow is a communications protocol that defines a set of control commands which can be used to control the behavior of one or more switches.
Around 2008: Concepts effectively hit the mainstream through a protocol called OpenFlow
- OpenFlow’s intellectual roots are with the RCP and 4D, but it was made practical when merchant silicon vendor opened their API’s, so that switch chip-sets could be controlled from software. So suddenly, there was an abundance of cheap switches that were built based on open chipsets that could be controlled from software.
- This development effectively allowed us to decouple the control plane and the data plane in commodity switching hardware.
Advantages of SDN over conventional networks
- Coordination: easier to coordinate behavior among a network of devices
- Evolve: Behavior of the network is easier to evolve
- Reasoning: Easier to reason about
* These characteristics are all rooted in the fact that the control plane is separate from the data plane. This allows us to apply conventional CS techniques to old networking problems.
* Before, it was difficult to reason about or debug a network’s behavior.
SDN’s infrastructure
- Control plane: typically a software program written in a high-level language, such as Python or C
* Affects the forwarding state that’s in the switch using control commands.
* OpenFlow is one standard that defines a set of control commands by which a controller can control the behavior of one or more switches.
-Data plane: typically programmable hardware, and is controlled by the control plane.
Which of the following are examples of control plane operations?
- Computing a forwarding path that satisfies a high-level policy
- Computing a shortest-path routing tree
- Rate-limiting traffic
- Load balancing traffic based on hash of source IP
- Authenticate a user’s device based on MAC address
- Computing a forwarding path that satisfies a high-level policy
- Computing a shortest-path routing tree
- Authenticate a user’s device based on MAC address
Control Plane
The logic that controls forwarding behavior
* Examples:
* Routing protocols
* Logic for configuring network middle boxes
* Routing protocol might compute shortest paths over a topology, but ultimately the results of such computations must be installed in switches that actually do the forwarding
Data Plane
Actual forwarding of traffic according to the forwarding logic from the Control Plane
* Examples:
* Forwarding packets at the IP layer, doing things like switching at layer 2
* The act of actually taking a packet at an input port and forwarding it at an output port is a data plane function
Why separate Control and Data planes?
- Independent evolution and development
* Plus, SW control of the network can evolve independently of the network hardware - Opportunity to control the network behavior from a high-level software program
* In theory, this allows network operators to debug and check behavior more easily than in the status quo where network behavior is determined by distributed low-level configuration across 100s of switches and routers
The separation of data and control provides opportunities:
- Data centers, by facilitating network tasks such as VM migration to adapt to fluctuating network demands
- In routing: it provides more control over decision logic
- Enterprise: provides the ability to write security applications such as applications that manage network access control
- Research: allows us to virtualize the network so that research networks and experimental protocols can coexist with production networks on the same underlying network hardware
What are reasons for separating data and control planes?
- No single point of failure
- Ability to scale to much larger networks
- Independent evolution of data and control planes
- Separating vendor hardware from control logic
- Easier reasoning about network behavior
- Independent evolution of data and control planes
- Separating vendor hardware from control logic
- Easier reasoning about network behavior
How does control/data separation make managing data centers easier?
- Monitoring/control of routes from a central point
- Migrating VMs without renumbering host addresses
- Fewer switches
- Auto load balance
- Monitoring/control of routes from a central point
- Migrating VMs without renumbering host addresses
2 fundamental challenges with SDN
- Scalability
* A single control element might be responsible for many forwarding elements (maybe hundreds to thousands of switches) - Consistency
* For redundancy and reliability, typically we want to replicate the controller. So, while it’s logically centralized physically there may be many replicas. In such a scenario, we need to make sure different controller replicas see the same view of the network, so that they make consistent decisions when they’re installing state in the data plane
-A final challenge, also worth mentioning, is Security/Robustness: want to make sure that the network continues to function correctly in the event that a controller replica fails or is compromised
What are ways to cope with scalability challenges?
- Eliminate redundant data structures
- Only perform control-plane operations for a limited # of hops
- Send all traffic to controller
- Cache forwarding decisions in switches
- Run multiple controllers
- Eliminate redundant data structures
- Only perform control-plane operations for a limited # of hops
- Cache forwarding decisions in switches
- Run multiple controllers
NOX
- NOX was a first generation OpenFlow controller
* It’s open-source, stable, and widely used - 2 flavors of NOX:
* “Classic”
* Written in C++ and Python and is no longer supported
* “New NOX”
* Written in C++ only
* Codebase is fast, clean, and well-supported
* More info is available at noxrepo.org- The basic abstraction that NOX supports is a switch control abstraction, where OpenFlow is the prevailing protocol
- Control is defined at the granularity of flows, which are defined by a 10-tuple in the original OpenFlow specification
- Controller may make different decisions for packets that belong to different parts of flow space, or packets that match different subnets of the fields defined by a flow
***Watch this lecture again
Basic programmatic interface for the NOX controller is based on
Events
-Controller knows how to process different types of events, such as a switch joining or leaving, packet in/rec’d event, various statistics
NOX provides good performance but requires
The programmer to understand and be comfortable with the facilities and semantics of low-level OpenFlow commands
POX
- NOX requires the programmer to write the control application in C++, which can be slow for development and debugging
* To address the shortcomings in development with C++, POX was developed
* POX is:
* Widely-used
* Maintained
* Supported
* Easy to use
* Easy to read and write control programs
* Since it’s implemented in Python, the performance of POX is not as good as the performance of NOX
When to use POX?
- Class Projet
- Large internet data center
- University research
- Class Projet
- University research
Ryu
- Open-source Python controller
* Supports OpenFlow 1.0, 1.2, 1.3, as well as the Nicira extensions
* Works with OpenStack
* Support for OpenStack and later versions of OpenFlow are advantages over other SDN controllers
* It does NOT perform as well as other SDN controllers, because it was created in Python
Floodlight
- Written in java
* Supports OF 1.0
* Fork from the earlier “Beacon” controller
* Advantages:
* Good documentation
* Integration with REST API
* Good performance
* Disadvantage:
* Steep learning curve. Use it if you already know Java, if you need production level performance and support, and will use the REST API to interact with the controller - ** All of the 4 controllers shown are still relatively hard to use because they entail interacting directly with OpenFlow flow table modifications, which operate at a very low level of matching on flows and performing specific actions.
- ** As we’ll see, it’s possible to develop programming languages on top of these controllers that make it much easier for a network operator to reason about network behavior
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
Constructing a firewall
Building a hash table that maps switch and source MAC address to a True or False value, depending on whether traffic should be forwarded or dropped
Caching
- Packets only reach controller if no flow table entry at switch
- When controller decides on action, installs in switch
- Decision/flow table entry is cached
OpenFlow makes modifying forwarding behavior easy because forwarding decisions are based on…
Matches on the OpenFlow 10-tuple
