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
Abstracted Flow Table
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
Abstracted Flow Table
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
Abstracted Flow Table
OpenFlowController
OpenFlowProtocol
Control Plane
Secure Channel
Abstracted Flow Table
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
SDN architectural framework (2)
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
SDN architectural framework (3)
21
Application Plane Application Service
Network Services Abstraction Layer
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”)
Device & Resource Abstraction Layer (DAL)
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
Network Services Abstraction Layer
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
Elements of SDN architecture (2)
23
Network Services Abstraction Layer
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
Elements of SDN architecture (3)
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
Device & Resource Abstraction Layer (DAL)
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
CHANGED BEHAVIOUR IN LATER VERSIONS
Type=“OUTPUT” LengthOutput port Max Length
Flow action descriptor
• Flow action descriptor structure– Structures used to describe flow actions
67
32 bits
CHANGED BEHAVIOUR IN LATER VERSIONS
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
Action DescriptionOutput Output to switch port
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
• Drop action [required]:– Implicit action associated with a flow-entry that has no specified action
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
• The group table contains group entries.
• 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
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
Per-group# flow entries
Transmit bytes
Transmit overrun errors
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 (2)
• 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
Pipeline processing (3)
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
Pipeline processing (4)
• Per-table packet processing:
104
Flow Table
Match fields:Ingress port + metadata +
packet headers
Action setA C
Match fields:Ingress port + metadata +
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
Connection interruption
• 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
OpenFlow message types
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
Controller-to-Switch
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
CHANGED BEHAVIOUR IN LATER VERSIONS
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
Fields new to v1.1.0 are in bold.
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
Modify Flow Entry Message
• Flow Mod message structure– Structure used to add/delete/modify flow entries
109
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
buffer id
table id
32 bits
cookie
flow match descriptor
idle timeout
hard timeout priority
flags padding
instructions descriptor
cookie mask
command
output port
output group
Fields new to v1.1.0 are in bold.
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
Action DescriptionOutput Output to switch port
Copy TTL out Copy TTL from next-to-outermost to outermost header
Copy TTL in Copy TTL from outermostheader to next-to-outermost
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
Push MPLS Push a new MPLS label
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
OpenFlow message types
117
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
ID Type
10 Packet-In
11 Flow-removed
12 Port status
Asynchronous
Controller-to-Switch
Messages new to v1.2.0 are in bold.
ID Type
20 Barrier Request
21 Barrier Reply
22 Queue Get Config Request
23 Queue Get Config 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 destination address
Ethernet source address
Ethertype
VLAN ID
VLAN priority
IP DSCPIP ECNIP protocol
IPv4 source address
IPv4 destination address
Fields new to v1.2.0 are in bold.
• 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
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
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 table contains a set of flow entries
• 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
Basic OpenFlow match fields
131
Ingress port
Ingress physical port
Metadata
Ethernet destination address
Ethernet source address
Ethertype
VLAN ID
VLAN priority
IP DSCP
IP ECN
IP protocol
IPv4 source address
IPv4 destination address
Fields new to v1.3.x are in bold.
• 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 destination 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
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
Duration (seconds)
Duration (nanoseconds)
Per-queueTransmit packets
Transmit bytes
Transmit overrun errors
Duration (seconds)
Duration (nanoseconds)
Per-group# flow entries
Transmit bytes
Transmit overrun errors
Duration (seconds)
Duration (nanoseconds)
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)
• 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
• 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
• Drop action [required]:– Implicit action associated with a flow-entry that has no specified action
135
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
136
Supported Actions
137
Action DescriptionOutput Output to switch port
Copy TTL out Copy TTL from next-to-outermost to outermost header
Copy TTL in Copy TTL from outermostheader to next-to-outermost
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
Push MPLS Push a new MPLS label
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
Push PBB Push a new PBB service tag (I-tag)
Pop PBB Pop the outer PBB service tag (I-tag)
Actions new to v1.3.0 are in bold.
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
138
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
• If no output action or group action are specified in an action set, the packet is dropped
139
Actions
• Order of application of actions in the ‘Action Set’
140
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.
141
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 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
• The group table contains group entries.
• Each group entry contains:
143
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
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
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
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)
• 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.
148
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. The instructions may explicitly direct the packet to another flow table.
149
Pipeline processing (2)
• 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
Pipeline processing (3)
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
Pipeline processing (4)
• Per-table packet processing:
152
Flow Table
Match fields:Ingress port + metadata +
packet headers
Action setA C
Match fields:Ingress port + metadata +
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
Flow table example
• <Give an example of a flow table with realistic entries>– Example for ARP packet– NAT function– VID addition
153
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
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
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
156
Switch bootstrapping
157
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
158
Connection interruption
• 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 route
– Applies only to OpenFlow-hybrid switches
159
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
160
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
161
Messages new to v1.3.x are in bold
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
162
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
163
OpenFlow protocol
• Common OpenFlow packet header– All OpenFlow messages start with this header
164
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
165
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
166
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 Multipart Request
19 Multipart Reply
ID Type
10 Packet-In
11 Flow-removed
12 Port status
Asynchronous
Controller-to-Switch
Messages new to v1.3.x are in bold.
ID Type
20 Barrier Request
21 Barrier Reply
22 Queue Get Config Request
23 Queue Get Config 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.
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)
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.
168
Handshake
• Once TLS session is established, the controller sends a Features Request message.
• The switch responds with a Features Reply message:
169
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 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
170
Modify Flow Entry Message
• Flow Mod message structure– Structure used to add/delete/modify flow entries
171
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
buffer id
table id
32 bits
cookie
flow match descriptor
idle timeout
hard timeout priority
flags padding
instructions descriptor
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
172
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
173
Type=“OUTPUT” LengthOutput port
Max Length
Flow action descriptor
• Flow action descriptor structure– Structures used to describe flow actions
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
Proactive vs reactive flow entries
• <Explain the two approaches>
175
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
176
Send Packet Message
• Packet-Out message structure– For packets sent from the controller to the switch
177
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
Packet-In Message
• Packet-Out message structure– Structure used to add/delete/modify flow entries
178
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
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
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
181
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
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
Message flow example
184
Controller SwitchHello Hello
Features Request
Features Reply
Topology discovery
• <proactive rules for dealing with LLDP packets>– If ethertype=LLDP, output to CONTROLLER
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
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 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
OpenFlow message types
198
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 Multipart Request
19 Multipart Reply
ID Type
10 Packet-In
11 Flow-removed
12 Port status
30 Role status
31 Table status
32 Request Forward
Asynchronous
Controller-to-Switch
Messages new to v1.4.0 are in bold.
ID Type
20 Barrier Request
21 Barrier Reply
22 Queue Get Config Request
23 Queue Get Config Reply
24 Role Request
25 Role Reply
26 Get Async Request
27 Get Async Reply
28 Set Async
29 Meter Mod
33 Bundle Control
34 Bundle Add
Basic OpenFlow match fields
199
Ingress port
Ingress physical port
Metadata
Ethernet destination address
Ethernet source address
Ethertype
VLAN ID
VLAN priority
IP DSCP
IP ECN
IP protocol
IPv4 source address
IPv4 destination address
Fields new to v1.4.0 are in bold.
• 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 destination 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
Modify Flow Entry Message
• Flow Mod message structure– Structure used to add/delete/modify flow entries
200
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
importance:- Used for flow eviction
purposes
buffer id
table id
32 bits
cookie
flow match descriptor
idle timeout
hard timeout priority
flags importance
instructions descriptor
cookie mask
command
output port
output group
Fields new to v1.4.0 are in bold.
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
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).
• 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 table contains a set of flow entries
• 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
Basic OpenFlow match fields
211
Ingress port
Ingress physical port
Metadata
Ethernet destination address
Ethernet source address
Ethertype
VLAN ID
VLAN priority
IP DSCP
IP ECN
IP protocol
IPv4 source address
IPv4 destination address
TCP source port
Fields new to v1.5.0 are in bold.
• OXM_field types for the OXM_class: OFPXMC_OPENFLOW_BASICTCP 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 destination 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
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
Duration (seconds)
Duration (nanoseconds)
Per-queueTransmit packets
Transmit bytes
Transmit overrun errors
Duration (seconds)
Duration (nanoseconds)
Per-group# flow entries
Transmit bytes
Transmit overrun errors
Duration (seconds)
Duration (nanoseconds)
Per-bucketPacket count
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
• 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
• Drop action [required]:– Implicit action associated with a flow-entry that has no specified action
216
Actions new to v1.5.x are in bold.
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
217
Actions new to v1.5.x are in bold.
Actions (3)
• Meter [optional]:– Directs the packet to the specified header
• Copy-field [optional]:– Copies data between pipeline or header fields
218
Actions new to v1.5.x are in bold.
Supported Actions
219
Action DescriptionOutput Output to switch port
Copy TTL out Copy TTL from next-to-outermost to outermost header
Copy TTL in Copy TTL from outermostheader to next-to-outermost
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
Push MPLS Push a new MPLS label
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
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)
Actions new to v1.5.0 are in bold.
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
• As the packet passes through the pipeline the ‘Action Set’ is modified by instructions (Write-Actions, Clear-Actions) of matching flow entries
220
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
• If no output action or group action are specified in an action set, the packet is dropped
221
Actions
• Order of application of actions in the ‘Action Set’
222
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.
223
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 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
• The group table contains group entries.
• Each group entry contains:
225
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
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
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
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
Table-miss flow entry exists ?
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
Table-miss flow entry exists ?
No
Yes
No
Output Action ?
Yes
Drop packetNo
Ingress Processing (previous slide)
Egress Processing
Egress tables exist?
Packet Out
Yes
Matching (3)
• 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.
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 (1)
• Definition: the set of linked tables that provide matching, forwarding and packet modifications in an OpenFlow switch
• 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 (2)
• 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
Pipeline processing (3)
• 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
Pipeline processing (4)
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
Pipeline processing (5)
• Per-table packet processing:
238
Flow Table
Match fields:Ingress port + metadata +
packet headers
Action setA C
Match fields:Ingress port + metadata +
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
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
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
244
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 correspond ing flow entries is also synchronised
• Flow entry sychronisation can be unidirectional or bi-directional.
245
Flow table example
• <Give an example of a flow table with realistic entries>– Example for ARP packet– NAT function– VID addition
246
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
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
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
249
Switch bootstrapping
250
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
251
Connection interruption
• 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 route
– Applies only to OpenFlow-hybrid switches
252
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
253
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
254
Messages new to v1.5.x are in bold
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.– 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
Messages new to v1.5.x are in bold
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
256
OpenFlow protocol
• Common OpenFlow packet header– All OpenFlow messages start with this header
257
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
258
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
259
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 Multipart Request
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
Controller-to-Switch
Messages new to v1.5.0 are in bold.
ID Type
20 Barrier Request
21 Barrier Reply
22 Queue Get Config Request
23 Queue Get Config Reply
24 Role Request
25 Role Reply
26 Get Async Request
27 Get Async Reply
28 Set Async
29 Meter Mod
33 Bundle Control
34 Bundle Add
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.
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)
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.
261
Handshake
• Once TLS session is established, the controller sends a Features Request message.
• The switch responds with a Features Reply message:
262
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 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
263
Modify Flow Entry Message
• Flow Mod message structure– Structure used to add/delete/modify flow entries
264
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
importance:- Used for flow eviction
purposes
buffer id
table id
32 bits
cookie
flow match descriptor
idle timeout
hard timeout priority
flags importance
instructions descriptor
cookie mask
command
output port
output group
Fields new to v1.5.0 are in bold.
Flow match descriptor• Flow match descriptor structure– Payload is a set of OXM (OpenFlow Extensible Match) flow match fields
265
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
266
Type=“OUTPUT” LengthOutput port
Max Length
Flow action descriptor
• Flow action descriptor structure– Structures used to describe flow actions
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
Proactive vs reactive flow entries
• <Explain the two approaches>
268
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
269
Send Packet Message
• Packet-Out message structure– For packets sent from the controller to the switch
270
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
Packet-In Message
• Packet-Out message structure– Structure used to add/delete/modify flow entries
271
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
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
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
277
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
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
Message flow example
280
Controller SwitchHello Hello
Features Request
Features Reply
Topology discovery
• <proactive rules for dealing with LLDP packets>– If ethertype=LLDP, output to CONTROLLER
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