Extended Maximizing Unavailability Interval (eMUI): Maximizing

Transcript Extended Maximizing Unavailability Interval (eMUI): Maximizing

OpenFlow Switch Specification v1.3.0 – OpenFlow Channel

指導教授：王國禎學生：詹益晨國立交通大學資訊工程系行動計算與寬頻網路實驗室

Outline

• Introduction • Related Work • Message types • Message Handling • OpenFlow Channel Connections – Connection Setup – Connection Interruption – Encryption – Multiple Controllers – Auxiliary Connections

Outline

• Flow Table Modification Messages • Group Table Modification Messages • Meter Modification Messages • Conclusions • References

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.

Related Work

OF version

Three Message Types Connection Setup / Interrupt Encryption Spanning Tree Message Handling Multiple Controller Auxiliary Connections Flow Table Modification Messages Flow Removal Group Table Modification Messages Meter Modification Messages

v1.1.0

V V V V V V V

V V V V V V V V V V 5

Message Type

Message Type

Controller-to-Switch

Initial

Controller

Function

Manage or inspect the state of the switch.

Asynchronous Symmetric Switch Denote a packet arrival, switch state change, or error.

Controller/Switch Denote the connection setup, the echo of the request/reply, or additional function.

Message Type

Controller-to-Switch

Features Configuration Modify-State Read-State Packet-out Barrier Role-Request Asynchronous-Configuration

Asynchronous

Packet-in Flow-Removed Port-status Error

Symmetric

Hello Echo Experimenter

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.

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.

OpenFlow Channel Connections

• Connection Setup • Connection Interruption • Encryption • Multiple Controllers • Auxiliary Connections

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.

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.

Encryption

• The switch and controller may communicate through a TLS connection. They mutually authenticate by exchanging certificates signed by a site-specific private key.

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.

Multiple Controllers

• Three roles of a controller

Role

OFPCR_ROLE_EQUL OFPCR_ROLE_SLAVE OFPCR_ROLE_MASTER

Function

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.

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.

The controller has full access to the switch, and the switch ensures it is the only controller in this role.

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.

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.

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.

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.

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.

Flow Table Modification Messages

Flow mod command

OFPFC_ADD OFPFC_MODIFY OFPFC_MODIFY_STRICT OFPFC_DELETE OFPFC_DELETE_STRICT

Function

New flow Modify all matching flows Modify entry strictly matching wildcards and priority Delete all matching flows Delete entry strictly matching wildcards and priority 21

Group Table Modification Messages

• A group table consists of group entries. • The ability for a ﬂow entry to point to a group enables OpenFlow to represent additional methods of forwarding

Group mod command

OFPGC_ADD OFPGC_MODIFY OFPGC_DELETE

Function

New group Modify all matching groups Delete all matching groups 22

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

OFPMC_ADD OFPMC_MODIFY OFPMC_DELETE

Function

New meter Modify all specified meter Delete all specified meter 23

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.

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

Extended Maximizing Unavailability Interval (eMUI): Maximizing

Transcript Extended Maximizing Unavailability Interval (eMUI): Maximizing

OpenFlow Switch Specification v1.3.0 – OpenFlow Channel

指導教授：王國禎 學生：詹益晨 國立交通大學資訊工程系 行動計算與寬頻網路實驗室

Outline

Outline

Introduction

Related Work

Message Type

Message Type

Message Handling

Message Handling

OpenFlow Channel Connections

Connection Setup

Connection Interruption

Encryption

Multiple Controllers

Multiple Controllers

Multiple Controllers

Auxiliary Connections

Auxiliary Connections

Auxiliary Connections

Auxiliary Connections

Flow Table Modification Messages

Group Table Modification Messages

Meter Modification Messages

Conclusions

References

Thank you!

Directory

指導教授：王國禎學生：詹益晨國立交通大學資訊工程系行動計算與寬頻網路實驗室