WSDN01 - Module 2 - OpenFlow - v1 · PDF file1.5.0 1.5.1. OpenFlowrevisions: features 6 1.0.0 •First non-experimental version ... –OpenFlow-only: perform forwarding based purely

Issue Date:

Revision:

SDN Workshop

Contact: [email protected]

[Date]

[xx]

WSDN01_v0.1

Issue Date:

Revision:

OpenFlowSDN Workshop

[Date]

[xx]

WSDN01_v0.1

SDN architectural framework

3

Application Plane

Application Service

Topology Discovery & Management

Network Devices – IP/MPLS/Transport

Southbound Interfaces

REST/RESTCONF/NETCONF/XMPP

Control Plane

(controller)

Traffic Engineering

Route selection & failover

Resource Management

BGP-LS PCE-Pi2RS

SNMP MIBs YANG

Configuration

OpenFlowSNMP Netconf

Data Plane

BGP PCCRIBs

RSVP-TE

East/West-bound

interfaces –BGP

IPFIXForCES

Northbound Interfaces

Note: designations of north-bound and south-bound are relative to the control plane (“controller”)

Device & Resource Abstraction Layer (DAL)

Network Services Abstraction Layer

Segment Routing

OpenFlow

OpenFlow versions

• From v1.0.0 in 2009 to v1.5.2 in 2015• Developed by the Open Networking Foundation (ONF)

since its foundation in March 2011• We shall start with v1.0.0 to get a basic understanding of

how it operates.– Note that there are significant changes in newer versions that will be

pointed out.

4

OpenFlow revision timeline

5

201520122010 2011 2013 2014 20162009

Version 1.0.x

Version 1.1.x

Version 1.2.x

Version 1.3.x

Version 1.4.x

Version 1.5.x

1.0.0 1.0.1 1.0.2

1.1.0

1.2.0

1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

1.4.0 1.4.1

1.5.11.5.0

OpenFlow revisions: features

6

1.0.0

• First non-experimental version

• Single table• Hard-coded

12-tuple match

1.1.0

• Multiple flow tables

• Group tables• Instructions• Metadata• MPLS support

1.2.0

• OpenFloweXtensible Match

• IPv6• Multiple

controllers

1.3.0

• Multipart framework

• Table-miss flow entry

• Per-flow meters

1.4.0

• Protocol extensibility• Flow monitoring• Eviction and vacancy

events• Message bundling• Table synchronisation

1.5.0

• Egress tables• Packet-aware pipeline• OpenFlow eXtensible

Statistics• Stats trigger• Non-ethernet packets

7

OpenFlow v1.0.0

OpenFlow v1.0.0

8

201520122010 2011 2013 2014 20162009

Version 1.0.x

Version 1.1.x

Version 1.2.x

Version 1.3.x

Version 1.4.x

Version 1.5.x

1.0.0 1.0.1 1.0.2

1.1.0

1.2.0

1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

1.4.0 1.4.1

1.5.11.5.0

OpenFlow v1.0.0

• First non-experimental release – version 1.0.0– Wire protocol 0x01– December 31, 2009

• Specified two types of OpenFlow-compliant switches*:– OpenFlow-only: perform forwarding based purely on OpenFlow flow

tables– OpenFlow-enabled: support ‘traditional’ Ethernet switching and

routing functions in addition to OpenFlow packet forwarding

9

* Definition was modified in later revisions of OpenFlow

OpenFlow components

An OpenFlow switch communicates with a controller over a secure connection using the OpenFlow protocol.

10

Secure Channel

Flow Table

OpenFlow Switch

OpenFlowProtocol

OpenFlowController

OpenFlow Switch components

• Flow table (single):– Set of flow entries which specify packet match conditions and

resulting actions

• Secure channel:– Channel to an external controller which manages the switch using the

OpenFlow protocol

11

Flow table

• Contains a set of flow entries with:– Packet match criteria (e.g. header fields to match against packets)– Zero or more actions to apply to matching packets– Activity counters that are updated for matching packets

12

Header Fields Actions Counters

Flow entry 1 Forward to port 1/1Flow entry 2 DropFlow entry n Send to controller

Match fields

13

Ingress portEthernet source address

Ethernet destination addressEthertypeVLAN ID

VLAN priorityIP source address

IP destination addressIP protocolIP ToS bits

TCP/UDP source portTCP/UDP destination port

Match can be an exact value or ANY which matches any value (wildcard). Bitmasks can also be used for partial matches.

Some fields may have dependencies e.g. IP protocol field can only be used if there is a corresponding match for the IPv4 EtherType.

Actions

14

Forward (output)Mandatory

Forwarding of packet to physical or virtual ports

EnqueueOptional

Forward a packet through a specified queue attached to a

port

DropMandatory

Implicit action associated with a flow-entry that has no specified

action

• Each flow entry has zero or more actions that determine how the switch handles matching packets– If no ’forward’ actions are specified, the packet is dropped

Modify-fieldOptional

Specify modification of packet header fields

Supported Actions

15

Action DescriptionOutput Output to switch port

Set VLAN VID Set the IEEE802.1q VLAN ID

Set VLAN PCP Set IEEE802.1q priority

Strip VLAN Strip the IEEE802.1q header

Set Ethernet source address Set Ethernet source address

Set Ethernet destination address Set Ethernet destination address

Set IP source address Set IP source address

Set IP destination address Set IP destination address

Set IP ToS Set IP Type of Service (ToS) bits

Set TCP/UDP source port Set TCP/UDP source port

Set TCP /UDP destination port Set TCP /UDP destination port

Enqueue Output packet to a queue

Counters

• Per-table, per-flow, per-port and per-queue

16

Per-tableActive Entries

Packet lookups

Packet matches

Per-flowReceived packets

Received bytes

Duration (seconds)

Duration (nanoseconds)

Per-portReceived packets

Transmitted packets

Received bytes

Transmitted bytes

Receive drops

Transmit drops

Receive errors

Transmit errors

Receive frame alignment errors

Received overrun errors

Receive CRC errors

Collisions

Per-queueTransmit packets

Transmit bytes

Transmit overrun errors

Flow table example

17

Header Fields ActionsInputport

Eth Src

Eth Dest Ether Type

VID PCP IPSrc

IP Dest

IP Proto

IP ToS

L4 SrcPort

L4 DestPort

* * 12:34:56:AB:CD:EF * * * * * * * * * Output to port 1/2

* * 11:22:33:44:55:66 * * * * * * * * * Output to port 3/8

Ethernet learning switch


Eth Src

Eth Dest

Ether Type

VID PCP IP Src IP Dest IP Proto

IP ToS

L4 SrcPort

L4 DestPort

* * * 0x0800 * * 10.1.1.0/24 192.168.32.3/32 6 * * 80 Forward

* * * 0x0800 * * 172.16.0.0/16

192.168.32.3/32 6 * * 80 Forward

* * * * * * * * * * * * Drop

Firewall

OpenFlow ports

18

Virtu

al P

orts

‘ALL’: all OpenFlow interfaces except the incoming interface

‘CONTROLLER’: logical interface to the OpenFlowcontroller

‘LOCAL’: local networking stack of the switch

‘TABLE’: sends packet for processing through the flow table (only for Packet-Out messages)

’IN_PORT’: ingress port of packet

‘NORMAL’: processes packets via the traditional forwarding path supported by the switch

‘FLOOD’: flood along the minimum spanning tree

Phys

ical

Por

ts

Physical hardware ports*

*For an ‘OpenFlow-enabled’ switch, these are ports that have been explicitly configured to be OpenFlow ports

Basic packet processing

• All packets ingressing the switch via an OpenFlow port are compared against the flow table.

• If a matching entry is found, any actions for that entry are performed on the packet e.g. forward to a specified port

• If no match is found, the packet is forwarded to the controller over the secure channel

19

Matching

20

Packet ingressing into

switch

Parse header fields

(see next slide)

Match flow

table ?Perform actions

Yes

No

Send to controller via

Secure channel

Header field parsing

21

Initialise headersSet input port, Ethernet source &

destination, Ethertype

Ethtype =

0x8100?

Ethtype =

0x0806?

Ethtype =

0x0800?

Yes

No

No

No

Set VLAN ID and PCP

Set IP source/destfrom within ARP

packet

Yes Set IP source/dest. protocol and ToS fields

Yes

Not IP Fragment

?

No

Yes

Packet Lookup

IP Proto = 6 or 17 ?

No

No

IP Proto = 1 ?

Yes Yes

Use UDP/TCP source and dest for L4

fields

Use ICMP type and code for L4

fields

OpenFlow Secure Channel

• This is the logical interface that connects each OpenFlowswitch to an OpenFlow controller.

• The OpenFlow controller uses this interface to:– Configure and manage the switch– Add, delete and modify flow entries– Receive events from the switch– Send packets out the switch

• OpenFlow version 1.0.0 only supported use of a single controller.

22

Connection setup

• A TLS connection is established by the switch to a configured IP address and TCP port 6633 (changed in later releases to the IANA-assigned port number of 6653)

• Traffic to/from the secure channel is not processed by the flow table

23

Connection interruption

• If connectivity with the controller is lost, the switch enters “emergency mode”.

• In “emergency mode”:– Matching process is based only on flow table entries marked with the

emergency bit (indicated via the Flags field of the Flow-Mod message)

– All non-emergency entries are deleted when entering emergency mode

• On initial startup, all switches are in “emergency mode”

• “Emergency mode” was removed from later versions.

24

CHANGED BEHAVIOUR IN LATER VERSIONS

OpenFlow protocol messages

• Protocol defines three types of messages.

• Controller-to-switch:– Are initiated by the controller and used to configure the switch or

query its state

• Asynchronous:– Are initiated by the switch and used to notify the controller about

network events or changes to the switch state

• Symmetric:– Can be initiated by either the controller or the switch and sent without

solicitation

25

Controller-to-Switch messages

• Initiated by the controller and may or may not require a response from the switch.

• Messages include:– Features: used by the controller to discover the capabilities

supported by the switch– Configuration: used to set and query configuration parameters– Modify-state: sent by the controller to manage state on the switch.

Main purpose is to add/delete/modify flows– Read-state: used by the controller to query stats from the switch– Packet-out: used by the controller to send a packet out of a specified

port of the switch– Barrier: used to ensure message dependencies

26

Asynchronous messages

• Initiated by the switch without solicitation from the controller.

• Messages include:– Packet-in: sent to the controller for all packets that:

• do not have a matching flow entry • OR are explicitly sent to the controller

– Flow-removed: sent when flows are removed from the flow-table. May be due to expiration or explicit deletion.

– Port-status: sent by the switch on port configuration or state changes.– Errors: sent when errors are detected

27

Symmetric messages

• Can be initiated by either the controller or the switch and sent without solicitation

• Messages include:– Hello: sent between the controller and switch upon connection

