xSDN01 - OpenFlow - v0.18 FA · (controller) Traffic(Engineering Route(selection(& failover...

Issue Date:

Revision:

SDN Workshop

Contact: [email protected]

[Date]

[xx]

TSDN01_v0.1

Routers

2

• Two key roles:

Determining network paths

Packet forwarding

Today’s router

3

Other Hardware

Network Interfaces

CPUs

ASICs NPUs

Switch Fabric

Control Memory (T)CAM

FIB

ManagementCLI SNMP

High AvailabilityResiliency Protocols

Network Layer

RIBRouting Protocols (unicast/multicast)

Services Layer

IP L2 L3 Application Layer (DPI etc)

QoSQueue

Management

Hardware Redundancy

Traffic Managers

Packet Memory

Scheduling Algorithms

FCAPS

Security

AAA

CPU Protection

Accoun-ting

How did we get here ?

4

Distribution of complexity

Backwards compatibility

Unanticipated applications

Need for higher performance

• ‘End-to-end principle’

• Better scaling • Survivability;; spreading of risk

• “Flag days” not realistic

• Short-term, incremental evolution of technology;; no major overhaul in last 20 years

• Networking is a victim of its own success

• New applications have been delivered on top of existing capabilities

• Tight coupling between different planes seen as critical for delivering higher performance

Clean Slate Project (1)

5

With what we know today, if we were to start again with a clean slate, how would we design a

global communications infrastructure

Mission: Re-invent the Internet

Two research questions:

How should the Internet look in 15 years?

Clean Slate Project (2)

6

• One of the flagship projects was ‘Internet Infrastructure: OpenFlow and Software Defined Networking’

• Seminal paper on OpenFlow…

...kicked off the SDN movement and the data communications world would never be the same again

OpenFlow: The Problem

• Initial Problem:

– A mechanism was required for researchers to run experimental network protocols.

– Open software platforms did not provide the required performance and commercial solutions were too closed and inflexible.

7

Hardware

Software Tight coupling

Closed systems;; only functionality exposed by vendors is available

Challenge: how do we influence packet switching/forwarding behaviour ?

OpenFlow: The Solution (1)

8

FROM TO

Routing/Bridging Protocols, RIBs,

routing policy and logic

Forwarding Tables

Secure Channel

Abstracted Flow Table

OpenFlowController

OpenFlowProtocol

Control Plane

Data Plane

Data Plane

Control Plane

Control Plane

Data Plane

Protocols and algorithms to calculate forwarding paths

Forwarding frames/packets based on paths calculated by control plane

OpenFlow: The Solution (2)

9

Secure Channel


OpenFlowController

OpenFlowProtocol

Data Plane

Control Plane

The Solution:

• OpenFlow provided a compromise that provided a means of influencing switching/routing decisions without opening up network software.

• The control software would run on a controller;; the outcomes of the calculations would be pushed down to the data plane running on the network element

OpenFlow: How it works (1)

10

Secure Channel


OpenFlowController

OpenFlowProtocol

Control Plane

* Ingress Port, Ethernet SA, Ethernet DA, VLAN ID, VLAN PCP, IP SA, IP DA, IP Proto, IP ToS, Source L4 Port, Dest L2 Port etc….

Adds, deletes and modifies flow table entries

Header Fields* Actions Counters

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

Switch forwards traffic by matching against header fields and taking corresponding actions

OpenFlow: How it works (2)

11

Secure Channel


OpenFlowController

OpenFlowProtocol

Control Plane

Secure Channel


Secure Channel

Abstracted Flow Table. . .

Switch 1 Switch 2 Switch n

OpenFlowProtocol

One controller manages many switches

OpenFlow: Today

• Initially synonymous with SDN

• Today, OpenFlow is relegated to being just a part of the greater SDN architecture, with other protocols competing in the same space

• It is, however:

12

The spark …that lit the fuse …

that started the fire (SDN)

OpenFlow: Implications

• Two primary implications:

13

The control plane (processes to determine how traffic is handled) is physically decoupled from the data plane (forwards traffic according to decisions passed down by the control plane).

The control plane is consolidated and centralised: a single software control plane controls multiple data planes (previously a 1:1 correspondence).

The Birth of SDN

14

The separation of control and data plane was not an objective in itself but was a consequence of the compromise approach taken by OpenFlow

It heralded a new era of programmability that has been vastly enhanced with new architectures and capabilities

The term ‘SDN’ itself was coined in an article about the OpenFlowproject at Stanford (http://www2.technologyreview.com/news/412194/tr10-software-defined-networking/)

Emergence and evolution of SDN

15

• OpenFlow was a starting point…– Ushered in an era of programmability– But a complete decoupling of the control plane and data plane was not practical:• We would have had to solve all the problems the industry had spent decades solving and refining: resiliency, scalability, convergence, redundancy etc

• SDN architecture today– Hybrid approach where some elements of the control plane remain distributed while others are centralised.

– Many different architectural models– All of them aspire to achieve the goals of agility and network programmability

Defining SDN

16

ONF: The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

This definition is too narrow…

As much a marketing term as a technical one

Automation through enhanced programmability and openinterfaces

Dis-aggregation and abstraction

Centralisation of network control with real-time network visibiity

SDN is …

A new approach to networking that provides greater network agility and flexibility by:

Objectives and benefits of SDN

17

Agility Automation

CAPEX/OPEX reduction Programmability

CentralisedControl

• Service provisioning• Network provisioning• Service automation

• Quicker introduction of new services for faster time to revenue

• Reduction in hardware

and network operations

costs

• Abstraction via simplified, open interfaces

• End-to-end service and network management

• End-to-end optimisation

SDN SDOs

18

SDN architectural framework (1)

19

ITU-T Y.3300

SDN Controllers

SDN Applications

Network Resources


20

Application Plane

Application Service

Network Services Abstraction Layer

Control Plane

Service App

Control Abstraction Layer (CAL)

Management Plane

App

Mgmt Abstraction Layer (MAL)

Service Interface

Device & Resource Abstraction Layer (DAL)

Forwarding Plane App Operational PlaneNetwork Device

CP Southbound Interface MP Southbound Interface

RFC7426


21

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 OpenFlow YANG

Configuration

OpenFlowSNMP Netconf

Data Plane

BGP PCCRIBs

Segment Routing 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”)


Elements of SDN architecture (1)

22

• Application Plane– “Consumers” of the network

– Traffic optimisationapplications

– OSS systems– End-customer self-service portals

– Etc.

Application Plane Application Service


REST/RESTCONF/NETCONF/XMPPNorthbound Interfaces

• Northbound interfaces– Abstraction of network services towards applications and services

• Network Services Abstraction Layer:– Normalises network and service constructs via an open API or interfaces - YANG models, NETCONF, RESTCONF


23


Topology Discovery & ManagementControl

Plane(controller)

Traffic Engineering

Route selection & failover

Resource Management

Configuration

East/West-bound

interfaces –BGP

• Control Plane layer– “The Controller”;; the brains of the operation

– Translates high-level instructions from north-bound interfaces and converts them to instructions for the resource layer

– Collection of key functions:• Topology discovery• Traffic engineering• Resource management• Route selection and failover• Service configuration• Mediation

– Southbound interfaces

Northbound Interfaces

Southbound Interfaces


24

Network Devices – IP/MPLS/Transport

Southbound Interfaces BGP-LS PCE-Pi2RS

SNMP MIBs OpenFlow YANG

OpenFlowSNMP Netconf

Data Plane

BGP PCCRIBs

Segment Routing RSVP-TE

IPFIXForCES

• Southbound interfaces– Myriad interfaces, plug-ins, and protocols, including OpenFlow

– Device-specific details abstracted from higher layers of the controller

• Data Plane– Traditional and newer generation dataplanes, physical and virtual

– Augmented by SDN-friendly protocols such as Segment Routing


Key SDN use cases

25

Data Centre network automation• Most widely-deployed and mature solution

• Automation of network connectivity via overlay networks

• Multi-tenancy

SD-WAN• Extension of DC automation concepts

• Site connectivity via overlay networking

Service Automation & provisioning• Direct customer access via portals• Bandwidth on demand• Bandwidth calendaring

Network optimisation• Link and path optimisation based on real-time network state

• Running networks "hotter"

Open source projects

26

Comparing and contrasting with NFV

27

FROM TO

Tightly coupled

Software

Purpose-built

hardware

COTS hardware

VirtualisedSoftware

SDN: decouples control plane and data planeNFV: decouples network software from closed, proprietary hardware systems

Issue Date:

Revision:

OpenFlowSDN Workshop

[Date]

[xx]

TSDN01_v0.1

OpenFlow versions

• From v1.0.0 in 2009 to v1.5.2 in 2015

• Developed by the 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.

29

OpenFlow revision timeline

30

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 revision: features

• <<Summarise features introduced in each release>>

31

32

OpenFlow v1.0.0

OpenFlow v1.0.0

33

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

34

* 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.

35

Secure Channel

Flow Table

OpenFlow Switch

OpenFlowProtocol

OpenFlowController

OpenFlow Switch components

• Flow table (single):– Performs packet lookup and forwarding

• Secure channel:– To an external controller which manages the switch using the OpenFlow protocol

36

Flow table

• Contains:– A set of flow entries (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

37

Header Fields Actions Counters

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

Match fields

38

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)

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 (1)

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

• Forward (output) action [required]:– Forwarding of packet to physical or virtual ports

• Enqueue action [optional]:– Forward a packet through a specified queue attached to a port

39

Supported Actions

40

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

Actions (2)

• Drop action [required]:– Implicit action associated with a flow-entry that has no specified action

• Modify-field action [optional]:– Specify modification of packet header fields

41

OpenFlow ports (1)

• Physical ports:

– Correspond to physical hardware ports

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

42

OpenFlow ports (2)

• Virtual ports:– ‘ALL’: all OpenFlow interfaces except the incoming interface

– ‘CONTROLLER’: logical interface to the OpenFlow controller

– ‘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

43

Modify-field actions

44

Set VLAN IDSet VLAN priorityStrip VLAN header

Modify Ethernet source addressModify Ethernet destination address

Modify IPv4 source addressModify IPv4 destination address

Modify IPv4 ToS bitsModify TCP/UDP source port

Modify TCP/UDP destination port

Counters

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

45

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

• <Give an example of a flow table with realistic entries>– Example for ARP packet– NAT function– VID addition

46

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

47

Matching

48

Packet ingressing into

switch

Parse header fields

(see next slide)

Match flow table ?

Perform actionsYes

No

Send to controller via Secure channel

Header field parsing

49

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

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 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.

50

Switch bootstrapping

51

Connection setup

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

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

52

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.

53

CHANGED BEHAVIOUR IN LATER VERSIONS

OpenFlow protocol messages

• Protocol defines three types of messages.

• Controller-to-switch:– Are initiated by the control 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

54

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

55

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

56

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

57

OpenFlow protocol

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

58

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

59

Version of specification OpenFlow protocol version

1.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 message types

60

ID Type0 Hello1 Error2 Echo Request3 Echo Reply4 Vendor

SymmetricID Type5 Features Request6 Features Reply7 Get Config Request8 Get Config Reply9 Set Config13 Packet-out14 Flow Mod15 Port Mod16 Stats Request17 Stats Reply18 Barrier Request19 Barrier Reply20 Queue Get Config Request21 Queue Get Config Reply

ID Type10 Packet-In11 Flow-removed12 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 negotiated independently by each side is the lower of (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.

61

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.

62

Handshake

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

• The switch responds with a Features Reply message:

63

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 matching (existing) flow entries

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

– Delete: deletes all matching (existing) flow entries

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

64

Modify Flow Entry Message

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

65

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

66

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


Type=“OUTPUT” LengthOutput port Max Length

Flow action descriptor

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

67

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

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 queues configuration available are:– min-rate: minimum guaranteed data-rate– max-rate: maximum data-rate

68

Proactive vs reactive flow entries

• <Explain the two approaches>

69

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

70

Send Packet Message

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

71

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:- Initial portion of

packet

packet data

Packet-In Message

• Packet-Out message structure– Structure used to add/delete/modify flow entries

72

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

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– To verify liveness of the connection between controller and switch

73

Message flow example

74

Controller SwitchHello Hello

Features Request

Features Reply

Topology discovery

• <proactive rules for dealing with LLDP packets>– If ethertype=LLDP, output to CONTROLLER

75

Exclusions

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

76

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)

77

78

OpenFlow v1.1.0

OpenFlow v1.1.0

79

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

80

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

• 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

81

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).

82

OpenFlow components

83

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

84

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.

85

Match fields

86

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)

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

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/SCTP source and destfor 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 and remaining MPLS shim headers

No

No

Set IP source/destfrom within ARP

packet

VLAN Tag

MPLS label

ARP

IPv4

Supported Actions

88


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 (1)

• Output (forward) action [required]:– Forwarding of packet to physical or virtual ports

• Set-Queue action [optional]:– Forward a packet through a specified queue attached to a port


89

Actions (2)

• Group action [required]: processes the packet through the specified group

• Push-Tag/Pop-Tag action [optional]:– Push/pop of VLAN and MPLS headers

• Set-Field action [optional]:– Set packet header fields, manipulate TTL

90

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’.

91

Action Set (2)

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

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

92

Actions

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

93

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.

94

Group table

• Flow entries may point to a group in the group table.

• Group provide 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.

95

Group table


• Each group entry contains:

96

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

Counters

97


Packet lookups

Packet matches


Received bytes

Duration (seconds)Duration (nanoseconds)


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

Instructions

• Executed when a packet matches a flow entry.

• 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.

98

Matching (1)

99

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.

100

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.

101


• 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)– Continue to the next table– Be dropped

