SKRIPSI
ANALISIS PERFORMANSI KONTROLER POX, RYU DAN ONOS PADA ARSITEKTUR SOFTWARE DEFINED
NETWORK
PERFORMANCE ANALYSIS OF POX, RYU AND ONOS CONTROLLER ON SOFTWARE DEFINED NETWORK
ARCHITECTURE
Disusun oleh
MEGA SAFIRA NURAENI 17101105
PROGRAM STUDI S1 TEKNIK TELEKOMUNIKASI FAKULTAS TEKNIK TELEKOMUNIKASI DAN ELEKTRO
INSTITUT TEKNOLOGI TELKOM PURWOKERTO
2021
SKRIPSI
ANALISIS PERFORMANSI KONTROLER POX, RYU DAN ONOS PADA ARSITEKTUR SOFTWARE DEFINED
NETWORK
PERFORMANCE ANALYSIS OF POX, RYU AND ONOS CONTROLLER IN SOFTWARE DEFINED NETWORK
ARCHITECTURE
Disusun oleh
MEGA SAFIRA NURAENI 17101105
PROGRAM STUDI S1 TEKNIK TELEKOMUNIKASI FAKULTAS TEKNIK TELEKOMUNIKASI DAN ELEKTRO
INSTITUT TEKNOLOGI TELKOM PURWOKERTO
2021
i
ANALISIS PERFORMANSI KONTROLLER POX, RYU dan ONOS PADA ARSITEKTUR SOFTWARE DEFINED
NETWORK
PERFORMANCE ANALYSIS OF POX, RYU and ONOS CONTROLLER IN SOFTWARE DEFINED NETWORK
ARCHITECTURE HALAMAN JUDUL
Skripsi ini digunakan sebagai salah satu syarat untuk memperoleh Gelar Sarjana Teknik (S.T.)
Di Institut Teknologi Telkom Purwokerto 2021
Disusun oleh
MEGA SAFIRA NURAENI 17101105
DOSEN PEMBIMBING Eka Wahyudi, S.T., M.Eng.
Nanda Iryani, S.T., M.T.
PROGRAM STUDI S1 TEKNIK TELEKOMUNIKASI
FAKULTAS TEKNIK TELEKOMUNIKASI DAN ELEKTRO
INSTITUT TEKNOLOGI TELKOM PURWOKERTO
2021
ii
HALAMAN PENGESAHAN SKRIPSI
ANALISIS PERFORMANSI KONTROLLER POX, RYU dan ONOS PADA ARSITEKTUR SOFTWARE DEFINED NETWORK
PERFORMANCE ANALYSIS OF POX, RYU and ONOS CONTROLLER IN SOFTWARE DEFINED NETWORK ARCHITECTURE
Disusun oleh Mega Safira Nuraeni
17101105
Telah dipertanggungjawabkan di hadapan Tim Penguji pada tanggal ……..
Susunan Tim Penguji
Pembimbing Utama : Eka Wahyudi, S.T., M.Eng. ( ) NIDN.
Pembimbing Pendamping : Nanda Iryani, S.T., M.T. ( ) NIDN.
Penguji 1 : Jans Hendry, S.T., M.Eng. ( ) NIDN.
Penguji 2 : Utti Marina Rifanti, S.Si., M.Sc. ( ) NIDN.
Penguji 3 : Defrianto Pratama, S.Pd., M.Si. ( )
Mengetahui,
Ketua Program Studi S1 Teknik Telekomunikasi Institut Teknologi Telkom Purwokerto
Nama Lengkap Ketua Program Studi
NIDN.iii
HALAMAN PERNYATAAN ORISINALITAS
Dengan ini saya, MEGA SAFIRA NURAENI, menyatakan bahwa skripsi dengan judul “ANALISIS PERFORMANSI KONTROLLER POX, RYU DAN ONOS PADA ARSITEKTUR SOFTWARE DEFINED NETWORK” adalah benar- benar karya saya sendiri. Saya tidak melakukan penjiplakan kecuali melalui pengutipan sesuai dengan etika keilmuan yang berlaku. Saya bersedia menanggung risiko ataupun sanksi yang dijatuhkan kepada saya apabila ditemukan pelanggaran terhadap etika keilmuan dalam skripsi saya ini.
Purwokerto, 09 September 2021 Yang menyatakan,
(Mega Safira Nuraeni)
iv
PRAKATA
Puji dan syukur penulis panjatkan kehadirat Allah SWT yang telah melimpahkan kasih dan sayang-Nya sehingga penulis dapat menyelesaikan skripsi yang berjudul “Analisis Performansi Kontroller POX, Ryu dan ONOS Pada Arsitektur Software Defined Network”.
Maksud dari penyusunan skripsi ini adalah untuk memenuhi salah satu syarat dalam menempuh ujian sarjana Teknik Telekomunikasi pada Fakultas Teknik Telekomunikasi dan Elektro Institut Teknologi Telkom Purwokerto.
Dalam penyusunan skripsi ini, banyak pihak yang sangat membantu penulis dalam berbagai hal. Oleh karena itu, penulis sampaikan rasa terima kasih yang sedalam-dalamnya kepada:
1. Bapak Dr. Arfianto Fahmi, S.T., M.T. selaku Rektor Institusi Teknologi Telkom Purwokerto.
2. Ibu Dr. Anggun Fitrian Isnawati, S.T., M.Eng. selaku Dekan Fakultas Teknik Telekomunikasi dan Elektro Purwokerto.
3. Bapak Herryawan Pujiharsono, S.T., M.Eng. selaku Kepala Program Studi S1 Teknik Telekomunikasi
4. Bapak Eka Wahyudi, S.T., M.Eng. selaku pembimbing pertama yang membantu dalam penulisan ini.
5. Ibu Nanda Iryani, S.T., M.T. selaku pembimbing kedua yang membantu dalam penulisan ini.
Purwokerto, 18 Agustus 2021
(Mega Safira Nuraeni)
V
VI
ABSTRAK
Teknologi jaringan semakin berkembang dan mengalami perubahan, perubahan tersebut salah satunya jaringan statis konvensional yang mulai digantikan dengan jaringan dinamis. Software Defined Network masuk dalam jaringan dinamis tersebut, Software Defined Network memisahkan control plane dengan data plane. Pada control plane terdapat sebuah controller, controller ini berfungsi sebagai pusat kontrol jaringan software defined network. Dalam menentukan kinerja terbaik controller dibutuhkan pengujiaan, menguji performansi controller menjadi salah satu cara dalam menentukan perbandingan kinerja pada jenis jenis controller. Pengujian ini mengujikan controller POX, Ryu dan ONOS yang diterapkan pada topologi linear dengan jumlah switch dan host yang bervariasi dari 10 switch 10 host, 12 switch 12 host, 14 switch 14 host, dan 16 switch dan 16 host dengan penambahan background traffic 50 – 200 Mbps dengan menggunakan iperf. Hasil dari penelitian Quality of Service (QoS) meliputi troughput, delay dan jitter masih dalam rekomendasi standar TIPHON. Pada controller pox menghasilkan rata rata keseluruhan nilai troughput sebesar 5.139,456 Kbits/sec, untuk nilai delay sebesar 0,078 ms dan nilai jitter sebesar 0,037 ms, pada controller Ryu menghasilkan nilai troughput sebesar 5.130,847 Kbits/sec, untuk nilai delay sebesar 0,082 ms dan nilai jitter sebesar 0,043 ms sedangkan untuk controller ONOS menghasilkan nilai troughput sebesar 5.139,468 Kbits/sec dengan nilai delay sebesar 0,100 ms dan nilai jitter sebesar 0,055 ms sehingga Controller POX memiliki kualitas lebih baik dari Ryu dan ONOS untuk semua topologi yang diujikan.
Kata Kunci: Software Defined Network (SDN), Controller, POX, Ryu, ONOS
vii ABSTRACT
Network technology is growing and undergoing changes, one of which is the conventional static network which is being replaced by a dynamic network.
Software Defined Network is included in the dynamic network, Software Defined Network separates the control plane from the data plane. In the control plane there is a controller, this controller functions as a software defined network control center. In determining the best performance of the controller, testing is needed, testing the performance of the controller is one way to determine the comparison of performance on the types of controllers. This test tested POX, Ryu and ONOS controllers which were applied to a linear topology with the number of switches and hosts varying from 10 switches to 10 hosts, 12 switches to 12 hosts, 14 switches to 14 hosts, and 16 switches and 16 hosts to add background traffic from 50 to 200.
Mbps by using iperf. The results of the Quality of Service (QoS) research including throughput, delay and jitter are still within the recommendations of the TIPHON standard. The pox controller produces an average overall throughput value of 5,139,456 Kbits/sec, for a delay value of 0.078 ms and a jitter value of 0.037 ms, the Ryu controller produces a throughput value of 5,130.847 Kbits/sec, for a delay value of 0.082 ms. and a jitter value of 0.043 ms while the ONOS controller produces a throughput value of 5139.468 Kbits/sec with a delay value of 0.100 ms and a jitter value of 0.055 ms so that the POX Controller has better quality than Ryu and ONOS for all topologies tested.
Keywords:
Software Defined Network (SDN), Controller, POX, Ryu, ONOS
VIII
DAFTAR ISI
HALAMAN JUDUL ... I HALAMAN PENGESAHAN ... II HALAMAN PERNYATAAN ORISINALITAS ... III PRAKATA ... IV ABSTRAK ... VI
ABSTRACT... VIIDAFTAR ISI ... VIII DAFTAR GAMBAR ... X DAFTAR TABEL ... XII
BAB 1 PENDAHULUAN ... 1
1.1 LATAR BELAKANG ... 1
1.2 RUMUSAN MASALAH ... 3
1.3 BATASAN MASALAH ... 3
1.4 TUJUAN ... 3
1.5 MANFAAT ... 4
1.6
SISTEMATIKA PENULISAN ... 4
BAB 2 DASAR TEORI ... 5
2.1 KAJIAN PUSTAKA ... 5
2.2 DASAR TEORI ... 9
2.2.1 S
OFTWARED
EFINEDN
ETWORK... 9
2.2.2 O
PENF
LOW... 11
2.2.3 M
ININET... 11
2.2.4 C
ONTROLLER... 12
2.2.5 POX C
ONTROLLER... 13
2.2.6 R
YUC
ONTROLLER... 13
2.2.7 ONOS C
ONTROLLER... 14
ix
2.2.8 VIRTUAL MACHINE ... 15
2.2.9 D-ITG ... 16
BAB 3 METODE PENELITIAN... 19
3.1 ALAT YANG DIGUNAKAN ... 19
3.1.1 P
ERANGKATH
ARDWARE... 19
3.1.2 P
ERANGKATS
OFTWARE... 19
3.2
ALUR PENELITIAN... 19
BAB 4 ... 31
HASIL DAN PEMBAHASAN ... 31
4.1. P
ENGUKURAN PARAMETER TROUGHPUT... 31
4.1.1 P
ENGUJIANT
OPOLOGI10 S
WITCH DAN10 H
OST... 31
4.1.2 P
ENGUJIAN TROUGHPUT PADA12
SWITCH DAN12
HOST... 33
4.1.3 P
ENGUJIAN TROUGHPUT PADA14 S
WITCH DAN14 H
OST... 34
4.1.4 P
ENGUJIAN TROUGHPUT PADA16
SWITCH DAN16
HOST... 35
4.2 P
ENGUKURANP
ARAMETERD
ELAY... 37
4.2.1 P
ENGUKURAN DELAY PADA10 S
WITCH DAN10 H
OST... 37
4.2.2 P
ENGUJIAN DELAY PADA12 S
WITCH DAN12 H
OST... 38
4.2.3. P
ENGUJIAN DELAY PADA14 S
WITCH DAN14 H
OST... 40
4.2.4 P
ENGUJIAN DELAY PADA16 S
WITCH DAN16 H
OST... 41
4.3. PENGUKURAN PARAMETER JITTER ... 43
4.3.1 P
ENGUJIAN JITTER PADA10 S
WITCH DAN10 H
OST... 43
4.3.2 P
ENGUJIAN JITTER PADA12 S
WITCH DAN12 H
OST... 44
4.3.3 P
ENGUJIAN JITTER PADA14
SWITCH DAN14 H
OST... 45
4.3.4. P
ENGUJIAN JITTER PADA16 S
WITCH DAN16 H
OST... 47
4.4. A
NALISISP
ERBANDINGANC
ONTROLLERPOX, R
YU DANONOS ... 48
BAB 5 ... 50
PENUTUP ... 50
5.1 KESIMPULAN ... 50
5.2 S
ARAN... 51
DAFTAR PUSTAKA ... 52
X
DAFTAR GAMBAR
Gambar 2.1 Arsitektur Software Defined Nework ... 10
Gambar 2.2 Arsitektur Protocol OpenFlow ... 11
Gambar 2.3 Logo Mininet ... 12
Gambar 2.4 Logo POX Controller ... 13
Gambar 2.5 Logo Ryu Controller ... 14
Gambar 2.6 Logo ONOS Controller ... 15
Gambar 2.7 Tampilan Aplikasi Virtual Machine ... 16
Gambar 2.8 Arsitektur D-ITG ... 17
Gambar 3.1 Flowchart Alur Penelitian ... 20
Gambar 3.2 Topologi Jaringan Linear dengan 10 Switch & 10 Host ... 21
Gambar 3.3 Topologi Jaringan Linear dengan 12 Switch & 12 Host ... 22
Gambar 3.4 Topologi Jaringan Linear dengan 14 Switch & 14 Host ... 22
Gambar 3.5 Topologi Jaringan Linear dengan 16 Switch & 16 Host ... 23
Gambar 3.6 Controller POX terhubung dengan mininet ... 24
Gambar 3.7 Controller ONOS terhubung dengan mininet ... 24
Gambar 3.8 Controller Ryu terhubung dengan mininet ... 25
Gambar 3.9 Script pada mininet ... 25
Gambar 3.10 Script pada mininet ... 26
Gambar 3.11 Script pada mininet ... 26
Gambar 3.12 Perintah pada Iperf ... 28
Gambar 3.13 Perintah untuk mengirimkan data pada D-ITG ... 28
Gambar 3.14 Penamaan Log file ... 29
Gambar 3.15 Perintah untuk menguraikan Log file ... 29
Gambar 3.16 Log file pengujian D-ITG ... 30
Gambar 4.1 Grafik data pengujian troughput 10 Switch & 10 Host ... 32
Gambar 4.2 Grafik data pengujian troughput 12 Switch & 12 Host ... 33
Gambar 4.3 Grafik data pengujian troughput 14 Switch & 14 Host ... 35
Gambar 4.4 Grafik data pengujian troughput 16 Switch & 16 Host ... 36
Gambar 4.5 Grafik data pengujian delay 10 Switch & 10 Host ... 38
Gambar 4.6 Grafik data pengujian delay 12 Switch & 12 Host ... 39
xi
Gambar 4.7 Grafik data pengujian delay 14 Switch & 14 Host ... 40
Gambar 4.8 Grafik data pengujian delay 16 Switch & 16 Host ... 42
Gambar 4.9 Grafik data pengujian jitter10 Switch & 10 Host ... 43
Gambar 4.10 Grafik data pengujian jitter 12 Switch & 12 Host ... 45
Gambar 4.11 Grafik data pengujian jitter 14 Switch & 14 Host ... 46
Gambar 4.12 Grafik data pengujian jitter 16 Switch & 16 Host ... 47
xii
DAFTAR TABEL
Tabel 3.1 Spesifikasi perangkat ... 19
Tabel 3.2 Skenario pengujian controller ... 23
Tabel 3.3 Background Traffic... 27
Tabel 3.4 Hasil data troughput 10 Switch & 10 Host ... 31
Tabel 3.5 Hasil data troughput 12 Switch & 12 Host ... 33
Tabel 3.6 Hasil data troughput 14 Switch & 14 Host ... 34
Tabel 3.7 Hasil data troughput 16 Switch & 16 Host ... 36
Tabel 3.8 Hasil data delay 10 Switch & 10 Host ... 37
Tabel 3.9 Hasil data delay 12 Switch & 12 Host ... 39
Tabel 3.10 Hasil data delay 14 Switch & 14 Host ... 40
Tabel 3.11 Hasil data delay 16 Switch & 16 Host ... 41
Tabel 3.12 Hasil data jitter 10 Switch & 10 Host ... 43
Tabel 3.13 Hasil data jitter 12 Switch & 12 Host ... 44
Tabel 3.14 Hasil data jitter 14 Switch & 14 Host ... 46
Tabel 3.15 Hasil data jitter 16 Switch & 16 Host ... 47
1
BAB 1 PENDAHULUAN
1.1 LATAR BELAKANG
Perkembangan jaringan yang semakin meningkat dari waktu ke waktu sehingga berimbas pada ketidak mampuan pengelola dalam mengelola aliran data dengan optimal dan sederhana. Dalam perkembangan jaringan yang meningkat ini dapat disimpulkan bahwa teknologi sangat di butuhkan dan dianggap sebagai sumber daya utama untuk menunjang aktivitas dalam segala bidang, karena internet dapat menghubungkan dan mengakses segala informasi secara otomatis tanpa melakukan prosesnya secara manual. Berbanding lurus antara bertambahnya kebutuhan internet dengan kebutuhanan perangkat serta jumlah trafik yang semakin meningkat sehingga dibutuhkan pekerjaan tambahan dalam pengelolaan arsitektur jaringan konvensional, hal tersebut yang memunculkan ide ataupun gagasan baru pada industri dalam meminimalisir suatu pekerjaan dengan menggunakan arsitektur jaringan baru yaitu Software Defined Network (SDN) [1].
Software Defined Network yang sering disebut SDN merupakan salah satu terobosan jaringan dinamis dengan paradigma baru yang bertujuan untuk mempermudah dalam mendasain, membangun dan mengelola jaringan komputer.
Pendistribusian dalam pelayanan dilakukan secara terpusat yang memudahkan pelayanan tersebut berjalan dengan efisien, otomatis dan cepat[2]. Software Defined Network ini memisahakan control plane dan data plane pada device jaringan komputer. Pada control plane terdapat controller dan pada data plane terdapat switch, router dan network device. Tujuan dari penggunaan SDN dalam pembangunan sebuah arsitektur jaringan adalah untuk mempermudah dalam memanajemen jaringan, mengurangi biaya pada pengoperasian jaringan dan menunjang dalam pengembangan serta inovasi dalam sebuah arsitektur jaringan.
Teknologi pada SDN membutuhkan sebuah protokol Open Flow yang dapat menjadi jalur penghubung antara control plane dengan data plane [3].
Teknologi pada Software Defined Network tersebut sedikit banyak
memberikan solusi untuk teknologi teknologi terbarukan yang memberikan solusi
baru dalam mempermudah proses konfigurasi perangkat. Karena konfigurasi yang
2
terpusat inilah dalam menjalankan konfigurasi dapat memiliki efisien waktu yang lebih cepat dibandingkan dengan arsitektur jaringan konvensional dikarenakan perangkat switch akan menerima informasi rute berupa table flow dari controller [4].
Control plane dan data plane dipisahkan dengan tujuan untuk memisahkan router dan switch yang terdapat pada data plane yang berfungsi untuk melakukan forwarding pada paket data. Dalam menjalankan fungsinya, data plane membutuhkan sebuah software untuk menjalankan fungsinya, software inilah yang disebut sebagai controller yang digunakan sebagai pusat untuk mengontrol jaringan. Komponen yang paling utama pada Software Defined Network adalah controller. Controller ini berfungsi untuk mengkontrol datapath dari perangkat serta bertanggung jawab mementukan dalam penanganan paket dan mengelola table flow dengan cara menambahkan isi table flow melalui secure channel [5].
Sebagai penunjang utama dalam baik dan buruknya performa untuk jaringan SDN, maka menjaganya merupakan hal yang penting. Performa yang baik akan menghasilkan sebuah sistem yang baik pula. Menjaga stabilitas controller merupakan hal yang penting juga, karena apabila terjadi kendala hingga mengalami down maka jaringan yang terdapat dibawahnya akan mengalami gangguan [6].
Unjuk kerja controller menjadi salah satu cara dalam menentukan baik maupun buruknya sebuah controller dalam bekerja. Semakin bertambahnya penelitian terhadap controller, semakin banyak juga jenis jenis controller yang berkembang seperti POX, NOX, Ryu, ONOS, Maestro, Floodlight dan masih ada beberapa jenis lain yang semakin banyak bermunculan. Pengembangan controller ini menggunakan platform yang sangat beragam, karena keberagaman inilah yang menyebabkan setiap controller memiliki performansi yang berbeda-beda [7].
Untuk melihat bagaimana kontroler bekerja, dibutuhkan beberapa parameter
yang digunakan untuk pengujian atau yang sering disebut parameter QoS, dalam
parameter QoS terdapat beberapa parameter seperti parameter troughput dan
parameter latency. Troughput adalah besaran jumlah flow per detik yang dapat
ditangani sedangkan parameter latency merupakan banyaknya respon yang
diberikan controller per detik [8]. Berdasarkan permasalahan diatas yang telah
dijabarkan, penulis melakukan penelitian berjudul “ANALISIS PERFORMANSI
3
KONTROLER POX, RYU dan ONOS PADA ARSITEKTUR SOFTWARE DEFINED NETWORK”
1.2 RUMUSAN MASALAH
Rumusan masalah dari penelitian ini adalah:
1) Bagaimana performansi parameter Quality of Service (QoS) meliputi parameter Troughput, Delay serta Jitter pada controller POX, Ryu dan ONOS terhadap perubahan Switch dan Host dengan variasi background traffic 50 – 200 Mbps ?
2) Bagaimana performansi controller POX, Ryu dan ONOS berdasarkan standarisasi TIPHON ?
1.3 BATASAN MASALAH
Batasan masalah dari penelitian ini adalah:
1) Menggunakan topologi jaringan linear
2) Pengujian parameter troughput, delay dan jitter mengacu pada standarisasi TIPHON
3) Menggunakan Iperf untuk background traffic 4) Hanya menguji controller POX, Ryu dan ONOS.
5) Tidak membahas protocol routing.
6) Tidak membahas keamanan jaringan.
7) Menggunakan Tools D-ITG sebagai network analyzer.
1.4 TUJUAN
Tujuan dari penelitian ini adalah:
1) Membangun suatu jaringan menggunakan arsitektur Software Defined Network
2) Menganalisis unjuk kerja sistem sebagai penelitian yang menjabarkan performansi beberapa controller dalam bekerja.
3) Mengetahui performa controller terbaik diantara controller yang
diujikan (POX, Ryu dan ONOS)
4 1.5 MANFAAT
Penelitian ini diharapkan dapat memberikan suatu gambaran mengenai unjuk kerja arsitektur Software Defined Network dengan menggunakan POX, RYU dan ONOS controller. Dengan pengujian performansi POX, RYU dan ONOS controller diharapkan dalam pengimplementasiannya dapat memberikan informasi bagaimana controller POX, RYU dan ONOS berkerja.
1.6 SISTEMATIKA PENULISAN
Penelitian ini terbagi menjadi beberapa bab. Bab 1 berisi latar belakang,
rumusan masalah, manfaat dan tujuan penelitian, batasan masalah dan sistematika
penulisan. Bab 2 membahas dasar teori yang terdiri atas kajian pustaka penelitian
sebelumnya dan teori mengenai Software Defined Network, Controller pada
teknologi Software Defined Network, mininet, virtual box, POX, RYU dan ONOS
controller, Tools D-ITG. Bab 3 berisi alat yang digunakan yang terdiri atas perangkat
hardware dan software, alur penelitian yang terdiri atas studi literatur, perancangan
arsitektur jaringan, konfigurasi sistem, skenario pengujian controller serta
pengambilan data. Bab 4 berisi tentang hasil simulasi dan analisis sistem
berdasarkan hasil simulasi pengukuran parameter Quality of Service (QoS) berupa
parameter Troughput, Delay dan Jitter. Pada bab 5 berisi kesimpulan yang
didapatkan dari penelitian tersebut dan saran untuk penelitian selanjutnya.
5
BAB 2 DASAR TEORI
2.1 KAJIAN PUSTAKA
Pada tahun 2020 penelitian tugas akhir Abhimata Zuhra Pramudita dan I Made Suartana yang berjudul “Perbandingan Performa Controller OpenDay Light dan Ryu pada Arsitektur Software Defined Network” [2]. Penelitian ini telah membangan sebuah arsitektur jaringan linier dengan menggunakan 8 switch, 160 host sehingga 1 switch mengelola 20 host. Dalam penelitian tersebut bertujuan untuk mengetahui performa controller Opendaylight dan controller Ryu dengan melihat pada nilai troughput, delay, paket loss yang menggunakan simulator D-ITG serta mengetahui perbandingan resourch utilization menggunakan phoronix test- suite, dengan mensimulasikan pengiriman data dengan nilai beban traffic yang berbeda yaitu 100Mb, 500Mb, 1Gb hingga 10 Gb pada sejumlah switch dan host.
Hasil dari penelitian ini controller OpenDayLight memiliki performa yang lebih baik dibandingkan dengan controller Ryu. Dengan hasil pada controller ryu rata- rata nilai troughput sebesar 325,682 Mb/s, rata-rata nilai delay sebesar 0,31335s dan untuk nilai rata-rata packet loss sebesar 4,59% sedangkan untuk hasil penelitian pada controller OpenDayLight menghasilkan nilai rata rata troughput sebesar 318,749 Mb/s, rata-rata nilai delay sebesar 0,622309s dan untuk nilai rata- rata packet loss sebesar 10,11% lalu pengujian masing-masing percobaan sebanyak 10 kali. Hasil percobaan pada pengujian Reasource Utilization pada controller OpenDayLight memiliki hasil yang lebih baik dibandingkan dengan controller Ryu, hasil itu dapat dilihat dari performa CPU dan Memory.
Pada tahun 2020 Mohamed Eltaj dan Ahmed Hassan M.Hassan pada
penelitian yang berjudul “Performance Evaluation of SDN Controller : FloodLight,
POX and NOX“ [13]. Penelitian ini bertujuan untuk mengetahui parameter rata-rata
troughput TCP/UDP, rata-rata bandwidth, packet loss, latency, topology discovery
time dan prediction impection. Dalam penelitian ini menggunkan beberapa skenario
dalam pengujian, skenario yang diterapkan berupa perubahan pada topologi
jaringan yaitu menggunakan topologi linear, topologi tree yang terdiri dari 7 switch
6
dan 12 host dan topologi custom yang terdiri dari 7 switch, 7 host dan 3 controller.
Pada semua topologi jaringan memiliki bandwidth link 1.000 Mbit/s, pengujian ini juga mengui controller dengan nilai suggestion window yang berbeda yaitu sebesar 2 Mb, 20 Mb dan 32 Mb. Hasil dari uji coba penelitian ini adalah pada pengujian troughput bahwa controller POX dan NOX memiliki troughput terbaik di semua jenis topologi yang diuji dibandingkan dengan controller FloodLight. Pada pengujian bandwidth UDP, controller POX dan NOX menghasilkan nilai yang lebih baik dibandingkan dengan controller FloodLight. Untuk pengujian Latency, controller POX menjadi controller terbaik dengan respons tertinggi per milidetik dan pengujian terakhir yaitu topology discovery yang menghasilkan bahwa controller Floodlight tercatat pada semua jenis topologi.
Pada penelitian Kukuh Nugroho dan Dhimas Prabowo Setyanugroho berjudul “Analisis Kinerja RouteFlow pada Jaringan SDN (Software Defined Network) menggunakan Topologi Full-Mesh“ yang dibuat pada tahun 2019, telah dilakukan penelitian dalam menguji kualitas jaringan pada SDN menggunakan jenis controller RouteFlow [4]. Dalam penelitian tersebut menggunakan arsitektur jaringan Full Mesh yang terdiri dari empat buah switch, empat buah komputer dan satu buah controller. Untuk menguji kualitas jaringan SDN, pada penelitian ini menggunkan dua skenario pengujian yaitu menggunakan trafik data dan tanpa menggunakan trafik data dimana terdapat dua protokol layer transport (TCP dan UDP) digunakan untuk mengirimkan data. Pada pengujian ini menggunakan skema pertukaran data dengan ukuran yang bervariasi yaitu sebesar 4,8 Mbyte, 6,4 Mbyte, 8 Mbyte, 9,6 Mbyte, 11,2 Mbyte, dan 12,8 Mbyte. Parameter QoS yang diuji yaitu parameter delay, jitter dan troughput selain menguji parameter QoS terdapat juga parameter lain yang diuji yaitu melakukan pengukuran waktu konvergensi jaringan. Hasil dari pengujian ini adalah penggunaan menggunakan protokol UDP menghasilkan nilai parameter yang lebih baik dibandingkan dengan protokol TCP, untuk waktu konvergensi sebuah arsitektur jaringan dapat dikategorikan dalam keadaan konvergen sebesar 12,18 ms.
Pada tahun 2019 penelitian oleh Tony Manuel dan Bhargavi H Gosmawi
yang berjudul “Experimenting With Scalbility of Beacon Controller in Software
Defined Network“ [9]. Dalam penelitian tersebut, menganalisa parameter QoS
7
berupa troughput dengan menggunakan Iperf. Arsitektur jaringan yang digunakan yaitu topologi Mesh yang memiliki 6 switch dimana 5 switch mengontrol 10 host dan 1 switch lainnya dihubungkan dengan 1 controller sehingga pada arsitektur tersebut terdapat 50 host. Pengujian dilakukan sebanyak 6 kali dengan skenario penelitian setiap switch mengirimkan paket dengan mengubah jumlah host disetiap pengujian. Hasil dari pengujian ini disetiap percobaan menunjukan bahwa semakin banyak jumlah switch dan host, semakin menurun nilai troughput.
Penelitian selanjutnya yang dilakukan oleh Romasenna Edgar, Ahmad Tri Hanuranto dan Osphanie Mentari pada tahun 2019 dengan judul “Perancangan dan Analisis Sistem Pada Kontroler POX, RYU, dan OpenDayLight pada Software Defined Network“ [10]. Pada penelitian tersebut menguji parameter QoS berupa delay, jitter, paket loss dan troughput pengujian lainnya yaitu resource utilization.
Desain arsitektur yang digunakan adalah topologi tree dengan tiga rancangan yang terdiri atas switch tujuh, sembilan dan sebelas. Pengujian tersebut memerlukan iperf dalam memberikan background traffic, background traffic yang diberikan yaitu 0 Mbps, 50 Mbps, 100 Mbps, 150 Mbps dan 200 Mbps . Untuk nilai parameter yang telah didapat akan dibandingkan dengan nilai yang telah ditetapkan oleh badan standarisasi ITU-T.
Pada tahun 2019 I Putu Agus Eka Pratama dan I Made Adhiarta Wikantyasa melakukan penelitian dengan judul “Implementasi dan Analisis Simulasi QoS dan Performance Device dengan Menggunakan ONOS dan Iperf3 [1]. Pada penelitian ini menggunakan topologi custom yang tediri dari 18 host dan 10 switch dengan skenario pengujian pengiriman paket TCP dan UDP menggunakan Iperf 3. Dalam penelitian tersebut telah diperoleh nilai jitter, packet loss, troughput UDP, troughput UTP serta bandwidth rata rata di setiap host yang terdapat pada topologi ini. Lalu untuk analisa terhadap device Openflow Switch diperoleh data seperti Packet Received, Packet Send, Byte Received dan Byte Send.
Dalam Penelitian pada tahun 2018 oleh Moh Wahyudi Putra, Eko Sakti
Pramukantoro dan Widhi Yahya yang berjudul “Analisis Perbandingan
Performansi Kontroler Floodlight, Maestro, Ryu, POX dan ONOS dalam Arsitektur
Software Defined Network“ [8]. Dalam penelitian tersebut, dilakukan pengujian
QoS pada parameter troughput serta latency. Pengujian tersebut menggunakan
8
simulator Cbench dengan menggunakan jumlah switch dan host yang bervariasi yaitu 200 switch dan 400 host, 40 switch dan 800 host, 60 switch dan 1600 host, 80 switch dan 3200 host, 100 switch dan 6400 host, 12 switch dan 12.800 host. Dalam pengujian ini diperoleh hasil untuk penanganan aliran data yang berfungsi mengolah data dalam jumlah yang besar, controller maestro memiliki kemampuan lebih baik dibandingkan dengan controller Floodlight, Ryu, POX dan ONOS.
Controller maestro memiliki selisih nilai troughput 500 hingga 4.000 Flow/s dan nilai latency lebih baik dibandingkan controller lain dengan selisih nilai 1.000 hingga 5.000 ms.
Pada tahun 2018 penelitian oleh Mahmood Z. Abdullah, Nasir A. Al-awad dan Fatima W. Hussein yang berjudul “Performance Evaluation and Comparison of Softwide Defined Networs Controller“ [11]. Penelitian ini menggunakan jenis topologi linier, ini dikarenakan topologi linier tidak perlu membuat topologi secara manual yang disebut dengan topologi custom atau topologi standar seperti topologi single dan topologi tree. Topologi liner digunakan untuk menguji nilai troughput, delay dan controller libfluid, ONOS, OpenDayLight, POX dan ryu dalam bekerja menggunakan Iperf. Topologi liner terdiri berbagai jumlah switch, untuk skenario yang dijalankan menggunakan switch sebanyak 8, 16, 32, 64, 128, 256, 512 dan 1.024. Hasil dari nilai troughput yaitu semakin meningkat beban kerja nilai troughput pada controller semakin menurun, pengujian ini dilakukan hingga controller berhenti merespon, untuk controller libfuid dan POX berhenti merespon ketika jumlah switch sebanyak 1.024 switch dan controller lainnya berhenti ketika jumlah switch sebanyak 512 switch untuk nilai troughput terendah dimiliki oleh controller OpenDayLight. Untuk nilai delay dilihat dari rata-rata Round Trip Time (RTT) controller meningkat sebanding dengan bertambahnya jumlah switch, untuk controller ONOS, OpenDayLight, POX dan Ryu memiliki nilai delay yang sama dengan overload beban jaringan kurang dari 4ms. Untuk controller libfluid meningkat hingga mencapai 715,73 ms pada 512 switch. Controller ONOS memiliki nilai delay yang palig rendah dan controller libfluid memiliki delay tertinggi.
Pada tahun 2018 Sm Shamin, Shahadat Shisir, Ahosanul Hasan, Mahedi
Hasan dan Arafat Hossain pada penelitiannya yang berjudul “Performance Analysis
9
of Differernt Openflow based Controller Over Software Defined Network“ [12].
Pada penelitian ini mengimplementasikan controller Ryu, POX dan Pyretic openflow dengan basis menggunakan bahasa Pyton. Penelitian ini mensimulasikan menggunakan jenis topologi tree dengan metode virtualisasi berbasis proses dan mekanisme namespace jaringan. Dari hasil uji performansi controller tersebut didapatkan bahwa controller POX memiliki Round Trip Time (RTT) rata-rata terbesar 0,185 ms dan nilai RTT minimum terbesar yaitu 0,145 ms. Controller pyretic memiliki nilai minimum sebesar 0,137 ms, nilai maksimum sebesar 0,191 ms dan RTT rata-rata sebesar 0,161 ms. Controller Ryu memiliki nilai RTT maksimum sebesar 0,175 ms. Dari hasil yang didapat bahwa Controller Pyretic menunjukkan performa yang lebih baik dibandingkan dengan controller Ryu dan controller POX.
Dalam penelitian Siska L. Hanifa dan Rikie Kartadie berjudul “Uji Performa Kontroler Software Defined Network FloodLight vs ONOS“ pada tahun 2018 [14].
Pada penelitian ini bertujuan mengetahui performansi masing- masing controller melalui parameter troughput dan latency. Topologi yang digunakan yaitu topologi single yang terdiri dari 5 host, untuk skenario yang ditetapkan yaitu dengan melakukan 5 kali pengujian di mana pada setiap pengujian jumlah switch berubah yaitu 20, 90, 120, 330 dan 450 switch. Hasil dari pengujian performa controller ini untuk parameter latency dan troughput pada kedua controller cukup baik ketika jumlah switch kurang dari 60. Pada FloodLight, nilai latency tertinggi yaitu 2.780,04 respon/detik yang terjadi saat switch berjumlah 20 sedangkan untuk controller ONOS memiliki latency tertinggi ketika berada pada 30 switch dengan respons yang diberikan sebesar 5.931 respon/detik. Nilai troughput yang dihasilkan oleh controller FloodLight sebesar 1.500,38 flow/detik saat memiliki host sebanyak 450 sedangkan untuk ONOS, nilai troughput yang diberikan saat jumlah host sebanyak 450 yaitu 354,05 flow/detik.
2.2 DASAR TEORI
2.2.1 Software Defined Network
10
Software Defined Network (SDN) adalah arsitektur jaringan komputer dengan karakteristik dinamis, manageable, consteffective serta adaptable, hal tersebut yang mendasari Software Defined Network (SDN) menjadi arsitektur baru pada bidang jaringan komputer. Dari karakteristik yang dimiliki oleh arsitektur Software Defined Network (SDN), menjadi salah satu dari sekian banyak hal yang dibutuhkan dalam memenuhi aplikasi saat ini yang bersifat dinamis serta memiliki kebutuhan bandwidth tinggi. Dalam arsitektur Software Defined Network terdiri dari tiga layer, yaitu Application plane, Controller plane dan Data Plane [15].
Software Defined Network (SDN) menjadi sebuah paradigma baru untuk mengontrol serta memanajemen jaringan komputer. SDN memisahkan control plane dengan data plane, dengan adanya pemisahan tersebut seorang administrator dapat memodifikasi protokol di sepanjang perangkat jaringan [16].
Gambar 2.1 Arsitektur Software Defined Network [8].
Pada arsitektur Software Defined Network yang terdapat pada gambar 2.1 terdiri dari komponen, yaitu infrastuktur, kontrol dan aplikasi. Pada infrastruktur terdapat elemen elemen jaringan yang digunakan untuk mengatur SDN data patch.
Terdapat komponen berupa kontrol yang didalamnya terdapat controller untuk
mentranslasikan kebutuhan aplikasi dan infrastruktur dengan cara memberikan
intruksi-intruksi yang disesuaikan dengan SDN Datapath dan controller ini dapat
memberikan informasi yang relevan. Aplikasi berada pada layer ketiga, sesuai
dengan namanya, layer ini berisi aplikasi aplikasi yang digunakan pada
infrastruktur Software Defined Network yang berkomunisi dengan sistem melalui
North Bound Interfaces (NBI) [8].
11 2.2.2 Open Flow
Openflow pada gambar 2.2 adalah protokol yang terdapat pada arsitektur Software Defined Network yang bertugas sebagai jalur komunikasi control layer dengan data layer. Open flow bertugas memeberi akses serta mengatur forwarding plane yang terdapat pada switch dan router. Dilihat dari tugas yang dimiliki oleh openflow, ketika paket yang dikirimkan pada switch openflow tidak memiliki entri flow yang sesuai maka switch tersebut akan meneruskan paket menuju controller.
Gambar 2.2. Arsitektur Protocol OpenFlow
Controller akan melakukan drop pada paket paket yang tidak sesuai dengan flow lalu controller akan menambahkan entri flow pada table flow untuk paket serta mengintruksikan switch untuk meneruskan paket tersebut dengan entri flow yang baru. Hal tersebut yang mendasari open flow bertugas menjadi jembatan komunkasi yang diatur melalui controller yang akan memberikan respon terkait setiap paket yang akan datang [17].
2.2.3 Mininet
Pada gambar 2.3 menujukan logo dari mininet, dimana mininet sendiri
merupakan jaringan openflow, mininet menjadi simulator open source yang
pertama. Mininet juga menjadi tools simulator yang sering digunakan pada jaringan
openflow. Mininet mengemas jaringan menjadi sebuah viritual machine yang dapat
diunduh, dijalankan, diperikasa serta dimodifikasi oleh semua kalangan.
12
Gambar 2.3. Logo Mininet
Keuntungan yang diberikan oleh mininet yaitu baik untuk prototyping yang mudah untuk dibagiakan dan mudah untuk digunakan [18]. Mininet menjadi sebuah emulator yang menggunakan pendekatan secara virtual pada host, router, switch dan link. Sebagai salah satu emulator jaringan yang realistis, mininet dapat membuat topologi jaringan yang cukup kompleks dengan sumber daya yang sedikit dengan menerapkan virtualisasi untuk menjalankan banyak host dan switch namun hanya menggunakan satu kernel OS. Dalam penggunaannya, mininet ini memanfaatkan virtual software switch OpenSwitch yang digunakan dalam membangun berbagai macam jenis topologi pada OpenFlow Software Defined Network [17].
2.2.4 Controller
Ide terbaru pada arsitektur Software Defined Network adalah kemampuan
dalam program, memisahkan antara control plane dan data plane, tidak kalah
pentingnya ketika mengelola status jaringan sementara dengan menggunakan
kontrol terpusat. Pada sebuah jaringan, controller ini merupakan wujud dari
kerangka kerja Software Defined Network yang diidealkan. Secara teori, controller
menjadi salah satu elemen vital yang mewujudkan bidang kontrol terdistribusi serta
dapat membantu dalam pengawasan pada sebuah arsitektur jaringan. Berbagai
vendor komersial dan industri pengembangan saling berkompetisi dalam
mengembangkan performa controllernya. Terdapat banyak controller yang tersedia
pada Software Defined Network, beberapa controller bersifat open source namun
ada beberapa controller lain adalah hak milik oleh vendor. Contoh controller yang
bersifat open source adalah OpenDayLight, ONOS, Project Calico, Beacon,
NOX/POX, Project Floodlight (lisensi beacon dan apache), OpenVSwitch (OVS),
Ryu (oleh lab NTT), Faucet (Ryu berbasis python untuk jaringan produksi),
OpenContrail [19].
13
2.2.5 POX ControllerGambar 2.4 Menunjukan logo dari POX controller yang masuk dalam kategori open source yang menggunakan Bahasa python. POX secara resmi dapat digunakan pada Windows, Mac OS serta Linux. POX ini beroperasi sebagai switch, router, load balancing, perangakat firewall dan masih banyak lainnya.
Gambar 2.4. Logo POX Controller
POX juga menyediakan arsitektur yang baik dalam arsitektur Software Defined Network, beberapa kelebihan yang ada pada controller POX :
a. Dapat Menyediakan antarmuka Pythonic OpenFlow.
b. Memiliki komponen sampel yang dapat digunakan kembali dalam pemilihan jalur, penemuan topologi, dll.
c. Controller POX dapat digunakan pada sistemm operasi apapun yang telah diinstall simulator mininet.
d. Mendukung Graphical User Interface (GUI) yang sama dan arsitektur virtual yang serupa dengan NOX.
e. Controller POX lebih baik dibandingkan dengan NOX versi sebelum POX.
Script pada controller POX dapat diunduh dengan mudah pada Gudang POX yang terletak Github, script pada Command Line Interface (CLI) serta script lain yang digunakan untuk controller POX dapat ditemukan didalamnya [20].
2.2.6 Ryu Controller
14
Ryu adalah salah satu jenis controller yang berada pada arsitektur Software Defined Network. Pada gambar 2.5 Menunjukan logo dari controller RYU, secara umum fungsi controller sama untuk software defined network yaitu meningkatkan kemampuan jaringan serta mengkontrol jaringan. Ryu termasuk dalam controller dalam kategori open source yang telah dikembangkan NTT.
Gambar 2.5. Logo RYU Controller
Pada RYU Application Program Interface (API) dapat dikembangkan dengan mudah, Ryu menggunakan bahasa python sengga mudah dalam penggunakaanya. Controller Ryu ini memiliki banyak dokumentasi, dokumentasi inilah yang digunakan peneliti dalam mengembangkan dan menjadikan referensi dalam memecahkan masalah dalam penerlitian. Controller Ryu mendukung beberapa protocol pada arsitektur Software Defined Network seperti OpenFlow, Netconf, OF- config dan lainnya [21].
2.2.7 ONOS Controller
Open Network Operating System (ONOS) yang terdapat pada gambar 2.6
adalah salah satu dari sekian banyak controller yang diimplementasikan pada
arsitektur Software Defined Network, ONOS termasuk dalam controller open
source yang berorientasi dengan jaringan operator.
15
Gambar 2.6. Logo ONOS Controller
ONOS menggunakan Bahasa pemograman Java menggunakan OSGi dalam memanajemen fungsionalitas serta pada setiap fitur yang terdapat dalama ONOS diaktifkan dengan menggunakan Apache. ONOS diliris pada tahun 2014 yang diprakarsai dan dibuat oleh On. Lab, ONOS menjadi salah satu controller yang banyak digunakan pada arsitektur software defined network [22].
2.2.8 VIRTUAL MACHINE
Virtual Machine (VM) merupakan salah satu software yang digunakan dalam menjalankan program serta menerapkan aplikasi. Pada gambar 2.7 Merupakan tampilan software virtual machine Sehingga dapat menerapkan beberapa sistem operasi dalam satu komputer, setiap sistem operasi menjalankan serta terpisah dengan vm lainnya. Software virtual machine ini banyak digunakan dalam menerapkan cloud, di era ini layanan cloud public mengunakan virtual machine hal ini karena menyediakan sumber daya aplikasi virtual pada banyak user dalam bidang komputasi virtual machine ini hemat biaya dan lebih fleksibel.
Virtual Machine (VM) menjalankan sistem operasi sama seperti sistem operasi
utama namun benar-benar terpisah dari jendela aplikasi di desktop.
16
Gambar 2.7. Tampilan Aplikasi Virtual Machine
Software VM ini mendukung dalam mengakomodasi kebutuhan dalam menjalankan perangkat lunak yang memerlukan sistem operasi yang berbeda maupun menguji aplikasi pada lingkungan sandbox yang aman. Virtual Machine telah digunakan pada virtualisasi server yang memungkinkan dalam mengkonsolidasikan sumber daya komputasi, virtual machine ini juga dapat melakukan tugas yang dianggap beresiko seperti mengakses data yang teinfeksi virus. Karena virtual machine ini terpisah dengan sistem utama, maka bagaimanapun kondisi sistem operasi yang terletak pada virtual machine tidak akan merusak sistem operasi utama [23].
2.2.9 D-ITG
Distributed Internet Traffic Generator (D-ITG) merupakan sebuah platform
yang dapat menghasilkan traffic dengan menganut pada platform dengan akurat
karena pola traffic tersebut sudah ditentukan oleh waktu keberangkatan pada paket
atau Inter Departure Time (IDT) serta pada proses stokastik Packet Size (PS).
17
Gambar 2.8. Arsitektur D-ITG
Pada Gambar 2.8 menunjukkan sebuah arsitektur yang dimiliki oleh D-ITG, pada gambar tersebut terlihat hubungan antara platform yang disediakan oleh D- ITG. Berikut merupakan penjabaran tiga komponen utama yang terdapat pada arsitektur D-ITG :
a. ITG Send
ITG send merupakan sebuah komponen pengiriman pada D-ITG. Pada ITG Send dapat beroperasi pada tiga mode yang berbeda yaitu :
1. Mode aliran tunggal, ITG send hanya menghasilkan satu aliran saja.
Satu utas tersebut bertanggung jawab dalam membangkitkan arus serta memanajemen dari saluran sinyal melalui protokol TSP.
2. Mode beberapa aliran, ITG send menghasilkan satu set arus, pada mode ini beroperasi sebagai aplikasi dengan satu utas yang menerapkan prokol TSP mendorong proses pembuatan dan utas lain menghasilkan traffic
3. Mode daemon, pada mode ini ITG Send dikelola melalui jarak jauh oleh ITGManager menggunakan ITGApi. Dalam mengumpulkan data yang dihasilkan pada saat proses pembangkitan ITGSend baik secara lokal maupun jarak jauh menggunakan server ITGLog.
b. ITG Recv
Pada ITGRecv bekerja sebagai daemon. Saat permintaan koneksi TSP
datang, ITGRecv bertanggung jawab dalam mengelola komunikasi
18
dengan pengirim. ITGRecv dapat menyimpan informasi baik secara lokal maupun dalam jarak jauh dengan menggunakan ITGLog server log.
c. ITGLog
ITG Log merupakan server log yang bekerja pada server yang berbeda dengan host yang dimiliki ITGSend dan ITGRecv, ITGLog menyimpan serta menerima informasi log dari pengirim dan penerima. Hal tersebut ditangani oleh signaling protocol, protocol ini memungkinkan setiap pengirim dan penerima untuk mendaftar dan meninggalkan server log.
Informasi log dapat dikirim dengan TCP dan UDP [24].
19 BAB 3
METODE PENELITIAN
3.1 ALAT YANG DIGUNAKAN
Dalam pembuatan sistem ini dibutuhkan software dan hardware untuk menunjang penelitian dalam mendapatkan data data yang pada akhirnya akan diolah untuk dianalisis. Perancangan sistem ini bertujuan untuk mempermudah dalam menguji parameter QoS dalam skalabilitas controller POX.
3.1.1 Perangkat Hardware
Perangkat hardware yang digunakan dalam pembuatan sistem ditunjukkan pada tabel 3.1
Tabel 3.1 Spesifiksi Perangkat
Perangkat Spesifikasi
Sistem Operasi Windows 10
Processor Intel Celeron CPU N3060
RAM 4 GB
3.1.2 Perangkat Software
Perangkat software yang dibutuhkan dalam menunjang terbangunnyam sistem ini adalah sebagai berikut:
a. Virtualbox digunakan dalam membuat virtualisasi sistem operasi tambahan yang digunakan dalam sistem operasi utama. Virtual machine yang digunakan pada penelitian ini yaitu pada versi
b. Mininet digunakan untuk membuat jaringan serta mensimulasikan data plane pada SDN. Mininet akan digunakan pada sistem operasi ubuntu versi 14.04 LTS
c. Controller POX, RYU, ONOS digunakan untuk mengkontrol seluruh infrastruktur jaringan
d. D-ITG dan Iperf digunakan untuk membangkitkan trafik saat melakukan proses pengujian
3.2 ALUR PENELITIAN
20
Pada gambar 3.1 menunjukkan alur pengujian yang dijalankan dengan melalui beberapa tahap meliputi studi literatur, merancang arsitektur jaringan, melakukan konfigurasi sistem, pengujian controller, pengambilan data dan menganalisa data
Gambar 3.1. Flowchart Alur Penelitian a. Studi Literatur
Pada gambar 3.1 merupakan alur penelitian yang akan dilaksanakan dalam penelitian ini, pada tahap awal yang dilakukan yaitu studi literatur. Hal yang dilakukan dalam studi literatur yaitu melakukan pengumpulan referensi, materi, penelitian yang akan diajukan sebagai acuan dan tolak ukur dalam melakukan penelitian ini.
Tujuan lain dalam melakukan studi literatur yaitu pengembangan
penelitian dari penelitian sebelumnya sehingga terdapat inovasi inovasi
terbarukan. Pengumpulan materi dapat berupa jurnal, e-book, buku, dan
website-website rujukan lainnya.
21 b. Perancangan Arsitektur Jaringan
Pada pengujian ini, arsitektur jaringan yang digunakan yaitu topologi liner dengan menempatkan 1 controller pada topologi yang memiliki switch dan host yang berbeda. h menunjukan host, s menunjukkan switch dan c0 menunjukan controller yang digunakan, penghubung antara switch dan host berlaku sebagai protocol openflow Pada perancangan arsitektur jaringan ini menggunakan 4 topologi dengan menerapkan 1 network yang sama serta jenis topologi yang sama dan terdiri dari 10 switch, 12 switch, 14 switch dan 16 switch.
Gambar 3.2. Topologi Linear dengan 10 Switch dan 10 Host
Pada gambar 3.2 menunjukan topologi linear dengan
menggunakan 10 switch dan 10 host, pada setiap host terhubung dengan
switch dan switch tersebut terhubung dengan semua switch serta satu
buah controller.
22
Gambar 3.3. Topologi linear dengan 12 switch dan 12 host
Pada gambar 3.3 menunjukan topologi linear dengan menggunakan 12 Switch dan 12 Host, setiap switch terhubung dengan dengan host dan pada setiap switch terhubung dengan switch lainnnya serta satu buah controller.
Gambar 3.4. Topologi linear dengan 14 switch dan 14 host
Gambar 3.4 menunjukan topologi linear dengan menggunakan
14 switch dan 14 host. Setiap host terhubung dengan satu switch dan
setiap switch terhubung dengan switch lainnya serta satu buah
controller.
23
Gambar 3.5. Topologi linear dengan 16 switch dan 16 host
Pada gambar 3.5 menunjukan topologi linear dengan menggunakan 16 switch dan 16 host. Sama dengan pada pengujian pada topologi sebelumnya, setiap host terhubung dengan satu switch dan setiap switch terhubunga dengan switch lainnya serta satu buah controller.
Tabel pengalamatan untuk host yang digunakan pada saat menjalankan simulasi terdapat pada tabel 3.2. Apabila dalam membangun arsitektur jaringan mengalami kegagalan maka dilakukan perbaikan pada script program yang dijalankan.
Tabel 3.2 Skenario Pengujian Controller
Topologi Linear Awal Tujuan
Host IP Address Host IP Address 10 Switch dan Host Host – 10 10.0.0.10 Host - 1 10.0.0.1 12 Switch dan Host Host – 12 10.0.0.12 Host - 1 10.0.0.1 14 Switch dan Host Host – 14 10.0.0.14 Host - 1 10.0.0.1 16 Switch dan Host Host – 16 10.0.0.15 Host - 1 10.0.0.1
c. Konfigurasi sistem
Sistem yang digunakan adalah melakukan konfigurasi pada
mininet. Mininet digunaan dalam pembuatan topologi jaringan,
menghubungkan controller POX, Ryu dan ONOS yang akan
disimulasikan pada pengujian ini. Pada gambar 3.6 menunjukan
topologi linier yang dibuat pada mininet telah terhubung dengan
controller POX, pada gambar 3.7 menunjukan tampilan controller
24
ONOS pada web yang telah terhubung dengan mininet, pada gambar 3.8 menunjukan controller Ryu yang telah terhubung dengan mininet. Pada gambar 3.5 hingga gambar 3.7 menunjukan script yang dibuat dengan menggunakan mininet.
Gambar 3.6. Controller POX terhubung dengan mininet
Gambar 3.7. Controller ONOS terhubung dengan mininet
25
Gambar 3.8. Controller Ryu terhubung dengan mininet
Gambar 3.9. Script pada mininet
26
Gambar 3.10. Script pada mininet
Gambar 3.11. Script pada mininet
d. Skenario Pengujian Controller
Pada simulasi ini terdapat beberapa skenario pengujian yang
digunakan dalam mendapatkan nilai QoS untuk membandingkan
performansi pada controller yang digunakan yang diterapkan pada 4
topologi jaringan. Pada topologi 3.2 h1 dan h10 digunakan sebagai
komunikasi data yang akan diamati, h1 berperan sebagai penerima
trafik data dan h10 sebagai pengirim trafik data sedangkan h9 dan h2
digunakan sebagai pembangkit background traffic h9 sebagai user dan
h2 sebagai server, pada topologi 3.3 h1 dan h12 digunakan sebagai
komunikasi data yang akan diamati, h1 berperan sebagai penerima
27
trafik data dan h12 sebagai pengirim trafik data sedangkan h11 dan h2 digunakan sebagai pembangkit background traffic h11 sebagai user dan h2 sebagai server, pada topologi ketiga yang terdapat pada gambar 3.4 h1 dan h14 digunakan sebagai komunikasi data yang akan diamati, h1 berperan sebagai penerima trafik data dan h14 sebagai pengirim trafik data sedangkan h13 dan h2 digunakan sebagai pembangkit background traffic h13 sebagai user dan h2 sebagai server, pada topologi yang terakhir yang terdapat pada gambar 3.5 h1 dan h16 digunakan sebagai komunikasi data yang akan diamati, h1 berperan sebagai penerima trafik data dan h16 sebagai pengirim trafik data sedangkan h15 dan h2 digunakan sebagai pembangkit background traffic h15 sebagai user dan h2 sebagai server. Pada pengujian ini, host yang digunakan sebagai komunikasi data yang akan diamati menggunakan tools D-ITG sedangkan host yang digunakan sebagai pembangkit background traffic menggunakan Iperf.
Nilai background traffic yang digunakan bervariatif sesuai dengan yang diuraikan pada tabel 3.3 serta pengujian diterapkan pada topologi yang berbeda bertujuan untuk melihat pengaruh bertambahnya switch dan host pada performansi dalam jaringan. Untuk setiap background traffic yang diujikan, dilakukan pengujian sebanyak 30 kali. Dalam kurun waktu 20 detik pada setiap percobaan, dari percobaan tersebut dapat diambil hasil data untuk dilakukan analisa nilai QoS.
Tabel 3.3 Besaran Background Traffic
Protokol Data
Besar Data (Mbyte)
Besar Background Traffic (Mbps)
UDP 12,8
50
100
150
200
28
Gambar 3.12 Perintah pada Iperf
Pada gambar 3.12 menunjukan perintah yang dijalankan dengan menggunakan iperf untuk membangkitkan background traffic, pada perintah -u merupakan jenis paket yang dikirimkan adalah paket UDP sedangkan untuk -c menunjukan bahwa host 9 berlaku sebagai user dan disertakan ip server sebagai penerima, untuk -t merupakan waktu yang digunakan untuk mentransmiskan data, yaitu selama 20 detik dan -b merupakan bandwidth
e. Pengambilan data
Pengujian dilakukan untuk mendapatkan nilai parameter QoS troughput, delay dan jitter. Data yang akan digunakan dalam pengujian menggunakan protocol UDP dalam pengujiannya menggunakan tools bernama D-ITG. Pada D-ITG seluruh pengujian akan disimpan pada log file, dalam log file ini terdapat beberapa jenis paramater yang diujikan.
Penelitian ini bertujuan untuk membandingkan unjuk kerja controller POX, Ryu dan ONOS yang diterapkan pada topologi dengan jumlah switch dan host yang berbeda dan background traffic yang berbeda.
Gambar 3.13. Perintah untuk mengirimkan data pada D-ITG.
Pada gambar 3.13 merupakan salah satu contoh pengiriman data
pada topologi dengan 10 host. Pada script di atas h10 berperan sebagai
pengirim data karena pada script yang dijalankan terdapat perintah
ITGSend, untuk -a menunjukan bahwa host yang berperan sebagai
penerima data memiliki alamat ip 10.0.0.1, -T menunjukan protocol
yang digunakan saat melakukan pengujian, pada pengujian diatas
menggunakan protocol UDP, untuk perintah -C merupakan jumlah
paket yang dikirimkan setiap detiknya dan pada perintah di atas paket
29
yang dikirimkan sebanyak 10 paket per detik, pada perintah -c merupakan paket yang dikirimkan dari h10 menuju h1 yaitu sebesar 64.000 byte sehingga besar data yang dikirimkan menjadi 12,8 MByte dan bernilai konstant terhadap background traffic yang berubah untuk perintah -t yaitu waktu yang dibutuhkan dalam melakukan pengiriman trafik data, pada pengujian ini dibutukan waktu 20.000 ms atau 20 s dan pada script terakhir terdapat perintah -x yang mana perintah tersebut digunakan untuk menyimpan file hasil pengujian atau yang disebut log file pada host penerima data.
Gambar 3.14. Penamaan Log file
Pada gambar 3.14 terdapat script yang menunjukan perintah ITGRecv yang mana perintah tersebut digunakan untuk menerima data dan file.log tersebut untuk membuat file sebagai tempat tersimpannya hasil pengujian setiap data
Gambar 3.15. Perintah untuk menguraikan Log file
Pada perintah gambar 3.15 ITGDec merupakan perintah yang
digunakan untuk menguraikan log file dan nama file.log digunakan
untuk melihat parameter – parameter hasil uji.
30
Gambar 3.16 Log File pengujian D-ITG
Pada gambar 3.16 merupakan log file pengujian D-ITG, pada
log file tersebut tersimpan informasi – informasi yang berisi parameter
QoS berupa jumlah waktu yang dibutuhkan, minimal delay, maksimal
delay, rata rata delay, rata rata jitter, rata rata bitrate semua pengujian
tersebut akan tersimpan pada log file dan akan dianalisa.
31 BAB 4
HASIL DAN PEMBAHASAN
Dalam penelitian ini, mengujikan performansi beberapa jenis controller yang digunakan dalam jaringan Software Defined Network dengan mengujikan tiga jenis controller yaitu controller POX, Ryu dan ONOS. Pengujian performansi menggunakan protocol UDP pada topologi linear dengan jumlah switch dan host yang berubah. Pengujian ini dilakukan dengan mengkomunikasikan dua buah host yang akan diujikan yang terdapat pada skema yang terdapat pada gambar 3.2, 3.3, 3.4 dan 3.5, dengan pengujian menggunakan background traffic sebesar 50Mbps, 100Mbps, 150Mbps dan 200Mbps. Pengujian ini dilakukan selama 20 detik dengan setiap detiknya mengirimkan 10 paket data dan setiap background traffic diujikan sebanyak 30 kali. Untuk membangkitkan background traffic menggunakan iperf sedangkan untuk mengirimkan besar data menggunakan tools D-ITG, dalam D-ITG tertera hasil parameter QoS, dalam penelitian ini menganalisa parameter troughput, delay dan jitter yang akan dibandingkan pada hasil nilai setiap controller. Hasil data dari pengujian QoS ini akan dianalisa menggunakan standarisasi pada TIPHON.
4.1. PENGUKURAN PARAMETER TROUGHPUT
Troughput dari penelitian yang diambil dari log file yang tersimpan pada host server, semakin besar nilai troughput yang didapatkan pada sebuah pengujian jaringan maka semakin bagus pula kualitas sebuah jaringan tersebut. Dalam pengujian parameter troughput memiliki satuan Kbits/sec. Pada pengujian ini membandingkan nilai parameter troughput pada controller POX, Ryu dan ONOS dengan menggunakan topologi linear yang memiliki jumlah switch dan host yang berbeda.
4.1.1 Pengujian Topologi 10 Switch dan 10 Host
Pada tabel 4.1 menunjukan grafik data dengan pengujian menggunakan controller POX, Ryu dan ONOS dengan menggunakan pengujian background traffic 50Mbps, 100Mbps, 150Mbps dan 200Mbps.
Tabel 4.1. Hasil data troughput 10 switch dan 10 host
Nswitch & NHost
Besar Trafik (Mbps)
POX (Kbits/sec)
RYU (Kbits/sec)
ONOS
(Kbits/sec)
32 10 Switch & 10 Host
50 5.138,285 5.131,776 5.139,034 100 5.141,357 5.132,200 5.140,465 150 5.139,268 5.130,486 5.139,439 200 5.138,913 5.128,925 5.138,935
Gambar 4.1 Grafik data pengujian troughput 10 switch dan 10 host Pada pengujian pertama menggunakan background traffic sebesar 50Mbps, controller POX menghasilkan nilai troughput sebesar 5.138,285 Kbits/sec dan mengalami rata rata peningkatan tertinggi pada pengujian menggunakan background traffic sebesar 100 Mbps menjadi 5.141,357 Kbits/sec, kemudian mengalami penurunan nilai troughput pada pengujian background traffic 150 Mbps menjadi 5.139,268 Kbits/sec dan terjadi penurunan kembali pada pengujian background traffic sebesar 200 Mbps menjadi sebesar 5.138,913 Kbits/sec.
Pengujian menggunakan controller Ryu pada background traffic 50 Mbps menghasilkan nilai troughput sebesar 5.131,776 Kbits/sec dan pada pengujian background traffic 100 Mbps kembali mengalami peningkatan menjadi sebesar 5.132,200 Kbits/sec, namun ketika pengujian menggunakan background traffic 150 Mbps terjadi penurunan troughput menjadi sebesar 5.130,486 Kbits/sec dan kembali mengalami penurunan pada pengujian background traffic 200 Mbps menjadi sebesar 5.128,925 Kbits/sec. pada pengujian menggunakan controller ONOS menghasilkan nilai troughput sebesar 5.139,034 Kbits/sec pada pengujian
5122 5124 5126 5128 5130 5132 5134 5136 5138 5140 5142 5144
50 Mb 100 Mb 150 Mb 200 Mb
Bandwidth (KBIts/sec)
Troughput 10 Switch & 10 Host
POX RYU ONOS
![Gambar 2.1 Arsitektur Software Defined Network [8].](https://thumb-ap.123doks.com/thumbv2/123dok/3345881.3805067/24.893.320.698.510.756/gambar-arsitektur-software-defined-network.webp)