establishment– Echo: echo request/reply messages can be sent from either the

switch or the controller; request messages must be responded to with a reply.

– Vendor: vendor-specific messages

28

OpenFlow protocol

• Common OpenFlow packet header– All OpenFlow messages start with this header

29

xid

version lengthtype

Version:- version of OpenFlow protocol

Type: - type of OpenFlow protocol message

Length: - total length of message in octets

xid: - transaction ID used to match responses with requests

32 bits8 bits 16 bits8 bits

OpenFlow version numbers

30

Version of specification OpenFlow protocol version1.0.x 0x011.1.x 0x021.2.x 0x031.3.x 0x041.4.x 0x051.5.x 0x06

• Version number has incremented with every major release of the OpenFlow specification

• OpenFlow versions are NOT backwards-compatible. For example, a device running version 0x03 will not fall back to 0x01 to interwork with a device that only supports 0x01.

OpenFlow message types

31

ID Type0 Hello

1 Error

2 Echo Request

3 Echo Reply

4 Vendor

SymmetricID Type5 Features Request

6 Features Reply

7 Get Config Request

8 Get Config Reply

9 Set Config

13 Packet-out

14 Flow Mod

15 Port Mod

16 Stats Request

17 Stats Reply

18 Barrier Request

19 Barrier Reply

20 Queue Get Config Request

21 Queue Get Config Reply

ID Type10 Packet-In

11 Flow-removed

12 Port status

Asynchronous

Controller-to-Switch

Features

Configuration

Modify-state

Read-state

Packet-out

Configuration

Barrier

Version negotiation

• On connection establishment:

– Each side sends a Hello message with the ‘version’ set to the highest OpenFlow version supported by the sender. The Hello message does not have a body, just the OpenFlow header.

– The OpenFlow protocol version negotiated independently by each side is:

minimum (version number that was sent, version number that was received)

– This only works if the side with the higher version number also supports the lower version number. If not, an error occurs.

32

Understanding switch capabilities

• Due to the large number of required and optional OpenFlowcapabilities, it is important for the controller to understand the features supported by the switch it is managing.

• A features/capabilities discovery is done via a handshake to acquire this information.

33

Handshake

• Once the TLS session is established, the controller sends a Features Request message.

• The switch responds with a Features Reply message:

34

32 bits

datapath id

#buffers

Datapath ID:- Uniquely identifies a

datapath. Lower 48-bits are the switch MAC address.

Capabilities:- Types of stats supported

etc.

Actions:- Action types supported

by switch

Ports:- Array of OpenFlow-

enabled physical ports

actions

port descriptors…

#tables

Capabilities

Padding

Flow table modification messages

• 5 possible operations:

– Add: instantiates a new flow entry in the flow table

– Modify: modifies elements of all (existing) matching flow entries

– Modify-Strict: modifies elements of flow entries that exactly match all fields including wildcards and priority

– Delete: deletes all (existing) matching flow entries

– Delete-Strict: deletes flow entries that exactly match all fields including wildcards and priority

35

Modify Flow Entry Message

• Flow Mod message structure– Structure used to add/delete/modify flow entries

36

buffer id

command

32 bits

cookie

flow match descriptor

idle timeout

hard timeout priority

output port flags

flow action descriptor

Cookie:- Opaque value set by the

controller

Command- Add/Modify/Modify-

strict/Delete/Delete-strict

Priority:- Priority of flow entry.

Higher numerical value implies higher priority

Flow match descriptor

• Flow match descriptor structure– Structure used to describe flow match requirements

37

wildcard fields

vid

ingress port

32 bits

ethernet source address

ethernet destination address

ethertypepaddingpcp

ipv4 source address

ipv4 destination address

tcp/udp dest porttcp/udp source port

Wildcard fields:- Bitmap indicating

which fields are wildcards

paddingip protocolip tos

CHANGED FORMAT IN LATER VERSIONS

Type=“OUTPUT” LengthOutput port Max Length

Flow action descriptor

• Flow action descriptor structure– Structures used to describe flow actions

38

32 bits


Type=“ENQUEUE” LengthPort

32 bits

Queue ID

Padding

Type=“SET VLAN ID” LengthVID Padding

32 bits

Type=“SET NETWORK SRC/DST” Length

32 bits

IP address

Proactive vs reactive flow entries

• Entries in the flow table can be installed either a priori (proactive) or on demand (reactive):

39

Proactive Reactive• Applicable when flow patterns

are known ahead of time• More suitable for aggregate

traffic flows• May require larger tables to

allow a complete set of flow entries

• No delays with flow installation

• May be more applicable to dynamic flow patterns

• Optimises flow table usage as inactive flows may be timed out

• Delays may be experienced with flow installation as first packet needs to be sent to controller

• Uninterrupted connection to controller is essential

It is also possible to have a combination of proactive and reactive flow entries

Flow removal

• All flow entries have two timers associated with them:

– idle_timeout: maximum time that can elapse without a flow matching the flow entry

– hard_timeout: maximum time that a flow entry can remain in the flow table

– A Flow-removed message is sent by the switch to the controller when a flow entry is removed from the flow table

40

Packet-In Message

• Packet-In message structure– For packets sent from the switch to the controller

41

buffer id

total length input port

data (ethernet frame)

Buffer ID:- Identifies where packet

is buffered

Reason:- Either due to no match

or explicit action

Data:- Initial portion of

packet

reason padding

Packet-Out Message

• Packet-Out message structure– For packets sent from the controller to the switch

42

buffer id

32 bits

input port size of actions array

flow action descriptor

Buffer ID:- Same as the buffer ID in

the original Packet-In message

Packet data:- original packet (useful

only when original packet was not buffered)

packet data

Queue structures

• Limited QoS support is provided through a simple queuing mechanism

• Flows can be mapped to queues which attach to a port and can be used to schedule the packets exiting the datapathon that output port

• Each queue is identified by a port number and a queue ID• The only queue configuration options available are:

– min-rate: minimum guaranteed data-rate– max-rate: maximum data-rate

43

Echo Request/Reply Messages

• Echo Request may be initiated by either the controller or the switch

• May be used for a number of reasons:– To determine latency of connection between controller and switch– As a liveness detection mechanism to verify liveness of the

connection between controller and switch

44

Switch bootstrapping

• OpenFlow switches need to be configured with:– URI or <IP address>:<port> of OpenFlow controllers– Can be accomplished via OF-CONFIG

• For OpenFlow-enabled switches:– OpenFlow-capable ports need to be identified and configured– A mechanism must exist to channel flows to either OpenFlow

processing or ‘normal’ processing

• Ports and queues need to be configured• For topology discovery via LLDP (de-facto mechanism):

– A flow entry to direct all received LLDP packets to the controller should be installed

45

Message flow example

46

Controller SwitchHello Hello

Features Request

Features Reply

Packet-Out

Packet-In

Flow-Mod

Initial exchange of Hellos with version negotiation

Discovery of switch features

Reaction to unknown packet flow

Installation of new flow entry

Topology discovery (1)

• The challenge: – How can an OpenFlow controller discover the topology of a network

comprising of OpenFlow switches in the absence of a distributed control plane ?

• OpenFlow Discovery Protocol (OFDP):– Not a formally specified protocol (topology discovery is not specified

in any OpenFlow specification documents)– The concept was inherited from the first implementation of an

OpenFlow controller (the NOX implementation)

47


• Switches need to be bootstrapped as follows:

– URI or <IP address>:<port> of OpenFlow controllers

– A proactive rule is instantiated on all switches to allow dealing with LLDP packets:• If ethertype=LLDP, output to CONTROLLER• In other words, if a packet is received with an ethertype of 0x88cc, it must be

encapsulated within a Packet-In frame and sent to the controller

48

Aside: LLDP

• Standardised by IEEE 802.1ab• Single-hop neighbour discovery protocol

• Operates at Layer 2 (Ethernet layer)• Allows nodes to advertise their identities and capabilities

and learn the identities and capabilities of directly-connected neighbours

• Uses an Ethertype of 0x88cc and a destination multicast address of 01-80-C2-00-00-0E

49

Aside: LLDP (2)

50

LLDPDULLDP Ethertype

Chassis ID TLV

Port ID TLV TTL TLV

Optional TLV ... ...

End of LLDPDU TLV

DescriptionChassis ID TLV Identifier of the switch that sends the LLDP packet

Port ID TLV Identifier of the port through which the packet is sent

TTL TLV Time validity of the information in the LLDP frame

End of LLDPDU Indicates end of the payload in the LLDP frame

Topology discovery process (1)

51

Controller

OpenFlowSwitch 1 (OFS1)



p1 p1

p2

p2

p2

p1

Switches establish OpenFlow channel with the controller

11

1

1


52

Controller




p1 p1

p2

p2

p2

p1

Controller learns of all active ports on all switches via Features Reply message

2

2

2

2


53

Controller



p1 p1

p2

p2

p2

p1

Flow entry installed to forward all LLDP packets to controller

3

3

3

3


Inputport

Eth Src

Eth Dest

Ether Type VID PCP IPSrc

IP Dest

IP Proto

IP ToS

L4 SrcPort

L4 DestPort

Action

* * * 0x88cc * * * * * * * * Send to controller


54

Controller


p1

p2

Controller generates a Packet-Out message (with an encapsulated LLDP packet) for each active port on each switch (only switch OFS1 shown)

4

4Packet-OutOutput port: p1Encapsulated packet: LLDP

Chassis ID: OFS 1Port ID: p1

Packet-OutOutput port: p2Encapsulated packet: LLDP



55

Controller




p1 p1

p2

p2

p2

p1

Switch sends encapsulated LLDP packet out of each active port (only switch OFS1 shown)

5

5

5

LLDPChassis ID: OFS 1

Port ID: p2


Port ID: p1


56

Controller




p1 p1

p2

p2

p2

p1

Switches OFS1 and OFS2 forward received LLDP packets to controller via Packet-In message

6

6

6

Packet-InInput port: p1Encapsulated packet: LLDP





• Controller learns that:

– Port p1 of OFS1 is directly connected to port p1 of OFS3– Port p2 of OFS1 is directly connected to port p1 of OFS2– Port p2 of OFS2 is directly connected to port p2 of OFS3– Port p1 of OFS3 is directly connected to port p1 of OFS1– Port p1 of OFS2 is directly connected to port p2 of OFS1– Port p2 of OFS3 is directly connected to port p2 of OFS2

57

Exclusions

• What OpenFlow does not do (or specify):– Communication between controllers when using multiple controllers

(v1.2.0+)– How OpenFlow is used by northbound applications– Topology discovery– How to bootstrap the network– Construction of paths that traverse multiple OpenFlow switches– Configuration of OpenFlow switches (some of this is enabled by OF-

CONFIG)

58

Versions 1.0.1/1.0.2

• Both releases were errata and/or clarifications for the 1.0.0 specification