102


103

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:

104

Flow Table

Match fields:Ingress port + metadata +

packet headers

Action setA C


packet headers

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

105


106

ID Type

0 Hello

1 Error

2 Echo Request

3 Echo Reply

4 Experimenter

SymmetricID Type

5 Features Request

6 Features Reply

7 Get Config Request

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

22 Queue Get Config Request

23 Queue Get Config 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

107


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

108

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 pipelineTABLE_MISS_DROP • Drop the packet

Config:- Bitmap of flags to

describe the behaviourof the table for unmatched packets



109


controller





buffer id

table id

32 bits

cookie


idle timeout


flags padding

instructions descriptor

cookie mask

command

output port

output group


110

OpenFlow v1.2.0

OpenFlow v1.2.0

111

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

112

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

113

OpenFlow ports

114

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

115




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 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 switchmay be simultaneously connected to multiple controllers in Equal state, multiple controllers in Slave state and at most a single controller in Master state.

116


117

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

118

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

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

119

Basic OpenFlow match fields

120

Ingress port

Ingress physical portMetadata


Ethernet source address

Ethertype

VLAN ID

VLAN priority

IP DSCPIP ECNIP 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 OPARP SPAARP TPAARP SHA

ARP THA

IPv6 source addressIPv6 destination address

IPv6 Flow LabelICMPv6 typeICMPv6 codeIPv6 ND TargetIPv6 ND SLL IPv6 ND TLLMPLS Label

