CC BY
226
Application of the OpenFlow Protocol Based on the Mininet Network Emulator with the Installation of a Floodlight Controller
V.V. Jakovlev, Zh.M. Berkinbayeva Emperor Alexander I St. Petersburg State Transport University St. Petersburg, Russia jakovlev@pgups.ru, berkinbayeva.zhanniyet@gmail.com
Abstract. OpenFlow provides accurate traffic management across the entire spectrum of switches and routers in the corporate environment, both physical and virtual, regardless of vendor. This eliminates the need to individually configure the device of each vendor through its own interface. Mininet is a network emulation platform that creates OpenFlow infrastructure elements on a single computer (physical or virtual): controller, switches, nodes, and connections. This article describes the architecture of the OpenFlow protocol, the message in the protocol, the flow table, the basic modules in the Floodlight controller architecture, and, of course, the vulnerability of the OpenFlow protocol. Results of experiment with checking the three main types of network topology with transmission of the traffic by installing the Mininet network emulator and configuring the Floodlight controller are considered.
Keywords: software-defined networking, OpenFlow, Floodlight controller, flow table, Mininet, Network virtualization, Quality of Service, Programmable Networks.
Introduction
OpenFlow is an open standard that allows you to work with experimental protocols within existing networks. This standard is an extension for commercial routers, switches, and even domestic routers [1], and its implementation does not require any action on the part of the network device provider. The standard is a fundamental element of the Software Definition Network (SDN) concept.
Today, most networks do not have a high level of organization, which prevents the network from being managed effectively as required by modern requests. The openFlow standard solves these problems. It acts as a management protocol between network devices. In simple terms, the concept of networking SDN separates the layer of data transmission from the control layer [2]. On the basis of this, it turns out that at the data level, the simplest switches control the flow of data based on predetermined rules that are set by the central network controllers. The network structure of SDN has a high degree of virtualization [1], all ports, both virtual and physical, are managed in the same way.
General architecture
The first concept of OpenFlow standard was developed at Stanford University in 2008 [1]. More than a year later, in
Angel Fernandez del Campo Universidad Politécnica de Madrid Madrid, Spain afc@dit.upm.es
December 2009, the first version of the OpenFlow protocol was released. After the release of OpenFlow protocol was managed by the Open Networking Foundation (ONF). Shortly after its release, most companies have announced support for OpenFlow protocol in their devices. It is worth noting that OpenFlow is not the only such protocol, there are also others: OpFlex, Yang and NetConf, but they are not as common as the OpenFlow [3].
Despite the age, OpenFlow it is quite a promising development in the field of network technologies. For this reason, there is a question - is this technology necessary whether in our time. In classic routers or switches, packet transmission and high-level routing are performed on one device, whereas when using OpenFlow, these actions are separated [4]. The SDN controller in the concept of SDN networks is the brain of the entire network, transmitting data to the switches and routers "on the bottom", through southboundAPIs, and to software applications "on top", through northboundAPIs. For the organization of the work of several SDN networks, controllers must be interconnected with each other, for this purpose the OpenFlow protocol is used.
The system consists of two components: a switch with Openflow protocol and controller. Openflow switch, in turn, consists of three parts:
1) The Flow Table, which defines the actions for each flow switch
2) Secure Channel, which provides service information transfer between the controller and switch
3) The Openflow protocol, which open and standardized method of communication the switch with the controller itself. Thus, given a standard method for programming switches without having to configure each switch individually. The OpenFlow architecture is shown in figure 1.
OpenFlow is widely implemented by network equipment manufacturers because of the simple (and hence cheaper in the realization) structure of the OpenFlow switch, which can be implemented through small modifications of software and hardware. As a result, the transition to the OpenFlow protocol it is relatively easy and can be carried out step by step with the implementation of the protocol in those network segments that require OpenFlow functions.
Fig. 1. Architecture of OpenFlow
• Role-Request. Used to change the current role of the controller on the switch (to increase the role from Slave to Master) (for protocol version 1.3).
• Asynchronous-Configuration: this message can be used by the controller to set the filter on asynchronous messages received from the switch (for protocol version 1.3).
Asynchronous messages. Switches send asynchronous messages to the controller for notification of the arrival of the packet, change of status of the switch or error.
The following types of asynchronous messages are:
• Packet-in. If there are no corresponding rules in the switch table for the package, the switch generates a Packet-in message and sends it to the controller. For all packets sent to the virtual port CONTROLLER, Packet-in message is sent to the controller.
• Flow-Remove. When a rule for a new flow is added to the switch by using the Flow-mod message, it is set to the time-out value. This rule must be removed in this period of time because there is not enough activity or no rule is used.
• Port status. The switch can send messages to the Port status controller when the port configuration status changes.
Messages of openflow protocol
OpenFlow protocol can support the following types of messages: the first, controller-to-switch - used by the controller for the direct control and management of the switch state; The second type, asynchronous messages are initiated by the switch and the controller are used for notification of network events (errors, failures) and changes the switch state; third symmetrical messages can be used as the controller and the switch.
Controller-to-switch massage. The controller initiates the following message [5]:
• Features. Controller requests the status of the switch using the request features; the switch must respond using the features of the response, which indicate the possibility of a switch. This is usually done when creating OpenFlow channel.
• Configuration: the controller sets and requests the switch configuration parameters. The switch only responds to requests from the controller.
• Modify-State. Sent by the controller to manage the switch. To add / remove modify rules in the OpenFlow tables and installation the characteristics (parameters) of the switch port.
• Read-State. Used by the controller to collect statistical data from the switch.
• Packet-out. Used by the controller to send packets from a specific port on the switch and sending packets received using the packet-in message. packet-out messages must contain the whole packet or an identifier buffer ID, references the package that you downloaded to the switch. The massage must contain a list of actions that should be applied in this order: if the action list is empty, then the packet is reset.
• Barrier. Request / response is used by the controller to ensure that the installed dependencies between messages or to receive notifications on completed transactions. Used when necessary processing of messages in a specific order.
Flow table
In the SDN switch with OpenFlow support, only the data transfer level is implemented. Each switch has its own unique table, which it fills out only on the basis of information received from the central controller. This switch table is named flowtable because the SDN network transfers data streams rather than individual packets (the rule in the switch is set only for the first packet, and then all other packets in the stream are used). These tables classify incoming packets based on the port, MAC address, IP address, and other tools [6].
Each entry in the package is cut off by a header (a bit string of a specific length). For this bit string, the flow tables, starting from the first, are looking for a rule, that has a field of the characteristics, most closer corresponds to the packet header. When there is a match, on the packet and its header conversion performed by defining a set of instructions specified in the rule results.
Recording of the flow can prescribe forward the packet to a particular port (the normal physical port or a virtual port assigned by the switch, or reserved virtual port, set the protocol specification). Reserved virtual ports Define common forwarding actions: sending a controller, broadcasting (avalanche) distribution, forwarding without OpenFlow. Virtual ports can precisely define channel aggregation groups, tunnels, or feedback interfaces [7].
If the desired rule is not found in the first table, the packet is encapsulated and sent to the controller, which generates the appropriate rule for the packets of that type and installs it on the switch (or on the set of switches it manages) or the package can be changed or reset. The processing pipeline statements allow you to forward packets to subsequent tables for further processing and to pass information between tables as metadata. The instructions also define the rules for modifying counters that can be used to collect a variety of statistics figure 2.
Rule Action
(mated fields) (instructions)
• Packet* byte counters
1. F orwa rd pac kets to port (s(.
2. Encapsulate and forward to controller.
3. Drop packet.
4. Send to normal processing pipeline.
Switch VIAN VIAN MAC MAC EttiM ir IP IP IP L4 M
Pot (0 M m . dtt ewe Src Dm ToS Prol tport dport
Fig. 2. Flow table in OpenFlow switch
Openflow controller
The OpenFlow controller is a kind of SDN controller that uses the OpenFlow protocol. Actually, SDN controller is the main point in SDN networks figure6. OpenFlow controller uses the same name protocol for connecting and configuring of network devices [8], to determine the best path through which the application traffic will pass. SDN controllers simplify network management by focusing the entire process of communication between applications and devices for efficient network management and modification (If, of course, it is required). Due to the fact that network management is carried out programmatically, administrators can work with traffic more efficiently, thereby increasing network performance. Summarizing, we can say that the OpenFlow controllers create a central point for managing compatible devices in the network. This protocol was created to increase the flexibility of working with the network, through the universalization of all
Vulnerabilities in the openflow potocol
The advantages and disadvantages of the SDN architecture for Network infrastructure security are well understood. However, the assessment of architectural vulnerabilities should be based not only on speculation about the theoretical architecture, but also on the experiments and results of the implementation of the OpenFlow protocol in the industrial
networks. The following types are currently defined threats to OpenFlow networks. Controller modes (reactive or proactive) can easily be identified by an attacker without using specific approaches or software. The identity is based on the first packet delay for the new traffic flow and is available to each user connected to the network or using the services of the infrastructure from external networks. As a result, some attacks can use the specific behavior of the controller [9]. For example, an unauthorized installation of switch processing rules that reduces the efficiency or disruption of a network is easier to implement in reactive mode due to the particularity of the controller approach to table management flows in this mode. However, it is possible to perform this attack on the reactive controller, but it is more difficult because a complex attack is required and the likelihood of a quick attack is significantly higher. Security threats that are relevant to most information systems, such as port scanning and network service definitions, are critical to the SDN architecture because of the vulnerability of the OpenFlow channel and the large number of management traffic that is transferred between switches and network controllers [10].
Controller floodlight
FloodLight - OpenFlow Java-controller for companies and enterprises (class enterprise) with open source. FloodLight appeared from the source code of Beacon. Has the license Apache - i.e. Can be used for any purpose.
Uses pure Java (OSGI is not required, supported by Eclipse, but is not required). Very easy to build and run. It is the core of Big Network Controller from Big Switch. Portability between applications and FloodLight Big Network Controller provides. Architecture and its features, the main components are considered in [2; 4; 8; 9; 11].
FloodLight has a modular architecture, due to which facilitates the process of expansion and modification. In describing the architecture, two main concepts are used: the service and module. Service is an interface that exports the state and generates events. Service consumers can get / set the state and to sign or unsubscribe to events. A lot of implementations of the same service are allowed. Each module, in turn, can use a certain set of services (dependencies) for implementation of some functionality. The module may provide respectively, zero or more services. That is, the modules export services. All FloodLight modules are written in Java. All modules have a minimal number of dependencies between them that simplifies application development.
The general architecture of FloodLight is shown in figure
4.
Features:
• The modular loading system, which makes it possible to expand and increase the functionality of the controller.
• Easy installation with minimal dependencies.
• Supports a wide range of physical and virtual OpenFlow switches.
• Supports integration with non-OpenFlow networks, ie it can manage a lot of "islands" of physical OpenFlow switches.
• One of the main development goals - high performance.
• Supports platform OpenStack cloud orchestration.
network devices (figure 3).
Fig. 3. Possible actions in SDN networks
Fig. 4. Architecture and basic modules of FloodLight
Features and opportunity of mininet
Mininet is a computer network emulator in the Linux environment. Mininet creates virtual OpenFlow networkscontrollers, switches, and hosts-on one real or virtual machine. Enables you to quickly create, communicate, and configure software-defined networks. Almost every operating system is a computational resource virtualization using process abstraction. Mininet uses a virtualization-based process to launch many hosts and switches on one core OS. The mininet can create a kernel or a custom space of openflow-switch, a controller for the fabric control, and organizes a connection on the simulated network. Mininet connects switches and hosts using virtual Ethernet pairs. Currently, Mininet supports only Linux, but in the future it can support other operating systems such as Solaris or FreeBSD.
Mininet supports five built-in network topologies, namely, a minimal topology, a single topology, a linear topology, a tree topology, and a reverse topology [12].
Mininet installation and check of different network topologies
Starting with the 2.6.24 version, the Linux kernel supports the virtualization and isolation Mechanisms-cgroups [13], which provide network interfaces, routing tables, and ARP tables with processes within the same operating system. This is one type of OS-level virtualization that allows you to run many of the same processes in an isolated and resource-limited environment.
The default topology is the minimum topology, which is predefined with one OpenFlow kernel switch connected to two host controllers and OpenFlow, while the number of switches and nodes can be changed for other topologies using the command-line interface (CLI).
How to use it
All the work with a virtual network mininet, namely to deploy the network of the desired topology, change different host or switch settings, and so on, is done in a simple command interpreter- mn:
$ sudo mn
Run without parameters, MN will go into the command's interpretation mode. By default, it will create a minimal network consisting of two hosts (h1, h2), switch (s1), and OpenFlow Controller (c1):
$ sudo mn
*** Creating network *** Adding controller *** Adding hosts: h1 h2
*** Adding switches: s1
*** Adding links: (h1, s1) (h2, s1) *** Configuring hosts h1 h2
*** Starting controller *** Starting 1 switches s1
*** Starting CLI: mininet>
The Mininet interpreter uses a number of native commands that allow virtual network management to be almost real. The following are examples of key features. You can display a list of all hosts, switches, and controllers by using the command: nodes
To view a network topology, you can use the following command to map the switch and host ports: net
You can display the network interface configuration of a particular host using the classic ifconfig command before which you specify a specific host name:
mininet> hi ifconfig
In the above command, you can specify a specific switch instead of the host name, and the configuration of its ports will be displayed.
You can turn off and turn on any of the switch ports as desired:
mininet> link si hi down mininet> link si hi up
You can view the routing table for a particular host using the following command: route Run Ping:
mininet> hi ping h2
Ping everyone:
mininet> pingall
Actually, you can perform most of the standard Linux commands on each of the hosts by specifying its name first. For example, to see the processes of any of the hosts or switches, the same: ps
mininet> si ps
You can end any of the processes by using the standard: Kill-9. In addition to checking the availability of nodes using ping, you can still test bandwidth between nodes using the old: iperf
mininet> iperf hi h2
Interface throughput can be limited from 10 to 1000 Mbit/s. Well, after all, you can just get the terminal to any of the nodes:
mininet> xterm hi Additional services.
On each of the virtual hosts, in addition to the standard processes, you can run third-party services. For example, this could be a simple Web server in Python:
mininet> hi python -m SimpleHTTPServer 80 &
and try to connect to it from another node:
mininet> h2 wget -O — hi
You can shut down the Web server if you want to:
mininet> hi kill %python
The mininet virtual network does not exist permanently — it is created when you write MN with or without specific parameters, and is destroyed when the interpreter exits. All this is happening almost instantaneously. Even a large network with several hundred hosts and dozens of switches are created in seconds. And it's all on a single-processor virtual machine with one gigabyte of RAM.
You can collapse the entire virtual network and exit the OS shell with the following command: quit.
If the interpreter's work was not completed correctly, you can get rid of the dangling processes and other service data by using the command:
$ sudo mn -c
Now, by complicating the topology, I will show you three main topologies of the OpenFlow network: Single, Linear and Tree topology.
There are four basic topologies that you can use, "not would" with the Python syntax — they are already described and implemented as MN parameters. Here are some details about each one.
Minimal. As has been previously shown, the default is to run the MN without parameters. In this case, you create two hosts that are connected to the same switch, which in turn is controlled by the OpenFlow controller. You cannot specify an arbitrary number of hosts or switches in this topology.
Single. As with minimal, all hosts connect to the same switch. The only difference is the ability to specify the number.
Single topology.
The Single topology consists of a single OpenFlow-enabled switch connected to multiple hosts as defined. The switch in turn connected to the OpenFlow controller though secure channel. A single topology has 16 numbers of hosts is developed in Mininet using CLI command as:
$ sudo mn --topo = single,i6
When running the above command for OpenFlow-enabled single topology in command line, a Mininet console will create a single OpenFlow-enabled network topology has 16 hosts, and is connected to a single OpenFlow-enabled switch. The switch in turn is connected with control plane (an OpenFlow controller) as shown in figure 5.
Fig. 5. OpenFlow single topology with 16 hosts
Интеллектуальные технологии на транспорте. 2018. № 2
9
Linear topology
In linear topology, if there are 'n' hosts on the network then 'n' numbers of switches are required. Which means that each host will be connected to the appropriate switch. For example, host hi will connect to switch S1, host h2 with switch s2, and all the switches are connected to one another which in turn is connected to a common controller. A linear topology with 16 hosts is designed in Mininet using CLI command as:
$ sudo mn --topo = linear,16
Similarly, when execution of above command for the linear topology on the command line, the Mininet console will create a linear topology OpenFlow support with 16 hosts. Since, as discussed that each host is connected to its own switch, 16 switches are also required in the network and the switches are connected with each other as shown in
figure 6.
create a tree topology that has 16 hosts in Mininet as shown in figure 7.
The command presented above builds a network with the classic three tiered model. When each access-level switch is connected to four hosts. The access switches will in turn be included in the distribution of the four switches, which in turn are placed in a single core. Unfortunately, such capabilities as stacking switches or aggregation of channels and the standard VLANs are not implemented in Mininet, making the model not entirely realistic. But in general terms, it's quite similar.
Fig. 6. OpenFlow linear topology with 16 hosts
A linear topology with 16 hosts connected to its own switches in linear fashion is clearly shown in figure 10. All switches are interconnected with each other and in turn connected with OpenFlow controller as shown in the figure 6.
Tree Topology.
A tree topology is depending on the location of the switches and hosts in a tree fashion. This means, that there are multiple branches in the topology and in these branches multiple switches and hosts are connected according to topological design. A tree topology which has 16 hosts is developed at the command line CLI using the following command:
$ sudo mn --topo = tree,depth=2,fanout=4
In the above CLI command, to create a tree topology, the syntax of the command determines the depth and fanout. Here, the depth indicates the number of levels of switches and the fanout indicates the number of available output ports to connect switches or hosts. Depth is require for the number of levels of switches to connect starting from controller. This means that, let the controller be at level '0', then according to this example there will be two levels of the switch, and finally, the level of hosts will appear. The number of hosts require to connect with each switch depends on the number of fanout, the fanout in this example is 4. In this example, the number of switch levels is two and each switch has 4 numbers of output ports for connection of next level. The above command will
Fig. 7. OpenFlow tree topology with 16 hosts
To build a network using its own topology, you can use a key: custom
$ sudo mn —custom /<script path>/topo-2sw-2host.py —topo mytopo
Network settings.
By default, all objects in the Mininet network are connected by virtual gigabit channels. This can be verified by executing the IPERF command in the Mininet interpreter, which will test bandwidth between the two network objects.
mininet> iperf
Installation and setup of floodlight controller
Floodlight is open-source software, whose source code is published on GitHub: github.com/floodlight/floodlight. However, it is easier to use the integrated development environment (IDE), such as Eclipse, to add new modules. The next steps are necessary to download floodlight and integrate it with Eclipse.
Enter the following commands:
sudo apt-get install build-essential default-jdk ant python-dev eclipse git clone
git://github.com/floodlight/floodlight.g it
cd floodlight ant eclipse
1. Launch Eclipse
2. "File" ^ "Import" ^ "General" ^ "Existing Projects into Workspace" ^ "Next"
3. In the "Select root directory" click "Browse" and select the parent directory where you placed floodlight. ^ click "Finish"
4. Create the FloodlightLaunch target:
(a) Click "Run" ^ "Run Configurations"
(b) Right Click on "Java Application" ^ "New"
• For "Name" use "FloodlightZhanniuyet"
• For "Project" use "Floodlight
• For "Main" use "net.fioodlightcontroller.core.Main"
(c) Click "Apply"
Adding a module to Floodlight. In order to add a module with new functionalities, it is needed to change the default startup modules:
src/main/resources/floodlightdefault.pr operties
src/main/resources/META-
INF/services/net.floodlight.core.module .IFloodlightModule Adding the new class created.
Conclusion
As a result of the work done, it has been found that the application of the OpenFlow protocol to configure the switch allows you to dynamically configure the network infrastructure components. To simulate a script by using SDN, this project used the Mininet software which developed by Stanford University and released under the BSD open source to simulate the network and floodlight as a network controller. Another tool that is used is virtual box to launch the Mininet virtual network.
By using the Mininet simulated various network topologies with traffic transfer. This approach to modelling SDN networks has the following advantages over analogues: rapid creation of network topology, portability of code in real controllers, virtual network on local PC, independence from the manufacturer of network equipment and good scalability. The creation of virtual networks based on Mininet promotes the flexible, dynamic development of network applications, allowing the creation of innovations using software.
References
1. Smelyansky R. Integrated environment for the analysis and design of distributed real-time embedded computing
systems, Programming and Computing Software, 2012, No. 9, pp. 242-254.
2. Shalimov A., Zuikov D., Zimarina D., Pashkov V., Smeliansky R. Advanced study of SDN/OpenFlow controllers, Proc. 9th Central & Eastern European Software Engineering Conference in Russia, Moscow, 2013, pp. 105-110.
3. Akyildiz F., Ahyoung L., Wang P., Min L., Chou W. A roadmap for traffic engineering in SDN-OpenFlow networks. 2014. No. 71, pp. 2-30.
4. Autenrieth A., Elbers J., Kaczmarek P. Cloud orchestration with SDN/OpenFlow in carrier transport networks, Proc. Transparent Optical Networks (ICTON), 2013 15th International Conference on. - IEEE, Bristol, 2013, pp. 274-282.
5. Quality of Service (QoS). Available at: http://www.cisco.com/c/en/us/products/ios-nx-os-software/ quality-of-service-qos/index.html.
6. ONF Specification//Open network foundation. Available at: https ://www.opennetworking.org/sdn-resources/onf-specifications.
7. Multiprotocol Label Switching Traffic Engineering Technology Overview. Available at: http://www.ciscopress. com/articles/article.asp?p=520184.
8. Karimzadeh M., Valtulina L., Applying G. SDN / OpenFlow in Virtualized LTE to support distributed mobility management (DMM), Proc. Proceedings of the 4th International Conference on Cloud Computing and Services Science, CLOSER 2014, Portugal, 2014, pp. 639-644.
9. Diego K., Fernando R., Paulo V. Towards secure and dependable software-defined networks, Proc. The second ACM SIGCOMM workshop on Hot topics in software defined networking, 2013, pp. 14-76.
10. Margaret Wasserman and Sam Hartman. Security analysis of the open networking foundation (onf) openflow switch specification. Available at: https://tools.ietf.org/id/draft-mrw-sdnsec-openflow-analysis-00.html.
11. Vidya B. Harkal A., Deshmukh A. Software Defined Networking with Floodlight Controller, Proc.International Conference on Internet of Things, Next Generation Networks and Cloud Computing, Portugal, 2016, pp. 23-27.
12. Lantz, B., Heller, B., & McKeown, N. A network in a laptop: Rapid prototyping for software-defined networks. 2010. Available at: http://conferences.sigcomm.org/hotnets/ 2010/papers/a19-lantz.pdf.
13. Cgroups technology. Available at: https://ru.wikipedia.org/ wiki/Cgroups.
14. Floodlight is an Open SDN Controller, Project Floodlight. Available at:http://www.projectfloodlight.org/ Floodlight.
15. How to Use Access Control Lists (ACLs). Available at: http://symfony.com/doc/current/security/acl.html.
Применение протокола OpenFlow на базе эмулятора сети Mininet с установкой контроллера Floodlight
В.В. Яковлев, Ж.М. Беркинбаева Петербургский государственный университет путей сообщения Императора Александра I Санкт-Петербург, РФ jakovlev@pgups.ru, berkinbayeva.zhanniyet@gmail.com
Ангел Фернандез дел Кампо Мадридский политехнический университет Мадрид, Испания afc@dit.upm.es
Аннотация. Протокол OpenFlow обеспечивает точное управление трафиком по всему спектру коммутаторов и маршрутизаторов в корпоративной среде, как физических, так и виртуальных, независимо от поставщика. Это устраняет необходимость индивидуальной настройки устройства каждого поставщика через собственный интерфейс. Mininet является платформой эмуляции сети, которая создает на одном компьютере (физическом или виртуальном) элементы инфраструктуры OpenFlow: контроллер, коммутаторы, узлы и соединения.
В статье описывается архитектура протокола OpenFlow, сообщение в протоколе, таблица потоков, базовые модули в архитектуре контроллера Floodlight и уязвимость протокола OpenFlow. Рассматриваются результаты эксперимента по проверке трех основных типов топологии сети с передачей трафика путем установки сетевого эмулятора Mininet и настройки контроллера Floodlight.
Ключевые слова: программно-конфигурируемые сети, OpenFlow, контроллер Floodlight, таблица потоков, Mininet, виртуализация сети, качество обслуживания, программируемые сети.
Литература
1. Smelyansky R. Integrated environment for the analysis and design of distributed real-time embedded computing systems / Smelyansky R. // Programming and Computing Software. - 2012. - № 9. - Pp. 242-254.
2. Shalimov A., Zuikov D., Zimarina D., Pashkov V., Smeliansky R. Advanced study of SDN/OpenFlow controllers / Shalimov A. // Proc. 9th Central & Eastern European Software Engineering Conference in Russia. - 2013. -Pp. 105-110.
3. Akyildiz F., Ahyoung L., Wang P., Min L., Chou W. / Akyildiz F//A roadmap for traffic engineering in SDN-OpenFlow networks. - 2014. - № 71. - Pp. 2-30.
4. Autenrieth A., Elbers J., Kaczmarek P. Cloud orchestration with SDN/OpenFlow in carrier transport networks/ Autenrieth A. // Proc. Transparent Optical Networks (ICTON), 2013 15th International Conference on. -IEEE. - 2013. - Pp. 274-282.
5. Quality of Service (QoS). URL: http://www.cisco.com/c/ en/us/products/ios-nx-os-software/quality-of-service-qos/index. html.
6. ONF Specification//Open network foundation. URL: https://www.opennetworking.org/sdn-resources/onf-specifications.
7. Multiprotocol Label Switching Traffic Engineering Technology Overview. URL:http://www.ciscopress.com/ articles/article.asp?p=520184.
8. Karimzadeh M., Valtulina L., Applying G. SDN / OpenFlow in Virtualized LTE to support distributed mobility management (DMM) / Karimzadeh M. // Proc. Proceedings of the 4th International Conference on Cloud Computing and Services Science, CLOSER 2014. - 2014. - Pp. 639-644.'
9. Diego K., Fernando R., Paulo V. Towards secure and dependable software-defined networks / Diego K. // Proc. The second ACM SIGCOMM workshop on Hot topics in software defined networking. - 2013. - Pp. 14-76.
10. Margaret Wasserman and Sam Hartman. Security analysis of the open networking foundation (onf) openflow switch specification. URL: https://tools.ietf.org/id/draft-mrw-sdnsec-openflow-analysis-00.html.
11. Vidya B., Harkal A., Deshmukh A. Software Defined Networking with Floodlight Controller / Vidya B. // Proc. International Conference on Internet of Things, Next Generation Networks and Cloud Computing. - 2016. - Pp. 2327.
12. Lantz, B., Heller, B., & McKeown, N. A network in a laptop: Rapid prototyping for software-defined networks. 2010. URL:http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf.
13. Cgroups technology. URL:https://ru.wikipedia.org/ wiki/Cgroups.
14. Floodlight is an Open SDN Controller, Project Floodlight. URL:http://www.projectfloodlight.org/Floodlight.
15. How to Use Access Control Lists (ACLs). URL: http://symfony.com/doc/current/security/acl.html.
Интеллектуальные технологии на транспорте. 2018. № 2
12
