4.4 Virtualizing the Addition of Flow Table Entries
4.4.2 Virtualizer Design
The goal of the virtualizer is to provide prioritization and fairness for adding entries to flow tables with unpredictable addition performance, such as TCAM-based flow tables.
Furthermore, the virtualizer operates on a distributed system, with the resource being located on a data plane element and being controlled by an SDN controller on a different device.
The unpredictable flow entry addition rate limits the design space for these goals.
Well-proven approaches that involve modeling a static flow addition rate suggested, e.g., by Bozakov and Rizk [BR13] and Blenk et al. [BBK15] for similar problems cannot be used to provide prioritization in this scenario. With performance modeling not being applicable, we conclude that a feedback mechanism is required for the OpenFlow switch to provide information to the controller, which flow entries have been already installed.
This leaves queueing approaches as a well understood and matching design approach to tackling the issue.
An overview of an SDN message queueing system and its main components are given in Figure4.16. The two main components are the queue manager and the scheduling algorithm. The queue manager decides in which queue a new work item should be placed. The scheduler decides which queue should be serviced next and how much service it should get.
Before discussing the design of the solution for the distributed queueing system, we characterize the queueing and scheduling problem at hand:
• One bottleneck resource: the TCAM
• No preemption: once the flow entry addition process has been started, it cannot be interrupted
• Variable execution times: the time it takes to add flow entries is not static
• The bottleneck resource control operates on the OpenFlow switch and the scheduler operates on the OpenFlow controller
• Strict priority scheduling and fairness for equal priority is required
• Flow entry message must not be lost or dropped
As depicted in Figure4.17, one or more flow tables are available in the ASIC. For this investigation, all resources that are not relevant are left out to ensure readability.
The controller must keep track of the flow entries that have been sent to the OpenFlow switch and wait for each of them to be reported as installed by the switch. Using a queue management approach, the controller can schedule the application requests either for fairness or prioritization. Each hardware flow table is represented by a set of queues and a scheduler. The controller analyzes each flow entry addition requests from the applications to determine which hardware flow table they will be added to. Then, according to the priority of the application, the request is added to one of the queues of the corresponding flow table. For each table, a scheduler then decides which queue to service next, depending on the feedback information from the switch. The approach is depicted in Figure4.17. The priorities are depicted in red for high priority, orange for mid priority, and green for low priority. The applications themselves can assign different priorities to their messages. These are combined with the application’s priority to determine the actual per-flow table priority.
The most straightforward approach is to order the OpenFlow messages by their prioritization and send them to the data plane device that processes them in a first in, first
Queue management
algorithm
Enqueue-end
c messages/s
Dequeue-end
Per data plane resource Scheduling
algorithm SDN protocol
message queue
Messages from control plane
applications
Figure 4.16: Overview over an SDN message queueing system and its terminology (adapted from [AHA16]).
4.4 ������������ ��� �������� �� ���� ����� ������� 71
NW_DST: 10.0.0.0/8 NW_DST: 172.16.0.0/12 NW_DST: 192.168.0.0/16 NW_DST: 0.0.0.0/0 Prio: 1
Prio: 5 Prio: 5 Prio: 5
Out: None Out: P1 Out: Ctrl Out: P2 Out: P3
Memory Interface Flow Table 1
NW_DST: 10.0.0.0/8 NW_DST: 172.16.0.0/12 NW_DST: 192.168.0.0/16 NW_DST: 0.0.0.0/0 Prio: 1
Prio: 5 Prio: 5 Prio: 5
Out: None Out: P1 Out: Ctrl Out: P2 Out: P3
Memory Interface Flow Table n
…
Add Entry Add Entry
Add Entry Add Entry
Add
Entry Add
Entry Add Entry Add Entry Add
Entry
Application 1 Application 2
Add Entry Add Entry
Add Entry
Add Entry Add Entry
Add Entry
Switch 1 Controller
Add Entry Add Entry
Add Entry Add Entry
Add Entry Add
Entry Add Entry
Add Entry Add Entry
Add Entry Add
Entry Add Entry
Add Entry Add Entry
Add Entry
Scheduler Controller
Scheduler Scheduler
Scheduler Controller
Add Entry
Add Entry Add Entry Add
Entry
Virtual Queues Virtual Queues Queue Manager Low Priority High Priority
Completion Feedback Scheduler Control
Figure 4.17: Design model for flow_mod virtualization with prioritization (adapted from [Vil18]).
out (FIFO) order. Unfortunately, the OpenFlow standard specifies that the processing of OpenFlow messages does not have to occur in FIFO order; „hence, controllers should not depend on a specific processing order“. Using a priority queue on the data plane device and tagging OpenFlow messages accordingly provides prioritization but provides the controller little control and feedback over the process. If the waiting times caused by the queueing become too long, the controller has no option to remove requests from low priority queues and provide information to the application. The same is true if requests are dropped from the queue, providing information on that to the applications becomes difficult for the controller. Another approach would be to implement a Transmission Control Protocol (TCP)-like end-to-end flow control mechanism with prioritization between the controller and each resource. While this approach is promising as well, it requires a significant redesign of the OpenFlow agent on the data plane devices.
However, this is not possible with existing OpenFlow agents of available hardware devices, because of their proprietary nature. Furthermore, the TCP connection used
to transport the OpenFlow protocol would have to be replaced by one that supports multiple independent streams, such as Stream Control Transmission Protocol (SCTP).
One problem is that OpenFlow does not provide a primitive to monitor or control the hardware flow tables in the ASIC directly from the controller. Instead, the OpenFlow model presents the available matching memory as a pipeline of flow tables, independent of how the hardware looks like. Furthermore, OpenFlow does not provide any primitive to get information on the processing of OpenFlow messages inside of the switch. Two OpenFlow primitives exist to get information on the state of the processing of OpenFlow message:
• barriers, available from OpenFlow version 0.9
• bundles, available from OpenFlow version 1.4
The barrier command should ensure that all OpenFlow messages that the switch received before the barrier_request message have been completely processed before the barrier_reply is sent. Unfortunately, since this command includes all OpenFlow messages, it cannot be used to track flow entry addition operations for a specific hardware flow table only. Therefore, it cannot be used. The flow bundle feature, however, is more interesting. It was designed to improve the synchronization of flow table modifications by providing a primitive to defined groups of OpenFlow messages that are executed at the same time. Bundles are opened by sending the corresponding message including an id to the switch. Then, the controller can add arbitrary OpenFlow messages to the bundle until it decides to close it. Another advantage is that the messages are already validated when they are added to the bundle, which reduces the processing time later.
After that point in time, the bundle can be committed or discarded. If it is committed, the switch will reply with a bundle_commit_reply message that indicates if all messages in the bundle have been committed successfully.
The ability to open multiple flow bundles in parallel, commit them independently from each other, and get an acknowledgment for each of them means that this feature could be used to implement queuing control on an OpenFlow switch per hardware flow table.
The disadvantage, however, is that when flow bundles are used to implement queuing for flow entry additions, control plane applications and OpenFlow controllers that use the flow bundles feature already for other purposes cannot be supported. Furthermore, the order of the processing of the OpenFlow message processing could be changed by the separation of flow entry additions from the other messages. However, the goal of this design is to show the usefulness and possibility of control path virtualization in SDN protocols, not to fix all shortcomings of OpenFlow. Since using flow bundles is the only available way to implement this feature on an actual hardware switch, we will proceed with this design.
A priority round robin scheduler is used on the OpenFlow controller inspired by the work of Tsao and Lin [TL01]. The quantum of the scheduler, which is the part of work assigned to each queue per time interval, e.g., the number of transmitted bytes for packet
4.4 ������������ ��� �������� �� ���� ����� ������� 73
schedulers is defined differently for this use case. As discussed before, the processing times per flow entry addition are dynamic. Therefore, we need to share the time used per application instead of the number of executed flow entry additions. Therefore, we assign time slots directly to the queues, by specifying the quantum in milliseconds.
Since preemption is not possible the quantum size has a significant influence on the granularity of control. Once the assigned service quantum is consumed by a queue the next queue with the same priority is selected. The scheduler keeps at least one flow bundle open per hardware flow table on the OpenFlow switch. New flow_mod messages are, after determining their destination hardware flow table, placed in a queue on the controller and added to one of the corresponding flow bundles on the switch by the queue management algorithm. The scheduler selects the next queue to service, commits the next bundle, and determines, based on the time slice used by the queue, which queue should be serviced next. Furthermore, the scheduler must wait for the bundle_commit_reply message before updating the time slice calculation.
Queues are selected by their priority to implement strict prioritization. This means that the set of queues that contain messages with the highest priority are always served until they are empty. Only then queues with lower priority are served as well. By ensuring that higher application always take precedence as required in ISP networks, this approach can lead to starvation of lower priority control plane application. The effects of starvation must be handled by each application individually, by implementing control path bottleneck mitigation approaches as discussed in Chapter5.
The flow entry addition scheduler was prototypically implemented using the Floodlight OpenFlow controller�. The focus of the prototype is the investigation of the system’s behavior in an overload event of the TCAM match table memory interface resource. The goal of the evaluation is to show if an SDN protocol feature like the flow bundle can provide the required functionality to implement a virtualizer. Only the parts need to support this use case are implemented.
The design of the prototypical implementation of the system reflects a queueing system design, except that it is event-driven due to the nature of OpenFlow controllers. The two main entities in the prototype implementation, like in most queueing systems, are the queue manager and the scheduler. The queue manager opens and closes flow bundle as well as assigns messages to queues and bundles. The scheduler is responsible for selecting the queue that should be serviced next and initiate the servicing by committing flow bundles. When a control plane application requests a flow entry addition, the queue manager checks if an open flow bundle is available for the addressed switch and flow table. In this experiment, flow bundles are created proactively when the switch connects to the controller to ensure that the flow bundle creation does not affect the scheduler performance. If an open flow bundle is available, the flow is added to that bundle. If the selected bundle has reached its maximum size, it is closed, and the scheduler is called.
9 Project Floodlight. Floodlight OpenFlow Controller. Accessed: 2018-09-12. url: http://www.
projectfloodlight.org/.
The scheduler calculates the queue that should be serviced next and commits its flow bundle. Once the switch reports back that the bundle has been committed successfully, the corresponding service time information is collected, and the scheduler is called again.
Though this approach, the queued messages for each resource are kept on the data plane device while the queue with references to these messages is kept on the controller.
Thereby, the controller has full knowledge of the queue lengths. The scheduler is kept on the controller and can modify, rearrange, or discard bundles at will. Furthermore, errors that happen while committing bundles are reported by corresponding OpenFlow protocol messages. Thereby, the requirements for virtualizing resources are met. Resource controllability is provided through controlling and committing bundles by the control plane. The information required to gain resource visibility: resource utilization, resource saturation, and resource errors are provided except for resource utilization. Resource saturation information is provided by the number of the outstanding flow addition entries.
Resource errors are provided through the OpenFlow protocol. However, gathering detailed information on the resource utilization of the TCAM match table memory interface resource requires a modification of the ASIC driver and the corresponding OpenFlow facilities to transport this information to the controller. Since we do not have access to the proprietary ASIC drivers, we rely on an estimation. The utilization of the resource can be estimated to be either 0% or 100% determined by the available saturation information.