MPLS TC

121

OpenFlow v1.3.5

OpenFlow v1.3.x

122

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

123

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

124




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

125

OpenFlow components

126

OpenFlow 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 OpenFlowswitch 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

127

OpenFlow Logical Switch

• 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:– To an external controller which manages the switch using the OpenFlow protocol

128

Flow tables


• Each flow entry consists of:

129

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 take 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

130


131

Ingress port

Ingress physical 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 BoSPBB ISIDTunnel ID

IPv4 Ext Header

Counters

132


Packet lookups

Packet matches


Received bytes

Duration (seconds)

Duration (nanoseconds)


Transmitted packets

Received bytes

Transmitted bytes

Receive drops

Transmit drops

Receive errors

Transmit errors



Receive CRC errors

Collisions

Duration (seconds)



Transmit bytes


Duration (seconds)



Transmit bytes


Duration (seconds)



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)

• 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

133

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 through the specified table

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

134

Instructions new to v1.3.x are in bold

Actions (1)

• DEFINITION: an operation that acts on a packet




135

Actions (2)




136

Supported Actions

137





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


138

Action Set (2)





139

Actions


140


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


Action List

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



141

Group table




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

142

Group table



143







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

144

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

145

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

146

OpenFlow Ports








Matching (1)

147

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)




