OpenFlow Switch Specification v1.3.0 –
OpenFlow Channel
指導教授：王國禎
學生：詹益晨
國立交通大學資訊工程系
行動計算與寬頻網路實驗室
1
Copyright © 2012, MBL@CS.NCTU
Outline
•
•
•
•
•
Introduction
Related Work
Message types
Message Handling
OpenFlow Channel Connections
– Connection Setup
– Connection Interruption
– Encryption
– Multiple Controllers
– Auxiliary Connections
2
Copyright © 2012, MBL@CS.NCTU
Outline
•
•
•
•
•
Flow Table Modification Messages
Group Table Modification Messages
Meter Modification Messages
Conclusions
References
3
Copyright © 2012, MBL@CS.NCTU
Introduction
• The OpenFlow channel is the interface that connects each
OpenFlow switch to a controller.
• Through this interface, the controller configures and
manages the switch, receives events from the switch, and
sends packets out the switch.
• The OpenFlow channel is usually encrypted using TLS, but
may be run directly over TCP.
4
Copyright © 2012, MBL@CS.NCTU
Related Work
OF version
v1.1.0
v1.3.0
Three Message Types
V
V
Connection Setup / Interrupt
V
V
Encryption
V
V
V
V
Spanning Tree
Message Handling
Multiple Controller
V
Auxiliary Connections
V
Flow Table Modification Messages
V
V
Flow Removal
V
V
Group Table Modification Messages
V
V
Meter Modification Messages
V
5
Copyright © 2012, MBL@CS.NCTU
Message Type
Message Type
Initial
Controller-to-Switch
Controller
Asynchronous
Switch
Symmetric
Function
Manage or inspect the state of the
switch.
Denote a packet arrival, switch state
change, or error.
Denote the connection setup, the
Controller/Switch echo of the request/reply, or
additional function.
6
Copyright © 2012, MBL@CS.NCTU
Message Type
Controller-to-Switch
Asynchronous
Symmetric
Features
Packet-in
Hello
Configuration
Flow-Removed
Echo
Modify-State
Port-status
Experimenter
Read-State
Error
Packet-out
Barrier
Role-Request
Asynchronous-Configuration
7
Copyright © 2012, MBL@CS.NCTU
Message Handling
• The OpenFlow protocol provides reliable message delivery
and processing, but does not automatically provide
acknowledgements or ensure ordered message processing.
• Message Delivery
– Message are guaranteed delivery, unless the OpenFlow
channel fails entirely.
• Message Processing
– Switches must process every message received from a
controller in full, possibly generating a reply.
– If a switch cannot completely process a message
received from a controller, it must send back an error
message.
8
Copyright © 2012, MBL@CS.NCTU
Message Handling
• Message Ordering
– Ordering can be ensured through the use of barrier
messages.
– In the absence of barrier messages, switches may
arbitrarily reorder messages to maximize performance;
hence, controllers should not depend on a specific
processing order.
9
Copyright © 2012, MBL@CS.NCTU
OpenFlow Channel Connections
•
•
•
•
•
Connection Setup
Connection Interruption
Encryption
Multiple Controllers
Auxiliary Connections
10
Copyright © 2012, MBL@CS.NCTU
Connection Setup
• The switch must be able to establish communication with a
controller at a user-configurable IP address, using a userspecified port.
• If the switch knows the IP address of the controller, the
switch initiates a standard TLS or TCP connection to the
controller. The switch must identify incoming traffic as local
before checking it against the flow tables.
11
Copyright © 2012, MBL@CS.NCTU
Connection Interruption
• If a switch loses contact with the current controller, it
should attempt to contact one or more backup controllers
and immediately enter either “fail secure mode” or “fail
standalone mode”.
• In “fail secure mode”, the only change to switch behavior is
that packets and messages destined to the controllers are
dropped.
• In “fail standalone mode”, the switch acts as a legacy
Ethernet switch or router.
12
Copyright © 2012, MBL@CS.NCTU
Encryption
• The switch and controller may communicate through a TLS
connection. They mutually authenticate by exchanging
certificates signed by a site-specific private key.
13
Copyright © 2012, MBL@CS.NCTU
Multiple Controllers
• Improve reliability, fast recovery and Controller load
balancing.
• Multiple controllers is only to help synchronize controller
handoffs performed by the controllers.
• It only addresses controller fail-over and load balancing, and
doesn’t address virtualization which can be done outside
the OpenFlow protocol.
• When OpenFlow operation is initiated, the switch must
connect to all controllers, and try to maintain connectivity
with all of them concurrently.
14
Copyright © 2012, MBL@CS.NCTU
Multiple Controllers
• Three roles of a controller
Role
Function
The controller has full access to the switch.
OFPCR_ROLE_EQUL
The controller receives all the switch asynchronous
message, and it can send controller-to-switch commands
to modify the state of the switch.
The controller has read-only access to the switch.
OFPCR_ROLE_SLAVE
OFPCR_ROLE_MASTER
The controller doesn’t receive all the switch
asynchronous message, and it is denied ability to execute
controller-to-switch commands that modify the state of
the switch.
The controller has full access to the switch, and the
switch ensures it is the only controller in this role.
15
Copyright © 2012, MBL@CS.NCTU
Multiple Controllers
• A switch may be simultaneously connected to multiple
controllers in Equal state, multiple controllers in Slave state,
and at most one controller in Master state.
• Each controller may communicate its role to the switch via a
OFPT_ROLE_REQUEST message.
• Different controllers can receive different notifications, a
controller in master mode can selectively disable
notifications it does not care about, and a controller in slave
mode can enable notifications it wants to monitor.
16
Copyright © 2012, MBL@CS.NCTU
Auxiliary Connections
• Auxiliary connections are created by the OpenFlow switch
and are helpful to improve the switch processing
performance and exploit the parallelism of most switch
implementations.
• Auxiliary connections must use the same source IP address
as the main connection, but can use a different transport. It
should have the same destination IP address and same
transport destination port as the main connection.
17
Copyright © 2012, MBL@CS.NCTU
Auxiliary Connections
• The switch must setup and maintain auxiliary connections
with the controller only while the corresponding main
connection is alive.
• If switch detects that the main connection to a controller is
broken, it must immediately close all its auxiliary
connections to that controller, to enable the controller to
properly resolve Datapath ID conflicts.
18
Copyright © 2012, MBL@CS.NCTU
Auxiliary Connections
• The controller is free to use the various switch connections
• How to maximize performance on most switch:
– All OpenFlow controller messages which are not Packetout should be sent over the main connection.
– All Packet-out messages containing a packet from a
Packet-in message should be sent on the connection
where the Packet-in came from.
– All other Packet-out messages should be spread across
the various auxiliary connections using a mechanism
keeping the packets of a same flow mapped to the same
connection.
– If the desired auxiliary connection is not available, the
controller should use the main connections.
19
Copyright © 2012, MBL@CS.NCTU
Auxiliary Connections
• The switch is free to use the various controller connections
– All OpenFlow messages which are not Packet-in should
be sent over the main connection.
– All Packet-in messages spread across the various
auxiliary connection using a mechanism keeping the
packets of a same flow mapped to the same connection.
20
Copyright © 2012, MBL@CS.NCTU
Flow Table Modification Messages
Flow mod command
Function
OFPFC_ADD
New flow
OFPFC_MODIFY
Modify all matching flows
OFPFC_MODIFY_STRICT
Modify entry strictly matching wildcards and priority
OFPFC_DELETE
Delete all matching flows
OFPFC_DELETE_STRICT
Delete entry strictly matching wildcards and priority
21
Copyright © 2012, MBL@CS.NCTU
Group Table Modification Messages
• A group table consists of group entries.
• The ability for a flow entry to point to a group enables
OpenFlow to represent additional methods of forwarding
Group mod command
Function
OFPGC_ADD
New group
OFPGC_MODIFY
Modify all matching groups
OFPGC_DELETE
Delete all matching groups
22
Copyright © 2012, MBL@CS.NCTU
Meter Modification Messages
• A meter table consists of meter entries, defining per-flow
meters.
• Per-flow meters enable OpenFlow to implement various
simple QoS operations, such as rate-limiting, and can be
combined with per-port queues to implement complex QoS
frameworks.
Group mod command
Function
OFPMC_ADD
New meter
OFPMC_MODIFY
Modify all specified meter
OFPMC_DELETE
Delete all specified meter
23
Copyright © 2012, MBL@CS.NCTU
Conclusions
• In the OpenFlow Switch Specification v1.3.0, we can realize
they want to raise the reliability of the OpenFlow channel
connection.
• In the OpenFlow Channel:
– The controller-to-switch messages were added two new
messages, Role-request and Asynchronous-Configuration.
– Update three sections, multiple controllers, auxiliary
connections, and meter modification messages.
24
Copyright © 2012, MBL@CS.NCTU
References
• OpenFlow Switch Specification (wire protocol 0x01),
version 1.1.0, February 28, 2011
• OpenFlow Switch Specification (Wire Protocol 0x04),
version 1.3.0, June 25, 2012
25
Copyright © 2012, MBL@CS.NCTU
Thank you!
26
Copyright © 2012, MBL@CS.NCTU