• Clarifications:– Packets that do not match any flow should be forwarded to the

controller using a Packet-In message

• Changes:– In addition to “emergency mode”, a new “fail-secure mode” was

defined. In ‘fail-secure’ mode, all packets and messages destined to the controller are dropped. Flow entries continue to be used and expire based on their timeouts.

– IANA allocated port 6653 for OpenFlow communications and was required to be used as the default port (for both TLS or plain TCP)

59

60

OpenFlow v1.1.0

OpenFlow v1.1.0

61

201520122010 2011 2013 2014 20162009

Version 1.0.x

Version 1.1.x

Version 1.2.x

Version 1.3.x

Version 1.4.x

Version 1.5.x

1.0.0 1.0.1 1.0.2

1.1.0

1.2.0

1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

1.4.0 1.4.1

1.5.11.5.0

OpenFlow v1.1.0

• Second major release – version 1.1.0– Wire protocol 0x02– February 28, 2011

• This section highlights deltas from the previous release v1.0.0

62

New features

• Multiple flow tables, pipeline and pipeline processing• Group table

• ‘Actions’ in flow table changed to instructions which describe a set or list of actions

• MPLS header fields supported• Outcome for packets without a match in a flow table are

configurable

• Per-packet metadata for communication between tables• Vendor message changed to Experimenter message

63

OpenFlow switch types

• Specifies two types of OpenFlow-compliant switches:

– OpenFlow-only: perform forwarding based purely on OpenFlow flow tables

– OpenFlow-hybrid: support ‘traditional’ Ethernet switching and routing functions in addition to OpenFlow packet forwarding (was referred to as OpenFlow-enabled in v1.0.0).

64

OpenFlow components

65

OpenFlow Switch

OpenFlow Protocol

Controller

Secure Channel Group Table

Flow Table

Flow Table

…

Flow tables

• Each flow table contains a set of flow entries• Each flow entry consists of:

– Match fields– Counters– Set of instructions to apply to matching packets

66

Match Fields Counters Instructions

• Ingress port

• Packet headers

• Metadata

• Modify action set

• Apply actions• Modify pipeline

processing

New flow table elements

• Metadata: A maskable register value that is used in order to carry information from one flow table to another

• Instructions: either a set of actions to add to the action set, a list of actions to apply immediately to the packet or a modification to pipeline processing.

• Action Set: a set of actions associated with a packet that are accumulated while the packet is processed by each table. The 'Action Set' is executed when the instruction set instructs the packet to exit the processing pipeline.

67

Match fields

68

Ingress port

MetadataEthernet source address

Ethernet destination address

Ethertype

VLAN ID

VLAN priority

MPLS labelMPLS traffic classIPv4 source address

IPv4 destination address

IPv4 protocol

IPv4 ToS bits

TCP/UDP source port

TCP/UDP destination port

Match can be an exact value or ANY which matches any value (wildcard). Bitmasks can also be used for partial matches

Some fields may have dependencies e.g. IP protocol field can only be used if there is a corresponding match for the IPv4 EtherType.

Fields new to v1.1.0 are in bold.

Header field parsingInitialise headers

Set input port, Ethernet source & destination, Ethertype

Ethtype =

0x8100?

Ethtype =

0x0800?

Yes

No

No

No

Set VLAN ID & PCP

YesSet IP source/dest. protocol and ToS

fields

Yes

Not IP Fragment

?

No

Yes

Packet Lookup

IP Proto = 6 or 17 ?

No

No

IP Proto = 1 ?

Yes Yes

Use UDP/TCP/SCTP source and dest

for L4 fields

Use ICMP type and code for L4

fields

Skip any remaining VLAN tags

Switch supports MPLS?

No

Ethtype =

0x8847/8?

Yes Use MPLS label and TC

Supports ARP

Ethtype =

0x0806?

Skip any remaining MPLS

shim headers

No

No

Set IP source/destfrom within ARP

packet

VLAN Tag

MPLS label

ARP

IPv4

Instructions (1)

• Definition: attached to a flow entry as part of an ‘Instruction Set’ and describe the OpenFlow processing that takes place when a packet matches the flow entry.

• Each instruction either:– Modifies pipeline processing e.g. directing the packet to another flow

table OR– Contains a set of actions to add to the ‘Action Set’ OR– Contains a list of actions to apply immediately to the packet

70

Instructions (2)

• Supported instructions include:– Apply-Actions: immediately applies the specified actions. The ‘Action

Set’ is not modified.– Clear-Actions: clears all actions in the ‘Action Set’– Write-Actions: merges the specified actions into the current ‘Action

Set’.– Write-Metadata: writes to the metadata field– Goto-Table: indicates that the packet should next be processed

through the specified table

• Each instruction type may only appear once in the instruction set.

71

Supported Actions

72


Set VLAN VID Set the IEEE802.1q VLAN ID

Set VLAN PCP Set IEEE802.1q priority

Set Ethernet src addr Set Ethernet source address

Set Ethernet dest addr Set Ethernet destination address

Set IP src addr Set IP source address

Set IP dest addr Set IP destination address

Set IP ToS Set IP Type of Service (ToS) bits

Set IP ECN Set IP ECN bits

Set TCP/UDP src port Set TCP/UDP source port

Set TCP /UDP destport

Set TCP /UDP destination port

Copy TTL out Copy TTL from next-to-outermost to outermost header

Copy TTL in Copy TTL from outermostheader to next-to-outermost

Action DescriptionSet MPLS label Set value of MPLS label

Set MPLS TC Set MPLS TC bits

Set MPLS TTL Set value of MPLS TTL

Decrement MPLS TTL

Decrement value of MPLS TTL

Push VLAN Push a new VLAN header

Pop VLAN Pop the outermost VLAN header

Push MPLS Push a new MPLS label

Pop MPLS Pop the outermost MPLS label

Set queue Set ID of queue to output packet to

Set group Set group ID

Set IP TTL Set value of IP header TTL

Decrement IP TTL Decrement value of IP TTL

Actions new to v1.1.0 are in bold.

Actions

73



Set-QueueOptional


port

DropMandatory


action

• Definition: an operation that acts on a packet

Push/Pop-TagOptional

Push/pop of VLAN and MPLS headers

GroupMandatory

Processes the packet through the specified group

Set-fieldOptional

Set packet header fields, manipulate TTL etc.

Action Set (1)

• An ‘Action Set’ is associated with each packet and is empty by default

• As the packet passes through the pipeline the ‘Action Set’ is modified by instructions (Write-Actions, Clear-Actions) of matching flow entries

• The ’Action Set’ is carried between flow tables as the packet progresses through the pipeline

• There is a maximum of one action of each type in the ‘Action Set’.

74

Action Set (2)

• The ’Action Set’ is executed when an instruction set does not include a ‘Goto-Table’ action i.e pipeline processing terminates

• If no output action or group action are specified in an action set, the packet is dropped

75

Actions in Action Set

• Order of application of actions in the ‘Action Set’

76

Order Action1 Copy TTL inwards

2 Pop

3 Push

4 Copy TTL outwards

5 Decrement TTL

6 Set

7 QoS

8 Group

9 Output

If no output action or group action are specified in an action set the packet is dropped.

Action List

• Associated with the ‘Apply-Actions’ instruction and the Packet-Out message.

• Actions in the ‘Action List’ are immediately executed in the order specified in the list.

• Multiple actions of the same type may appear in the same ‘Action List’ and have a cumulative effect.

77

Group table (1)

• Flow entries may point to a group in the group table.• The group table provides sets of actions for flooding,

multipath, fast reroute, link aggregation and indirection.• The group table contains group entries.

• Each group entry has a list of action buckets with semantics depending on group type. The group type determines which of the buckets are applied to each packet.

78

Group table (2)

• The group table contains group entries.• Each group entry contains:

79

Group Identifier Group Type Counters Action Buckets

Group Type Description

all • Executes all buckets in the group• Multicast/broadcast forwarding• Packet is replicated for each bucket

select • Executes one bucket in the group• Packets are sent to a single bucket, based on a hash algorithm

indirect • Executes the one defined bucket in the group• For example, BGP next-hop indirection

fast-failover • Executes the first live bucket• Bucket liveness tied to port(s) or group

Group table: all

80

Group Table

Counters

Bucket 1 ActionsSet output port 1/1


Bucket n ActionsSet output port m/n

. . .

Replicates packet to all buckets and executes corresponding actions

ID=1 Type = ‘all’

Group table: select

81

Group Table

ID=2 Type = ‘select’ Counters




Hashes packet to one of the buckets in proportion to the configured weight

Weight = 1

Weight = 1

Weight = 10

Group table: indirect

82

Group Table

ID=3 Type = ‘indirect’ Counters

Bucket 1 All packets are directed to the single bucket

ActionsSet output port 1/1

Group table: fast-failover

83

Group Table

ID=4 Type = ‘fast-failover’ Counters




• Only a single bucket is used at a time.

• All packets are sent to the first active bucket.

• Liveness of buckets depends on liveness of watched port or group

Watch port/group

Watch port/group

Watch port/group

Counters

84


Packet lookups

Packet matches


Received bytes

Duration (seconds)



Transmitted packets

Received bytes

Transmitted bytes

Receive drops

Transmit drops

Receive errors

Transmit errors



Receive CRC errors

Collisions


Transmit bytes


Per-group# flow entries

Transmit bytes


Per-bucketPacket count

Byte count

Fields new to v1.1.0

Matching (1)

85

Packet In Start at table 0

Update countersExecute instructions:• update action set• update packet/match set

fields• update metadata

Execute action set

Yes

Do one of following, depending on table configuration:• send to controller• drop• continue to next table

Yes

NoNo

Match in table n ?

Gototable n ?

Matching (2)

• Every flow entry has a 16-bit priority value associated with it• It is possible that a packet may match more than one flow

entry.• Only the highest-priority flow entry matching the packet is

used as the matching flow entry for the packet.

86

Pipeline processing (1)

• Definition: the set of linked tables that provide matching, forwarding and packet modifications in an OpenFlow switch

• Matching starts at the first table and may continue to other tables

• If a matching entry is found, the instructions associated with the flow entry are executed.

87


• Pipeline processing stops when the instruction set associated with a matching flow entry does not specify a next table. The packet’s action set is processed and it is forwarded at this point.

• If no match is found (called a table miss), the behaviourdepends on switch configuration; the packet may:– Be forwarded to the controller (default option)– Continuing to the next table– Be dropped

88


89

OpenFlow Switch

Flow Table

0…

Flow Table

1

Packet In

Ingress port

Action set = {}

Packet+ Ingress port +

metadata

Action set

Flow Table

n

PacketAction

set

Execute Action

Set

Packet Out


• Per-table packet processing:

90

Flow Table

Match fields:Ingress port +

metadata + packet headers

Action setA C



Action set

B

• Find highest-priority matching flow entry

