CC BY
70
Технічні науки
Scientific Journal «ScienceRise» №3/2(3)2014
11. Diakov, V. P. (2007). Soil deformation mechanism and model the critical speed of loading. Advances in science and technology of agriculture, 10, 51-53.
12. Phan, Xuan Dung (1992). Substantiation of the parameters of the rotary cultivator working body propasnogo. Tashkent, 17.
13. Shamota, V. A. (1986). Justification shape and size of processing row spacing Garden. Kishinev : Science, 92-95.
14. Matryshko, V. M. (1999). Research results mills with vertical axis rotation Kyiv : NAU, 5, 245-250.
Рекомендовано до публікації д-р техн. наук Дмитриков В. П.
Дата надходження рукопису 28.09.2014
Прасолов Євген Якович, кандидат технічних наук, кафедра безпеки життєдіяльності, Полтавська державна аграрна академія, вул. Сковороди, 1, м. Полтава, Україна, 36003 E-mail: [email protected]
Крьока Максим Вікторович, Полтавська державна аграрна академія, вул. Сковороди, 1, м. Полтава,
Україна, 36003
E-mail: [email protected]
Левін Володимир Валер’янович, Полтавська державна аграрна академія, вул. Сковороди, 1, м. Полтава,
Україна, 36003
E-mail: [email protected]
UDC 621.391
DOI: 10.15587/2313-8416.2014.27459
TESTING AND ANALYSIS SDN TECHNOLOGY ©Taher Abdullah
The Software Defined Networking (SDN) is currently one of the most promising technologies in mobile backhaul networks based on the OpenFlow protocol. OpenFlow provides a specification to migrate the control logic from a switch into the controller. In this paper we apply Mininet software to verify the OpenFlow protocol messages. Keywords: SDN openflow protocol, switch, Mininet, Wireshark
Software Defined Networking (програмно-конфігурована мережа) (SDN) є в даний час однією з найбільш перспективних технологій в мобільних мережах транзитних з’єднань на основі протоколу OpenFlow. OpenFlow надає специфікацію для перенастроювання керуючої логіки від комутатора в контролері. У даній роботі ми застосовуємо програмне забезпечення Mininet для перевірки повідомлення протоколу OpenFlow.
Ключові слова: протокол OpenFlow програмно-конфігурованої мережі (або протокол OpenFlow SDN), комутатор, Mininet, Wireshark
1. Introduction
Software Defined Networking (SDN) is a new approach in networking Technology, designed to create high level abstractions on top of which hardware and software infra-structure can be built to support new cloud computing applications. SDN is also referred to as programmable network, since it isolates control plane from data plane and pro-vides an independent and centralized unit to control the network [1].
OpenFlow protocol follows SDN approach, and gives programmable control of flows to network administrators to define a path that a flow takes from source to destination regardless of the network topology, and utilizes flow based processing for forwarding packets. OpenFlow has gathered significant interest among developers and manufacturers of network switches, routers, and servers.
The original idea of SDN described in was born at Stanford University around 2005. The SDN concept brings the separation of network device features to the control plane, and the data plane [2]. While the control plane is programmatically accessible through well-
defined API (Application Programming Inter- face), data plane ensures a data processing according to the rules uploaded to the device. OpenFlow has been developed since 2007, and the first protocol specification was approved in 2009. Lately the development was adopted by the Open Networking Foundation (ONF) consortium.
SDN Slack Operating System
Fig. 1. A SDN approach to separate several layers and introduce transparency of the network
57
Технічні науки
Scientific Journal «ScienceRise» №3/2(3)2014
The protocol defines the structure of control messages and it describes the way how messages are exchanged. OpenFlow is based on the centralized approach with a controller as a main driving element. This controller runs a software platform with the API enabling the direct control of data flows in a network.
Fig. 2. Main components of an OpenFlow switch [2]
Network intelligence is (logically) centralized in software-based SDN controllers, which maintain a global view of the network. As a result, the network appears to the applications and policy engines as a single, logical switch [3]. With SDN, enterprises and carriers gain vendor independent control over the entire network from a single logical point, which greatly simplifies the network design and operation. SDN also greatly simplifies the network devices themselves, since they no longer need to understand and process thousands of protocol standards but merely accept instructions from the SDN controllers. Perhaps most importantly, network operators and administrators can programmatically configure this simplified network abstraction rather than having to hand-code tens of thousands of lines of configuration scattered among thousands of devices. In addition, leveraging the SDN controller’s centralized intelligence, IT can alter network behavior in real-time and deploy new applications and network services in a matter of hours or days, rather than the weeks or months needed today. By centralizing network state in the control layer, SDN gives network managers the flexibility to configure, manage, secure, and optimize network resources via dynamic, automated SDN programs. Moreover, they can write these programs themselves and not wait for features to be embedded in vendors’ proprietary and closed software environments in the middle of the network. In addition to abstracting the network, SDN architectures support a set of APIs that make it possible to implement common network services, including routing, multicast, security, access control, bandwidth management, traffic engineering, quality of service, processor and storage optimization, energy usage, and all forms of policy management, custom tailored to meet business objectives. For example, an SDN architecture makes it easy to define and enforce consistent policies across both wired and wireless connections on a campus.
2. Software-defined networking
The SDN architecture is remarkably flexible; it can operate with different types of switches and at different protocol layers [4]. SDN controllers and switches can be implemented for Ethernet switches (Layer 2), Internet routers (Layer 3), transport (Layer 4) switching, or application layer switching and routing. SDN relies on the common functions found on networking devices, which essentially involve forwarding packets based on some form of flow definition.
An OpenFlow Switch consists of one or more flow tables and a group table, which perform packet lookups and forwarding, and an Open Flow channel to an external controller [5]. The switch communicates with the controller and the controller manages the switch via the Open Flow protocol. Using the Open Flow protocol, the controller can add, update, and delete flow entries in flow tables, both reactively (in response to packets) and proactively. Each flow table in the switch contains a set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to apply to Matching packets.
First matching entry in each table is being used. If a matching entry is found, the instructions associated with the specific flow entry are executed. If no match is found in a flow table, the outcome depends on configuration of the table-miss flow entry: for example, the packet may be forwarded to the controller over the OpenFlow channel, dropped, or may continue to the next flow table. Instructions associated with each flow entry either contain actions or modify pipeline processing. Actions included in instructions describe packet forwarding, packet modification and group table processing. Pipeline processing instructions allow packets to be sent to subsequent tables for further processing and allow information, in the form of metadata, to be communicated between tables. Table pipeline processing stops when the instruction set associated with a matching flow entry does not specify a next table; at this point the packet is usually modied and forwarded. Flow entries may forward to a port. This is usually a physical port, but it may also be a logical port defined by the switch or a reserved port defined by this specification. Reserved ports may specify generic forwarding actions such as sending to the controller, flooding, or forwarding using non-OpenFlow methods, such as "normal" switch processing , while switch-defined logical ports may specify link aggregation groups, tunnels or loopback interfaces. Actions associated with flow entries may also direct packets to a group, which specifies additional processing. Groups represent sets of actions for flooding, as well as more complex forwarding semantics (e. g. multipath, fast reroute, and link aggregation). As a general layer of indirection, groups also enable multiple flow entries to forward to a single identifier (e. g. IP forwarding to a common next hop). This abstraction allows common output actions across flow entries to be changed efficiently. The group table contains group entries; each group entry contains a list of action buckets with specific semantics dependent on group type. The actions in one or
58
Технічні науки
Scientific Journal «ScienceRise» №3/2(3)2014
more action buckets are applied to packets sent to the group. Switch designers are free to implement the internals in any way convenient, provided that correct match and instruction semantics are preserved. For example, while a flow entry may use an all group to forward to multiple ports, a switch designer may choose to implement this as a single bitmask within the hardware forwarding table. Another example is matching; the pipeline exposed by an OpenFlow switch may be physically implemented with a number of hardware tables.
3. SDN In MININET Program
3. 1. Mininet Program
Mininet is a network emulator which creates a network of virtual hosts, switches, controllers, and links. Mininet hosts run standard Linux network software, and its switches support OpenFlow for highly flexible custom routing and Software-Defined Networking [6].
Mininet supports research, development, learning, prototyping, testing, debugging, and any other tasks that could benefit from having a complete experimental network on a laptop or other PC. Mininet provides an easy way to get correct system behavior (and, to the extent supported by your hardware, performance) and to experiment with topologies.
Mininet networks run real code including standard Unix/Linux network applications as well as the real Linux kernel and network stack (including any kernel extensions which you may have available, as long as they are compatible with network namespaces.) Because of this, the code you develop and test on Mininet, for an OpenFlow controller, modified switch, or host, can move to a real system with minimal changes, for real-world testing, performance evaluation, and deployment. Importantly this means that a design that works in Mininet can usually move directly to hardware switches for line-rate packet forwarding.
We will need to install these files individually. The files include virtualization software, a SSH-capable terminal, an X server, and the VM image. The tutorial image is distributed as a compressed VirtualBox image (vdi). VirtualBox enables you to run a virtual machine inside a physical machine, and is free and available for Windows, Mac and Linux [7]. 3
3. 2. Message between Controller with Switch by Open flow Protocol
The communication between the controller and switch happens using the OpenFlow protocol, where a set of defined messages can be exchanged between these entities over a secure channel [8]. The secure channel is the interface that connects each OpenFlow switch to a controller. The Transport Layer Security (TLS) connection to the user-defined (otherwise fixed) controller is initiated by the switch on its power on. The controller's default TCP port is 6633. The switch and controller mutually authenticate by exchanging certificates signed by a site-specific private key. Each switch must be user-configurable with one certificate for authenticating the controller (controller certificate) and
the other for authenticating to the controller (switch certificate).
The OpenFlow protocol supports three message types, controller-to-switch, asynchronous, and symmetric, each with multiple sub-types[9]. Controller-to-switch messages are initiated by the controller and used to directly manage or inspect the state of the switch. Asynchronous messages are initiated by the Switch and used to update the controller of network events and changes to the switch state. Symmetric Messages are initiated by either the switch or the controller and sent without solicitation. The message types used by OpenFlow are described below. Can we see this message by wireshark program in Fig. 3.
Message between controller and switches by wireshark program Fig 3.
> Symmetric
Symmetric messages are sent without solicitation, in either direction.
Hello: Hello messages are exchanged between the switch and controller upon connection startup.
Echo: Echo request/reply messages can be sent from either the switch or the controller, and must return an echo reply. They are mainly used to verify the liveness of a controller-switch connection, and may as well be used to measure its latency or bandwidth.
Experimenter: Experimenter messages provide a standard way for OpenFlow switches to offer additional functionality within the OpenFlow message type space. This is a staging area for features meant for future OpenFlow revisions.
> Controller-to-Switch
Features: The controller may request the
capabilities of a switch by sending a features request
У CapturingІгспіЬ(ІИрЬкк) fiVirtihcrklMU
file fit yien Jo Capture jjmlyic Statistics Wepheny Joels
ІііаЮ(ЙІ!зНХ8іК*Ф*їі'іі'ЄІєі«ІВІ
I Е-ртисп... clitr Sava
680 24. 155379QQ(127. H.l 7Д а ашппцр.д.о.і
758 24.669075QQ(fe8Q::ec62:«)ff:fi 7W 24 66992900(127,0.6.1
Bff ?8 67»54flWfaaB;;ac62 adffifi 827 28.67252900(127.0.6.1 8» ?8 ?154150Ot f *00 »*b iff f f t
8M 28.81624600! 117.9.8.1 819 32 55320100(fe!0::Wtb2df:fl ви зг.зззвоввві127.0.0.1 918 Э2.ОД0800Ое90::ес&«ИМ<
»1 t! ?7ia25GGC 44:52 *d:2f:41:41
74 HlUo (5"l (88)_______________
74 Hello (SM| (88)
74 Features fan) (83)
242 Features Мї ІС8ИІ І176ВІ______________________________________________________
13B Part Status (Ml) 164B)________________________________________________________
134 Picket In (AMI (Buf 10256; (9981 ■> Router Solicitation hoi ee:(2:ed:2f41.ee 98 Packet Out (OH) I9uf№2!6) (2461
154 Packet In (AM) ISufIt»257) (SSfll .> Router Solicitation Iron 3S:ib:2f:H:lc:»
98 Picket But (OH) HufI0 257) (2481
174 Picket In (AM) |0ufl(fc250) (lSSfi) -> Multicast Listener Report Hessigg v2 90 Packet Out (CSM) IBufD-2591 (2461
»4 Picket m (AM) №№3391 (ВВІ Router seUcitotion fm ее e; ea ;f 41 и
90 Picket Out IC8M) (Buf 10 259) (249)______________________________________________
134 Picket In (AM) №№260) (8881 *> Reuter BoUcitltion free 92:ib:2f:(7:lc $7
90 Picket Out (CSM) №10260) (246)_____________________________________________
174 Picket In (AMI №№261) (10961 *> MultidSt Listener Report Message v2
30 Picket Out (rap IBuflMBl) (246)____________________________________________
154 Picket In (AM) IBufID-262) (9881 Router Solicitation hoi ee:62:ed:2Ml.et
90 Picket Out (СОН) <ЭиР1Р=Д63) (2461_________________________________________
154 Picket In (AM) IBufIMM) [88911> Router Solicitetion from a2:ib:2f:f7;lc:67
90 Pickit Out К SHI I Buf 10269) (2461________________________________________
74 Echo Request (8И) (90)
74 Echo Reply (SMI 188)
DFPtUP 120 Picket In (AM) I Buf 7№ 264) (БОБІ => Hhc his 10.0.0.2» 7*11 10.0,0,1
984 37 2732590Є!32;іЬ:2И7Тс:67 ii;B2:«d 41:« OFPtARP 126 Picket In (AM) №10=26!) (6361 *> 10,0,0,2 n it 32 * 2l:f7;le;67
OPPelCIF 192 Picket In (AM) №№266) (116ВІ «> Echo (ping) reqwit кМОіОбЗЗ, Jef1/236, tt>64
QFP*ICIff 192 Packet In (AMI IBufID-267) (11661 -> Echo (ping) r®ly id-QnQ{93, serl/256, ttl-64
ice fIqu Rqd (дм) (sag)
74 Echo Request ISM) (98) 74 Echo Mr (9M) 199)
90 00 V) 00 00 ЄЄ 09 00 4! <0
$ |Id (loopback); «live ceptun in ргортн» Pill ft” )| Pedes 4634 Displayed; 80 Marked 0
Fig. 3. Controller/switch messages are initiated by the controller and may or may not require a response from the switch
59
Технічні науки
Scientific Journal «ScienceRise» №3/2(3)2014
Configuration: The controller is able to set and query configuration parameters in the switch.
Modify-State: Modify-State messages are sent by the controller to manage state on switches.
Read-State: Read-State messages are used by the controller to collect various information from the switch, such as current Configuration, statistics and capabilities.
Packet-out: These are used by the controller to send packets out of a specified port on the switch, and to forward packets received via Packet-in messages.
Barrier: Barrier request/reply messages are used by the controller to ensure message dependencies have been met or to receive notifications for completed operations.
Role-Request: Role-Request messages are used by the controller to set the role of its OpenFlow channel, or query that role.
Asynchronous-configuration: The Asynchro-
nous-configuration message are used by the controller to set an additional filter on the asynchronous messages that it wants to receive on its OpenFlow channel, or to query that filter.
• Asynchronous
Asynchronous messages are sent without a controller soliciting them from a switch. Switches send asynchronous messages to controllers to denote a packet arrival, switch state change, or error. The four main asynchronous message types are described below.
Packet-in: Transfer the control of a packet to the controller. For all packets forwarded to the controller reserved port using a flow entry or the table-miss flow entry, a packet-in event is always sent to controllers.
Flow-Removed: Inform the controller about the removal of a flow entry from a flow table
Port-status: Inform the controller of a change on
a port.
Error: The switch is able to notify controllers of problems using error messages.
3. 3. Controller Adds Flow Entries In Switch
The Openflow switch, consists of a flow table containing flow entries, used to perform packet lookup and forwarding and a secure channel to the controller, through which Openflow messages are exchanged between the switch and the controller [10]. Can we see flow entries by by Mininet in Fig.4.
^ switch: si (root)
resign intt-vti;*# dpctl durtp-Plcw ttp: 127,0.0.1:6634 I
stats.reply <xid=0x5F9910b)? flags=nohe typi-l(floy) I
«<Лів=0, Jurat ion.»c=55s, duration.n»c=KSOWWte, tabl#mid=0. priority^, I n.pacl(.ets=59. n_bytes=56fl4, idle.ti»eout^O-harcl-tirieoiJit=0Jicrrip,in-port=l,dl-wl*l rt=toffffpdL5rc=Je:69s71t9b?5b;28pdLd3t=fa:f5:8cte2?5e;JC|pnw_5rc=l|5.|).|).l,n*Lcb.p icnf_tapf=^(cap_wd«=*,«tifli4=oytpyt:^
dL^at,foh_hsae=5S10Md№,, tabli_id=0,, priority^, n_F4ckrts=50, ri_bytes=5S84, ldlt_tlPisoiJt=6C|J,hard_ti*,i»ijt=01,lc№/in_pcrf't=21rdl_vla nsQfcffff,dlesrcsfаіfSiSeie2;Sa; 50 ,dLdst^Sa;69;71?ЗЬїЄЬї 28 ,питвгег10#0,2, nw.ds t=10.0.0.1,n4-tos^xWricivHt!jpe=0f icnpeccdeM},actiore=oijtputtl wo*;ic=0r duretiwv.wc=5C*, diration.nwc=5C9C|№Wfe, tabbjd=0, priority1), rt_WCktt*s2, п_ЬаМї=Є4, ldle_t(Beftrt=eo,K^d.t1iie0vt?(i,#rp,|n_p0^^dLtflWs0ir f f f f, d l_src=f a: fS:8a; *2:5a; 30, d l.dst=3a: 63:71: 9h ’ЛЬ’ 28, rw_s«=10.0. fl, 2, nu_ds fcslft *0*0*1 ,nif_pr0to=bactlon&=oijbput;l
І ccaktoQ, Jurat ion_»c=50s, duration_reflc=4El9Q£)0£)00s, tabl*_id=0, prJority=0, ln.packrte=2, n.bytas=B4, idle.tiweoiA=0O,hard.tir*«Jt=O,arp,irLPort=l,dlj/l«=O)c lffff,dl.5rt=3a:6$i7ll9bl5bl2fl,dLdst=ffl:f^lSc1cJlS*l3C|,riiii,5M:=lC|.C|.0.1,nitii.dst=l|J I .0.0.2pn«_prrtfl^,«tions=flytpYt:2
Cflpki^G, diM‘aticirt_rt$ec=S29Mt||ltHls1, tflblOd=0, priority^,
n patkttsci, n bytas=42, Idle tlfltout=0O,hird tiwoiJt-0,airp,(n p6rl=2,dl у1мї=0*. і ffff1rdl_arc=fa:fS;8eie2i5a:501rdLdst=Sa:63i71i3bi5b:281rritf_arc=10IC|I0*2,nu_dst=l&
+0+0 *1 ,n«.pro№2,act lons^output; 1 “ rooi-&Fiininat-v*i"* I
Fig. 4. Flow entries
Main components of a flow entry in a flow table [11].
• Match fields: to match against packets. These consist of the ingress port and packet headers, and optionally metadata specied by a previous table.
• Priority: matching precedence of the flow entry.
• Counters: updated when packets are matched.
• Instructions: to modify the action set or pipeline processing.
• Timeouts: maximum amount of time or idle time before flow is expired by the switch.
• Cookie: opaque data value chosen by the controller. May be used by the controller to filter flow statistics, flow modification and flow deletion. Not used when processing packets.
4. Design topologies in Mininet
The SDN emulator needs topologies that are defined in Python for its execution, since all topologies available quite similar structure, parsing them to generate executable Mininet topologies is possible with ease. Topologies to be used in Mininet are executable/loadable Python classes interfacing with the Mininet API. So each usable Mininet topology is similar, having the same content in the head and the tail of a file. The difference between executable and loadable files is in the code at the end of the Python script. If the topology is executed from a Linux shell, Mininet is automatically started with the topology defined and secure shell (SSH) access available. Loaded means that Mininet was started alone from the Linux shell and the topology was given as a calling argument via the topo parameter. The code that defines SSH access to the topology nodes is not executed, only the part defining that the topology is used. In return this means using the topology just by loading SSH access is not available. So the preferred usage is to directly execute the topology from a Linux shell.
Mininet can use. An adjustment of the bandwidth in M bps is also possible by setting the B.w value of all edges to the given value. Further, the parser requires the files to be located in the same directory and without specifying input parameters the program will terminate. However, some values can be omitted, like the bandwidth limitation, which is otherwise initialized to 10M bps. If omitted, the remote controller IP is initialized with”10.0.2.2”, which is the standard IP for the host OS when using Oracle Virtualbox for virtualization.
4. 1. Opendaylight controller
OpenDaylight is an open source project with a modular, pluggable, and flexible controller platform at its core. This OpenFlow controller is implemented strictly in software and is contained within its own Java Virtual Machine (JVM). As such, it can be deployed on any hardware and operating system platform that supports Java.
OpenDaylight is a community to promote and/or propose standardization of SDN northbound APIs, so that services that use an open flow controller can be written quickly and effectively. This controller is based on OSGi (Open Serices Gateway initiative) framework
60
Технічні науки
Scientific Journal «ScienceRise» №3/2(3)2014
and it exposes REST (Representational State Transfer - a web based) API.
The controller platform itself contains a collection of dynamically pluggable modules to perform needed network tasks. There are a series of base network services for such tasks as understanding what devices are contained within the network and the capabilities of each, statistics gathering, etc. In addition, platform oriented services and other extensions can also be inserted into the controller platform for enhanced SDN functionality.
The southbound interface is capable of supporting multiple protocols (as separate plugins), e. g. OpenFlow 1.0, OpenFlow 1.3, BGP-LS, etc. These modules are dynamically linked into a Service Abstraction Layer (SAL). The SAL exposes device services to which the modules north of it are written. The SAL determines how to fulfill the requested service irrespective of the underlying protocol used between the controller and the network devices [12].
4. 2. Internet Traffic Generator (D-ITG)
To evaluate the performance of Mininet D-ITG in version 2.8.0-rc1 was used: “Distributed Internet Traffic Generator (D-ITG) is a platform capable to produce traffic that accurately adheres to patterns defined by the inter departure time between packets (IDT) and the packet size (PS) stochastic processes” [13]. Therefore, it offers a rich variety of probability distributions for the traffic generation and uses some models proposed to emulate sources of various protocols. With it, it is possible to generate various packet streams and collect
statistics with a logging server. Important modules of the D-ITG are depicted. The ITGSend module is responsible for the traffic generation, while the ITGRecv module is the sink for the packets, which are delivered over a Data Channel. To collect logging information both, the ITGSend and ITGRecv are communicating via a Log Channel with the ITGLog module. For remote control the ITGManager offers the functionalities to adjust parameters of ITGSend through the Signaling Channel.
4. 3. Measurement Trials
Fig. 5 depicts the topology of our measurement trials. S1 to S6 are the switches in the topology, while Sender/Receiver denote the hosts that are handling generated traffic. On each sender a ITGSend process is called to generate the traffic, while on each receiver ITGRecv handles the receipt of the packets. Besides, the log server collects the relevant statistical data of the hosts by running an instance of ITGLog. S4 is shutdown for a few measurement trials and therefore all dashed links are unavailable. To sum up, in total we performed trials, each for TCP and UDP with a duration of one minute for each trial.
The D-ITG decoder provides data files that can be analyzed with MatLab. Initially, every trial is evaluated and plotted as shown in Fig. 6. In the plots, graphs show specific characteristics in the time sequence from 0 s to 60 s. In more detail, the upper left plot depicts the throughput in M bps, while the upper right shows the delay in ms. The lower left plot is evaluating the jitter value in ms.
Fig. 5. Topology in in web interface controller
61
Технічні науки
Scientific Journal «ScienceRise» №3/2(3)2014
Irau^iput
С'ЕІіу
M-MM It — —і—t
•4i7Tm "ГГІТТІ
M M і
, 1 [_±_J 1 1 Mill Ш ~T —M-f-M M M 1
M-4-4-4-M МММ D.‘ 1 M M 1 —f-4-f-M
'■ГГТТТ1 M M m і 01 M M 1 ГТТТТ1
10 2D ЗО 10 lime [s]
10 a 3D 40 50
йпк[е]
b
Fig. 6. Evaluation of traffic with a constant test bitrate of 10Mbps. The delay within the edges of the SDN topology is 1ms: a-Traffic generation over TCP b -Traffic generation over UDP
a
5. Conclusion & future work
This paper presents SDN technology We have analyzed all messages between switch open flow and controller and captured in wireshark, Allows us to understand the relationship between controller and
switch openflow and relationship between switches.
In second part we have used the simulators mininet and built by the new topology Consists of 6 switches and 6 host in the Python languages, all this devices controlled by opendaylight controller and D-ITG program for Generate traffic between devices we show the results in graphs.
References
I. Khatri, V. (2013). Khatri vikramajeet analysis of openflow protocol in local area net- degree programme in information technology. Tampere university of technology, 74.
2. Hegr, T., Bohac, L., Uhlir, V., Chlumsky, P. (2013). OpenFlow Deployment and Concept Analysis. Information and communication technologies and services,
11 (5), 327-335.
3. Open New York Foundation Software-Defined Networking (2012). The New Norm for Networks.
4. Octopress, M. T.-P. (2013). A Quarterly Technical Publication for Internet and Intranet Professionals. A Quarterly Technical Publication for Internet and Intranet Professionals.
5. Open Networking Foundation (2013). OpenFlow Switch Specification, 1-205.
6. Mininet Team-Powered by Octopress (2014). Mininet Overview. Available at: http://mininet.org/overview/
7. Openflow (2011). Explain all the requirements to run Mininet.
8. Azodolmolky, S. (2013). Software Defined Networking with OpenFlow. Packt Publishing, 153.
9. Open Networking Foundation (2014). OpenFlow Switch Specification, 4, 1-171.
10. Kontesidou, G., Zarifis, K. (2009). Openflow Virtual Networking: A Flow- Based Network Virtualization Architecture Openflow Virtual Networking: A Flow-Based. Royal Institute of Technology.
II. Technical Solution Guide (2013). HP OpenFlow Protocol Overview, 18.
12. Opendaylight. Available:
http://www.opendaylight.org/ project/tech nical-overview
13. S. Avallone, S., Guadagno, S., Emma, D. (2004). D-ITG Distributed Internet Traffic Generator. University’s di Napoli Federico II COMICS Lab, Department di Informatics e Sistemistica, 4.
Рекомендовано до публікації д-р техн. наук Тіхонов В. І.
Дата надходження рукопису 25.09.2014
Taher Abdullah, PHD, Telecommunication systems department, Odessa National Academy of Telecommunications named after O. S. Popov, Ukraine E-mail: [email protected]
62
