Generalized forwarding and SDN

Earlier, we described destination-based forwarding as two steps:

1. match: find the destination IP address
2. action: send the packet through the switching fabric to the correct output port

The match-plus-action pattern

This "match-plus-action" pattern is widely used in networking devices:

• match can use:
  • multiple header fields
  • different protocols
  • different layers of the network stack
• action can include:
  • forwarding to one or more output ports (as in destination-based forwarding)
  • sending traffic across multiple links for load balancing
  • changing header values (as in NAT)
  • dropping packets (as in a firewall)
  • sending packets to a special server for deeper inspection (e.g., DPI)

In this generalized model: a match-plus-action table extends the traditional forwarding table used in destination-based routing.

Devices that use this approach are called programmable or flow-based packet switches, because they can make decisions using both network-layer and link-layer addresses. This term is increasingly used instead of just layer 3 "routers" or layer 2 "switches".

These match-and-action capabilities are controlled by a remote SDN controller that computes, installs, and updates match-plus-action tables in each packet switch.

OpenFlow

OpenFlow helped introduce the match-plus-action model and played a major role in the development of SDN.

Each rule in the match-plus-action forwarding table (known as a flow table entry in OpenFlow) includes:

• match fields:
  • header values to which an incoming packet will be matched
  • packets that match nothing may be dropped or sent to the controller for more processing
• counters:
  • updated as packets are matched to flow table entries
  • might include:
    • the number of packets that have been matched by that table entry
    • the time since the table entry was last updated
• actions:
  • forward to a port
  • drop the packet
  • copy to multiple ports
  • rewrite selected header fields
  • etc.

Match

In OpenFlow 1.0, a match-and-action rule can match:

• 11 packet-header fields
• and the incoming port number

OpenFlow's match abstraction:

• allows for a match to be made on selected fields from three layers of protocol headers (thus defying the layering principle)
• allows forwarding on the basis of Ethernet addresses rather than IP addresses

As a result, an an OpenFlow-enabled device can act as:

• a router (layer-3 device) forwarding datagrams
• a switch (layer-2 device) forwarding frames

Originally, OpenFlow 1.0 supported 12 match fields. Later versions introduced a much more flexible and extensible match structure rather than a fixed count of fields.

Action

Each flow table entry contains a list of zero or more actions that are applied to matching packets.

Possible actions are:

• forwarding:
  • send to a specific output port
  • broadcast to all ports except the incoming one
  • multicast over a selected set of ports
• dropping:
  • no action indicates that a matched packet should be dropped
• modify-field:
  • change packet header values before forwarding

OpenFlow examples of match-plus-action

To show how flexible generalized forwarding is, consider a network with:

• 6 hosts
• 3 packet switches (each with 4 interfaces)

Simple forwarding

Goal:

• packets from h5 or h6 destined to h3 or h4
• should go s3 → s1 → s2
• and avoid the direct link between s3 and s2

Flow table entry in s3:

Match                                                       Action
IP Src = 10.3.*.* ; IP Dst = 10.2.*.*                       Forward(3)

Flow table entry in s1:

Match                                                       Action
Ingress Port = 1 ; IP Src = 10.3.*.* ; IP Dst = 10.2.*.*    Forward(4)

Flow table entry in s2:

Match                                                       Action
Ingress port = 2 ; IP Dst = 10.2.0.3                        Forward(3)
Ingress port = 2 ; IP Dst = 10.2.0.4                        Forward(4)

Load balancing

Goal:

• traffic from h3 destined to 10.1.*.* uses link s2 → s1
• traffic from h4 destined to 10.1.*.* uses link s2 → s3 → s1
• (this couldn't be achieved with IP's destination-based forwarding)

Flow table entry in s2:

Match                                                       Action
Ingress port = 3; IP Dst = 10.1.*.*                         Forward(2)
Ingress port = 4; IP Dst = 10.1.*.*                         Forward(1)

Additional rules are needed:

• at s1 to forward the datagrams received from s2 to either h1 or h2
• at s3 to forward datagrams received on interface 4 from s2 over interface 3 toward s1

Firewalling

Goal:

• s2 should only accept traffic from hosts connected to s3 (10.3.*.*)

Flow table entry in s2:

Match                                                       Action
IP Src = 10.3.*.* IP Dst = 10.2.0.3                         Forward(3)
IP Src = 10.3.*.* IP Dst = 10.2.0.4                         Forward(4)

If no other rules exist: all other traffic is effectively blocked.