To establish a communication channel with the controller, the user should configure the IP address, port number (optional) and the transport protocol (TCP/TLS) of the controller.The switch should provide a mechanism to configure these parameters via a standard Command-line Interface (CLI) or use a configuration file or other mechanism.

Based on the configured transport path protocol the switch should follow either the TCP procedure or the TLS procedure explained in this section for establishing connectivity to the controller.

struct sockaddr_in controller_address;
memset(&controller_address, '0', sizeof(controller_address));
controller_address.sin_family = AF_INET;
controller_address.sin_addr.s_addr = inet_addr("10.0.0.10");
controller_address.port = htons(6653);
if (socket (AF_INET, SOCK_STREAM, 0) < 0)
    {
        printf("\n Error : Could not create socket \n");
        return 1;
    }
if ((connect (s, (struct sockaddr*)&controller_address, sizeof(controller_address)) < 0))
    {
       printf("\n Error : Connect Failed \n");
       return 1;
    }

  //Register the error strings libssl SSL_load_error_strings ();
   // Register the available ciphers and digests SSL_library_init ();
  // New context with mode as client and version as SSL 2 or 3sslContext = SSL_CTX_new (SSLv23_client_method ());
  if (sslContext == NULL)
    {
      printf("\n Error: Could not create SSL context\n");
        return 1;
    }

  // Create a new SSL struct sslHandle = SSL_new (sslContext);
    if (sslHandle == NULL)
      {
        printf("\n Error: Could not create SSL handle\n");
          return 1;
      }
  // Bind the SSL struct to the TCP connection if (!SSL_set_fd (sslHandle, socket))
      {
        printf("\n Error: Could not set socket \n");
          return 1;
      }
  // Initiate SSL handshake
    if (SSL_connect (sslHandle) != 1)
      {
        printf("\n Error: Could not connect using SSL\n");
          return 1;
      }

When the connection between the switch and controller is first established, either side of the connection must immediately send the hello message. The procedure to send and receive the hello message is explained in detail in Sending and processing hello message recipe of Chapter 2, Symmetric Messages and Asynchronous Messages.

The OpenFlow specification doesn't mandate any failure handling while establishing the communication channel. However it is recommended for the switch to re-initiate the connection periodically until the connection is successful. If the switch is unable to establish a connection with any of the configured controllers and the switch is a hybrid switch, thenthe switch can operate in non-openflow mode until the connection to any one of the controllers is successful.

During the initialization of the OpenFlow switch, it should initiate a connection to all the configured controllers and should maintain the connectivity to all the controllers concurrently. The procedure to establish an OpenFlow communication channel to multiple controllers is similar to that of establishing a connection to a single controller as was explained in the Connection setup on TCP & TLS recipe. However, as the switch has to process requests concurrently from multiple controllers, the switch could employ mechanisms to read and process the message from multiple channels. This can be done, either by having different threads or different processes, each handling requests from multiple controllers, or should use some of the constructs provided by the operating system such as the select() system call.

In a steady state, the switch should be able to send asynchronous message to all controllers through the channels associated with the controller. Similarly, the switch should be able to process the OpenFlow request message from any of the connected controllers. When a switch receives the OpenFlow request message from any one of the controllers, the switch should send the response only to the channel which is associated with that controller.

The OpenFlow specification doesn't mandate any failure handling while establishing the communication channel. However, it is recommended for the switch to try to re-initiate the connection periodically until the connection is successful.

The message format used by the controller to send OFPT_ROLE_REQUEST messages is defined in the Setting the role of a controller's communication channel recipe in Chapter 1, OpenFlow Channel Connection Establishment (Part 2). The switch should use the same message format for sending the reply message back to the controller.

If the role requested from the controller is master or slave, then the switch must validate the generation_id to check for stale messages. This is required because, if the stale messages are processed by the switch, then there is a possibility of one or more controllers and the switch might be out of sync with respect to the role.

Once the switch receives a role request message, it must return an OFPT_ROLE_REPLY message, if there is no error encountered while processing this role request message. The structure of this reply message is exactly same as the OFPT_ROLE_REQUEST message.

The field role should be set with the current role of the controller.

The field generation_id should be set to the current generation_id (the generation_id associated with the last successful role request). If the current generation_id was never set, the generation_id in the reply must be set to the maximum field value (the unsigned equivalent of -1).

If the validation of generation_id fails, the switch must discard the role request message and return an error message with type OFPET_ROLE_REQUEST_FAILED and the code as OFPRRFC_STALE.

The procedure to handle a role request message from the controller is as follows:

handle_role_request_message (struct ofp_role_request role_request) {
  struct ofp_role_request role_reply;
  /* pseudo-code to validate the generation_id. Here the
   * generation_is_defined and cached_generation_id are global
   * variables */
  if (generation_is_defined && (int64_t)
     (role_request.generation_id - cached_generation_id) < 0)
  {
     send_error_message(OFPET_ROLE_REQUEST_FAILED, OFPRRFC_STALE);
  }
  else
  {
     cached_generation_id = role_request.generation_id;
     generation_is_defined = true;
    /* Here connection is the connection data structure which is
   * maintained by the switch */
     connection.role = role_request.role;
     role_reply.role = role_request.role;
     role_reply.generation_id = cached_generation_id;
     send_openflow_message (connection, role_reply);
  }
}

The procedure to send error messages is explained in the Setting the role of a controller's communication channel recipe in Chapter 1, OpenFlow Channel Connection Establishment (Part 2).

