Apart from the main connection, a switch can initiate one or more connections towards the controller to improve its processing performance and exploit the parallelism of most switch implementations. These connections are termed auxiliary connections. For auxiliary connections, the switch should assign the auxiliary ID value as a non-zero value and the Datapath ID the same as that of the main connection towards that controller.
To establish an auxiliary connection to the controller, the main connection between the switch and controller should have been successfully established.
The procedure to establish an auxiliary connection to a controller is similar to that of establishing a main connection to the controller which was explained in the first recipe of this chapter. The IP address of the controller used by the switch to establish an auxiliary connection should be the same as that of the main connection. However auxiliary connections are not restricted to use the same transport protocols as those of the main connection. Depending on the configuration, the switch can use TCP, TLS, UDP or DTLS to establish auxiliary connections. When a switch detects that the main connection to a controller is closed or broken, it must close all its auxiliary connections to that controller immediately.
The switch must accept any OpenFlow message types and sub-types on any connections. The main connection or an auxiliary connection cannot be restricted to a specific message type or sub-type. However, the processing performance of different connections may be different. The switch may choose to process the different auxiliary connections with different priorities; for example, one auxiliary connection may be dedicated to high priority requests and another may be dedicated to lower priority requests.
The OpenFlow specification provides some guidelines for sending and receiving messages in main and auxiliary connections, as follows:
- All OpenFlow messages which are not Packet in should be sent over the main connection.
- A Mechanism should be provided in the switch to keep track of the packet of the same flow mapped to the same connection, when there are multiple auxiliary connections between the switch and controller.
- An OpenFlow switch which uses an unreliable auxiliary connection should follow recommendations specified in RFC 5405 wherever it is required. RFC 5405 provides guidelines on the usage of UDP protocol such as congestion control, message sizes, reliability, checksums, and middle box traversal, etc.
- If the auxiliary connection from the switch is established in unreliable transport protocols like UDP and DTLS, then only the following message type should be supported to send /receive in an auxiliary connection:
OFPT_HELLO OFPT_ERROR OFPT_ECHO_REQUEST OFPT_ECHO_REPLY OFPT_FEATURES_REQUEST OFPT_FEATURES_REPLY OFPT_PACKET_IN OFPT_PACKET_OUT OFPT_EXPERIMENTER
Support to send and receive other message types should not be provided
- After establishing the auxiliary connection over unreliable transport protocols, if the switch receives a first message other than
OFPT_HELLOthen the switch should either:- Assume the connection is set up properly and use the version number from that message or it must return an error message of the
OFPET_BAD_REQUESTtype with the code asOFPBRC_BAD_VERSION.
- Assume the connection is set up properly and use the version number from that message or it must return an error message of the
- If the OpenFlow switch receives an error message with the error type
OFPET_BAD_REQUESTand the codeOFPBRC_BAD_VERSIONon an unreliable auxiliary connection, then it must either send a new Hello message or terminate the unreliable auxiliary connection. - If the switch doesn't receive any message on an auxiliary connection after a chosen amount of time lower than 5 seconds, the switch must either send a new
Hellomessage or terminate the unreliable auxiliary connection.
- For more information about establishing the main connection to the controller, refer to the Connection setup on TCP and TLS recipe of Chapter 1, OpenFlow Channel Connection Establishment (Part 2)