Software Defined Network (SDN) Journal Resume

Resume International Journal

  A SURVEY OF PAST, PRESENT AND FUTURE 

OF SOFTWARE DEFINED NETWORKING

Created by: Pritesh Ranjan, Pankaj Pande, Ramesh Oswal, Zainab Qurani, Rajneeshkaur Bedi

Software Defined Networking is the most recent advancement, extending the idea of programmable networks. SDN framework decouples the network service from underlying implementation providing a novel approach for application to configure, operate and communicate with the network. This paper presents a study of programmable networks with emphasis on the motives and challenges of SDN. Following it we give an overview of SDN architecture its current applications and future applications.

 Software Defined Networking is a result of such necessities. SDN as an example of “programmable networks” talks of network evolution. The basic driving idea of SDN is the decoupling of data plane from control plane. Control Plane is all the logic that decides what is to be done and instructs the data (or forwarding) plane to implement the decision. Control plane has the logic of controlling and forwarding behavior like tracking topology changes, install forwarding rules, computing routes etc. Data plane on the other hand forwards traffic based on rules as dictated by control plane logic like forward, filter, buffer, rate-limit and measure packets. SDN advocate the centralization of control plane and distributed data plane. The all powerfulcentralized control plane called the controller will control all the data planes and can be implemented completely in software in software and installed on commodity hardware.

The immediate benefit of this separation is the global network view – the controller can see the status of all routes and switches quickly deciding the best route. It also helps in selecting the best egress point in an autonomous system for different flows. Another advantage is the horizontal integration in networking devices which allows for separate and independent growth of hardware and software. It also allows rapid innovation of software because many new players can work on developing controller application as long as they have a well defined API to communicate with the hardware. This approach promises more flexibility in choosing the hardware and software by the customer.

SDN ARCHITECTURE

Today’s network devices come preinstalled with software from manufacturer and leave a very little customization option for the customers. This vertical integration in traditional networks i.e. tight coupling of forwarding plane and control plane, hinder innovation. The SDN architecture splits the networking devices into data plane and control plane. Data plane is not intelligent but can perform forwarding packets very fast and efficiently. It physically carries data packets from one port to another by following rules that are programmed into the device hardware. Control plane has the responsibility of adding behavior into the device; it decides the logic to program the data plane. These two planes communicate over a secure channel over a standard protocol called OpenFlow.

OpenFlow provides an open API between control layer and application layer. This provides an abstraction for business applications to use facility provided by control layer without going into the details of their implementation. In the remainder of this section we will examine the component of the architecture namely: the infrastructure layer (switch/router), the control layer (controller), southbound API and northbound API.

Infrastructure Layer: Switch

When a packet arrives at the switch the header fields are extracted and matched for the flow entries installed in the switch, if a match is found, the corresponding action in flow entry is performed. A default action for packet handling should be provided -like packet discard, forwarding to another flow table or to the controller- which will be executed in case of table miss.

The Control Layer: Controllers

The underlying infrastructure devices are connected to controller which decides and installs the rules on switches. To cater scalability and reliability issues two approaches have been proposed , centralized and distributed. With a physically as well as logically centralized controller the switches are heavily dependent on a single controller which can become a single point of failure or bottleneck. To cater the problem of controller failure OpenFlow makes a provision for multiple replica controllers which provide backup for the controller.

In this approach not all the requests are sent to global controller but only those are forwarded which require centralized network view. The main purpose of controller is to add flow rule it can accomplish this task in following way.

Controller to Switch Message

This type includes handshake, packet_out message for installing flow entry. It also handles switch configuration, role configuration, setting asynchronous message configuration and many others. Controller to switch messages are initiated by the controller and sent to switch over a TCP connection established between switch and controller. A message of this type may or may not require a response from switch.

Following are type of controller to switch message

1. Features request/reply message – A features request message is sent by controller to get the capabilities of switch. A features reply message is sent by switch which consists of capabilities supported by it. Usually the features message is sent at the time when connection is established through OpenFlow channel.

2. Configuration- The controller can set switch’s configurations through this message. It can also query switch’s configurations via query message.

3. Modify-State – Modify state messages are sent by controller to modify state on the switches .They are used to add/delete and modify flows or group tables on switches .

4. Read-State– Read state messages are used to get switch statistics.

5. Packet-out– The controller sends this message to instruct the switch to send a packet out a particular port or enqueue it or simply drop it by not specifying any action.

6. Barrier – Controller sends this message to ensure that the message dependencies have been met. When switch receives this message it has to finish processing all previously received messages before executing any new message after the Barrier Request.

Source : http://www.ijarcsms.com/docs/paper/volume2/issue4/V2I4-0042.pdf

Resume Paper Tugas Akhir Telkom University

PERANCANGAN DAN ANALISIS SOFTWARE DEFINED NETWORK PADA JARINGAN LAN : PENERAPAN DAN ANALISIS METODE PENJALURAN PATH CALCULATING MENGGUNAKAN ALGORITMA DIJKSTRA

Karya : Brayan Anggita Linuwih, Agus Virgono, Budhi Irawan

Dalam tugas akhir ini dilakukan pembuktian penerapan layanan routing menggunakan metode path calculating algoritma dijkstra sebagai rekayasa kontrol penjaluran pada jaringan LAN berbasis Software- Defined Network dan menganalisa perbandingan kinerja metode pemilihan jalur terbaik dalam lalulintas jaringan pada jaringan LAN berbasis Software-Defined Network dengan jaringan konvensional yang juga diterapkan algoritma dijkstra dengan arsitektur yang sama namun tidak memiliki perangkat control plane. Pembuktian dilakukan dengan melakukan emulasi jaringan sebuah yang terdiri dari 11 buah switch yang saling terhubung