• Apply instructions:i. Modify packet and update

match fields (APPLY-ACTIONS)

ii. Update action set (CLEAR-ACTIONS, WRITE-ACTIONS)

iii. Update metadata

• Send match data and action set to next table

A

B

C


• If connectivity with the controller is lost, the switch enters either “fail-secure” or “fail-standalone” mode

• The concept of “emergency mode” was deprecated.• ‘Fail-secure’ mode:

– In all packets and messages destined to the controller are dropped.– Flow entries continue to be used and expire based on their timeouts.

• ‘Fail-standalone’ mode:– All packets are processed via the NORMAL port i.e. the switch acts

as a traditional Ethernet switch or router– Applies only to OpenFlow-hybrid switches

91


92

ID Type

0 Hello

1 Error

2 Echo Request

3 Echo Reply

4 Experimenter

SymmetricID Type

5 Features Request

6 Features Reply


8 Get Config Reply

9 Set Config

13 Packet-out

14 Flow Mod

15 Group Mod

16 Port Mod

17 Table Mod

18 Stats Request

19 Stats Reply

20 Barrier Request

21 Barrier Reply



ID Type

10 Packet-In

11 Flow-removed

12 Port status

Asynchronous


Features

Configuration

Modify-state

Read-state

Packet-out

Configuration

Barrier

Messages new to v1.1.0 are in bold.

Flow match descriptor

• Flow match descriptor structure– Structure used to

describe flow match requirements

93


wildcard fields

vid

length

32 bits

ethernet source address

paddingpcp

ipv4 source addressipv4 source address mask

tcp/udp dest porttcp/udp source port

padding

ip tos

typeingress port

ethernet source address mask

ethernet destination address ethernet destination

address mask

ethertype

ipv4 destination addressipv4 destination address mask

mpls labelmpls tc

metadata

metadata mask

ip protocol


Table Mod Message

• Table-Mod message structure

94

32 bits

Table ID

Config

Padding

Flag DescriptionTABLE_MISS_CONTROLLER • Send packet to controller (Packet-In)

TABLE_MISS_CONTINUE • Continue to the next table in the pipeline

TABLE_MISS_DROP • Drop the packet

Config:- Bitmap of flags to

describe the behaviourof the table for unmatched packets



95


controller





buffer id

table id

32 bits

cookie


idle timeout


flags padding

instructions descriptor

cookie mask

command

output port

output group


96

OpenFlow v1.2.0

OpenFlow v1.2.0

97

201520122010 2011 2013 2014 20162009

Version 1.0.x

Version 1.1.x

Version 1.2.x

Version 1.3.x

Version 1.4.x

Version 1.5.x

1.0.0 1.0.1 1.0.2

1.1.0

1.2.0

1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

1.4.0 1.4.1

1.5.11.5.0

OpenFlow v1.2.0

• Third major release – version 1.2.0– Wire protocol 0x03– December 5, 2011

• This section highlights deltas from the previous release v1.1.0

98

New features

• New OpenFlow Extensible Match (OXM) instead of the previous static, fixed-length structures.

• Use of OXM for writing to packet header fields• Support of IPv6

• Packet parsing specification is removed• Support for multiple controllers

99

OpenFlow ports

100

OpenFlow Ports

Physical Ports Logical Ports Reserved Ports

• Correspond to hardware interfaces of the switch

• Abstracted interfaces that do not directly correspond to hardware interfaces of the switch

• For example: LAGs, tunnels, loopback interfaces

• Specify generic forwarding actions:

• ALL• CONTROLLER• TABLE• IN_PORT• ANY• LOCAL• NORMAL*• FLOOD*

* Only supported by OpenFlow-hybrid switches

Supported Actions

101




Set MPLS TTL Set value of the MPLS TTL

DecrementMPLS TTL

Decrement MPLS TTL

Push VLAN Push a new VLAN tag

Pop VLAN Pop the outer VLAN tag


Pop MPLS Pop the outer MPLS label

Set Queue ID Set queue ID when outputting to a port

Set Group Apply group

Action DescriptionSet Network

TTLSet value of the IP TTL

Decrement Network TTL

Decrement IP TTL

Set Field Set a header field using OXM TLV format

Multiple controllers

• Multiple controllers are supported to improve reliability• Communication between controllers is not specified by the

OpenFlow specification• Controller roles:

– EQUAL: controller has complete access to the switch and is equal to all other controllers in the same role

– SLAVE: controller only has read-only access to the switch– MASTER: controller has complete access to the switch; there can

only be one controller with this role

• A switch may be simultaneously connected to multiple controllers in Equal state, multiple controllers in Slave state and at most a single controller in Master state.

102


103

ID Type

0 Hello

1 Error

2 Echo Request

3 Echo Reply

4 Experimenter

SymmetricID Type

5 Features Request

6 Features Reply


8 Get Config Reply

9 Set Config

13 Packet-out

14 Flow Mod

15 Group Mod

16 Port Mod

17 Table Mod

18 Stats Request

19 Stats Reply

ID Type

10 Packet-In

11 Flow-removed

12 Port status

Asynchronous



ID Type

20 Barrier Request

21 Barrier Reply



24 Role Request

25 Role Reply

Flow match descriptor• Flow match descriptor structure

– Payload is a set of OXM (OpenFlow Extensible Match) flow match fields

104

length

32 bits

typepadding

OXM TLVs

lengthoxm_fieldoxm_class

payload

OXM TLV header

oxm_class:- Specifies a set of

related match types- OFPXMC_OPENFLOW_BASIC:

contains the basic set of OpenFlow match fields

oxm_field:- Match field within the

oxm_class

oxm_type:- combination of oxm_class

and oxm_type

OXM example

105

lengthoxm_field=13 (TCP source

port)_

oxm_class=0x8000 (OFPXMC_OPENFLOW_BASIC)

payload

HM

OXM TLV for TCP source port

Flow match field prerequisites

• The matching of header fields of a protocol can only be done if the OpenFlow match also explicitly matches the corresponding protocol

• For example, a match for the TCP source port is only allowed if it is preceded by:– A match for an IP Ethertype (either 0x0800 or ox86dd) AND– A match for IP protocol = 6 (TCP)– In other words, matching on the TCP port is only allowed if the

EtherType is IP and the IP protocol is TCP

106

Basic OpenFlow match fields

107

Ingress port

Ingress physical port

Metadata


Ethernet source address

Ethertype

VLAN ID

VLAN priority

IP DSCP

IP ECN

IP protocol

IPv4 source address



• OXM_field types for the OXM_class: OFPXMC_OPENFLOW_BASICTCP source port

TCP destination port

UDP source port

UDP destination port

SCTP source port

SCTP destination port

ICMPv4 type

ICMPv4 code

ARP OP

ARP SPA

ARP TPA

ARP SHA

ARP THA

IPv6 source address


IPv6 Flow Label

ICMPv6 type

ICMPv6 code

IPv6 ND Target

IPv6 ND SLL

IPv6 ND TLL

MPLS Label

MPLS TC

108

OpenFlow v1.3.5

OpenFlow v1.3.x

109

201520122010 2011 2013 2014 20162009

Version 1.0.x

Version 1.1.x

Version 1.2.x

Version 1.3.x

Version 1.4.x

Version 1.5.x

1.0.0 1.0.1 1.0.2

1.1.0

1.2.0

1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

1.4.0 1.4.1

1.5.11.5.0

OpenFlow v1.3.x

• Fourth major release – version 1.3.0– Wire protocol 0x04– April 13, 2012

• Updated in v1.3.1, v1.3.2, v1.3.3, v1.3.4, v1.3.5

• This section provides a ground-up description of v1.3.5– March 26, 2015

110

New features

• ‘Stats’ framework renamed to ‘multipart’ framework• Introduction of table-miss flow entry

• Support for per-flow meters• Support for PBB

• Auxiliary connections• Improved version negotiation via version bitmap

111

OpenFlow switch types

• Specifies two types of OpenFlow-compliant switches:– OpenFlow-only: perform forwarding based purely on OpenFlow flow

tables– OpenFlow-hybrid: support ‘traditional’ Ethernet switching and routing

functions in addition to OpenFlow packet forwarding (was referred to as OpenFlow-enabled in v1.0.0).

• As with prior versions of the protocol, v1.3.x only supports Ethernet packets

112

OpenFlow components

113

OpenFlow Logical Switch

OpenFlow Protocol

Controller

OpenFlowChannel

Group Table

Flow Table

Flow Table

…

OpenFlow components

• OpenFlow controller:– An entity that interacts with the OpenFlow switch using the OpenFlow

switch protocol. – Typically, a single controller manages multiple OpenFlow Logical

Switches

• OpenFlow Logical Switch:– A set of OpenFlow resources that can be managed as a single entity– Includes a datapath and control channel– Was previously referred to simply as an OpenFlow Switch. The

concept of an OpenFlow Logical Switch allows multiple such logical switches to be configured on a single physical switch.

114


• One or more flow tables:– Performs packet lookup and forwarding

• A Group Table

• Datapaths:– components of the switch that are directly involved in traffic

processing and forwarding. Includes the pipeline of flow tables, the group table and the ports.

• OpenFlow channel:– Channel to an external controller which manages the switch using the

OpenFlow protocol

115

Flow tables

• Each flow table contains a set of flow entries• Each flow entry consists of:

116

Match Fields Priority Counters Instructions Timeouts Cookie Flags

• Header fields

• Pipeline fields

• Modify action set

• Apply actions• Modify pipeline processing

• Precedence of flow entry

• The match fields and priority taken together identify a unique flow entry in a specific flow table

Match Fields

• Two types of match fields:

– Header match fields: match values extracted from the packet header

– Pipeline match fields: match fields matching values attached to the packet for pipeline processing and not associated with packet headers e.g. • IN_PORT• IN_PHY_PORT• METADATA• TUNNEL_ID

117


118

Ingress port


Metadata



Ethertype

VLAN ID

VLAN priority

IP DSCP

IP ECN

IP protocol

IPv4 source address


Fields new to v1.3.x are in bold.



UDP source port


SCTP source port


ICMPv4 type

ICMPv4 code

ARP OP

ARP SPA

ARP TPA

ARP SHA

ARP THA

IPv6 source address


IPv6 Flow Label

ICMPv6 type

ICMPv6 code

IPv6 ND Target

IPv6 ND SLL

IPv6 ND TLL

MPLS label

MPLS TC

MPLS BoS

PBB ISID

Tunnel ID

IPv4 Ext Header

Counters

119


Packet lookups

Packet matches


Received bytes

Duration (seconds)



Transmitted packets

Received bytes

Transmitted bytes

Receive drops

Transmit drops

Receive errors

Transmit errors



Receive CRC errors

Collisions

Duration (seconds)



Transmit bytes


Duration (seconds)


Per-group# flow entries

Transmit bytes


Duration (seconds)


Per-bucketPacket count