148



• 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.

149


• 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– continue to the next table– being dropped

150


151

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



152

Flow Table


packet headers

Action setA C


packet headers

Action set

B







A

B

C

Flow table example


153

OpenFlow Channel



• There is one OpenFlow channel per OpenFlow controller

154

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

155






156


157

Connection setup



158



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


• ‘Fail-standalone’ mode:– All packets are processed via the NORMAL port i.e. the switch acts as a traditional Ethernet switch or route


159






160



• 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

161

Messages new to v1.3.x are in bold



• 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


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

162

Symmetric messages




– Experimenter: vendor-specific messages

163

OpenFlow protocol


164

xid

version lengthtype







165


1.0.x 0x011.1.x 0x021.2.x 0x031.3.x 0x041.4.x 0x051.5.x 0x06



166

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


– 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.

167

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)




168

Handshake



169

32 bits

datapath id

#buffers




etc.


enabled physical portsReserved

#tables

Capabilities

Paddingauxiliary ID








170



171


controller





buffer id

table id

32 bits

cookie


idle timeout


flags padding


cookie mask

command

output port

output group


172

length

32 bits

typepadding

OXM TLVs


payload

OXM TLV header





oxm_class


and oxm_type




173

Type=“OUTPUT” LengthOutput port

Max Length



