Software Defined Networking (SDN) Motivation

Motivation for SDN

• Traditional IP networks faced challenges with increasing complexity and the dynamic nature of networks.
• Network policy implementations necessitated changes down to individual network devices, often via vendor-specific commands and manual configurations.
• Traditional IP networks lacked automatic response mechanisms to dynamic network environment changes.
• Traditional IP networks tightly coupled the control and data planes, making them inflexible.
• Protocol updates in traditional IP networks could take up to 10 years due to the need for changes to propagate to every device across an IP network.
• Software Defined Networking (SDN) aims to overcome legacy IP networking limitations.
• SDN separates the control plane logic from the data plane.
• With SDN, network switches primarily forward traffic, while control logic is in a logically centralized controller or network OS.
• SDN allows for innovation in network reconfiguration policy enforcement.
• Production-level SDNs require a physically distributed control plane for performance, reliability, and scalability, despite the centralized nature of control logic.
• The separation of control and data planes uses a programming interface between the SDN controller and the switches.
• The SDN controller uses an API to control data plane elements; OpenFlow is an example of such an API.
• An OpenFlow switch contains packet handling rules
• Each rule directs how to handle a subset of network traffic (dropping, forwarding, modifying, etc.).
• An OpenFlow switch can act as a firewall, switch, router, load balancer, or traffic shaper, as determined by the controller.
• SDN allows for a separation of concerns between defining networking policies, hardware implementation, and traffic forwarding.
• This separation simplifies networking management and enables innovation through newer networking abstractions.

SDN Advantages

• Traditional computer networks have three planes of functionality:

  • Data plane: Forwards data packets or frames.
  • Control plane: Determines paths using protocols to populate forwarding tables.
  • Management plane: Monitors and configures control functionality (e.g., using SNMP-based tools).

• A network policy defined in the management plane is enforced by the control plane, and executed by the data plane.

• Conventional networks tightly couple the data and control planes, embedding the networking components

• Adding new networking features to conventional networks requires modifying all control plane devices (firmware/hardware upgrades).

• Specialized equipment (middleboxes) such as load balancers, intrusion detection systems and firewalls were introduced to avoid modifying all control plane devices.

• Middleboxes need strategic placement in the network topology, making them difficult to reconfigure.

• SDN decouples the control plane, isolating it as an external entity (SDN controller).

• With SDN, middlebox services can be viewed as SDN controller applications, offering advantages such as:

  • Shared abstractions: Easy programming due to shared abstractions provided by the control platform and network programming languages.
  • Consistent information: All network applications have the same global network view, leading to consistent policy decisions and control plane module reuse.
  • Locality of placement: Middlebox applications can take actions from anywhere in the network.
  • Simpler integration: Networking applications integrate more smoothly (e.g., load balancing and routing).

The SDN Landscape

• The SDN architecture can be decomposed into layers.
• Each layer performs its own functions through different technologies.
• The SDN landscape can be viewed from plane-oriented, SDN layers, and system design perspectives.

SDN Technologies

• Infrastructure: Consists of networking equipment (routers, switches, middlebox hardware).
  • Physical networking equipment are forwarding elements that perform simple forwarding, directed by a centralized control system.
  • Examples: OpenFlow switches like SwitchLight, Open vSwitch, Pica8, etc.
• Southbound interfaces: Act as connecting bridges between control and forwarding elements.
  • These APIs are tightly coupled with the forwarding elements of the underlying physical or virtual infrastructure.
  • Examples: OpenFlow, ForCES, OVSDB, POF, OpFlex, OpenStack, etc.
• Network virtualization: Provides support for arbitrary network topologies and addressing schemes.
  • Existing virtualization constructs (VLAN, NAT, MPLS) require box-by-box configuration without a unifying abstraction.
  • Advancements: VxLAN, NVGRE, FlowVisor, FlowN, NVP.
