Extended Maximizing Unavailability Interval (eMUI): Maximizing

download report

Transcript Extended Maximizing Unavailability Interval (eMUI): Maximizing

OpenFlow Switch Specification v1.3.0 – OpenFlow Channel

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

1

Copyright © 2012, [email protected]

Outline

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

Copyright © 2012, [email protected]

2

Outline

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

Copyright © 2012, [email protected]

3

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, [email protected]

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

Copyright © 2012, [email protected] v1.3.0

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.

6

Copyright © 2012, [email protected]

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

Copyright © 2012, [email protected]

7

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, [email protected]

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, [email protected]

OpenFlow Channel Connections

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

Copyright © 2012, [email protected]

10

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.

11

Copyright © 2012, [email protected]

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, [email protected]

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]

13

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, [email protected]

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.

15

Copyright © 2012, [email protected]

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, [email protected]

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, [email protected]

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, [email protected]

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.

19

Copyright © 2012, [email protected]

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, [email protected]

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

Copyright © 2012, [email protected]

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

OFPGC_ADD OFPGC_MODIFY OFPGC_DELETE

Function

New group Modify all matching groups Delete all matching groups 22

Copyright © 2012, [email protected]

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

Copyright © 2012, [email protected]

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, [email protected]

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

Copyright © 2012, [email protected]

25

Thank you!

Copyright © 2012, [email protected]

26