174

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



175

Flow removal




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

176

Send Packet Message


177

buffer id

32 bits

length of actions array

action list




packet

packet data

input port

padding

Packet-In Message


178

buffer id

total length



is buffered

Reason:- One of:

- no match- explicit action- TTL expired

Match fields:- Pipeline fields

associated with the packet


packet

reason table ID

cookie

match fields (OXM TLVs)

32 bits

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

179

Multipart message types

180

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




181

QoS structures: queues


• Flows can be mapped to queues which attach to a port

• The only queue configuration available is:– min-rate: minimum guaranteed data-rate

182

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

183


184


Features Request

Features Reply

Topology discovery


185

Exclusions

• What OpenFlow does NOT do (or specify):– Communication between controllers when using multiple controllers (v1.2.0+)

186

187

OpenFlow v1.4.x

OpenFlow v1.4.x

188

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.4.x

• Fifth major release – version 1.4.0– Wire protocol 0x05– October 14, 2013

• This section highlights deltas from the previous release v1.3.x

189

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

190

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.

191

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_updown: 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.

192

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.

193

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

194

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-directal 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

195


• 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 correspond ing flow entries is also synchronised

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

196

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

197


198

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


199

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



200


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


201

OpenFlow v1.5.x

OpenFlow v1.5.x

202

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

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

203

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

204




• Unlike prior versions of the protocol, v1.5.x also supports non-Ethernet packet types such as IPv4 and IPv6 for support of IP routing functionality.

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

OpenFlow components

• OpenFlow controller:– An entity that interacts with the OpenFlow switch using the OpenFlowswitch 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

207

OpenFlow Logical Switch

• 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.

• One or more OpenFlow channel:– To externals controllers which manage the switch using the OpenFlow protocol

208

Flow tables


• Each flow entry consists of:

209

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 take 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• ACTION_SET_OUTPUT• PACKET_TYPE