• Network operating systems (NOS): Ease network management by using a logically centralized controller.
  • Provide abstractions, essential services, and common APIs to developers.
  • Examples: OpenDayLight, OpenContrail, Onix, Beacon, HP VAN SDN.
• Northbound interfaces: Software ecosystems that guarantee programming language and controller independence.
  • Examples: Floodlight, Trema, NOX, Onix, SFNet.
• Language-based virtualization: Expresses modularity and abstraction, allowing different views of a single physical device.
  • Examples: Pyretic, libNetVirt, AutoSlice, RadioVisor, OpenVirteX, etc.
• Network programming languages: Achieve network programmability using low-level or high-level languages.
  • High-level languages offer abstractions, modularity, reusable code, and faster development.
  • Examples: Pyretic, Frenetic, Merlin, Nettle, Procera, FML, etc.
• Network applications: Implement control plane logic and translate to commands in the data plane.
  • Wide variety of applications include routing, load balancing, security enforcement, QoS enforcement, power consumption reduction, network virtualization, mobility management, etc.
  • Examples: Hedera, Aster*x, OSP, OpenQoS, Pronto, Plug-N-Serve, SIMPLE, FAMS, FlowSense, OpenTCP, NetGraph, FortNOX, FlowNAC, VAVE, etc.

SDN Infrastructure Layer

• SDN infrastructure includes networking equipment performing simple forwarding tasks, without embedded intelligence or control.

• Network intelligence is delegated to a logically centralized Network Operating System (NOS).

• SDN networks are built on open and standard interfaces for configuration and communication compatibility.

• These networks dynamically program heterogeneous devices as forwarding devices.

• A data plane device forwards packets, while a controller is software running on commodity hardware.

• OpenFlow is the most widely accepted design of SDN data plane devices.

• An OpenFlow device uses a pipeline of flow tables, where each entry includes:

  • Matching rule
  • Actions to be executed on matching packets
  • Counters for statistics of matching packets

• Other specifications: Protocol-Oblivious Forwarding (POF) and Negotiable Datapath Models (NDMs).

• In an OpenFlow device, packet lookup starts in the first table and ends with a match or a miss.

• Possible actions for a packet include:

  • Forwarding to outgoing port
  • Encapsulating and forwarding to controller
  • Dropping the packet
  • Sending to normal processing pipeline
  • Sending to next flow table

SDN Southbound Interfaces

• Southbound interfaces (APIs) separate the control plane and data plane functionality.

• API proposals like OpenFlow promote interoperability and vendor-agnostic devices.

• OpenFlow is the most widely accepted southbound standard for SDNs.

• OpenFlow provides specifications for OpenFlow-enabled forwarding devices and communication between data and control plane devices.

• OpenFlow protocol provides three information sources:

  • Event-based messages from forwarding devices to the controller for link or port changes
  • Flow statistics generated by forwarding devices and collected by the controller
  • Packet messages sent to the controller when the forwarding device doesn't know how to handle a new flow

• These channels provide flow-level information to the Network Operating System (NOS).

• Other API proposals: ForCES, OVSDB, POF, OpFlex, OpenState, etc.

• ForCES provides a flexible approach to network management without a logically centralized controller.

• OVSDB acts complementary to OpenFlow or Open vSwitch.

• It allows control elements to create vSwitch instances, set QoS policies, attach interfaces, configure tunnel interfaces, manage queues, and collect statistics.

SDN Controllers: Centralized vs Distributed

• Traditional networks use low-level, device-specific instruction sets and proprietary network operating systems, challenging device-agnostic developments.
• SDN offers a logically centralized control through a controller.
• A controller is a key element in SDN, supporting control logic to generate network configurations based on operator-defined policies.
• Base network service functions are essential for all controllers:
  • Topology
  • Statistics
  • Notifications
  • Device management
  • Shortest path forwarding
  • Security mechanisms
