-
Notifications
You must be signed in to change notification settings - Fork 192
Connection Features
Network control protocols must be designed with scalability and high availability in mind. Node failures and high traffic loads may cause frustration for early adopters of new technologies, as these two important points are not usually considered by initial versions. Previous OpenFlow versions fall into this category of protocols, often criticized by the lack of mechanisms to handle control plane issues.
The newer OpenFlow versions try to address control plane scalability and high availability with the addition of new features for OpenFlow connections. Auxiliary connections allow higher scalability for message exchanging, while controller roles try to enable fast failover for OpenFlow controllers. Event filtering, in turn, may be seen as a mechanism that sum up on these two topics. In the next subsections we will see a more detailed description of each feature and how they have been implemented in our software switch.
Auxiliary connections allow a controller to create more than one Communication Channel with a single switch. These connections add the possibility to exploit message parallelism and create a channel for specific types of messages. For instance, a controller can use one connection only for packet-in messages.
As a proof-of-concep, the switch has implemented basic support for auxiliary connections. In our implementation, there is support for only one additional channel and it only carries packet-in messages. The following items show steps added in the switch code to handle auxiliary connection.
-
The software switch sends OpenFlow messages for the Communication Channel, encapsulated into a struct called ofbuf. The struct is a buffer that holds information such as the pointer for the first allocated byte and the size of bytes in use. In order to identify which connection is being used to receive or send the message, we have added a new member called conn_id. The possible values for conn_id are MAIN_CONNECTION and PTIN_CONNECTION.
-
A new connection listener was added to the Datapath. If an auxiliary connection is specified when running the datapath, the auxiliary listener is opened after the main connection listener.
-
When the Datapath talks to remotes, it searches for the auxiliary connection. If the connection exists, it processes messages received by the connection.
-
On sending OpenFlow messages, the switch by default maps to the MAIN_CONNECTION. If the message is a reply from a sent message of a sender connection, the connection id is set to the same id used by the sender. In the last case, if the message type is a packet-in, the switch uses PTIN_CONNECTION for the connection id.
The start of an auxiliary connection from one controller is disabled by default in our software switch standard program execution. To enable auxiliary connections a user should specify the multiconn option in the command line option.
Controller Role is a mechanism to permit connection of multiple controllers with different duties. One of the possible use cases of roles is for fast failover, in which when the main controller goes down, a backup controller assumes the switch command. There are three possible roles for controllers: Master, Slave and Equal. A master controller has permissions to send and receive any type of OpenFlow messages. Slaves have very strict default permissions, allowed only to receive a specific set of messages. The last role, Equal, is the default role when a controller connects to the switch and the other controllers connected do not have a defined role.
Role election is totally driven by the control plane, though some additional code is required for the switch. In order to implement controller role support in our software switch we first filtered asynchronous messages received by Slave controllers. Then we restricted slaves to send only read state messages, for example, flow stats and table stats. The last insertion is the algorithm defined by the specification to handle the role request generation_id. Messages with a generation id smaller than previous generation ids seen by the switch are discarded. The code below presents the function that implements the algorithm.
static ofl_err
dp_check_generation_id(struct datapath *dp, uint64_t new_gen_id){
if(dp->generation_id >= 0 && ((uint64_t)(new_gen_id - dp->generation_id) < 0) )
return ofl_error(OFPET_ROLE_REQUEST_FAILED, OFPRRFC_STALE);
else dp->generation_id = new_gen_id;
return 0;
}Event Filtering enables controllers to filter undesired asynchronous messages, sent by the switch. Filtering of asynchronous messages is possible for three types: port status, packet-in and flow removed. In addition, a controller can also choose to not receive these message types for the generation reason. For example, a packet-in can be generated by an action to output the packet for the controller. This feature, along with auxiliary connections, gives power for controllers to create exclusive message channels.
Message filtering is handled by the Datapath. On a set async request, the Datapath sets the controller remote channel with bitmap values sent in the message defined by the OpenFlow 1.3 specification, shown on Listing \ref{asyncmessage}. Each bit set in the bitmap represents a message type and a reason. For instance, a bit with value 4 in flow_removed_mask[0], determines if the controller will receive flow removed messages with reason OFPRR_DELETE when the role is Master.
Filtering happens before the sending of an OpenFlow message. The Datapath function to send an OpenFlow buffer through the Communication Channel checks the remote configuration and the type of message to be sent. If it is one of the three asynchronous messages and the reason and the controller roles matches the remote filtering configuration, the message is dropped.
/* Asynchronous message configuration. */
struct ofp_async_config {
struct ofp_header header;
/* OFPT_GET_ASYNC_REPLY or OFPT_SET_ASYNC. */
uint32_t packet_in_mask[2];
/* Bitmasks of OFPR_* values. */
uint32_t port_status_mask[2]; /* Bitmasks of OFPPR_* values. */
uint32_t flow_removed_mask[2];/* Bitmasks of OFPRR_* values. */
};
OFP_ASSERT(sizeof(struct ofp_async_config) == 32);