Byte count

Counters new to v1.3.x are in bold

Per-meterFlow count

Input packet count

Input byte count

Duration (seconds)

Duration (nanoseconds)Per-meter bandIn band packet count

In Band byte count

Instructions (1)



table OR– Contains a set of actions to add to the ‘Action Set’ OR– Contains a list of actions to apply immediately to the packet

120

Instructions (2)

• Supported instructions include:– Meter: direct packet to the specified meter– Apply-Actions: immediately applies the specified actions. The ‘Action

Set’ is not modified.– Clear-Actions: immediately clears all actions in the ‘Action Set’– Write-Actions: merges the specified actions into the current ‘Action

Set’.– Write-Metadata: writes to the metadata field– Goto-Table: indicates that the packet should next be processed


• Each instruction type may only appear once in the Instruction Set.

121

Instructions new to v1.3.x are in bold

Actions

122



Set-QueueOptional


port

DropMandatory


action


Push/Pop-TagOptional


GroupMandatory

Processes the packet through the specified group

Set-fieldOptional


Supported Actions

123





DecrementMPLS TTL

Decrement MPLS TTL










Decrement IP TTL


Push PBB Push a new PBB service tag (I-tag)

Pop PBB Pop the outer PBB service tag (I-tag)


Action Set (1)

• Definition: a set of actions associated with the packet that are accumulated while the packet is processed by each table and that are executed when pipeline processing terminates

• An ‘Action Set’ is associated with each packet and is empty by default

• As the packet passes through the pipeline the ‘Action Set’ is modified by instructions (Write-Actions, Clear-Actions) of matching flow entries

124

Action Set (2)

• The ‘Action Set’ is carried between flow tables as the packet progresses through the pipeline

• There is a maximum of one action of each type in the ‘Action Set’.

• The ’Action Set’ is executed when an instruction set does not include a ‘Goto-Table’ action .pipeline processing terminates

• If no output action or group action are specified in an action set, the packet is dropped

125

Actions

• Order of application of actions in the ‘Action Set’

126

Order Action1 Copy TTL inwards

2 Pop

3 Push-MPLS

4 Push-PBB

5 Push-VLAN

6 Copy TTL outwards

7 Decrement TTL

8 Set

9 QoS

10 Group

11 Output

If no output action or group action are specified in an action set the packet is dropped.

Action List

• Definition: ordered list of actions included in a flow entry in the Apply-Actions instruction or a Packet-Out message

• Actions in the ‘Action List’ are immediately executed in the order specified in the list.

• Multiple actions of the same type may appear in the same ‘Action List’ and have a cumulative effect.

127

Group table (1)

• Flow entries may point to a group in the group table.• The group table provides sets of actions for flooding,

multipath, fast reroute, link aggregation and indirection.• The group table contains group entries.

• Each group entry has a list of action buckets with semantics depending on group type. The group type determines which of the buckets are applied to each packet.

128

Group table (2)

• The group table contains group entries.• Each group entry contains:

129

Group Identifier Group Type Counters Action Buckets

Group Type Descriptionall • Executes all buckets in the group

• Multicast/broadcast forwarding• Packet is replicated for each bucket

select • Executes one bucket in the group• Packets are sent to a single bucket, based on a hash algorithm

indirect • Executes the one defined bucket in the group• For example, BGP next-hop indirection

fast-failover • Executes the first live bucket• Bucket liveness tied to port(s) or group

Group table: all

130

Group Table

Counters



Bucket n ActionsSet output port m/n

. . .

Replicates packet to all buckets and executes corresponding actions

ID=1 Type = ‘all’

Group table: select

131

Group Table

ID=2 Type = ‘select’ Counters




Hashes packet to one of the buckets in proportion to the configured weight

Weight = 1

Weight = 1

Weight = 10

Group table: indirect

132

Group Table

ID=3 Type = ‘indirect’ Counters

Bucket 1 All packets are directed to the single bucket

ActionsSet output port 1/1

Group table: fast-failover

133

Group Table

ID=4 Type = ‘fast-failover’ Counters




• Only a single bucket is used at a time.

• All packets are sent to the first active bucket.

• Liveness of buckets depends on liveness of watched port or group

Watch port/group

Watch port/group

Watch port/group

Table-miss flow entry

• Specifies how to process packets unmatched by other flow entries in the flow table

• Identified by its match and priority:– Wildcards all match fields– Has the lowest priority (zero)

• Has similar behaviour to other flow entries:– does not exist by default– can be added or removed by the controller at any time– it may expire

• If no table-miss flow entry exists, unmatched packets are dropped

134

Meter table

• Consists of meter entries, defining per-flow meters• A meter measures the rate of packets assigned to it and

enables controlling the rate of those packets

135

Meter Identifier Meter Bands Counters

Band Type Rate Burst Counters Type specific arguments

• Defines the lowest rate at which the band can apply

The meter applies the band with the highest configured rate that is lower than the current measured rate.

OpenFlow ports

136

OpenFlow Ports

Physical Ports Logical Ports Reserved Ports

• Correspond to hardware interfaces of the switch

• Abstracted interfaces that do not directly correspond to hardware interfaces of the switch

• For example: LAGs, tunnels, loopback interfaces

• Specify generic forwarding actions:

• ALL• CONTROLLER• TABLE• IN_PORT• ANY• LOCAL• NORMAL*• FLOOD*

* Only supported by OpenFlow-hybrid switches

Reserved ports

137

Res

erve

d Po

rts‘ALL’: all OpenFlow interfaces except the incoming interface

‘CONTROLLER’: logical interface to the OpenFlowcontroller

‘LOCAL’: local networking stack of the switch

‘TABLE’: sends packet for processing through the flow table (only for Packet-Out messages)

’IN_PORT’: ingress port of packet

‘NORMAL’: processes packets via the traditional forwarding path supported by the switch

‘FLOOD’: flood along the minimum spanning tree

Matching (1)

138

Packet In Start at table 0

Update countersExecute instructions:• update action set• update packet/match

set fields• update metadata

Execute action set

Yes

Yes

NoNo

Match in table n ?

Gototable n ?

Drop packet

Table-miss flow entry exists ?

No

Yes

Matching (2)




139



• Matching starts at the first table and may continue to other tables

• If a matching entry is found, the instructions associated with the flow entry are executed. The instructions may explicitly direct the packet to another flow table.

140


• Pipeline processing stops when the instruction set associated with a matching flow entry does not specify a next table. The packet’s 'Action Set' is processed and it is forwarded at this point.

• If no match is found (called a table miss), the behaviourdepends on the table-miss flow entry in the table. The actions may include:– forwarding to the controller– continuing to the next table– being dropped

141


142

OpenFlow Switch

Flow Table

0…

Flow Table

1

Packet In

Ingress port

Action set = {}

Packet+ Ingress port +

metadata

Action set

Flow Table

n

PacketAction

set

Execute Action

Set

Packet Out



143

Flow Table



Action setA C



Action set

B







A

B

C

Flow table example

144


Eth Src

Eth Dest Ether Type

VID PCP IPSrc

IP Dest

IP Proto

IP ToS

L4 SrcPort

L4 DestPort

* * 12:34:56:AB:CD:EF * * * * * * * * * Output to port 1/2

* * 11:22:33:44:55:66 * * * * * * * * * Output to port 3/8

Ethernet learning switch


Eth Src

Eth Dest

Ether Type

VID PCP IP Src IP Dest IP Proto

IP ToS

L4 SrcPort

L4 DestPort

* * * 0x0800 * * 10.1.1.0/24 192.168.32.3/32 6 * * 80 Forward

* * * 0x0800 * * 172.16.0.0/16

192.168.32.3/32 6 * * 80 Forward

* * * * * * * * * * * * Drop

Firewall

OpenFlow Channel

• This is the logical interface that connects each OpenFlowswitch to an OpenFlow controller.

• The OpenFlow controller uses this interface to:– Configure and manage the switch– Add, delete and modify flow entries– Receive events from the switch– Send packets out the switch

• There is one OpenFlow channel per OpenFlow controller

145

OpenFlow Connection

• A TLS or TCP network connection that is used by the OpenFlow channel to carry OpenFlow messages between a switch and a controller.

• An OpenFlow channel has a main connection (tcp or tls) and optionally, a number of auxiliary connections (tcp, tls, dtls or udp), in order to exploit parallelism– Auxiliary connections on non-reliable transport, such as dtls or udp,

can only support a small subset of the OpenFlow protocol e.g. they can be used to read stats

146

Multiple controllers

• Multiple controllers are supported to improve reliability• Communication between controllers is not specified by the

OpenFlow specification• Controller roles:

– EQUAL: controller has complete access to the switch and is equal to all other controllers in the same role

– SLAVE: controller only has read-only access to the switch– MASTER: controller has complete access to the switch; there can

only be one controller with this role

• A switch may be simultaneously connected to multiple controllers in Equal state, multiple controllers in Slave state and at most a single controller in Master state.

147

Connection setup

• A TLS connection is established by the switch to a configured IP address and TCP port 6653 (as of version 1.3.3). Prior to v1.3.3, TCP port 6633 was used.

• Traffic to/from the secure channel is not processed by the flow table

148


• If connectivity with the controller is lost, the switch enters either “fail-secure” or “fail-standalone” mode

• The concept of “emergency mode” was deprecated in v1.1.0

• ‘Fail-secure’ mode:– In all packets and messages destined to the controller are dropped.

Flow entries continue to be used and expire based on their timeouts.

• ‘Fail-standalone’ mode:– All packets are processed via the NORMAL port i.e. the switch acts

as a traditional Ethernet switch or router– Applies only to OpenFlow-hybrid switches

149

OpenFlow protocol messages

• Protocol defines three types of messages.

• Controller-to-switch:– Are initiated by the controller and used to configure the switch or

query its state

• Asynchronous:– Are initiated by the switch and used to notify the controller about

network events or changes to the switch state

• Symmetric:– Can be initiated by either the controller or the switch and sent without

solicitation

150

Controller-to-Switch messages

• Initiated by the controller and may or may not require a response from the switch.

• Messages include:– Features: used by the controller to discover the capabilities supported by the switch– Configuration: used to set and query configuration parameters– Modify-state: sent by the controller to manage state on the switch. Main purpose is to

add/delete/modify flows– Read-state: used by the controller to query stats from the switch– Packet-out: used by the controller to send a packet out of a specified port of the switch– Barrier: used to ensure message dependencies– Role-Request: used by the controller to set or query the role of its OpenFlow channel– Asynchronous-Configuration: used by the controller to filter asynchronous

messages it receives

151

Messages new to v1.3.x are in bold






– Port-status: sent by the switch on port configuration or state changes.– Errors: sent when errors are detected

152

Symmetric messages

• Can be initiated by either the controller or the switch and sent without solicitation

• Messages include:– Hello: sent between the controller and switch upon connection