• SDN Controllers can be categorized based on centralized or distributed architecture:
  • Centralized controllers:
    • Typically a single entity that manages all forwarding devices in the network
    • Can have issues with scaling and single point of failure
    • Architectures like Maestro, Beacon, NOX-MT use multi-threaded designs
    • Controllers such as Rosemary offer specific functionality and guarantees security and isolation of applications via a container based architecture called micro-NOS
  • Distributed controllers:
    • Can be scaled to meet the requirements of any environment
    • Distribution can occur in two ways: a centralized cluster of nodes or a physically distributed set of elements
    • Properties of distributed controllers include weak consistency semantics and fault tolerance

An Example Controller: ONOS

• ONOS (Open Networking Operating System) is a distributed SDN control platform.
• Aims to provide a global view of the network to applications, scale-out performance, and fault tolerance.
• The prototype was built based on Floodlight, an open-source single-instance SDN controller.
• With ONOS' distributed architecture, multiple ONOS instances run in a cluster.
• Management and sharing of the network state are achieved by maintaining a global network view.
• This view is built using network topology and state information discovered by each instance.
• Applications consume information from the view and update decisions back to the view.
• An OpenFlow manager receives the changes from the applications and programs appropriate switches.
• Titan (graph database) and Cassandra (distributed key value store) are used to implement the view.
• Applications interact with the network view using the Blueprints graph API.
• ONOS redistributes the work of a failed instance to other remaining instances when an instances fails.
• Each switch in the network connects to multiple ONOS instances, with only one acting as its master.
• Each ONOS instance acts as a master for a subset of switches.
• Upon failure of an ONOS instance, an election is held on a consensus basis to choose a master.
• Zookeeper is used to maintain mastership between the switch and the controller.

Programming the Data Plane: The Motivation

• P4 (Programming Protocol-independent Packet Processors) is a high-level programming language to configure switches, working with SDN control protocols.

• P4 enables the control plane to manage devices from different vendors.

• P4 provides an extensible, flexible approach to parse packets and match header fields, while exposing an open interface to controllers.

• P4 acts as a general interface between switches and the controller, allowing the controller to define how switches operate.

• The primary goals of P4 are:

  • Reconfigurability: The controller should be able to modify how packets are parsed and processed in switches.
  • Protocol independence: The controller defines a packet parser and match+action tables, enabling switches to be independent of any particular protocol.
  • Target independence: Packet processing programs should be independent of underlying target devices.

• Generalized programs written in P4 should be converted into target-dependent programs by a compiler.

Programming the Data Plane: P4's Forwarding Model

• Switches using P4 use a programmable parser and match+action tables to forward packets.

• The tables can be accessed in multiple stages in a series or parallel manner.

• The P4 model allows generalization of packet processing across various forwarding devices (routers, load balancers, etc.).

• A compiler maps these programs to different forwarding devices.

• Two main operations of the P4 forwarding model are:

  • Configure: Programming the parser, specifying header fields, and defining the order of stages.
  • Populate: Altering entries in the match+action tables specified during configuration, including adding and deleting entries.

• Configuration determines packet processing and supported protocols, while population decides policies applied to packets.

An Introduction To The P4 Programming Language

• P4 is a packet processing language that defines the configuration of a switch and the processing of a packet.
• P4 characteristics include:
  • Legal header types are declared for the parser to be aware of possible packet formats.
  • A control flow program uses declared header types and a set of actions to specify how headers are processed.
  • Table Dependency Graphs (TDGs) identify dependencies between header fields.
  • Tables with no dependencies may be executed in parallel.
• The control flow logic to process packets is written using P4, transformed to TDGs using a compiler and mapped to a specific target switch.

SDN Applications: Overview

• Traffic Engineering
  • Optimizing traffic flow to minimize power consumption, use network resources judiciously, and perform load balancing.
  • Power consumption can be reduced with optimization algorithms and monitoring of the data plane load.
  • ElasticTree identifies and shuts down specific links and devices depending on traffic load.
  • Load balancing applications (Plug-n-Serve, Aster*x) achieve scalability using wildcard patterns.
  • SDN automates router configuration to reduce routing table growth.
  • Providers use SDN to scale traffic optimization dynamically (e.g., ALTO VPN enables provision of VPNs in cloud infrastructure).
