Software Defined Networking

Objective.

• A tool to enable a higher degree of control over network devices and traffic flow.

Main aspects.

• Control plane is separated from the device implementing the data plane.

• A single control plane is bale to manage multiple network devices.

Initial deployments.

• Universities: to try out radical new protocols in parallel with existing traffic.

• Busy data centres: overcome the VLAN ID tag limit (4095).

Protocols:

• OpenFlow (first).

• P4 (now).

OpenFlow

A protocol existing between SDN switches and a new entity.

• SDN controller.

Allows the SDN controller to manage flow tables in SDN switches.

SDN switch contains.

• Openflow agent.

• Flow tables.

• Performs packet lookup and forwarding.

• Is able to communicate (securely) with the controller.

A flow table is composed of:

• Flow entries (matches properties in packets’ headers).

• Counters (for activity).

• A set of actions to be applied (to matching packets).

• When no actions are present, the switch can.

  • Drop the packet.

  • Ask the controller what to do.

Controller

Service existing in a server, which uses the OpenFlow protocol to interact with SDN switches.

Formulates flows and programs switches.

Is able to receive directives from external applications via northbound REST API.

REST API

SDN switch

Has an OpenFlow agent that is able to communicate with the controller.

Processes commands received by the controller.

Dataplane of a switch:

• Ports.

• Flow tables.

• Flows.

• Classifiers (Match).

• Modifiers and actions.

Packets are matched to flows in flow tables using the match/classifiers.

Flows contain sets of modifiers and actions which are applied to each packet that it matches.

Flow table

Each flow table entry contains: Match, Action and counters.

Flows

Examples of matching.

• TCP port 80 for a /32 IP address (fine matching).

• All in ingress port 4 (course matching).

Matching can be done from layer 1 to layer 4 fields.

• OSI Network Stack model.

• Layer1: Input port of the switch.

• Layer2: Ethernet (L2 Data).

• Layer3: IP (L3 Network, can be subnet masked).

• Layer4: (L4 Transport, TCP/UDP ports)

Actions

When a switch first connects to a controller, it specifies which actions are supported.

• Not all switches need to implemente all OpenFlow actions.

Examples of actions:

• Forward a packet to a set of ports.

• Drop a packet.

• Add, modify or remove VLAN ID or priority on a per-destination-port basis.

• Modify the IP DSCP (i.e., QoS).

• Modify the destination MAC address.

• Send the packet to the OpenFlow controller (Packet In).

• Receive the packet from the OpenFlow controller and send it to ports (Packet out).

OpenFlow

Protocol

Supports three types of messages:

• Controller→switch: may not require a response

  • Feature request.

  • Configuration.

  • Modify state – used to add / delete / modify flows on the switch.

• Asynchronous: switch sends an unsolicited message to controller

  • Packet-in.

  • Flow removed.

• Symmetric: unsolicited sent by either switch or controller

  • Hello.

  • Echo.

Switch

Start-up example.

Message Details

Controller <-> Switch Connectivity keep alive.

• ECHO_REQUEST / ECHO_REPLY

Implement flows into the switch’s flow table.

• FLOW_MOD

Switch acknowledges to the controller that actions were executed.

• BARRIER_REQUEST

Flow insertion

Flows can be pre-loaded.

• But this is just like any ordinary non-SDN switch.

SDN supports two other ways, involving interaction between the controller and the switch.

• Reactive.

• Proactive.

Reactive flow insertion

The flow’s first packet is sent to the controller (PACKET_IN).

The controller analyses the packet. Based on the packet’s information and directives present in the controller, the controller sends a FLOD_MOD message to the switch, telling it to insert a flow table entry for the packet.

Subsequent packets (in flow) match the entry until idle or hard timeout.

Loss of connectivity between the switch and controller limits the utility of the switch.

Proactive flow insertion

The controller pre-populates flow table in the switch.

There is zero setup time for new flows.

Loss of connection between switches and the controller does not disrupt network traffic.

Switch in proactive forwarding mode only, would default to action = drop.

Northbound REST API is used to populate proactive flows.

OpenFlow Problems

It only controlled flow tables, not the switch pipeline.

Fragmentation adoption.

• Different pace in adopting versions.

• The protocol evolves slowly (i.e., slow adoption of new match fields).

• Optional fields are not mandatory.

Limited tunnel support.

High codebase footprint.

Limited telemetry.

It wasn’t designed to be updated.

Lack of intelligence at the dataplane.