210


211

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 FlagsAction Set Output port

Packet Type

Counters

212


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)



Transmit bytes


Duration (seconds)



Byte count

Counters new to v1.5.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)

• 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

213

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 through the specified table

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

214

Instructions new to v1.5.x are in bold

Instructions (3)

215

Flow Table

Flow Table

Apply-actionslist 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-actionsset of actions• merge in

action setGoto-tabletable-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 (1)

• DEFINITION: an operation that acts on a packet




216

Actions new to v1.5.x are in bold.

Actions (2)




217


Actions (3)

• Meter [optional]:– Directs the packet to the specified header

• Copy-field [optional]:– Copies data between pipeline or header fields

218


Supported Actions

219





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)


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 for ingress processing– is initialised with the output action for the current output port


220

Action Set (2)





221

Actions


222


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


Action List

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



223

Group table




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

224

Group table



225







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

226

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

227

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

228

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

229

OpenFlow Ports








Matching (1)

230

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)

231

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)




232

Packet Type-aware pipeline

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

• New OXM pipeline field identifies the packet type.

233

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 Empty0 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

234


• 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.

235


• 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– continue to the next table– being dropped

236


237

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 outputport

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



238

Flow Table


packet headers

Action setA C


packet headers

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

239

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.

240

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_updown: 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.

241

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.

242

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

243


• 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-directal 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

244


• 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 correspond ing flow entries is also synchronised

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

245

Flow table example


246

OpenFlow Channel



• There is one OpenFlow channel per OpenFlow controller

247

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

248






249


250

Connection setup



251



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


• ‘Fail-standalone’ mode:– All packets are processed via the NORMAL port i.e. the switch acts as a traditional Ethernet switch or route


252






253



• 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

254




• 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


– 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

255


Symmetric messages




– Experimenter: vendor-specific messages

256

OpenFlow protocol


257

xid

version lengthtype







258


1.0.x 0x011.1.x 0x021.2.x 0x031.3.x 0x041.4.x 0x051.5.x 0x06



259

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

Version negotiation


– 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.

260

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)




261

Handshake



262

32 bits

datapath id

#buffers




etc.


enabled physical portsReserved

#tables

Capabilities

Paddingauxiliary ID








263



264


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



265

length

32 bits

typepadding

OXM TLVs


payload

OXM TLV header





oxm_class


and oxm_type




266

Type=“OUTPUT” LengthOutput port

Max Length



267

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



268

Flow removal




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

269

Send Packet Message


270

buffer id

32 bits

length of actions array

action list




packet

packet data

input port

padding

Packet-In Message


271

buffer id

total length



is buffered

Reason:- One of:

- no match- explicit action- TTL expired

Match fields:- Pipeline fields

associated with the packet


packet

reason table ID

cookie

match fields (OXM TLVs)

32 bits

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

272

Multipart message types

273

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

OpenFlow eXtensible Statistics (OXS)

• Extensible flow entry statistics: OpenFlow eXtensibleStatistics (OXS)

• Similar concept to OXM

• Allows encoding of arbitrary flow statistics

274

Flow stats descriptor• Flow stats descriptor structure– Payload is a set of OXS (OpenFlow Extensible Stats) flow stats fields

275

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

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:

• Bundle messages may be schedule to be committed at a specified execution time.

276

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




277

QoS structures: queues


• Flows can be mapped to queues which attach to a port

• The only queue configuration available is:– min-rate: minimum guaranteed data-rate

278

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

• Different flow entries in the same flow table may use the same meter, different meter or no meters at all

279


280


Features Request

Features Reply

Topology discovery


281

Exclusions

• What OpenFlow does NOT do (or specify):– Communication between controllers when using multiple controllers (v1.2.0+)

282

Issue Date:

Revision:

Thank You !End of session

[Date]

[xx]

TSDN01_v0.1

Date post:	21-Aug-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

xSDN01 - OpenFlow - v0.18 FA · (controller) Traffic(Engineering Route(selection(& failover...

Documents