OpenFlow Switch Specification v1.3.0 – OpenFlow Channel

1. OpenFlow Switch Specification v1.3.0 – OpenFlow Channel 指導教授：王國禎 學生：詹益晨 國立交通大學資訊工程系 行動計算與寬頻網路實驗室

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

3. Outline • Flow Table Modification Messages • Group Table Modification Messages • Meter Modification Messages • Conclusions • References

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.

5. Related Work

6. Message Type

7. Message Type

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.

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.

10. OpenFlow Channel Connections Connection Setup Connection Interruption Encryption Multiple Controllers Auxiliary Connections

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.

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.

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.

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.

15. Multiple Controllers Three roles of a controller

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.

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.

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.

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.

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.

21. Flow Table Modification Messages

22. 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

23. 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.

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.

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

26. Thank you!