• Mobility and Wireless
  • Wireless networks face challenges including management of the limited spectrum, allocation of radio resources, and load-balancing.
  • SDN simplifies the deployment and management of various wireless networks (WLANS, cellular networks).
  • SDN-based wireless networks offer on-demand virtual access points (VAPs), dynamic spectrum usage, wireless infrastructure sharing, etc.
  • OpenRadio decouples wireless protocols from underlying hardware by providing an abstraction layer.
  • Light virtual access points (LVAPs) offer one-to-one mapping between LVAPs and clients.
  • Applications, such as Odin, provide features such as mobility management, channel selection algorithms, etc.
  • A user can move between APs without lag as the mobility manager automatically moves the client LVAP to a different AP.
• Measurement and Monitoring
  • Applications add features to other networking services.
  • SDN-based broadband connections enable systems to respond to network conditions.
  • Applications improve existing SDN features using OpenFlow
  • Sampling and estimation techniques are used to reduce the control plane load from data plane statistics.
  • OpenSketch is a southbound API for flexible network measurements.
  • OpenSample and PayLess are examples of monitoring frameworks.
• Security and Dependability
  • Applications focus on improving network security.
  • Security policies are can be imposed on network entry points.
  • Programmable devices enforce security policies on a wider network.
  • An SDN application named, DDoS detection, identifies and mitigates DDoS flooding attacks by leveraging timely network information.
  • SDN also detects traffic anomalies, mutates IP addresses of hosts to fake dynamic IPs (OF-RHM), and monitors cloud infrastructures (CloudWatcher).
• Data Center Networking
  • SDN offers services such as live migration of networks, troubleshooting, real-time monitoring, etc.
  • SDN applications can help detect anomalous behavior in data centers.
  • SDN can create different models build application signatures from network device information.
  • Anomalies are identified, and measures can be taken.
  • SDN performs dynamic reconfigurations of virtual networks during live virtual network migrations.
  • LIME provides live migration.
  • FlowDiff detects abnormalities.

SDN Applications: Internet Exchange Points (IXPs)

• SDN improves IXP operation.

• Internet routing is handled through Border Gateway Protocol (BGP).

• BGP's limitations include routing only on destination IP prefix and limited control over end-to-end paths.

• SDN can perform multiple actions on traffic by matching over various header fields.

• An Internet Exchange Point (IXP) facilitates interconnection between networks for traffic exchange and BGP routes.

• SDX enables multiple applications:

  • Application specific peering
  • Traffic engineering
  • Traffic load balancing
  • Traffic redirection through middleboxes

• In SDX architecture, each AS has a virtual SDN switch that connects its border router to every other participant AS.

• Each AS defines forwarding policies without influencing how others forward packets.

• Each AS can drop, modify, or forward traffic using SDN applications.

• Policies can differ based on traffic direction (inbound or outbound).

• SDX combines policies from multiple participants into a single policy for the physical switch.

• SDX uses the Pyretic language to match packet header fields and express actions.

• In application-specific peering, a network can forward HTTP traffic to one AS and HTTPS traffic to another

• This is expressed using the match statement.

SDN Applications: Wide Area Traffic Delivery

• Application specific peering: ISPs can direct high application traffic flows (YouTube, Netflix) to dedicated ASes.
• Inbound traffic engineering: SDN enables forwarding rules based on the source IP address and source port of the packets, enabling an AS to control how traffic enters its network.
• Wide-area server load balancing: Can be achieved via the SDX, as it supports the modification of packet headers. An IP address can be assigned to a service, and the destination IP addresses of packets can be modified at the exchange point to balance the request load amongst the backend servers.
• Redirection through middle boxes can be achieved via SDX to overcome challenges in existing approaches to using middleboxes (firewalls, load balancers, etc):
  • SDX can identify and redirect desired traffic through a sequence of middleboxes.