If the requested role is OFPCR_ROLE_MASTER, then the switch should change the role of the existing master controller to OFPCR_ROLE_EQUAL.

If the requested role is OFPCR_ROLE_SLAVE and after successfully setting the role of this communication channel as a slave in the switch, the switch:

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:

To get the features supported by switch, the communication channel between the switch and controller should have been successfully established.

On reception of OFPT_FEATURES_REQUEST, the switch should prepare an OFPT_FEATURES_REPLY message and send the reply message to the controller.

The OFPT_FEATURES_REQUEST message sent from the controller doesn't contain any body other than the OpenFlow header which is defined in the OpenFlow Header section of the Appendix.

The format of OFPT_FEATURES_REPLY is as follows:

/* Switch features. */
struct ofp_switch_features {
struct ofp_header header;
uint64_t datapath_id; /* Datapath unique ID. The lower 48-bits are for a MAC address, while the upper 16-bits are implementer-defined. */
uint32_t n_buffers;  /* Max packets buffered at once. */
uint8_t n_tables;    /* Number of tables supported by datapath. */
uint8_t auxiliary_id;/* Identify auxiliary connections */
uint8_t pad[2];      /* Align to 64-bits. */
        /* Features. */
uint32_t capabilities; /* Bitmap of support "ofp_capabilities". */
uint32_t reserved;
};

Let's see the brief description of the image:

Based on the capability of the switch, it should set the bitmap with the following flag values:

/* Capabilities supported by the datapath. */
enum ofp_capabilities {
OFPC_FLOW_STATS = 1 << 0,    /* Value 1. Flow statistics. */
OFPC_TABLE_STATS = 1 << 1,   /* Value 2. Table statistics. */
OFPC_PORT_STATS = 1 << 2,    /* Value 4. Port statistics. */
OFPC_GROUP_STATS = 1 << 3,   /* Value 8. Group statistics. */
OFPC_IP_REASM = 1 << 5,      /* Value 16. Can reassemble IP fragments. */
OFPC_QUEUE_STATS = 1 << 6,   /* Value 32. Queue statistics. */
OFPC_PORT_BLOCKED = 1 << 8   /* Value 64. Switch will block looping ports. */
};

The procedure to handle the feature request message is as follows:

handle_features_request_message (struct ofp_header features_request)
{
  struct ofp_switch_features features_reply;
  features_reply.datapath_id = htonnl(datapath_id);
  features_reply.n_buffers = htonl(buffer_size);
  features_reply.n_tables = supported_no_of_flow_tables;
  features_reply.capabilities = htonl (OFPC_FLOW_STATS | OFPC_TABLE_STATS);
  features_reply.auxiliary_id = 0; /* Assuming main connection */
  send_openflow_message (connection, features_reply);
  /* The send_openflow_message function adds the OF header */
}

On reception of an OFPT_GET_CONFIG_REQUEST message, the switch should prepare an OFPT_GET_CONFIG_REPLY message and send it to the controller.

The OFPT_GET_CONFIG_REQUEST message doesn't contain a body other than an OpenFlow header which is defined in the OpenFlow Header section of the Appendix.

The OFPT_GET_CONFIG_REPLY message uses the following message format:

/* Switch configuration. */
struct ofp_switch_config {
struct ofp_header header;
uint16_t flags;           /* Bitmap of OFPC_* flags. */
uint16_t miss_send_len;   /* Max bytes of packet that datapath
                             should send to the controller.*/
};

The flags take the value as:

enum ofp_config_flags {
/* Handling of IP fragments. */
OFPC_FRAG_NORMAL = 0,     /* No special handling for fragments. */
OFPC_FRAG_DROP = 1 << 0,  /* Drop fragments. */
OFPC_FRAG_REASM = 1 << 1, /* Reassemble (only if OFPC_IP_REASM set). */
OFPC_FRAG_MASK = 3,
};

The value in miss_send_len should be set to the switch's current maximum bytes of data that will be sent to the controller while sending buffered packets. By default this value is 128 bits.

The flag value should be set to the configured value of the IP fragment detail.

On reception of OFPT_SET_CONFIG, which has the same message format as that of OFPT_GET_CONFIG_REPLY, the switch should set the value of miss_send_len and IP fragment related details.

The procedure to handle OFPT_GET_CONFIG_REQUEST is as follows;

handle_get_config_message (struct ofp_header get_config_request)
{
  struct ofp_switch_config config_reply;
  features_reply.flags = htons(supported_flags);
  features_reply.miss_send_len = 128; /* default value */
  send_openflow_message (connection, config_reply);
  /* The send_openflow_message function adds the OF header */
}

If a switch loses its connection with all the connected or configured controllers, then the switch should immediately enter either fail secure mode or fail standalone mode depending upon the switch configuration or implementation. The connection loss can be identified by either OpenFlow echo request timeouts or TLS session timeouts or other disconnection procedures such as TCP socket close, etc.

When the switch is in fail secure mode, the switch should drop all the packets and messages destined to controllers. However, all the flow entries programmed by the controller should persist in the switch and expire based on the configured timeout value in fail secure mode.

The fail standalone mode is usually possible only on Hybrid switches. When a switch is in fail standalone mode, the switch should act as a legacy Ethernet switch or router and should process all the packets.

Upon connecting to a controller again, the existing flow entries remain intact. The controller can delete all the existing flow entries, if desired. The switch can be configured to start up with the operational mode either as fail secure mode or fail standalone mode until it successfully connects to a controller.