Software-defined Networking (SDN) is a network paradigm based on four pil- lars: i) decoupling of control and data plane, ii) flows as a key concept for packet forwarding, iii) control logic is moved outside the forwarding devices, and iv) programmability of the network.
Figure 10: Major components of an OpenFlow-supporting network
The first pillar is the decoupling of the control logic from network devices. Hence, Decoupled control and data plane SDN assumes networking devices to be pure forwarding devices without own local
control logic at the devices. To this end, the data plane has to offer a standardized interface to allow receiving control signals from an external controller. One of the most popular standardized interfaces nowadays is OpenFlow.
Traditional network devices make forwarding decisions on a per-packet basis. In Flow-based packet forwarding contrast to this, SDN uses the flow concept for packet forwarding decisions. Here,
2.5 software-defined networking 31
or value ranges. All packets matching a flow can be applied to one or a set of ac- tions, e.g., to forward it to a specific port, rewrite protocol fields, or drop the packet. Two exemplary actions are packet duplication and replacement of the destination IP address.
The control plane consists of one or more SDN controllers, i.e., a software that may run on commodity hardware. The controller communicates with the SDN-enabled switches by its southbound API, while providing access to NetApps, i.e., control
applications by its northbound API. The actual network logic resides in the control External control logic applications which use well-defined abstractions and primitives offered by the con-
troller. Therefore, the controller has to translate these commands to the respective SDN flow entries and implement them in the involved SDN switches. Furthermore, the controller takes care of security tasks such as NetApp isolation, deciding how to handle previously unseen flows, and how to resolve conflicts between NetApps.
By doing so, the network becomes programmable. Foremost, network applications have two benefits. First, they lower the costs of network management as the network Pro-
grammable network can be controlled in a standardized and automatic fashion. Second, standardized
programming interfaces allow for innovative network applications, abstracting from different vendors and hardware, thereby allowing innovative network software that would be hard to realize without SDN.
2.5.1 OpenFlow
The OpenFlow protocol is the most popular implementation of the SDN paradigm. The following section is based on the OpenFlow protocol specification [Ope15] stan- dardized by the Open Networking Foundation (ONF). The core element of this spec- ification is an OpenFlow switch. However, the standard only presents concepts and ideas but does not provide information on how to implement them.
Figure 11: Conceptual components of an OpenFlow flow entry
Simplified, an OpenFlow switch contains a number of flow tables and network ports. A flow table contains flow entries which are set by the OpenFlow controller and define how incoming packets are handled. Figure 11 provides a conceptual overview of an SDN flow entry. Each flow consists of three components: a matcher, an instruction, and statistic counters. The controller can install these entries, modify them later on, and read their statistic counters by communicating via the OpenFlow
2.6 multi-mechanisms transitions 32
protocol with the switch. Upon incoming packets, an OpenFlow switch tries to find a matching flow entry by comparing the packets’ header field with the flow entries in its flow tables. If a matching flow entry is found, one or several actions are applied to the packet, e.g., forwarding it to a specific port, modifying its header fields or drop- ping it. OpenFlow has evolved considerably between the first version 1.0 [Ope09] and its current version 1.5.1 [Ope15]. While in version 1.0 only a single flow table per switch exists and the set of actions and instructions are limited, OpenFlow 1.5.1 offers plenty of features and performance improvements. For example, multiple con- catenated flow tables and group tables allow storing flow entries much more efficient than a single flow table. Additionally, a richer set of matchers and more actions are available.
2.5.2 SDN in Hardware
It is crucial to guarantee a packet forwarding performance close to line speed and not to slow down the forwarding process by OpenFlow unnecessarily. Thus, a fast and efficient technique is required to match, process, and forward packets to deter- mine if they belong to a particular flow. In today’s SDN-enabled hardware switches, fast packet matching is allowed by Content-Addressable Memory (CAM). This spe- cial memory allows using arbitrary addresses to access memory, a concept similar to HashMaps known from programming languages. If a packet has to be matched, all memory entries are searched within one clock cycle and the result is returned [ACS03]. While CAM allows a lookup in constant time, inserting new data is comparably slow, similar to HashMaps. Hence, using CAM is avoided in case of the flow statistic counters, which are instead stored in the switch’s Static Random-Access Memory. CAM has an additional disadvantage as it allows only for exact matching but not partial matching. Therefore, tasks like matching a subnet that includes wildcards are not possible. Therefore, modern SDN switches store their flow tables in Ternary Content-Addressable Memory (TCAM) which allows setting specific parts of a key as "don’t care" values, which allows partial key matching. At present, optimizing TCAM memory usage, energy consumption, and manufacturing costs are on-going research challenges [ACS03].
2.6 m u lt i-mechanisms transitions
The concept of multi-mechanism transition used in this thesis is taken from the defini- tion provided by the members of the Collaborative Research Centre "MAKI"8
[Ric17;
Wik16; SHK+15; FHK+16]. Transitions are a paradigm adapting a communication
system’s service or protocol components. Hence, a group of protocols or services that offer the same functionality is required. This group, offering exchangeable func- tionality, is denoted as a multi-mechanism [Wik16]. The transition between these mechanisms is initiated by a context change which can be, e.g., varying bandwidth, changing requirements, or different QoE needs and aims at a stable system perfor- mance. To this end, the mechanisms which perform best for a given context is chosen. The performance can be for example the user-perceived QoE, fairness, or service sta- bility. However, costs must also be taken into account when selecting the optimal
8
2.6 multi-mechanisms transitions 33
mechanism. Thereby, costs depend on the application scenario, available resources, and environmental constraints. If the environment changes often and rapidly, the mechanism transition may not pay off and be kept constant to avoid continuous and potentially costly oscillations between mechanisms and their potentially high costs. In the scope of this thesis, transitions occur in the exchange of predictive models in the scope of Prefetching systems (ref. Section 4) and when considering different proactive caching mechanisms in the presence of varying cache storage sizes (ref. Section 5).
3
R E L AT E D W O R K