establishment– Echo: echo request/reply messages can be sent from either the

switch or the controller; request messages must be responded to with a reply.

– Experimenter: vendor-specific messages

153

OpenFlow protocol

• Common OpenFlow packet header– All OpenFlow messages start with this header

154

xid

version lengthtype

Version:- version of OpenFlow protocol

Type: - type of OpenFlow protocol message

Length: - total length of message in octets

xid: - transaction ID used to match responses with requests

32 bits8 bits 16 bits8 bits

OpenFlow version numbers

155

Version of specification OpenFlow protocol version1.0.x 0x011.1.x 0x021.2.x 0x031.3.x 0x041.4.x 0x051.5.x 0x06

• Version number has incremented with every major release of the OpenFlow specification

• OpenFlow versions are NOT backwards-compatible. For example, a device running version 0x03 will not fall back to 0x01 to interwork with a device that only supports 0x01.


156

ID Type

0 Hello

1 Error

2 Echo Request

3 Echo Reply

4 Experimenter

SymmetricID Type

5 Features Request

6 Features Reply


8 Get Config Reply

9 Set Config

13 Packet-out

14 Flow Mod

15 Group Mod

16 Port Mod

17 Table Mod

18 Multipart Request

19 Multipart Reply

ID Type

10 Packet-In

11 Flow-removed

12 Port status

Asynchronous


Messages new to v1.3.x are in bold.

ID Type

20 Barrier Request

21 Barrier Reply



24 Role Request

25 Role Reply

26 Get Async Request

27 Get Async Reply

28 Set Async

29 Meter Mod

Version negotiation

• On connection establishment:

– Each side sends a Hello message with the ‘version’ set to the highest OpenFlow version supported by the sender. The Hello message can optionally include a version bitmap that specifies all the versions supported by the sender.

157

If (the version bitmap is supported by both sides) AND (the two bitmaps have some common bits set)

negotiated version = highest version set in both bitmapsElse

negotiated version =minimum (version number that was sent,

version number that was received)

Understanding switch capabilities

• Due to the large number of required and optional OpenFlowcapabilities, it is important for the controller to understand the features supported by the switch it is managing.

• A features/capabilities discovery is done via a handshake to acquire this information.

158

Handshake

• Once TLS session is established, the controller sends a Features Request message.

• The switch responds with a Features Reply message:

159

32 bits

datapath id

#buffers

Datapath ID:- Uniquely identifies a

datapath. Lower 48-bits are the switch MAC address.

Capabilities:- Types of stats supported

etc.

Ports:- Array of OpenFlow-

enabled physical portsReserved

#tables

Capabilities

Paddingauxiliary ID

Flow table modification messages

• 5 possible operations:

– Add: instantiates a new flow entry in the flow table

– Modify: modifies elements of all (existing) matching flow entries

– Modify-Strict: modifies elements of flow entries that exactly match all fields including wildcards and priority

– Delete: deletes all (existing) matching flow entries

– Delete-Strict: deletes flow entries that exactly match all fields including wildcards and priority

160



161


controller





buffer id

table id

32 bits

cookie


idle timeout


flags padding


cookie mask

command

output port

output group

Flow match descriptor• Flow match descriptor structure

– Payload is a set of OXM (OpenFlow Extensible Match) flow match fields

162

length

32 bits

typepadding

OXM TLVs

lengthoxm_fieldoxm_class

payload

OXM TLV header

oxm_class:- Specifies a set of

related match types- OFPXMC_OPENFLOW_BASIC:

contains the basic set of OpenFlow match fields

oxm_field:- Match field within the

oxm_class

oxm_type:- combination of oxm_class

and oxm_type

OXM example

163

lengthoxm_field=13 (TCP source

port)_

oxm_class=0x8000 (OFPXMC_OPENFLOW_BASIC)

payload

HM

OXM TLV for TCP source port

Flow match field prerequisites

• The matching of header fields of a protocol can only be done if the OpenFlow match also explicitly matches the corresponding protocol

• For example, a match for the TCP source port is only allowed if it is preceded by:– A match for an IP Ethertype (either 0x0800 or ox86dd) AND– A match for IP protocol = 6 (TCP)– In other words, matching on the TCP port is only allowed if the

EtherType is IP and the IP protocol is TCP

164

Type=“OUTPUT” LengthOutput port

Max Length

Flow action descriptor

• Flow action descriptor structure– Structures used to describe flow actions

165

32 bits

Type=“SET QUEUE” Length

32 bits

Queue ID

Type=“SET MPLS TTL” LengthTTL Padding

32 bits

Type=“SET FIELD” Length

32 bits

OXM TLV

Padding

Proactive vs reactive flow entries

• Entries in the flow table can be installed either a priori (proactive) or on demand (reactive):

166

Proactive Reactive• Applicable when flow patterns

are known ahead of time• More suitable for aggregate

traffic flows• May require larger tables to

allow a complete set of flow entries

• No delays with flow installation

• May be more applicable to dynamic flow patterns

• Optimises flow table usage as inactive flows may be timed out

• Delays may be experienced with flow installation as first packet needs to be sent to controller

• Uninterrupted connection to controller is essential

It is also possible to have a combination of proactive and reactive flow entries

Flow removal

• All flow entries have two timers associated with them:

– idle_timeout: maximum time that can elapse without a flow matching the flow entry

– hard_timeout: maximum time that a flow entry can remain in the flow table

• A Flow-Removed message is sent by the switch to the controller when a flow entry is removed from the flow table

167

Packet-In Message

• Packet-In message structure– For packets sent from the switch to the controller

168

buffer id

total length

data (ethernet frame)

Buffer ID:- Identifies where packet

is buffered

Reason:- One of:

- no match- explicit action- TTL expired

Match fields:- Pipeline fields

associated with the packet

Data:- Initial portion of

packet

reason table ID

cookie

match fields (OXM TLVs)

32 bits

Packet-Out Message

• Packet-Out message structure– For packets sent from the controller to the switch

169

buffer id

32 bits

length of actions array

action list

Buffer ID:- Same as the buffer ID in

the original Packet-In message

Packet data:- Initial portion of

packet

packet data

input port

padding

Multipart Request/Reply Messages

• Replace Stats-Request and Stats-Reply messages in earlier versions

• Used to encode requests or replies that may carry a large amount of data which may not be able to fit within a single OpenFlow message (max length of 64KB)

• A request or reply can span multiple messages and must use the same xid (transaction ID) for all messages in the message sequence

170

Multipart message types

171

Type DescriptionDESC Information about the switch manufacturer, hardware revision, software revision, serial number etc

FLOW Individual flow statistics

AGGREGATE Statistics about multiple flow entries

TABLE Table statistics

PORT_STATS Port statistics

QUEUE Queue statistics

GROUP Group statistics

GROUP_DESC Lists the set of groups in the switch together with their bucket actions

GROUP_FEATURES Capabilities of groups on a switch

METER Meter statistics

METER_CONFIG Configuration for one more more meters

METER_FEATURES Set of features of the metering system

TABLE_FEATURES Capabilities of the currently configured tables e.g. supported actions, instructions, match fields etc.

PORT_DESC Description of all the standard ports of the OpenFlow switch

EXPERIMENTER Experimenter-defined behaviour

Echo Request/Reply Messages

• Echo Request may be initiated by either the controller or the switch

• May be used for a number of reasons:– To determine latency of connection between controller and switch– As a liveness detection mechanism to verify liveness of the

connection between controller and switch

172

QoS structures: queues

• Limited QoS support is provided through a simple queuing mechanism

• Flows can be mapped to queues which attach to a port• The only queue configuration available is:

– min-rate: minimum guaranteed data-rate

173

QoS structures: meters

• Definition: switch elements that can measure and control the rate of packets

• The meter triggers a meter band if the rate passing through the meter exceeds a predefined threshold

174

Switch bootstrapping

• OpenFlow switches need to be configured with:– URI or <IP address>:<port> of OpenFlow controllers– Can be accomplished via OF-CONFIG

• For OpenFlow-hybrid switches:– OpenFlow-capable ports need to be identified and configured– A mechanism must exist to channel flows to either OpenFlow

processing or ‘normal’ processing

• Ports and queues need to be configured• For topology discovery via LLDP (de-facto mechanism):

– A flow entry to direct all received LLDP packets to the controller should be installed

175

Message flow example

176

Controller SwitchHello Hello

Features Request

Features Reply

Packet-Out

Packet-In

Flow-Mod

Initial exchange of Hellos with version negotiation

Discovery of switch features

Reaction to unknown packet flow

Installation of new flow entry


• The challenge: – How can an OpenFlow controller discover the topology of a network

comprising of OpenFlow switches in the absence of a distributed control plane ?

• OpenFlow Discovery Protocol (OFDP):– Not a formally specified protocol (topology discovery is not specified

in any OpenFlow specification documents)– The concept was inherited from the first implementation of an

OpenFlow controller (the NOX implementation)

177


• Switches need to be bootstrapped as follows:

– URI or <IP address>:<port> of OpenFlow controllers

– A proactive rule is instantiated on all switches to allow dealing with LLDP packets:• If ethertype=LLDP, output to CONTROLLER• In other words, if a packet is received with an ethertype of 0x88cc, it must be

encapsulated within a Packet-In frame and sent to the controller

178

Aside: LLDP

• Standardised by IEEE 802.1ab• Single-hop neighbour discovery protocol

• Operates at Layer 2 (Ethernet layer)• Allows nodes to advertise their identities and capabilities

and learn the identities and capabilities of directly-connected neighbours

• Uses an Ethertype of 0x88cc and a destination multicast address of 01-80-C2-00-00-0E

179

Aside: LLDP (2)

180

LLDPDULLDP Ethertype

Chassis ID TLV

Port ID TLV TTL TLV

Optional TLV ... ...

End of LLDPDU TLV

DescriptionChassis ID TLV Identifier of the switch that sends the LLDP packet

Port ID TLV Identifier of the port through which the packet is sent

TTL TLV Time validity of the information in the LLDP frame

End of LLDPDU Indicates end of the payload in the LLDP frame


181

Controller




p1 p1

p2

p2

p2

p1

Switches establish OpenFlow channel with the controller

11

1

1


182

Controller




p1 p1

p2

p2

p2

p1

Controller learns of all active ports on all switches via Features Reply message

2

2

2

2


183

Controller



p1 p1

p2

p2

p2

p1

Flow entry installed to forward all LLDP packets to controller

3

3

3

3


Inputport

Eth Src

Eth Dest

Ether Type VID PCP IPSrc

IP Dest

IP Proto

IP ToS

L4 SrcPort

L4 DestPort

Action

* * * 0x88cc * * * * * * * * Send to controller


184

Controller


p1

p2

Controller generates a Packet-Out message (with an encapsulated LLDP packet) for each active port on each switch (only switch OFS1 shown)

4

