Design, Implementation and Validation of a
Control Application for Load Balancing and Routing with
Security Constraints in SDN
SUPERVISOR:
Prof. Davide Adami
Prof. Michele Pagano
CANDIDATE:
QIANYING ZHAO
Software-defined networking (SDN) is a new networking paradigm that subverts the architecture of traditional networks, using data plane and control plane separation to achieve centralized control and programmability of the network.
In this thesis, by means of an SDN-based approach, we design, develop and test a control application to achieve network load balancing and routing with security constraints. For load balancing function, we propose a new policy for routing traffic flows according to links utilization, which takes advantage of traffic statistics provided by OpenFlow. For security routing function, we enable the control application with the capability of taking different countermeasures, such as traffic flows re-routing or blocking, when different attacks are detected.
The thesis includes relevant background knowledge, a description of several tools for designing and implementing this network control application, details about the implementation, and experimental validation of the developed functionalities.
Chapter 1 Introduction...1
Chapter 2 Software-Defined Networking and OpenFlow...3
2.1 SDN (Software-Defined Networking)...3
2.1.1 What is SDN?...3
2.1.2 Why SDN?...4
2.1.3 SDN architecture... 5
2.1.4 SDN’s advantages...7
2.1.5 SDN History...7
2.2 OpenFlow... 8
2.2.1 Comparison between different versions... 9
2.2.2 OpenFlow elements...9
2.2.3 OpenFlow communication process... 16
2.3 Summary... 17
Chapter 3 POX and Mininet...19
3.1 Control platform: POX...19
3.1.1 SDN Controllers...19
3.1.2 POX...20
3.2 Mininet... 24
3.2.1 Mininet’s advantages...24
3.2.2 Mininet's drawbacks...24
3.2.3 Mininet System Architecture...25
3.2.4 Mininet installation...26
3.3 Summary... 27
Chapter 4 Design and Implementation of the Control Application...29
4.1 Control Application... 29
4.1.1 Topology Discovery Module...30
4.1.2 Network Statistics Handler...32
4.1.3 Controller Logic... 35
4.1.4 Topology database...45
4.1.5 Flows database... 45
4.1.6 Attack detection component simulation... 46
4.1.7 Run the application...46
4.2 Topology...47
4.2.1 Routing domain... 47
4.2.2 Fat-Tree... 49
4.2.3 Run topology... 50
Chapter 5 Experiments... 51
5.1 Load-Balancing Tests... 51
5.1.2 Base_number in Routing Domain Topology...55
5.1.3 Random Tests in Routing Domain Topology... 58
5.1.4 Tests in Fat-Tree Topology...72
5.2 Tests with security constraints...82
5.2.1 Routing with security constraints tests in routing domain topology...82
5.2.2 Routing with security constraints tests in Fat-Tree topology...90
5.3 Summary... 98
Conclusions... 99
Appendix 1: Code...101
Appendix 2: Load of Each Link...141
Introduction
Since theirs birth to now, traditional IP networks have exerted their potential, widely exceeding original expectations. Meanwhile, IP networks have become more and more complicated, and now it seems they have reached a bottleneck.
In the last years, a new networking paradigm, Software-Defined Networking (SDN) appeared, revealing new, unknown, unexplored directions for the development of network services. Indeed, SDN through the separation of the data plane from the control plane, achieve centralized control and, most important, network programmability. The most well-known SDN southbound interface, OpenFlow [1], enables the communication between the data plane and a remote controller, where both control plane and applications reside.
This thesis aims at designing, implementing and validating a new application for an SDN controller that enables the network with load balancing and secure routing capabilities, i.e., forwarding traffic flows according to links utilization and adopting suitable countermeasures in case of physical or cyber- attacks addressed to the network infrastructure.
Basically, this means forwarding "allowed traffic", blocking or redirecting "malicious traffic", re-routing "allowed traffic" to avoid links or nodes under attack.
All these operations are performed considering current load of links and a custom designed load balancing policy. The detection of attacks is out of the scope of this thesis, therefore we suppose that the controller is part of a system that includes an attacks detection component.
More specifically, the ultimate goal of a load balancing strategy is to distribute the traffic generated by the hosts in the network "equally" across all the available links. In this case, the problem to be solved is how to determine which path is the path with the minimum load, in real time.
In traditional IP networks, the next forwarding device is determined by deploying the relevant routing protocols in each forwarding device. The features of these protocols are so easy to make that only some links are used all the time because they do not consider the changes in the utilization of the links.
In this thesis, we design a load balancing policy that makes the cost value of link dependent on its utilization, so the cost of each path will change with its load, and the link with low load will have higher priority to be selected.
For now, we want to emphasize the two key aspects of the load balancing policy: 1. Real-time estimation of the utilization of each link within the network;
2. Mapping of the link utilization to the link cost according to the actual situation and the requirements for network load balancing.
About routing with security constraints, the purpose is to apply different countermeasures when a physical or cyber attack occur and involves a portion of the network. Our approach can be summarized as follows:
When a link is under attack, the link is marked as unavailable in the topology and the flows affected by this event are rerouted also considering load balancing policy.
When a switch is under attack, both the switch and its connected links are marked as unavailable in the topology and the flows affected by this event are rerouted according to the load balancing policy.
When a malicious traffic flow is discovered, all the switches are notified that packet belonging to such traffic flow must be dropped.
The organization of this thesis is the following.
Chapter 2 introduces SDN technology and its most famous southbound interface, OpenFlow, respectively. For SDN, it includes its definition, the reasons it occurs, its architecture, its advantages. For OpenFlow, it deals with its main components and analyzes its communication process between the data plane and the control plane.
Chapter 3 describes some of the most important SDN controllers, focusing on the structure, installation and startup of POX. It also introduces Mininet’s advantage, drawbacks, architecture, installation and startup. POX is a controller adopted in this thesis, its structure is simple and it suitable for beginners in SDN. Mininet is a small and convenient network emulator, it is necessary in SDN’s experiments.
Chapter 4 introduces the design and implementation of our control application, including its architecture, the working process of its components and the idea at the basis of the load balancing policy. Also the topologies used in the tests are described.
Chapter 5 shows and discusses experimental results. It includes the results of the tests about the load balancing and routing with security constraints functions in two different scenarios. About the tests on load balancing, we assigned different values to two parameters of the load balancing policy, by Control variable method [2], to learn how the different parameters of the policy affect load balancing. Concerning routing with security constraints tests, we show the processing results when different attacks occur, and the time it takes to process these attacks.
Software-Defined Networking and OpenFlow
Software-Defined Networking (SDN) is a new network paradigm. Flexible control of network traffic is achieved by separating the control plane from the data plane. OpenFlow is the most important southbound interface of SDN. Both of them are the background of this thesis.
This chapter will introduce some brief knowledge about Software-Defined Networking and OpenFlow [19].
2.1 SDN (Software-Defined Networking)
This section will introduce what is SDN - the definition of SDN, the cause of the scientific community, the architecture of SDN, and what are benefits deriving from its use compared with traditional networks.
2.1.1 What is SDN?
Regarding the question of what SDN is, each organization gives different definition. Some people think that SDN is the separation of control plane and data plane, and some think that making the network programmable is SDN. Some of the most competent organizations/communities on the subject give the definition of SDN below:
OpenDaylight [3]:
Software Defined Networking (SDN) separates the control plane from the data plane within the network, allowing the intelligence and state of the network to be managed centrally while abstracting the complexity of the underlying physical network.
Open Networking Foundation [4]:
This architecture decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services.
SDNCentral [5]:
Software-defined Networking (SDN) is a new approach to design, build and manage networks. The basic concept is that SDN separates the network’s control (brain) and forwarding (muscle) planes to make it easier to optimize each of them.
SDN allows network administrators to manage network services through the abstraction of lower level functionalities. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane).
From the quotations above, we can summarize the three characteristics of SDN:
(1) Programmability: SDN has established a new network abstraction model, providing users with a complete set of common APIs, enabling users to program, implement, control and manage the network on the controller, thereby speeding up the process of network service deployment and innovation.
(2) Separation of control plane and data plane: Separation here refers to decoupling of the control plane and the data plane. The control plane and the data plane are no longer dependent on each other. They can complete the evolution of the architecture independently. The separation of the control plane and the data plane is an important indicator that the SDN architecture is different from the traditional network architecture. It is the architectural foundation for the network to gain more programmability.
(3) Centralized control: Mainly refers to centralized and unified management of distributed networks. In the SDN architecture, the controller collects and manages all network state information. Centralized control provides an architectural foundation for software-defined networking, and also provides for network automated management.
Therefore, a network that satisfies the above three characteristics can be called an SDN network. Among these three features, the separation of control plane and data plane creates conditions for logical centralized control. The centralized control logic provides the architectural foundation for open programmable control, and the open programming of network is the core feature of SDN. After knowing what SDN is, next part will explain why SDN is introduced.
2.1.2 Why SDN?
Today, with the rapid development of the networks, the traditional network paradigm is full of crises. There are four main problems:
• Deployment and management in traditional network are difficult. • Bottleneck of distributed architecture.
• Flow control is difficult to achieve. • The device is not programmable.
including social media, mobile devices, and cloud computing, traditional networks are pushed to their limits.
To solve this problem, SDN founder Professor Nick McKeown studied and compared the innovation model of the computer industry and the innovation model of the network industry. After analyzing the innovation model of the computer industry, he summed up the following three factors supporting its rapid innovation.
The computer industry has found a general-purpose, computation-oriented underlying hardware: a general-purpose processor that enables the functions of the computer can be implemented in a software-defined manner.
The software-defined way of computer functions brings more flexible programming capabilities, making the types of software applications explode.
The open source model of computer software has spawned a large amount of open source software, accelerated the process of software development, and promoted the rapid development of the entire computer industry. The Linux open source operating system is the best proof.
In contrast, the traditional network equipment is similar to the IBM mainframe in the 1960s. The network equipment hardware, operating system, and applications are tightly coupled to form a closed system. These three parts are interdependent, and usually belong to the same network equipment manufacturer. Each part of the innovation and evolution requires the rest to make the same upgrade. Such architecture hinders the development of network innovation severely. If the network industry can, like today's computer industry, possess the three basic elements: general-purpose hardware, software-defined functions, and open source models, it will certainly achieve faster innovation and eventually achieve unprecedented development like the computer industry. Under the influence of this idea, Professor McKeown's team proposed a new network architecture: SDN.
2.1.3 SDN architecture
In general, the SDN network architecture mainly includes: Application layer, Northbound interface, Control layer, Southbound interface, and Data layer (Infrastructure layer), as shown in Figure 2-1 [7]:
Figure 2-1: SDN Architecture
The SDN network application layer implements the corresponding network function application. These applications implement configuration, management, and control of network data plane devices through the northbound interface of the SDN controller.
The northbound interface is an open interface between the SDN controller and the network application, which provides a common open programming interface for SDN applications.
The SDN control layer is the brain of SDN, also known as the network operating system. The controller not only needs to provide different levels of programmability to the upper layer -network application through the northbound interface, but also configures, manages and controls the SDN data plane through the southbound programming interface uniformly.
In this layer, the controller acquires and maintains different types of network information, state details, topology details, statistical details, and so on.
Since the SDN controller is used to manage the network, it must have control logic for real-world network usage, such as switching, routing, Layer2 VPN, Layer3 VPN, firewall security rules, DNS, DHCP, etc. Vendors and open source communities need to implement their own services in their own SDN controller. These services expose their APIs to the upper layer - application layer (usually based on REST), allow network administrators to easily configure, manage, and monitor the network using the SDN controller on the application.
The southbound interface is an open interface between the SDN controller and the data plane. The SDN controller controls the data plane through the southbound interface to implement network behavior such as data plane forwarding.
international industry standard. NOX, Onix, and Floodlight are all open source controllers based on the OpenFlow control protocol.
The SDN data plane includes data plane devices which are implemented based on software and hardware. The data plane device receives instructions from the controller through the southbound interface and performs specific network data processing in accordance with these instructions. At the same time, the SDN data plane device can also feed back the network configuration and run-time status to the controller through the southbound interface.
2.1.4 SDN’s advantages
Compared with the traditional network paradigm, SDN has the following advantages [8]:
Provides the network structure: A unified view of the entire network architecture, simplifying configuration, management, and optimization.
Accelerates the introduction of new services: Network operators can deploy novel functions through software without having to wait for a device provider to add a solution to their proprietary device as before.
Reduces the error rate: By developing components that perform many network management tasks automatically to reduce instability due to configuration errors by operators and technicians.
Delivers Agility and Flexibility: Software-Defined Networking helps organizations rapidly deploy new applications, services, and infrastructure to meet changing business goals and objectives quickly.
Enables Innovation: SDN enables organizations to create new types of applications, services, and business models that can offer new revenue streams and more value from the network.
After the network in the traditional IT architecture is deployed according to business requirements, if the service requirements change, it is very cumbersome to reconfigure the corresponding network devices (routers, switches, firewalls). In the fast-changing business environment of the Internet/mobile Internet, flexibility and agility are more critical. What SDN does is to separate the control function from the network device, managed by a centralized controller, without relying on the underlying network devices (routers, switches, firewalls), shielding the differences from the underlying network devices. Control is completely open, and users can define any network routing and transport rule policies they want to implement, making them more flexible and intelligent.
2.1.5 SDN History
It has been several years since SDN’s birth, and SDN has achieved rapid development. The following section will introduce the major events that have occurred since SDN was proposed:
In 2006, Dr. Martin Casado [9] of the McKeown Group, implemented a network architecture SANE for enterprise network security - proposed a logically centralized enterprise security solution, on the basis of RCP and 4D network architecture.
In 2007, Martin Casado and others implemented the Ethane project for enterprise network management based on SANE. The paper attracted the attention of the academic community at the ACM SIGCOMM conference that year. Ethane is not only the prototype of the SDN architecture, but also the predecessor of OpenFlow. In the same year, Professor Nick McKeown, Professor Scott Shenker and Dr. Martin Casado founded Nicira Networks [10] in Silicon Valley, the first startup in SDN history.
In 2008, Nick McKeown, Scott Shenker, Larry Peterson and Professor Jennifer Rexford [11] of Princeton University published a paper introducing OpenFlow [12], marking the birth of OpenFlow. In the same year, The McKeown Group released the first open source SDN controller NOX-Classic [13].
In 2009, SDN was named one of the top 10 breakthrough technologies by MIT Technology View [14], marking the birth of SDN. In the same year, the OpenFlow 1.0 version was released, and OpenFlow began to enter the public view.
In 2011 ONF was established, ONF (Open Networking Foundation) is a non-profit organization dedicated to promoting SDN industrialization and standards. The birth of ONF marked that SDN is officially recognized by the industry. In the same year, ONS (Open Networking Summit) [15] was established to promote the promotion of SDN applications and deployment cases, and ONRC (Open Network Research Center) is established in the same year.
In 2012 was an important turning point in the history of SDN development. Google released the SDN application case, which is the first SDN commercial deployment case. In the same year, VMware's acquisition of Nicira [16], triggered widespread industry attention to SDN.
In 2013, the Linux Foundation teamed up with Cisco, IBM, Intel and other traditional IT vendors to create the open source project OpenDaylight, with the goal of launching a common enterprise-class SDN control platform, marking the approval of traditional giants for SDN.
In 2014, P4 [17] was released, creating a precedent for data plane programming.
These landmark times constitute a history of SDN evolution. SDN technology is becoming more and more mature, has attracted a lot of attention in various fields, these attentions and development continue to grow. SDN will inevitably lead to a revolution, and reshape the entire network ecosystem.
2.2 OpenFlow
This section describes OpenFlow. We outline that OpenFlow is only a single part in the SDN architecture - Southbound API. OpenFlow is an open standard for a communications protocol that
in development for SDN.
2.2.1 Comparison between different versions
OpenFlow has been released in many versions since its birth. Now let's compare the three major versions of OpenFlow [18]:
OpenFlow 1.0: The first version of OpenFlow, released in 2009. OpenFlow 1.0 contains a Flow Table with three components in a flow entry: Header Fields, Counters and Actions, Also, the header fields contains 12 fixed matching elements. It laid the tone of OpenFlow protocol.
OpenFlow 1.1: This version introduced two major improvements: Multiple Tables and Group Table. The Multiple Tables greatly reduce the entries in a multistage processing way. Group Table provides a more convenient way to implement multicast, redirection, and other network functions.
OpenFlow 1.3: This version introduces a new table called "Meter Table" to extend QoS capability.
OpenFlow 1.4: OpenFlow 1.4 further extends the flow table scalability by introducing a new "Synchronized Table". With synchronized table, flow tables can be synchronized bidirectionally or unidirectionally. Moreover, OpenFlow 1.4 introduces a new feature called "Bundle". Bundle is similar to converting multiple operations into an atomic operation.
OpenFlow 1.5: The latest version of OpenFlow, released in 2014. This version further extends bundle with "Scheduled bundle" [29] by including an execution time property. In the following sections, we will introduce the elements of OpenFlow, including the Flow Table, Group Table, and Meter Table mentioned above.
2.2.2 OpenFlow elements
An OpenFlow-enabled switch is called an "OpenFlow Switch" [29]. An OpenFlow switch can include one Flow Table (supporting OpenFlow 1.0) or more Flow Tables (supporting for OpenFlow 1.1 and higher), OpenFlow channel and OpenFlow protocol. The schematic diagram of the architecture is shown in the Figure 2-2 [12]. Compared with OpenFlow 1.0, higher version also contain Group Table and Meter Table as mentioned above.
OpenFlow switch
OpenFlow switch can be divided into Flow Table and secure channel. A Flow Table is a table for storing flow entries. In the OpenFlow protocol specification, the controller can deliver a flow entry to the switch to instruct the switch to process packets matching the flow entry. The secure channel
is a secure link used to communicate with the controller. The secure channel can be established directly on top of TCP or based on sockets created after TLS encryption.
Figure 2-2: OpenFlow 1.0 architecture Flow Table
The OpenFlow switch uses the concept of flow to describe a collection of network packets with the same characteristics. To complete the processing of the flow, the OpenFlow switch defines a flow entry to process the corresponding data flow, and these flow entries are stored in the Flow Table. Each Flow Table consists of multiple flow entries. The user distinguishes flows by programming these entries, and defines the processing instruction for the flow. Each flow entry corresponds to a specific flow, and its structure usually consists of three main parts and others, as shown in Figure 2-3.
The Rule (match fields) of the flow entry is used to compare with the specified packet header, including the input port, the header identification field, and Metadata.
Figure 2-3: Flow entry structure
TheAction (instructions) is a set of instructions that are executed when a packet matches the flow entry. The instructions set is mainly composed of 'control instructions' and
described in Tables 2-1 and Table 2-2, respectively.
TheStats (counters) of the flow entry is used to collect statistics, such as the number of successful packets matching the flow entry. The statistics are the key information for user to analyze the traffic. The OpenFlow switch defines a large number of counters, Table 2-3 shows some important counters.
The processing flow of each network packet in a single Flow Table is shown in Figure 2-4:
The OpenFlow switch compare the fields to be matched of the arrived data packet with all flow entries in the current Flow Table. If there is a unique flow entry matching the fields of the packet, the OpenFlow switch first updates the status of counters of the flow entry, and then executes the instructions in the flow entry. These instructions indicate the specific operations that the packet needs to perform, such as forwarding the packet, drop the packet, etc.
Figure 2-4: Processing flow of packets in a single Flow Table
For multiple flow tables: The above illustrates how a data packet can be processed in a single table. There are multiple flow tables in OpenFlow 1.1 and higher version. When a data packet is processed in multiple flow tables, the process is similar to process it in a single flow table. The data packet enters the first flow table and looks for matching entry. If there it is, enters the next flow table through the Goto-Table instruction, and so on. Finally executes operating instruction set. Group Table
The Group Table is proposed in the OpenFlow 1.1 version specification. Each Group Table consists of multiple group entries, which are programmed by the user to define the set of ports and the actions to be performed. By using the "Group action" in the flow entry, the flow packet can be directed to a "group operation", thereby performing the action set in the Group Table. The existence of the Group Table enables the OpenFlow Switch to implement more and more flexible forwarding strategies. The entries in the Group Table usually consist of four parts, as shown in Figure 2-5:
.
Figure 2-5: Group Entry Structure
TheGroup Identifier of a group entry is used to uniquely identify this entry. It is a 32-bit integer. This is also one of the differences between the Group Table and the Flow Table structure.
TheCounters of the Group Table are similar to the functions in the Flow Table (see Table 2-3), are used to collect the status information of the entry in real time, such as the number of packets processed by the Group Table.
TheAction Buckets are used to store multiple Action Bucket, and each Action Bucket contains an instruction set for flow packet.
TheGroup Type is used to specify the type of the group entry. Currently, there are four Group Types are defined:
(1) ALL: It indicates that all Action Bucket in Action Buckets will be executed. (2) Select: Only one Action Bucket will be executed.
(3) Indirect: Execute one defined Action Bucket.
(4) Fast Failover: Execute the first active Action Bucket. Meter Table
Each Meter Table consists of a number of Meter entries, which can be used to measure and control the packet transmission rate of a flow. The structure usually consists of three parts, as shown in Figure 2-6. User can specify a corresponding meter in the flow entry to complete the measurement and control of the flow.
Figure 2-6: Meter Entry Structure
TheMeter Identifier is used to uniquely identify this meter entry and is also a 32-bit unsigned integer.
TheCounters are similar to the functions in the flow table (see Table 2-3). They are used to collect the status information in real time, such as the number of data packets processed by this entry. TheMeter Bands are used to define a set of operations corresponding to the entry.
Name Describe Apply-Actions actions Execute the specified 'actions'
immediately without making any changes to the operation instruction set
Clear-Actions Immediately delete all 'actions' in the operation instruction set
Write-Actions action Add the specified 'action' into the current operation instruction set. If there is already an 'action' with the same type in the current 'set', rewrite the 'action', otherwise add a new 'action'.
Goto-Table
next-table-id Jump to the specified flow table, where thetable-id must be greater than the current
flow table id. Table 2-1: Control Instructions
Table 2-2: Operation Instructions
Name Describe
Output port no Forward the packet to the specified port.
Group Group ID Send packet to specified Group Table
Drop Drop packet
Set-Queue queue id Set the cache queue ID of the packet
Meter meter id Send packet to specified Meter Table
Set-Field field type value It is used to modify the value of each packet header field of the packet.
Counter Length(bit) Per Flow Table
Reference Count 32
Packet Lookups 64
Packet Matches 64
Per Flow Entry
Received Packets 64
Received Bytes 64
Duration (seconds) 32
Duration (nanoseconds) 32
Per Group
Reference Count (flow entries) 32
Packet Count 64
Byte Count 64
Duration (seconds) 32
Duration (nanoseconds) 32
Per Group Buckets
Packet Count 64
Byte Count 64
Per Meter
Flow Count 32
Input Packet Count 64
Input Byte Count 64
Duration (seconds) 32 Duration (nanoseconds) 32 Per Port Received Packets 64 Transmitted Packets 64 Received Bytes 64 Transmitted Bytes 64 Received Drops 64 Transmit Drops 64 Received Errors 64 Transmit Errors 64
Receive Frame Alignment 64
Received Overrun Errors 64
Receive CRC Errors 64
Collisions 64
Duration (seconds) 32
Duration (nanoseconds) 32
Table 2-3: Counter types OpenFlow channel and OpenFlow message
The OpenFlow channel is the communication channel between the controller and the switch. The forwarding data in the channel is OpenFlow messages. The OpenFlow messages are divided into three categories – controller-to-switch messages, asynchronous messages, and symmetric messages.
Thecontroller-to-switch message type is initialized by the controller and delivered to the switch. It may require the switch to reply to the corresponding message. The following types of controller-to-switch messages were introduced:
Features: This type of message is divided into Request and Reply. The controller can initiate and send a Feature_Request message to request the switch to reply its feature information. The message has only the header. After receiving the Feature_Request message, the switch will reply the features of the switch and the switch port through the Feature_Reply message. Generally, the controller sends a Feature_Request message to obtain the switch's features immediately after the switch's OpenFlow channel is established. Configuration: The controller can set and request the configuration information of the switch, and the switch needs to perform configuration and reply to the configuration message.
Modify-State: Issued by the controller to modify the Flow Table and port status of the switch.
Read-State: Issued by the controller to obtain status information about the switch, including statistics on the Flow Table and port.
Packet-out: Issued by the controller to send packets to the designated switch's port. The Packet_out message is generally used to respond Packet_in message and is often followed by a Flow_mod message, which is used to instruct switch to send buffered data or directly send data.
2) Asynchronous message
An asynchronous message is sent from switch to controller asynchronously. The switch informs the controller of the arrival of new data packets and the change of the switch state through asynchronous message. The main asynchronous message types are described as follows:
Packet-in: Send message to controller. In the OpenFlow protocol version supporting single-Flow Table, the cause of packet-in may be the action guidance of the flow entry, or it may be because no matched flow entry.
Flow-Removed: When the OFF_SEND_FLOW_REM flag is set, the switch will notify the controller that the flow entry has been removed when the flow entry become invalid. The cause of the invalidation of flow entry is that controller deletes the flow entry or the flow entry expires.
Port-status: Used to inform the controller that port status has changed when port configuration or status change.
Role-status: When the role of controller changes, switch informs controller of the change. Flow-monitor: Inform controller that the Flow Table has changed. The controller can set
3) Symmetric message
Symmetric message can be sent by either the controller or the switch, without permission or invitation from the other side. The main symmetric message types are as follows:
Hello: The hello packet is used in the initial establishment of the OpenFlow channel between switch and controller. Used to negotiate version and more.
Echo: Echo Request/Reply can be sent by either the switch or the controller. Each request message requires a reply message. It is mainly used to maintain the activity of the connection, but it also supports the carrying of message content, which can be used for delay or bandwidth test.
2.2.3 OpenFlow communication process
The communication flow chart shown in Figure 2-7:
Figure 2-7: OpenFlow communication process
Establish an OpenFlow connection: The controller and the switch send Hello messages to each other. Only the Header is included in the Hello message. The version field in the OpenFlow Header is the highest version of the OpenFlow protocol supported by the sender. If both parties do not support the same OpenFlow protocol version, it should send an Error message and then disconnect.
Get switch features information: After the OpenFlow connection is established, the controller needs to get the features information of the switch. The features of the switch include switch ID (DPID), number of buffers in switch, switch port and port properties, and more. The controller sends a Features Request message to the switch to query the switch features. The Features Request message only contains OpenFlow Header. The switch returns Feature Reply message after receiving the Features Request message.
that require controller to configure. The first attribute is flag, which indicates how the switch handles IP fragmented packet. The second attribute is miss_send_len, which is used to indicate when a packet cannot be processed by a switch,the maximum number of bytes that are sent to controller .
Packet_in event (switch receives packet):
Trigger Packet_in message situation 1:
When the switch receives a packet, it tries to look up the Flow Table and find matched entry. If there is a matching entry in the Flow Table, the switch processes the packet according to the action list indicated by the Flow Table. If there is no matching entry in the Flow Table, the switch encapsulates the packet in a Packet_in message, and send it to the controller for processing. At this point, the packet will be cached in the switch for processing.
Trigger Packet_in message situation 2:
The action list indicated by the switch Flow Table contains the action "forwarded to the controller" (Output=CONTROLLER). At this point the packet will not be cached in switch. Controller configure Flow Table (Flow_Mod message): Flow_Mod messages are used to
add, delete, and modify Flow Table of OpenFlow switches. There are five types of Flow_Mod messages: ADD, DELETE, DELETE_STRICT, MODIFY, MODIFY_STRICT. ADD is used to add a new flow entry. DELETE is used to delete all flow entries that meet certain conditions. DELETE-STRICT is used to delete a specified flow entry. MODIFY is used to modify all flow entries that meet certain conditions. MODIFY-STRICT is used to modify a specified flow entry.
Switch forward packet (Packet_Out): Not need to add a flow entry to the switch to process all packets. There are a variety of data packets that appear in small numbers (such as ARP, IGMP, etc.), so that it is not necessary to specify the processing method for these types of data packets through the Flow Table entry. At this point, the controller can use the Packet_Out message to tell the switch how to handle these packets.
Finally, let us conclude the SDN work procedure based on OpenFlow:
1.
The host sends packets to the network,2.
If no match entry in OpenFlow switch Flow Table, the switch sends Packet_in to controller,3.
Controller sends flow entry or Packet_out to the switch,4.
Switch forwards the packet according to Flow Table.2.3 Summary
In this chapter, we have introduced two important knowledges: Software-Defined Networking and OpenFlow. We introduced the definition of SDN, reasons
for its
birth, its architecture, its advantages compared with traditional network and the development history. As can be seen from the above introduction, SDN is a new technology that developing rapidly, and it is expected tobring great changes to our lives. For OpenFlow, we introduced its components, and the communication process
POX and Mininet
According to the architecture of SDN we introduced in Chapter 2, we know that SDN-based networks consists of application layer, control layer, and data layer. The implementation of control application is the ultimate goal of the research work and it will be discussed in the next chapter. This chapter mainly introduces the development environment - POX, which is the controller (control layer) selected in this thesis, and the network emulation tool used to emulate the data layer work – Mininet [19].
3.1 Control platform: POX
3.1.1 SDN Controllers
The SDN controller is an important part of the SDN architecture and it is the brain of SDN. The performance of the SDN controller directly affects the performance of the network. Since the development of SDN, different organizations have introduced different controllers. We will briefly introduce these controllers.
• NOX
NOX [20] is the first controller in the history of SDN development. NOX was developed by Nicira. As the world's first SDN controller, NOX has been widely used in the early days of SDN development. The underlying layer of NOX is written in C++, supports OpenFlow 1.0. However, since the development language used by NOX is C++, the requirements for developers are higher, so the development cost is higher. In order to solve this problem, Nicira launched the brother version of NOX - POX.
• POX
POX [21] is developed based on Python language, the code is relatively simple, suitable for the beginners, so POX quickly became one of the most popular controllers in the early days of SDN development. POX is a green software that can be used without downloading. Because the Python language supports multiple platforms, POX supports many systems such as Linux, Mac OS, and Windows. In terms of functionality, the core of POX is consistent with the core of NOX. In addition, POX provides OpenFlow APIs based on the Python language and some reusable modules such as Topology Discovery.
Based on the Python language, Ryu [22] has beautiful coding style, clear modules and strong expandability. It not only supports OpenFlow 1.0 to 1.5 also supports other southbound protocols such as OF-Config, OVSDB, VRRP and NET-CONF. RYU can be used as a plug-in for OpenStack and also supports contract with open source intrusion detection system Snort [23]. RYU also supports the use of ZOOKEEPER to achieve high availability. In terms of built-in applications, the RYU source code already contains many basic applications, such as simple Layer 2 switching, routing, shortest path and simple firewall.
• Floodlight
Developed by Big Switch Networks, Floodlight [24] is written in JAVA and follows the Apache v2.0 license. It has excellent stable performance and is an enterprise-level SDN controller. The performance of Floodlight can meet the needs of commercial applications, and because of its excellent performance, widely adopted by academia and industry, has become one of the most popular SDN open source controller.
• OpenDaylight
OpenDaylight [3] is a highly available, modular, scalable, multi-protocol support controller platform. And it is a JAVA-based controller. OpenDaylight supports a variety of southbound protocols: OpenFlow 1.0 and 1.3, NETCONF and OVSDB.
• ONOS
ONOS [38] (Open Network Operating System), is a newly released open-source SDN controller that is focused on service provider use-cases. The platform is written in Java and uses OSGi for functionality management. Similar to OpenDaylight, the individual features are loaded using the OSGi runtime called Karaf.
3.1.2 POX
The previous section gives a brief introduction to various controllers. Due to:
1. Pox controller is simple and green. The code structure is very simple and can be used without installation. It is easy for beginners to get start;
2. Python language is simple and efficient, compared to c++, java, it is easier;
3. The candidate is at the first contact with SDN, with little programming experience.
POX is selected as the control platform in this thesis. Below we will focus on introducing the main features of POX.
areof_01 and OpenFlow.
2. of_01 runs a thread, which monitors the TCP connection with the switches (this function is implemented by the recoco method of pox). When a switch sends a protocol message, of_01 will trigger the event corresponding to the message. The event requires Source and Sink. The function of Source is to provide the component with an event that can be listened to, and provide an interface to trigger the event to the components that listen to it. Sink is the component that listens to the Source.of_01 triggers two Source events here. One is the connection of the switch (it will be created when the switch is connected to the pox); the other is the OpenFlow module, that is, the message sent by any switch will trigger OpenFlow event.
3. The basic process of POX data processing is the following: of_01 listens to the switch message, except that the handshake message, which is not triggered to the component (self-processing), and the other will trigger the event. The component that listens to the switch or OpenFlow will be triggered to handle the event by the corresponding function.
The schematic diagram of the POX architecture is shown in Figure 3-1:
POX download and use
To download POX, just in the command line type:
$ git clone http :// github . com / noxrepo / pox Pox does not need to be installed, you can use it directly after downloading. Run POX:
$ cd pox
After entering the pox directory, run pox.py to start the pox controller. The startup interface is shown in Figure 3-2.
Figure 3-2: Startup interface
You can also start other application components at startup. For example, start the Layer 2 learning application in the forwarding directory. The displayed interface is shown in Figure 3-3. The "py" parameter means that the command line mode is turned on, allowing the user to type commands to perform some basic operations.
Figure 3-3: Startup with other application components POX component
To learn the SDN controller, you need to understand the function of its code structure and its components. Below is a brief introduction of some POX components, see Table 3-1:
Component name Features
forwarding.l2_learning Simple Layer 2 switching application forwarding.l2_multi Shortest path two-layer switching
application based on network topology information
forwarding.l3_learning Layer 3 switching, adding ARP processing logic
host_tracker.host_tracker Host location and configuration tracking
lib.graph.* Using graph-related storage content
defined by Networkx
lib.packet.* Defines the decapsulation and processing
logic of network packets
lib.revent Definition of event system
log Log related
messenger.* Defines a message system that
communicates with external processes OpenFlow.libOpenFlow_01 Definition of the OpenFlow 1.0 library OpenFlow.spanning_tree Spanning tree strategy
OpenFlow.discovery Topology discovery module
topology Topology module
web.webcore Web service module
pox.core Core module of pox
3.2 Mininet
Mininet [25][26] is a network emulator for software-defined networks, including switches, hosts, and controllers, on a PC to meet the needs of researchers, i.e., building a network environment. This also allows us to do an SDN project without having to deploy a real network, but only on a PC. Indeed, the Mininet implements the data plane mentioned in the previous chapter.
In the following section, we will discuss the advantages, disadvantages, structure, and methods of installation and use of Mininet.
3.2.1 Mininet’s advantages
The mininet is widely used in the development of SDN, which stems from its many advantages.
1.
Run fast: It only needs a few time to run a simple network. So this can greatly shortenthe development cycle of the application.
2.
Custom topologies: In addition to the commands made available by the CLI, thanks to which it is possible to launch elementary network structures, the system is equipped with an API [27] written in Python, with which the user is free to specify the topology that best suits to your needs3.
Real programs: Anything that is executable on a Linux platform is compatible with the capabilities of a host in Mininet. For example, very popular applications such as Iperf and Wireshark and xterm.4.
SDN approach: The switches generated with Mininet can be programmed using the OpenFlow protocol. An SDN project that works properly on Mininet can easily be adapted to use real OpenFlow switches.5.
Multi-platform support: Mininet works on laptops, on servers, on virtual machines or on Cloud platforms.6.
Sharing and reproducibility of results: Anyone who owns a PC can execute the code developed by a user and verify their works correctness.7. Easy to use: Knowing how to write a script in Python for designing and launching an experiment in Mininet.
8. Open-source: Users are invited to examine the source code and possibly modify it, correct it or request extensions.
9. Constant development: Mininet is still under development. If users feel that it does not work properly, that it is badly designed or that it "makes no sense", they can report it on the mailing list, so that the user and developer community can try to provide explanations and suggestions to solve the problem.
3.2.2 Mininet's drawbacks
shared between the hosts and switches of the generated network.
Since Mininet uses a single Linux kernel for all virtual hosts, it is not possible to run software that depends on other operating systems, such as BSD or Windows.
If the user needs personalized behavior on the part of the network devices, it is their job to look for the implementation of an SDN controller that meets their needs or, alternatively, to develop one on their own.
Unlike a emulator, Mininet does not have a very accurate notion of virtual time. This means that temporal measures are based exclusively on real time.
3.2.3 Mininet System Architecture
The system architecture of the Mininet is shown in Figure 3-4 [27].
Figure 3-4: Mininet system architecture
Mininet supports Kernel Switch and Userspace Switch. The forwarding efficiency of Kernel Switch is higher than that of Userspace Switch. The forwarding logic of Userspace Switch needs to be done by datapath.
It can be seen from the figure that the system architecture also contains the ofprotocol module. As its name suggests, its role is to establish a link with the controller and resolve the OpenFlow protocol.
Mininet creates a HOST, which is actually a Namespace, which runs, bin/bash, etc. The link between the host and the switch port and the link between the switches are emulated by Veth Pairs (Virtual Ethernet Pairs).
Controllers can be located anywhere in the network, whether real or simulated, as long as they have IP-level connectivity between them and the machine on which the virtual switches are launched.
3.2.4 Mininet installation
In order to install locally from source, you first need to get the source code [25]: # git clone git://github.com/mininet/mininet
and then go into mininet file
# cd mininet and then install
# ./util/install.sh -a
"-a": The full installation includes the Mininet VM, as well as dependency software such as OpenvSwitch, and like OpenFlow Wireshark and POX. By default, these tools will be installed in your home directory.
After the installation is complete, the Mininet can be started by the sudo mn command. As shown in figure 3-5:
Figure 3-5: Mininet startup interface
help Print help information
nodes View all node information
net View network topology information
dump Output node information
h1 ping h2 Test connectivity between hosts
iperf Specify TCP test between nodes
iperfudp Specify UDP test between nodes
xterm Open xterm window
dpctl Operate datapath
py Running python
sh Execute shell script
host cmd Execute commands in the host
exit/qiut Exit Mininet
Table 3-2: Common command in Mininet
3.3 Summary
In this chapter, we introduced the two most important tools used in this paper: POX and Mininet. As the control platform in this paper, POX is simple and convenient for beginners. Mininet is used to emulate the data layer, so that experiments can be done on a single computer. These two tools are used often in writing and testing new control applications.
Design and Implementation of the Control Application
This chapter describes the design and implementation of the control application and the topology we used for experimental testing. The application is mainly composed of Topology Discovery Module, Network Statistics Handler, Controller Logic, Topology database and Flows database. The workflow of these modules will be introduced later. This application allows to control packet forwarding in a balanced, secure and centralized way.The general work of the application is that when the network is not under attack, the application applies a load balancing policy for calculating and installing a forwarding path for each flow in order to ensure that all flows can be well distributed in the network. When the network is under attack, the attack detection component sends a message to the application. When the application receives the message, it will analyze the information in the message, and adopt different countermeasures (rerouting, dropping, etc.) for different attacks to ensure the network is secure and reliable.
The topology is an essential part for the validation of the application, behaviour. We will briefly describe how the topology is generated in the last part of this chapter.
4.1 Control Application
Figure 4-1 shows the architecture of the control application:
Now, we start to explain each part in this structure.
4.1.1 Topology Discovery Module
The task of this module is to provide the topology at the data layer, including the switches, the hosts, and the links between them. The information of discovered switches and links will be stored in theTopology database for the Controller Logic module to calculate forwarding paths. It also tracks the host in the network and stores this information in the data structure that holds the hosts’ information.
This module consists of two sub-modules: discovery.py and myARPModule.py. discovery.py discovers the connectivity between OpenFlow switches by sending out LLDP packets.
myARPModule.py keeps track of the hosts, and keeps updated hosts’ location information.
Since both discovery.py and myARPModule.py [21][30] are components that had already been implemented, we will introduce the workflow of these two components below, instead of going into details of the implementation details. However, we will attach the code to appendix.
discovery.py
The behavior of this component is governed essentially by three timers:
_link_timeout is the time interval after which a link is considered as failed;
_timeout_check_period represents the frequency to check if a link is failed;
send_cycle_time is linked to the frequency with which LLDP packets are sent (at most it
can be equal to _link_timeout). Its workflow mainly includes:
1.
The switches in the network need to forward LLDP packets through each port they have. At the same time, they must pass all received LLDP packets to the controller. Suppose there is a bidirectional connection between port a of switch s1 and port b of switch s2, shown in Figure 4-2. For what has just been said, at the instant t, an LLDP packet will pass from s1 to s2. The controller, therefore, receives an LLDP message containing the identifier of the switch s1 and the port number corresponding to a from s2, is able to conclude that the unidirectional connection (or adjacency) from s1 to s2 is active.dictionary and generate an event that notifies the modules the discovery of a new connection; otherwise we simply update the corresponding timestamp. Besides, the
LinkEvent event contains two mutually exclusive flags: added and removed. The case just
treated requires that the first of the two flags is activated.
3. Each _timeout_check_period seconds, the module examines the adjacency database. A link is deemed to be failed if the corresponding timestamp precedes the current time by more than a _link_timeout seconds. In this case, it is necessary to remove the link from the adjacency dictionary. The component also raises an event for the modules involved. This time, the flag removed have to be set. It is important to stress that, in reality, the link may still be functioning.
myARPModule.py It has three functions:
1. Keep updated information about the location of the hosts in the network; 2. Allow the correct exchange of ARP messages;
3. Notify the discovery or removal of a host to the affected modules. Its work procedure mainly includes:
1. For each ARP Request received from a switch, the controller checks whether the host_ip (host_mac, switch_port) is present or not for the host send the request. In case of positive result, it will refresh the associated timer; otherwise, it inserts this message in the appropriate dictionary, starts a new timer and raises an event to notify the discovery of the host to the interested modules.
If the searched MAC address is the one relative to the default gateway for the sub-network, we need to construct and deliver the necessary response. This will contain the physical address corresponding to the switch port from which the ARP message was received. Otherwise, the MAC of interest is relative to a host belonging to the same sub-network. In this case, the controller limits itself to forwarding the request.
If we know the host_ip (host mac, switch port) for the destination host - the destination host connecting with this switch,forward the request to the correct port; otherwise, otherwise propagates the request through flooding except the port receiving request. Figure 4-3 summarizes what has been said so far.
2. For each ARP Reply received from a switch, If the controller already has the host_ip (host_mac, switch_port) relative to the host that generated the response, it simply refreshes the associated timer; if not, add the relevant information into the appropriate dictionaries, start a new timer and raise an event to notify the discovery of the node to the involved modules. If source host is a quarantined host in lastChance, remove it from lastChance dictionary.
If the packet is directed to the default gateway, it does not require any additional action. Otherwise, the response is given to the host of the sub-network. Observe, in this case, the knowledge of the destination node is taken for granted by the controller: since a response always requires a request, the information relating to the destination host have already been memorized. Figure 4-4 shows the process.
4.1.2 Network Statistics Handler
TheNetwork Statistics Handler is implemented by myStatsModule.py [30], and it is responsible for collecting statistics from every switch connected to the controller. Statistics taken from a switch concern：
1.
The ports available;2. The flows present within its Flow Table.
The Network Statistics Handler module provides statistics of each port and flow, and it takes advantage of traffic statistics provided by OpenFlow. The statistics of ports can be used to calculate links utilization in theController Logic module. The flow statistics can provide bandwidth of each flow. Statistics and ports status are used for calculating a new path.
Since the module had already been implemented, we don’t analyze the code in detail here. The code of this module will be attached to appendix. If you want to know the implementation details, of this module, please refer to the reference [30].
4.1.3 Controller Logic
Controller Logic module is the core of this control application, and is implemented by
controller_logic.py. This module performs some main functions as described below:
Forward traffic flow with load balancing policy: When no attack occurs,Controller Logic module calculates a forwarding path for each traffic flow taking into account a load balancing policy, and the information maintained in the Topology database, which is updated byTopology Discovery Module and Network Statistics Handler.
Drop malicious traffic flows: When the external attack detection component informs the controller that a malicious flow is detected, Controller Logic retrieves and deletes this flow fromFlows database, then notifies all switches to drop packets from this flow.
Reroute traffic flows: When the external attack detection component informs the controller of the occurrence of a link attack or switch attack, Controller Logic reroutes the flows affected by this attack to other safe links.
1. Forward traffic flows with load balancing policy
When one of the edge OpenFlow switch detects a new flow, theController Logic will calculate a path between the source and destination according to the current topology. In this thesis, we use Dijkstra's algorithm [31] to calculate shortest path between two nodes. In this algorithm the input parameters are the network topology and the source node (root), the output is the shortest paths tree between source to other destinations. In this work, the weight of each edge (link) in the topology is the value obtained after the utilization of each link is processed by the load balancing policy (we will introduce it later). Of course, you could choose other algorithms for calculating shortest paths. After calculating the path, the controller will deliver and install the related flow entry on each node (switch) along the routing path according to OpenFlow rules mentioned in Chapter 2. At the same time, theFlows database will also update related flow information. Then, when next packets of this flow arrive, switches can forward them directly (see Figure 4-5).
Figure 4-5: Traffic flow routing Now, we start to explain the load balancing policy.
If load balancing is not used in case the cost of all links is fixed and is the same, after we have calculated the shortest path, the path with the minimum hop number is always selected for routing packets. When the traffic in the network is very heavy, this leads to packet loss and high latency. Therefore, we should avoid this situation, and make all flows distributed across the network to reduce packet loss rate and latency. Therefore, we should introduce a load balancing policy.
As we know, the choice of path depends on the cost of the links. The links with smaller costs have a higher probability to be selected. In this thesis, we assume the bandwidths and therefore the cost of all links in the network are equal. Since we want to forward traffic flows with load balancing, this means we want to choose the links less used, therefore we need to make the links with less load (that is, with smaller utilization) have lower cost values.
Suppose there are two paths - path1, path2, the length of path1 is shorter than path2, but path1 already has some load. As mentioned above, path2 should be selected for a new flow. However, if the load of path1 is not enough to affect the data transmission, it can carry on other traffic. In this situation, we may hope that the path1 will be selected when a new traffic flow arrives. Therefore, the policy should also consider, when to care about more link utilization and when to care about more the number of hops. Considering this requirement, we set a parameter - "threshold" in the policy, which determines when we consider more the link load and when to consider more the hop number. When the utilization of a link is less than the threshold, indicating that this link is not used too much, the hop number has a more important role than the utilization (so link cost should not
change too much within this range). When the utilization of the link is more than threshold, the
utilization has a more important role than the hop number (this means cost of link will increase a
lot within this range).
There is also another situation, to be considered: in the network may exist some paths, much longer than others (see Figure 4-6). If the utilization of both paths with minimum hop number is just over the threshold, and a new flow arrives, we do not want to choose the longest path for it even through it is idle.
Figure 4-6: Network has a path much longer than others Considering the above factors, we design the following load balancing policy :
if u<threshold: 1 c else: ) 1 . 0 *( 10 _ * 1
base number u threshold
c
where, 'u' is the link utilization, 'c' is the link cost, '1' is the Arabic number 1, and it is the initial cost of all links. If you want you could choose another value. The input parameter is the link utilization, the output is the cost of the link.
When the link utilization is less than the threshold (the length of the path has a more important role than the utilization), the cost of each link does not change (cost does not change too much). That is, in this range, the controller will always select the path with the minimum hop number. However, when the link utilization is greater or equal than the threshold - the utilization has a more important role than the length of the path (the cost value of the link will change significantly).
Important: We use the step function when calculating the utilization, in order to achieve better robustness, that is, when the utilization is in the range of [a, a+0.1), the utilization=a.
For the sake of clarity, in Figure 4-7, the path with minimum hop number is s1-s3-s8, and its length (shortest path length) is 2.
If the utilization is in the range of [threshold, threshold+0.1), because of the step function, utilization=threshold actually. The cost of this link will become to 1*base_number. Now, a flow whose bandwidth is in the range of [threshold, threshold+0.1) arrives, the path with minimum hop number is selected for it naturally. At this moment, if the length of a path is within
base_number*shortest path length, this path has greater priority than the path with minimum hop
number. So we can deduce that when there are enough flows in the network, a path with the length is in range of [the shortest path length, base_number*the shortest path length] will have more loads. Let us give an example. In Figure 4-7, all links bandwidth is 10Mbps, the path with minimum hop number iss1-s3-s8, and we set threshold=0.2, base_number=1.6. When the first flow comes, if its bandwidth is 2Mbps, we assign the paths1-s3-s8 to it definitely. At this time, the sum of the cost of path s1-s3-s8 is 2*1.6=3.2. The cost of path s1-s2-s5-s8 and s1-s9-s10-s8 is 3*1=3, so these two paths are preferred to the paths1-s3-s8 when a new flow arrives.
Figure 4-7: Topology for example
It can be derived from the above analysis. If threshold=1, the hop number are always considered more. Threshold is equal to 0, means we always care more about link utilization. When
base_number=1, the cost of the link never change, so, regardless of the link utilization, we always
choose the path with the minimum hop number. In conclusion, the threshold is smaller, the load balancing is better; the base_number is larger, the load balancing is better. The curve of the policy (threshold=0.5, base_number=2) is shown in Figure 4-8:
Figure 4-8: Load balancing policy curve
However, since we are using the step function for link utilization, the actual policy curve is shown in Figure 4-9.
Figure 4-9: Load balancing policy curve using step function Figure 4-10 compares the two curves in the same figure:
Figure 4-10: Comparison between using step function and not using step function
The parameters threshold and base_number can be specified using the command line, after the
controller_logic module. The default value is threshold=0.5, base_number=2.
2. Drop malicious traffic flows
When receiving the information sent by the external attack detection component, the Controller Logic module checks whether there is information about malicious traffic. If there is, the method
handle_malicious will be activated. This method receives the source and destination IP address of
malicious traffic flow. First, it detects all flows in the Flows database, if a flow matches the malicious traffic flow, the controller deletes it fromFlows database. Then, the controller sends and
installs a flow entry on all switches to inform that when the received packets belong to this malicious traffic flow, they must be discarded.
We have already introduced the drop action in Chapter 2.2. Its function is to discard all matching packets. Make an example: actionDrop={'drop'} matchDrop= {'dl_type':pkt.ethernet.IP_TYPE,'nw_dst':destination,'nw_src':source} fieldsDrop={ 'command':of.OFPFC_ADD,'actions':actionDrop,'match':matchDrop,'priority':of.OF P_DEFAULT_PRIORITY+1}
for switch in self.connections:
installEntry(self.connections[switch],**fieldsDrop)
This is the code for installing the drop rule in all switches, and matchDrop describes the features of malicious traffic. ActionDrop is the action taken on the matching packet. fieldsDrop is the flow entry to be installed in all switches.
Figure 4-11: Drop malicious traffic flows
3. Reroute traffic flows
Routing is applied when the Controller Logic module receives information indicating that a portion of the network is under attack from the attack detection component. When a link is under attack, the method handle_attack_link is called. This method receives a link identifier. First, it deletes this link from the Topology database. Second, it retrieves from the Flows database, all flows passing through this link. Then, it sorts the flows in descending order of bandwidth, and reroutes each flow one by one. For each flow, we need a new topology, which does not include the failed link and the link whose remaining bandwidth is not enough to forward this flow after recalculating the load of each link. With this new topology, we calculate a new path for that flow. Finally, theFlows database is updated (see Figure 4-12).
There are two reasons for sorting traffic flows in descending order of bandwidth. First, we want the flows with higher bandwidth, experience less recovery time, because in the same recovery time, the flows with higher bandwidth will have more losses than the flows with lower bandwidth. Second, if we forward a higher bandwidth flow, and then a lower bandwidth flow, the probability that both