dengan perangkat control plane sebagai pengendali sebuah jaringan

Berikut adalah keunggulan Software-defined networking :

a. Manajemen terpusat dan kontrol perangkat jaringan dari beberapa vendor.

b. Peningkatan otomatisasi dan manajemen dengan menggunakan API.

c. Inovasi cepat melalui kemampuan untuk memberikan kemampuan jaringan baru dan jasa tanpa perlu mengkonfigurasi perangkat individu atau menunggu penjual rilis.

d. Programmability oleh operator, perusahaan, vendor perangkat lunak independen, dan pengguna (bukan hanya produsen peralatan) menggunakan pemrograman umum lingkungan, yang memberikan semua pihak peluang baru untuk mendorong pendapatan dan diferensiasi.

e. Peningkatan kehandalan jaringan dan keamanan sebagai akibat dari pengelolaan jaringan terpusat dan manajemen otomatis dari perangkat jaringan, penegakan kebijakan yang seragam, dan meminimalisir kesalahan konfigurasi yang lebih sedikit.

f. Kemampuan kontrol jaringan akan lebih rinci dengan menerapkan dengan kebijakan di tingkat sesi, pengguna, perangkat, dan aplikasi secara komprehensif.

g. Penyajian antarmuka yang lebih baik sebagai aplikasi manajemen jaringan terpus

Secara garis besar sistem tersebut ditujukan untuk menerapkan aturan penjaluran pada jaringan berbasisSoftware defined network menggunakan algoritma dijkstra. Dan selanjutnya membandingkan dua teknologi penjaluran yaitu teknologi jaringan berbasis router (konvensional) dan teknologi berbasis Software defined network. Jaringan di simulasikan dalam 2 bentuk sesuai basis teknologi yang akan diujikan. Perancangan jaringan dimulai dengan menentukan topologi yang akan digunakan, penerapan topologi pada emulator berbasis jaringan konvensional dan jaringan Software defined network, pengintegrasian komponen dalam topologi dan penerapan aturan penjaluran yaitu berbasis algoritma dijkstra.

Sistematika pengujian

berikut ini adalah rincian sistematika pengungujian dari pengujian awal dan pengujian QoS :

·         Pengujian Awal pada Pengujian penjaluran dilaksanakan dengan melakukan pengiriman paket ICMP sebesar 84 kilobyte dan tidak di berikan backround traffic. Pengujian ditentukan node sumberke node tujuan dipilih secara acak. Mewakili setiap router dengan 3 buah skenario. Untuk pengujian traceroute dilakukan dengan melakukan pengujian pada h1 sebagai node sumber dan h6 sebagai node sumber. Untuk mengetahui kinerja penjalurkan dilakukan percobaan menggunakan 3 buah skenario yang telah di tentukan. Dan akan di uji nilai end to end latency dan pemilihan jalur dari setiap skenario.

·        Pengujian QoS dilakukan menggunakan topologi custom. Dipilih h6 untuk dijadikan node tujuan pengiriman, kemudian h1 sebagai node sumber. Percobaan dilakukan sebanyak 30 kali. Pengambilan data juga diambil pada jaringan konvensional yang nantinya dijadikan bahan perbandingan dengan jaringan Software defined Network dari segi QoS.

Dalam pengukuran ini dibangkitkan trafik [2] UDP dan TCP, yaitu:

a.       Trafik Data dengan inter-departure time (IDT) konstan sebesar 100 pps dengan ukuruan paket yang terdistribusi poisson μ = 48 bytes, sehingga membutuhkan bandwidth 38,4 kbps

b.      VoIP dengan G.711 codec tanpa voice activation detection (VAD) sebanyak 100 pps dengan ukuran paket 80 bytes, sehingga membutuhkan bandwidth 70,4 kbps.

c.       Selain pemberian tiga jenis trafik tersebut secara bersamaan, dibangkitkan pula background traffic yang bervariasi (25 Mbps, 50 Mbps, 75 Mbps, dan 100 Mbps) menggunakan Iperf. Percobaan ini dilakukan untuk mengetahui pengaruh kepadatan trafik terhadap pemilihan jalur dengan melihat kualitas dari pengiriman trafik data yang sampai di penerima.

Hasil pengujian performansi penerapan algoritma dijkstra berbasis jaringan SDN menunjukkan bahwa nilai dari keempat parameter QoS masih berada pada nilai yang menjadi standar ITU-T G.1010 sertamemiliki nilai delay dan jitter yang lebih baik dibandingkan penerapan OSPF berbasis jaringan konvensional.

Nilai QoS untuk UDP pada layanan data, VoIP masing-masing bervariasi dan berada di kisaran (5.17 – 145.81) ms untuk delay, (0.05 - 0.93) ms untuk jitter, (13.22 – 73.41) kbps untuk throughput, 8,05 % - 33,81 % untuk packet loss di semua skenario yang telah dibuat. Adapun nilai QoS untuk TCP pada layanan data masingmasing bervariasi dan berada di kisaran (10.32 – 20.21) ms untuk delay, (0.5 - 3.02) ms untuk jitter, (38.12 –38.27) kbps untuk throughput di semua skenario yang telah dibuat.

Sumber: https://openlibrary.telkomuniversity.ac.id/pustaka/files/107465/jurnal_eproc/perancangan-dan-analisis-software-defined-network-pada-jaringan-lan-penerapan-dan-analisis-metode-penjaluran-path-calculating-menggunakan-algoritma-dijkstra.pdf