4Packet-OutOutput port: p1Encapsulated packet: LLDP


Packet-OutOutput port: p2Encapsulated packet: LLDP



185

Controller




p1 p1

p2

p2

p2

p1

Switch sends encapsulated LLDP packet out of each active port (only switch OFS1 shown)

5

5

5


Port ID: p2


Port ID: p1


186

Controller




p1 p1

p2

p2

p2

p1

Switches OFS1 and OFS2 forward received LLDP packets to controller via Packet-In message

6

6

6






• Controller learns that:

– Port p1 of OFS1 is directly connected to port p1 of OFS3– Port p2 of OFS1 is directly connected to port p1 of OFS2– Port p2 of OFS2 is directly connected to port p2 of OFS3– Port p1 of OFS3 is directly connected to port p1 of OFS1– Port p1 of OFS2 is directly connected to port p2 of OFS1– Port p2 of OFS3 is directly connected to port p2 of OFS2

187

Exclusions

• What OpenFlow does not do (or specify):– Communication between controllers when using multiple controllers

(v1.2.0+)– How OpenFlow is used by northbound applications– Topology discovery– How to bootstrap the network– Construction of paths that traverse multiple OpenFlow switches– Configuration of OpenFlow switches (some of this is enabled by OF-

CONFIG)

188

189

OpenFlow v1.4.x

OpenFlow v1.4.x

190

201520122010 2011 2013 2014 20162009

Version 1.0.x

Version 1.1.x

Version 1.2.x

Version 1.3.x

Version 1.4.x

Version 1.5.x

1.0.0 1.0.1 1.0.2

1.1.0

1.2.0

1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

1.4.0 1.4.1

1.5.11.5.0

New features

• More extensible wire protocol (TLV-based structures)• Optical port properties

• Flow monitoring to allow better co-ordination between multiple controllers

• Eviction and vacancy events to deal with finite table capacity

• Message bundling

• Table synchronisation

191

Flow eviction

• Mechanism used to reclaim switch resources• Has to be explicitly enabled

• Flow entries are selected for eviction based on:– A new flow entry field ‘importance’. Flow entries with lower

importance will always be evicted before entries with higher importance.

– The remaining lifetime of the flow entry. Flow entries with shorter remaining lifetimes will be evicted before entries with longer remaining lifetimes.

192

Table vacancy events

• Generates events (TABLE_STATUS) messages based on occupancy of flow tables

vacancy_down: generated when the remaining space in the flow table falls to less than the configured threshold

vacancy_up: generated when the remaining space in the flow table increases to more than the configured threshold

• The specification does not define the behaviour of controllers on receiving these messages.

193

Flow monitoring (1)

• Flow monitoring allows a controller to keep track of changes to flow tables

• Useful for multi-controller environments where controllers can be made aware of changes made to the flow table by other controllers

• Flow monitors can be created to match a subset of flow entries in selected flow tables.

• Events are generated for any changes to matching flow entries.

• Flow monitoring requests are done via multipart messages.

194

Flow monitoring (2)

• Types of flow monitors:

– Initial: all flow entries matching the flow monitor at the time of the request

– Add: new additions of flow entries matching the flow monitor

– Removed: removal of flow entries matching the flow monitor

– Modification: modification of flow entries matching the flow monitor

195

Flow table synchronisation (1)

• Allows flow entries in a table to be synchronised with another table:– Flow entries in the synchronised table are automatically updated to

reflect changes in the table it is synchronised with– Enables multiple matches on different views of the same data at

different points of the OpenFlow pipeline.

• Synchronisation can be uni-directional or bi-directional.• When a flow entry is added, modified or removed in the

source table, a corresponding flow entry is automatically added, modified or removed in the synchronised table

196

Flow table synchronisation (2)

• Entries in the synchronised table may not be identical to the corresponding entry in the source flow table e.g. transposed source/destination matches, different instruction sets etc.

• Recommended to be created as permanent flow entries (expiry timers set to zero) so that the lifetime of the corresponding flow entries is also synchronised

• Flow entry sychronisation can be unidirectional or bi-directional.

197

Bundle messages

• Bundle: sequence of OpenFlow modification messages that are applied as a single OpenFlow operation

• Provides a degree of atomicity (either all changes are applied or none at all)

• Example:1. OFPBCT_OPEN_REQUEST bundle_id2. OFPT_BUNDLE_ADD_MESSAGE bundle_id modication 13. OFPT_BUNDLE_ADD_MESSAGE bundle_id ...4. OFPT_BUNDLE_ADD_MESSAGE bundle_id modication n5. OFPBCT_CLOSE_REQUEST bundle_id6. OFPBCT_COMMIT_REQUEST bundle_id

198


199

ID Type

0 Hello

1 Error

2 Echo Request

3 Echo Reply

4 Experimenter

SymmetricID Type

5 Features Request

6 Features Reply


8 Get Config Reply

9 Set Config

13 Packet-out

14 Flow Mod

15 Group Mod

16 Port Mod

17 Table Mod


19 Multipart Reply

ID Type

10 Packet-In

11 Flow-removed

12 Port status

30 Role status

31 Table status

32 Request Forward

Asynchronous



ID Type

20 Barrier Request

21 Barrier Reply



24 Role Request

25 Role Reply


27 Get Async Reply

28 Set Async

29 Meter Mod

33 Bundle Control

34 Bundle Add


200

Ingress port


Metadata



Ethertype

VLAN ID

VLAN priority

IP DSCP

IP ECN

IP protocol

IPv4 source address





UDP source port


SCTP source port


ICMPv4 type

ICMPv4 code

ARP OP

ARP SPA

ARP TPA

ARP SHA

ARP THA

IPv6 source address


IPv6 Flow Label

ICMPv6 type

ICMPv6 code

IPv6 ND Target

IPv6 ND SLL

IPv6 ND TLL

MPLS label

MPLS TC

MPLS BoS

PBB ISID

Tunnel ID

IPv4 Ext Header

PBB UCA



201


controller





importance:- Used for flow eviction

purposes

buffer id

table id

32 bits

cookie


idle timeout


flags importance


cookie mask

command

output port

output group


202

OpenFlow v1.5.x

OpenFlow v1.5.x

203

201520122010 2011 2013 2014 20162009

Version 1.0.x

Version 1.1.x

Version 1.2.x

Version 1.3.x

Version 1.4.x

Version 1.5.x

1.0.0 1.0.1 1.0.2

1.1.0

1.2.0

1.3.0 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

1.4.0 1.4.1

1.5.11.5.0

OpenFlow v1.5.x

• Sixth major release – version 1.5.0– Wire protocol 0x06– December 19, 2014

• Latest release of the specification

• This section highlights deltas of version 1.5.1 (March 26, 2015) from the previous release 1.4.1

204

New features

• Egress tables• Packet Type-aware pipeline

• Extensible flow entry statistics: OpenFlow eXtensibleStatistics (OXS)

• Flow entry statistics trigger• Copy-Field action to copy between two OXM fields• Packet Register pipeline fields

• Scheduled Bundles• Meter action

205

OpenFlow components

206

OpenFlow Switch

OpenFlow Protocol

Controller

OpenFlowChannel Group

Table

Flow Table

Flow Table

…

Meter Table

OpenFlowChannel

Control Channel

OpenFlow Protocol

Controller

Port

PortFlow Table

Port

Port

Datapath

Pipeline


207

Ingress port


Metadata



Ethertype

VLAN ID

VLAN priority

IP DSCP

IP ECN

IP protocol

IPv4 source address


TCP source port


• OXM_field types for the OXM_class: OFPXMC_OPENFLOW_BASICTCP destination port

UDP source port


SCTP source port


ICMPv4 type

ICMPv4 code

ARP OP

ARP SPA

ARP TPA

ARP SHA

ARP THA

IPv6 source address


IPv6 Flow Label

ICMPv6 type

ICMPv6 code

IPv6 ND Target

IPv6 ND SLL

IPv6 ND TLL

MPLS label

MPLS TC

MPLS BoS

PBB ISID

Tunnel ID

IPv4 Ext Header

PBB UCA

TCP Flags

Action Set Output port

Packet Type

Instructions (1)



table OR– Contains a set of actions to add to the 'Action Set' OR– Contains a list of actions to apply immediately to the packet

208

Instructions (2)

• Supported instructions include:– Apply-Actions: immediately applies the specified actions. The ‘Action

Set’ is not modified.– Clear-Actions: immediately clears all actions in the ‘Action Set’– Write-Actions: merges the specified actions into the current ‘Action

Set’.– Write-Metadata: writes to the metadata field– Stat-Trigger: generate events based on stats thresholds– Goto-Table: indicates that the packet should next be processed


• Each instruction type may only appear once in the Instruction Set.

209

Instructions new to v1.5.x are in bold

Instructions (3)

210

Flow Table

Flow Table

Apply-actions{list of actions}• modify packet• update match fields• update pipeline fields• if output or group ->

clone packet

Packet Extract header fields

Clear-actions• empty action

setWrite-actions{set of actions}• merge in

action setGoto-table{table-ID}

Match

flow entryflow entryflow entryflow entry

flow entrytable-miss flow entry

Pipeline fields

Action Set

Find highest-priority matching flow entry

Apply instructions

Execute Action

Set

EgressPacket clones

Actions

211

Forward (output)

Mandatory


Set-Queue

OptionalForward a packet through

a specified queue attached to a port

Drop

MandatoryImplicit action associated with a flow-entry that has

no specified action


Push/Pop-Tag

Optional


Group

MandatoryProcesses the packet through the specified

group

Set-field

Optional


Meter

Optional

Directs the packet to the specified meter

Copy-field

Optional

Copies data between pipeline or header fields

Supported Actions

212





DecrementMPLS TTL

Decrement MPLS TTL










Decrement IP TTL


Push PBB Push a new PBB service tag (I-tag)

Pop PBB Pop the outer PBB service tag (I-tag)

Copy Field Copy value between headerand register

Meter Apply meter (rate limiter)


Egress tables

• In older versions, all processing was done in the context of the input port

• Egress tables allow processing to be done in the context of the output port

213

Matching (1)

214

Packet In • Clear action set• Initialise pipeline fields• Start at table 0

Update countersExecute instruction set:update action setupdate packet headersupdate match set fieldsupdate pipeline fieldsas needed, clone packet to egress

Execute action set:update packet headersupdate match set fieldsupdate pipeline fields

Yes

Yes No

No

Match in table n ?

Gototable n ?

Drop packet


No

YesGroup

Action ?

No

Yes

Output Action ?

Yes

Drop packetNo

Ingress Processing

Egress Processing (next slide)

Matching (2)

215

Start egress processing• action set = {output port}• start at first egress table

Update countersExecute instruction set:• update action set• update packet headers• update match set

fields• update pipeline fields• as needed, clone

packet to egress

Execute action set:• update packet headers• update match set fields• update pipeline fields

