Copyright © 2012, [email protected]
1
OpenFlow Switch Specification v1.3.0 – OpenFlow Channel
指導教授:王國禎 學生:詹益晨國立交通大學資訊工程系行動計算與寬頻網路實驗室
Copyright © 2012, [email protected]
2
Outline
• Introduction• Related Work• Message types• Message Handling• OpenFlow Channel Connections
– Connection Setup– Connection Interruption– Encryption– Multiple Controllers– Auxiliary Connections
Copyright © 2012, [email protected]
3
Outline
• Flow Table Modification Messages• Group Table Modification Messages• Meter Modification Messages• Conclusions• References
Copyright © 2012, [email protected]
4
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.
Copyright © 2012, [email protected]
5
Related WorkOF version v1.1.0 v1.3.0
Three Message Types V V
Connection Setup / Interrupt V V
Encryption V V
Spanning Tree
Message Handling V V
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
Copyright © 2012, [email protected]
6
Message Type
Message Type Initial Function
Controller-to-Switch Controller Manage or inspect the state of the switch.
Asynchronous Switch Denote a packet arrival, switch state change, or error.
Symmetric Controller/SwitchDenote the connection setup, the echo of the request/reply, or additional function.
Copyright © 2012, [email protected]
7
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
Copyright © 2012, [email protected]
8
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.
Copyright © 2012, [email protected]
9
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.
Copyright © 2012, [email protected]
10
OpenFlow Channel Connections
• Connection Setup• Connection Interruption• Encryption• Multiple Controllers• Auxiliary Connections
Copyright © 2012, [email protected]
11
Connection Setup
• The switch must be able to establish communication with a controller at a user-configurable IP address, using a user-specified 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.
Copyright © 2012, [email protected]
12
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.
Copyright © 2012, [email protected]
13
Encryption
• The switch and controller may communicate through a TLS connection. They mutually authenticate by exchanging certificates signed by a site-specific private key.
Copyright © 2012, [email protected]
14
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.
Copyright © 2012, [email protected]
15
Multiple Controllers
• Three roles of a controller
Role Function
OFPCR_ROLE_EQUL
The controller has full access to the switch.
The controller receives all the switch asynchronous message, and it can send controller-to-switch commands to modify the state of the switch.
OFPCR_ROLE_SLAVE
The controller has read-only access to the switch.
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.
OFPCR_ROLE_MASTER The controller has full access to the switch, and the switch ensures it is the only controller in this role.
Copyright © 2012, [email protected]
16
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.
Copyright © 2012, [email protected]
17
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.
Copyright © 2012, [email protected]
18
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.
Copyright © 2012, [email protected]
19
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 Packet-out 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.
Copyright © 2012, [email protected]
20
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.
Copyright © 2012, [email protected]
21
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
Copyright © 2012, [email protected]
22
Group Table Modification Messages
Group mod command FunctionOFPGC_ADD New group
OFPGC_MODIFY Modify all matching groups
OFPGC_DELETE Delete all matching groups
• 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
Copyright © 2012, [email protected]
23
Meter Modification Messages
Group mod command FunctionOFPMC_ADD New meter
OFPMC_MODIFY Modify all specified meter
OFPMC_DELETE Delete all specified meter
• 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.
Copyright © 2012, [email protected]
24
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.
Copyright © 2012, [email protected]
25
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