Yes

Yes No

No

Match in table n ?

Gototable n ?

Drop packet


No

Yes

No

Output Action ?

Yes

Drop packetNo

Ingress Processing (previous slide)

Egress Processing

Egress tables exist?

Packet Out

Yes

Matching (3)




216

Packet Type-aware pipeline

• First release to support non-Ethernet packets: IPv4 and IPv6

• New OXM pipeline field identifies the packet type.

217

Namespace ns_type Match description Packet-in and packet-out format

0 0 Ethernet packet (default) Ethernet header and Ethernet payload

1 0x0800 IPv4 packet (no preceding header)

IPv4 header and IPv4 payload

1 0x86dd IPv6 packet (no preceding header)

IPv6 header and IPv6 payload

0 1 No packet Empty

0 0xFFFF Experimenter-defined Experimenter-defined



• Pipeline processing happens in two stages: ingressprocessing and egress processing– Separation between the two stages is indicated by the first egress

table– Ingress tables: table IDs < first egress table– Egress tables: table IDs ≥ first egress table

218


• Pipeline processing starts with ingress processing at at the first table and may continue to other tables

• If a matching entry is found, the instructions associated with the flow entry are executed. The instructions may explicitly direct the packet to another flow table.

• Pipeline processing stops when the instruction set associated with a matching flow entry does not specify a next table. The packet’s action set is processed at this point.

219


• If the outcome of ingress processing is to forward the packet to an output port, (optional) egress processing may be performed in the context of that output port.

• If no match is found (called a table miss), the behaviourdepends on the table-miss flow entry in the table. The actions may include:– forwarding to the controller– continuing to the next table– being dropped

220


221

Flow Table

0…

Flow Table

1

Packet In Set

Ingress port

Action set = {}

Packet + pipeline fields (Ingress port,

metadata etc.)

Action set

Flow Table

n

Execute Action

SetAction set

Group Table

Flow Table

e…

Flow Table e+1

Set output

port

Action set =

{output}

Packet + pipeline fields

(output port, metadata etc.)

Action set

Flow Table e+m

Execute Action

SetAction set

Ingress Port

Packet Out

Output Port

Ingress processing

Egress processing

e = first egress table ID



222

Flow Table



Action setA C



Action set

B







A

B

C

Ingress and egress processing

• Similarities in behaviour:– Flow table matching– Execution of instructions– Table-miss processing

• Differences:– At the beginning of ingress processing, the Action Set is empty– At the beginning of egress processing, the 'Action Set' is initialised to

contain only the Output action for the current output port

223






– Port-status: sent by the switch on port configuration or state changes.– Role-status: informs the controller of a change in its role– Controller-status: informs the controller when the status of an OpenFlow channel

changes– Flow-monitor: informs the controller of a change in a flow– Errors: sent when errors are detected

224

Messages new to v1.5.x are in bold


225

ID Type

0 Hello

1 Error

2 Echo Request

3 Echo Reply

4 Experimenter

SymmetricID Type

5 Features Request

6 Features Reply


8 Get Config Reply

9 Set Config

13 Packet-out

14 Flow Mod

15 Group Mod

16 Port Mod

17 Table Mod


19 Multipart Reply

ID Type

10 Packet-In

11 Flow-removed

12 Port status

30 Role status

31 Table status

32 Request Forward

35 Controller Status

Asynchronous



ID Type

20 Barrier Request

21 Barrier Reply



24 Role Request

25 Role Reply


27 Get Async Reply

28 Set Async

29 Meter Mod

33 Bundle Control

34 Bundle Add

OpenFlow eXtensible Statistics (OXS)

• Extensible flow entry statistics: OpenFlow eXtensibleStatistics (OXS)

• Similar concept to OXM• Allows encoding of arbitrary flow statistics

226

Flow stats descriptor• Flow stats descriptor structure

– Payload is a set of OXS (OpenFlow Extensible Stats) flow stats fields

227

length

32 bits

reservedpadding

OXS TLVs

lengthoxs_fieldoxs_class

payload

OXS TLV header

oxs_class:- Specifies a set of

related stats types- OFPXSC_OPENFLOW_BASIC:

contains the basic set of OpenFlow stats

oxs_field:- Stats field within the

oxs_class

oxs_type:- combination of oxs_class

and oxs_type

Limitations of OpenFlow

• Matching and action process in OpenFlow is not advanced enough to describe the rich set of capabilities of contemporary routers and switches.

• As OpenFlow cannot express all necessary packet operations, it must be augmented by device-specific mechanisms e.g. application of advanced QoS features

• Large number of optional features so it’s not easy to work out a maximal set of intersecting features

228

229

OF-CONFIG

OF-CONFIG

• OF-CONFIG: OpenFlow Management and Configuration Protocol

• Companion protocol to OpenFlow• Motivation of the protocol is to enable the remote

configuration of OpenFlow switches• Latest version of 1.2 supports up to OpenFlow v1.3.0

230

OF-CONFIG components

231

Operational Context

OF-CONFIG

OpenFlowConfiguration

Point

OpenFlowSwitch

OpenFlow Protocol

OpenFlowController

An OpenFlow Configuration Point communicates with an operational context which is capable of supporting an OpenFlow switch using the OpenFlow Configuration and Management Protocol )OF-CONFIG)

Components (1)

• OpenFlow Logical Switch (OFLS):– Abstraction defined by OF-CONFIG– OF-CONFIG enables the configuration of the essential elements of

an OpenFlow Logical Switch so that an OpenFlow controller can communicate with and control the switch via the OpenFlow protocol

• OpenFlow Capable Switch (OFCS):– Physical or virtual network element that provides an operational

context to host one or more OpenFlow Logical Switches by partitioning a set of OpenFlow-related resources such as ports and queues between the hosted OpenFlow Logical Switches.

232

Components (2)

• OpenFlow Configuration Point (OFCP):– Service which sends OF-CONFIG messages to an OpenFlow

Capable Switch

• OpenFlow resource:– An element of an OpenFlow Capable Switch (e.g. ports, queues) that

can be associated with an OpenFlow Logical Switch

233

Relationships

234

OpenFlow Capable Switch

OF-CONFIG

OpenFlowConfiguration

Point


OpenFlowProtocol

OpenFlowController (s)


OpenFlowController (s)

OF resource(e.g port)




OpenFlowProtocol

Scope

• The basic scope of OF-CONFIG is a set of functions required to configure an OpenFlow v1.3 logical switch:– Discovery of capabilities of an OpenFlow Logical Switch

– Assignment of one or more controllers to an OpenFlow Logical Switch

– Assignment of resources of an OpenFlow Capable Switch to one or more OpenFlow Logical Switches

– Configuration of queues and ports– Ability to remotely configure properties of ports– Configuration of certificates for secure operation of OpenFlow Logical

Switches and OpenFlow controllers

235

OFLS instantiation

• Initially, the OFCS owns all the resources of the switch and does not have any data planes instantiated.

• Using OF-CONFIG, the OFCP can instantiate one or more OFLS and assign resources such as queues and ports to it.

236

Transport protocol

• NETCONF is used as the transport protocol for OF-CONFIG– OpenFlow Capable Switches need to implement SSH as the

transport protocol as required by NETCONF

• NETCONF defines a set of operations on top of a messaging layer (RPC – remote procedure calls)

237

NETCONF

238

Content <capable-switch>…</capable-switch>

Operations <get-config>,<set-config>,<notification>

RPC <rpc>,<rpc-reply>

Transport Protocol SSH, TLS, BEEP, SOAP

Layer Example

Data model

• Data model for OF-CONFIG 1.2 is encoded in an XML schema (YANG model is also available)

• Structured into classes and attributes of classes• All NETCONF base protocol operations are supported: edit-

config, get-config, copy-config, delete-config

239

Core Data model

240

Reproduced from OF-CONFIG 1.2 specification (https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1.2.pdf)

UML(Unified Modeling Language)

Association

Inheritance

Aggregation

Composition Switch contains different types of resources: ports, queues, certificates, flow tables

One or more instances of OpenFlow Logical Switches are contained within the OpenFlowCapable Switch

One or more OpenFlow controllers are associated with each OpenFlowLogical Switch

Example: OpenFlow Capable Switch

241


<capable-switch><id>CapableSwitch0</id><configuration-points>

...</configuration-points><resources>

...</resources><logical-switches>

...</logical-switches>

</capable-switch>

XML Example

Example: OpenFlow Logical Switch

242


<logical-switch><id>LogicalSwitch5</id><capabilities>...

<capabilities>

<datapath-id>datapath-id0</datapath-id><enabled>true</enabled><check-controller-certificate>false</check-

controller-certificate><lost-connection-behavior>failSecureMode</lost-

connection-behavior><controllers>...

</controllers><resources><port>port2</port><port>port3</port><queue>queue0</queue><queue>queue1</queue><certificate>ownedCertificate4</certificate>

<flow-table>1</flow-table><flow-table>2</flow-table>...

<flow-table>255</flow-table></resources>

</logical-switch>

XML Example

XML Example

243


<?xml version="1.0" encoding="UTF-8"?><rpc message-id="1"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><target><candidate/>

</target><default-operation>merge</default-operation><config><capable-switch xmlns="urn:onf:of12:config:yang"><logical-switches><switch><id>logic-switch-1</id><controllers><controller><id>controller-0</id><ip-address operation="replace">10.0.0.10</ip-address>

</controller></controllers>

</switch></logical-switches>

</capable-switch></config>

</edit-config></rpc>

<rpc-reply message-id="1"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/></rpc-reply

ExampleReplacing the ip-address element of the controller

244

References

References• OpenFlow® Switch Specification Ver 1.0.0• OpenFlow® Switch Specification Ver 1.0.1• OpenFlow® Switch Specification Ver 1.0.2• OpenFlow® Switch Specification Ver 1.1• OpenFlow® Switch Specification Ver 1.2• OpenFlow® Switch Specification Ver 1.3.0• OpenFlow® Switch Specification Ver 1.3.1• OpenFlow® Switch Specification Ver 1.3.2• OpenFlow® Switch Specification Ver 1.3.3• OpenFlow® Switch Specification Ver 1.3.4• OpenFlow® Switch Specification Ver 1.3.5• OpenFlow® Switch Specification Ver 1.4.0• OpenFlow® Switch Specification Ver 1.4.1• OpenFlow® Switch Specification Ver 1.5.0• OpenFlow® Switch Specification Ver 1.5.1• OpenFlow® Management and Configuration Protocol 1.2 (OF-Config 1.2)

245

Issue Date:

Revision:

Thank You !End of session

[Date]

[xx]

WSDN01_v0.1

247

Documents

WSDN01 - Module 2 - OpenFlow - v1 · PDF file1.5.0 1.5.1. OpenFlowrevisions: features 6 1.0.0 •First non-experimental version ... –OpenFlow-only: perform forwarding based purely