Fakultas Ilmu Komputer
Implementasi Routing Berbasis Algoritme Dijkstra Pada Software Defined
Networking Menggunakan Kontroler Open Network Operating System
Faizal Ramadhan1, Rakhmadhany Primananda2, Widhi Yahya3
Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1ichaloned@gmail.com, 2rakhmadhany@ub.ac.id, 3widhi.yahya@.ub.ac.id
Abstrak
SoftwareDefinedNetworking adalah sebuah paradigma baru yang muncul dalam industri jaringan untuk mengatasi permasalahan jaringan komputer saat ini seperti konfigurasi yang sulit karena menggunakan konfigurasi tingkat rendah dan perangkat visual yang terbatas. Menyebabkan bereksperimen dan implementasi protokol jaringan baru sangatlah sulit dan jaringan pun sulit dikelola. Konsep dari jaringan SDN adalah melakukan decouple atau memisahkan antara controlplane dan data plane pada router atau
switch. Kontroler ONOS menawarkan kelebihan dapat memberikan high-availability (ketersediaan yang tinggi), scalabe, dan perfomance sekelas carrier pada jaringan komputer. Algoritme Dijkstra’s shortest path adalah salah satu dari algoritme routing. Performa routing yang berbasis algoritme Dijkstra
shortest-path pada jaringan SDN yang menggunakan kontroler ONOS menghasilkan latency sebesar 0,092 ms dengan menggunakan fungsi geoDistance dan latency sebesar 0,097 ms dengan menggunakan fungsi linkMetric. Dapat disimpulkan bahwa latency akan semakin besar nilainya bersamaan semakin panjangnya path yang digunakan untuk berkomunikasi antar host. Sedangkan hasil pengujian performa kontroler SDN ONOS saat menjalankan routing berbasis algoritme Dijkstra serta menanggapi suatu kegagalan pada link jaringan menghasilkan bahwa kontroler ONOS dapat memberikan perfoma yang baik pada jaringan yang membutuhkan infrastruktur dengan jumlah kombinasi 20 switch dan 40 host, dan rata-rata waktu convergence kontroler ONOS yang dibutuhkan untuk mendapatkan jalur yang baru adalah sebesar 1,405s.
Kata kunci: SDN, ONOS, algoritme routing, dijkstra, performa kontroler, konvergensi.
Abstract
Software Defined Networking is a new paradigm that emerging in networking industry to solve today’s computer network problem such as the difficult configuration because it used low-level configuration as well as limited visual devices. By using the SDN network, the network will have advantages such as easy to developing and experimenting of new protocols, easy to manage, and ease the network to adapt when there is infrastructure changes. Controller is an important part of the SDN network, because the controller has function to control the login in SDN network. ONOS is a controller that offers the advantage delivering high-availablity, scalable, and bring performace as good as carrier grade class.
Dijkstra’s shortest path algorithm is one of the routing algorithms. Dijkstra’s shortest path routing performance on SDN network using ONOS controller produces lantecy time 0,092 ms using geoDistance function and latency time 0,097 using linkMetric function. This concluded latency time will increase along with the lenght the path used for communicate between hosts. Meanwhile the performance test result of ONOS controller while running Dijkstra algorithm as well as responding to fail path on the network link resulted that ONOS controller provide good performance on the network that requires infrastructure with combination of 20 switches and 40 hosts, and the average convergence time that ONOS needed to build new path is 1,405s.
Keyword: SDN, ONOS, routing algorithm, dijkstra, controller performance, convergence
1. PENDAHULUAN
Jaringan komputer saat ini telah menjadi jaringan yang sukses, namun masih memiliki
bereksperimen dan implementasi protokol jaringan baru sangatlah sulit. Software Defined Networking (SDN) adalah sebuah paradigma baru yang muncul dalam industri jaringan untuk mengatasi kelemahan jaringan tradisional yang kompleks serta sulit dikelola.
Konsep dari jaringan SDN adalah melakukan decouple atau memisahkan antara
control plane dan data plane pada router atau
switch. Dengan menggunakan jaringan SDN, jaringan akan memiliki kelebihan contohnya seperti memudahkan pengembangan dan eksperimen protokol baru, mudah dikelola, serta memudahkan jaringan beradaptasi saat terjadi perubahan infrastruktur (Hu, et al., 2014).
Kontroler merupakan sebuah bagian penting pada SDN, karena kontroler memiliki fungsi untuk mengatur logika dalam jaringan SDN tersebut. Salah satu kontroler yang di kenal adalah Open Network Operating System
(ONOS). ONOS dikembangkan oleh ON.LAB (The Open Networking Lab). ONOS memiliki kelebihan dapat memberikan high-availability
(ketersediaan yang tinggi), scalabe, dan
perfomance sekelas carrier provider (AT&T, NTT Communication) pada jaringan komputer. ONOS juga menyediakan sebuah tampilan berupa web responsif yang berfungsi untuk operator agar dapat memonitoring jaringan yang sedang berjalan (ON.LAB, 2014). ONOS di kembangkan menggunakan Bahasa pemrograman JAVA sehingga dapat dikembangkan pada berbagai jenis sistem operasi.
Pada penelitian (Karami & Akhtarkavan, 2015) berjudul “Improving OSPF Protocol based Latency : A new algorithm based on Dijkstra by using OSPF existing Metrics in SDN networks”, menjelaskan bahwa pencarian shortest-path
pada jaringan SDN yang diemulasikan pada simulator OMNET dapat dilakukan dengan menggunakan algoritme Dijkstra. Namun, simulator yang digunakan pada penelitian ini adalah Mininet sebagai emulasi jaringan SDN.
Dalam penelitian (Kim, et al., 2016) berjudul “OFMon: OpenFlow Monitoring System in ONOS Controllers”, telah menganalisa bagaimana penggunaan resource
CPU dan Memory saat menggunakan kontroler ONOS, tetapi pada penelitian ini menggunakan algoritme Dijkstra sebagai analisis routing.
Algoritme Dijkstra’s shortest path adalah salah satu dari algoritme routing. E.W. Dijkstra melakukan sebuah penelitian untuk menyelesaikan masalah penentuan jalur
terpendek dari titik ke titik tujuan. Algoritme ini dapat menemukan jalur terpendek dalam satu waktu sekaligus pada sebuah titik dan titik tujuan tersebut (Morris, 2004).
Dari penjelasan diatas diperlukan analisis bagaimana hasil algoritme Dijkstra yang di implementasikan sebagai algoritme routing. Pada penelitian ini menggunakan ONOS sebagai kontroler pada SDN dengan topologi jaringan Internet2 untuk mengukur hasil perjalanan node (predecessor node), latency sebagai bentuk performasi kontroler, dan fail path sebagai penguji algoritme routing untuk mencari jalur terpendek lain. Dengan menggunakan Mininet sebagai emulasi jaringan SDN. Diharapkan hasil analisis penelitian ini dapat membantu untuk mengembangkan SDN.
2. DASAR TEORI
2.1Software Defined Network
Software Defined Network (SDN) adalah sebuah perangkat yang memisahkan antara
control plane dari sebuah jaringan dari fowarding plane-nya, dan dimana sebuah control plane mengatur beberapa alat. SDN adalah arsitektur yang bersifat dinamis, mudah dikelola, hemat biaya, dan mudah beradaptasi, sehingga cocok untuk digunakan pada jaringan yang memiliki banwidth tinggi seperti aplikasi yang dinamis seperti saat ini. Arsitektur ini memisahkan antara kontrol jaringan dan fungsi fowarding untuk memungkinankan jaringan dapat diprogram secara langsung dan untuk menjadi sebuah pemisah dari aplikasi dan layanan jaringan. Protokol OpenFlow adalah elemen dasar untuk membangun solusi SDN vendor (Foundation, n.d.).
2.2 Open Flow
2.3 Algoritme Dijkstra
Algoritme Dijkstra bermula dari titik-titik graf yang memiliki sebuah jarak tertentu. E.W. Dijkstra melakukan sebuah penelitian untuk menyelesaikan masalah penentuan jalur terpendek dari titik ke titik tujuan. Sebuah jalur terpendek dapat dinamakan single-source shortest path. Algoritme ini dapat menemukan jalur terpendek dalam satu waktu sekaligus pada sebuah titik dan titik tujuan tersebut (Morris, 2004). Dapat dilihat pada Gambar 1 merupakan bentuk pseudocode algoritme Dijkstra.
Gambar 1 Pseudocode Algoritme Dijkstra
2.4 Open Network Operating System (ONOS)
Open Network Operating System (ONOS) adalah open source SDN operating system yang pertama kali yang menargetkan secara spesifik kepada Service Provider dan mission critical network. ONOS dibuat untuk memberikan high availability, scale-out, dan performance pada jaringan jika dibutuhkan. Sebagai tambahannya, ONOS telah menciptakan abstraksi Northbound
dan API untuk memungkinkan pengembangan aplikasi lebih mudah dan abstraksi Southbound
dan interface untuk memungkinkan untuk kontrol OpenFlow pada perangkat keras. Berikut adalah kelebihan kontroler ONOS:
1. Membawa fitur kelas carrier provider
(skala, ketersediaan, dan performa) untuk pesawat control SDN
2. Memungkinkan untuk memonitoring dengan Web-Style
3. Membantu service provider untuk memigrasikan jaringan yang ada ke jaringan yang baru.
2.5 Topologi Internet2 Network (Abilene)
Topologi Abilene merupaka topologi yang memiliki jaringan backbone High-perfomance atau berkemampuan tinggi yang direkomendasikan oleh Project Internet2.
Awalnya topologi ini menghubungkan 11 daerah yang terdapat pada United States. Topologi pada jaringan ini memiliki kecepatan 10Gbps konektifitas antara titik
atau node yang bertetangga dan kecepatan 100Mbps konektifitas antara titik dengan host. Bentuk gambaran topologi Abilene digambarkan pada Gambar 2.
Gambar 2 Topologi jaringan Internet2 (Abilene)
2.6 Mininet
Mininet adalah sebuah emulator bersifat open source yang mendukung protokol OpenFlow
untuk arsitektur SDN. Mininet salah satu alat yang populer yang digunakan untuk riset SDN oleh komuniti. Mininet menggunakan pendekatan virtualisasi untuk membuat sebuah jaringan yang terdiri dari hosts, switches, kontroler, dan links. Jaringan realitas secara virtual. Sebuah sistem operasi yang memvirtual sebuah sumber daya dengan proses abstraksi, Mininet menggunakan process-based
virtualisasi untuk mengemulasikan entitas pada kernel satu sistem operasi dengan menjalankan kode secara nyata, termasuk standar aplikasi jaringan, kernel nyata dari sistem operasi, dan tumpukan jaringan. Oleh karena itu, desain yang berkerja dengan baik memungkinkan untuk langsung diterapkan pada perangkat keras yang sebenarnya (Jiang, et al., 2014).
2.7 CBench
CBench (kontroler benchmark) adalah program yang khusus digunakan untuk menguji performa OpenFlow Controller dengan menghasilkan packet-in event untuk flow baru. CBench mengemulasikan sekelompok switch yang terkoneksi dengan kontroler, mengirim pesan packet-in, dan mengamati flow-mods
terdorong. CBench dapat mengukur dengan 2 macam model ukuran, yaitu throughput dan
latency
Mode latency: Sama seperti mode throughput
namun, untuk mode ini switch yang dibuat oleh CBench secara emulasi akan mengirim hanya paket tunggal ke kontroler. Kemudian CBench akan menghitung waktu respon ketika switch mengirimkan paket ke kontroler sampai paket tersebut dibalas atau diterima kembali oleh switch (Muntaner, 2012).
2.8 Wireshark
Wireshark adalah sebuah perangkat lunak penganalisa paket dalam jaringan. Wireshark akan mencoba untuk menangkap paket-paket dan menampilkannya sedetail mungkin. Sebuah penganalisa paket dalam jaringan yang digunakan untuk memeriksa apa yang terjadi dalam sebuak kabel jaringan, sama halnya seperti voltmeter yang digunakan oleh seorang ahli listrik untuk memeriksa apa yang terjadi didalam sebuah kabel elektrik. Sebelumnya alat seperti itu sangatlah mahal ataupun milik pribadi, bahkan keduanya. Tetapi dengan adanya Wireshark dapat memungkinkan untuk menganalisis paket-paket jaringan tanpa mengeluarkan biaya sedikitpun (Lamping, et al., 2014).
2.9 Latency
Latency adalah salah satu tolak ukur untuk mengukur sebuah performasi jaringan. Selain
latency juga terdapat bandwidth serta
throughtput. Latency digunakan untuk menghitung waktu yang dibutuhkan saat sebuah
source atau titik asal melakukan pengiriman paket atau pesan ke sebuah destination atau titik destinasi. Latency dihitung dengan satuan waktu, sebagai contoh suatu titik melakukan pengiriman pesan ke titik lain membutuhkan waktu selama 15 miliseconds (ms) (Azhar, 2013).
2.10 Convergence
Convergence atau konvergensi adalah sebuah tolak ukur berupa waktu yang didapat saat sebuah jaringan terdapat fail-path atau jalur yang terputus, lama waktu saat jalur terputus sampai mendapat sebuah jalur baru adalah waktu konvergensi. Untuk melakukan pengukuran ini dapat dilakukan simulasi pemutusan jalur saat sebuah host melakukan ping ke host yang lain, kemudian dilakukan perhitungan waktu sampai
host kembali mendapat balasan ping dari host
yang dipilih sebelumnya (Aris Saputra, et al., 2016).
3. PERANCANGAN SISTEM
3.1 Perancangan Topologi
Gambar 3 Bentuk rancangan topologi
Pada Gambar 3 topologi yang digunakan adalah topologi Internet2. Terdapat 11 switch
yang terhubung pada jaringan ini. Setiap switch
akan dihubungkan ke kontroler ONOS yang berfungsi untuk mengatur logika jaringan. Pada topologi ini terdapat 11 host yang berfungsi sebagai node pengujian.
Terdapat 14 jalur atau link yang nanti akan diberi bobot (link weight). Bobot akan ditentukan dari 2 macam bentuk fungsi link-weight yang disediakan oleh kontroler ONOS yaitu geoDistance link weight dan linkMetric link weight. Algoritme Dijkstra akan menghitung jalur terpendek dengan menyesuaikan bobot dengan fungsi link-weight
yang diberikan.
3.2 Perancangan geoDistanceLink Weight
GeoDistance linkweight dihitung dari jarak secara real-distance dilihat dari sisi letak
longitude dan latitude pada setiap switch. Kemudian cost link akan diambil dari hasil penjumlahan semua weight link dari link-link
yang dilewati. Tabel latitude dan longitute setiap
switch dapat dilihat pada Tabel 1.
Tabel 1 Latitude dan Longitute setiap switch
Untuk mendapatkan real-distance atau jarak sebenarnya dengan menggunakan Latitude
rumus pada Persamaan (1) untuk menentukan jarak sebenarnya.
𝑠. 𝑙𝑎𝑡 = 𝑆𝑜𝑢𝑟𝑐𝑒 𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒 𝑠. 𝑙𝑜𝑛 = 𝑆𝑜𝑢𝑟𝑐𝑒 𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒 𝑑. 𝑙𝑎𝑡 = 𝐷𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛 𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒 𝑑. 𝑙𝑜𝑛 = 𝐷𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛 𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒 𝑒𝑎𝑟𝑡ℎ. 𝑟𝑎𝑑 = 6378.1370
𝑟𝑒𝑎𝑙 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 = acos(𝑠𝑖𝑛(𝑟𝑎𝑑(𝑠. 𝑙𝑎𝑡)) × 𝑠𝑖𝑛(𝑟𝑎𝑑(𝑑. 𝑙𝑎𝑡)) +
cos(𝑟𝑎𝑑(𝑠. 𝑙𝑎𝑡)) × cos(𝑟𝑎𝑑(𝑑. 𝑙𝑎𝑡)) × cos(𝑟𝑎𝑑(𝑠. 𝑙𝑜𝑛) − 𝑟𝑎𝑑(𝑑. 𝑙𝑜𝑛)) × 𝑒𝑎𝑟𝑡ℎ. 𝑟𝑎𝑑
(1)
Sesuai dengan peta asli topologi Internet2, bobot pada link adalah nilai jarak antara setiap kota-kota besar di United States. Bentuk peta asli topologi Internet2 dapat dilihat pada Gambar 4.
Gambar 4Peta asli topologi Internet2
3.3 Perancangan linkMetricLink Weight
LinkMetriclink weight akan ditentukan dari sebuah skenario bandwidth pada setiap link. Tabel skenario bandwidth setiap link-nya dapat dilihat pada Tabel 2. Ini juga dimaksudkan agar perancang topologi tidak perlu melakukan
forwarding secara manual, melainkan tetap menggunakan algoritme routing dengan jalur atau path sesuai keinginan perancang topologi. Pada penelitian ini weight pada link akan disesuaikan dengan skenario bandwidth.
Tabel 2 Weight pada setiap link
Nilai metric pada kolom bagian paling kanan Tabel 2 didapat dari OSPF (Open shortest path first) reference. Pada Tabel 3 dapat dilihat perbandingan tabel bandwidth dan OSPF cost. Sebuah link memiliki bandwidth sebesar 10 Mbps maka cost atau metric pada link tersebut adalah 10 (OmniSecu, 2014).
Tabel 3 Perbandingan bandwidth dan OSPF cost
3.4 Perancangan Fail-path
Pada perancangan fail-path terdapat lima macam bentuk pemutusan link dengan source-destination yang berbeda-beda.
Tabel 4 Bentuk link pada topologi
Pada Tabel 4 adalah bentuk-bentuk link
yang terdapat pada topologi. Pada perancangan
fail-path yang perlu diperhatikan adalah bentuk
Gambar 5 fail-path h1 ke h2
Pada Gambar 5 dilakukan pemutusan fail-path yang akan dilalui saat host 1 berkomunikasi dengan host 2. Link yang diputus adalah link
antara switch 5 dengan switch 4. Dapat dilihat pada Tabel 5 untuk daftar link source dan
destination yang diputus.
Tabel 5 Tabel fail-path
4. PENGUJIAN DAN ANALISIS
4.1 Pengujian Algoritme Dijkstra
Pengujian Algoritme Dijkstra dilakukan untuk mengetahui path antara switch dengan
switch yang lain(source dan destination) apakah sudah melewati path yang paling terpendek atau melewati path dengan cost terkecil. Dapat dilihat di Tabel 6 skenario pengujian dengan mengambil sampel dari beberapa source dan
destination yang akan diuji.
Tabel 6 Table pengujian path algoritme Dijkstra
Pengujian ini dilakukan dengan cara menghitung cost pada path dan predecessor node antara host dengan host yang lain. Terdapat 2 macam penghitungan cost yang dilakukan yaitu geoDistance dan linkMetric.
Hasil pengujian yang didapat pada pengujian algoritme Dijkstra dengan menggunakan fungsi geoDistance h1 ke h2 menghasilkan cost sebesar 4539.9314 dengan jalur yang dilewati adalah S5, S4, S3, S2, S1. Hasil pengujian dapat dilihat pada Gambar 6.
Gambar 6 Hasil path geoDistance dari h1 ke h2
Pada Gambar 7 dapat dilihat hasil path yang ditandakan dengan garis berwarna hijau terang beserta nilai total besar paket yang dikirim dari h1 ke h2.
Gambar 7 Hasil path h1 ke h2 dalam bentuk Web-UI
Algoritme Dijkstra dapat dibuktikan dengan membuat tabel Dijkstra seperti pada Gambar 8.
Gambar 8 Gambar tabel perhitungan dijkstra dari titik h1
Pada gambar 8 dapat dilihat pada kolom s1 (switch 1) adalah nilai shortest path yaitu 4541 (biru) dengan jalur yang telah dilalui adalah S5, S4, S3, S2, S1. Nilai yang digunakan pada tabel Dijkstra menggunakan nilai yang dibulatkan ke atas sehingga nilai yang didapat pada gambar tabel Dijkstra dan hasil nilai cost pengujian memiliki margin error sebesar 2. Jadi, terbukti bahwa jalur terpendek yang h1 menuju h2 adalah S5, S4, S3, S2, S1 dengan cost 4539.9314.
Tabel 7 Hasil pengujian algoritme Dijkstra pada fungsi Geo Distance
Tabel 8 Hasil pengujian algoritme Dijkstra pada fungsi Link Metric
Pada Tabel 7 perbedaan hasil cost dengan hasil pembuktian tabel Dijkstra terdapat perbedaan nilai karena penghitungan tabel Dijkstra menggunakan pembulatan ke atas sehingga memiliki batas kesalahan sebesar 1 hingga 3 nilai.
4.2 Pengujian Flow Setup Delay
Pengujian Flow Setup Delay dimaksudkan untuk menghitung berapa lama waktu yang dibutuhkan kontroler untuk membalas sebuah paket flow. Daftar skenario pengujian dapat dilihat pada Tabel 9, Tabel 10, dan Tabel 11.
Tabel 9 Flow Setup Delay dengan switch bervariasi
Tabel 10 Flow Setup Delay dengan host bervariasi
Tabel 11 Flow Setup Delay dengan host dan switch
bervariasi
Berikut adalah grafik hasil pengujian yang dilihat pada Grafik 1, 2 dan 3.
Grafik 1 Grafik hasil pengujian flow setup delay dengan switch bervariasi
Grafik 3 Grafik hasil pengujian flow setup delay dengan switch dan host bervariasi.
Dari Grafik 1 dapat disimpulkan bahwa kontroler ONOS dapat memberikan respon per detik diatas 100000 respon per detik pada jumlah
switch sebanyak 25 switch, 50 switch, dan 75 switch. Performa akan turun sebesar ±60% pada jumlah switch sebanyak 100 switch, 125 switch, dan 150 switch. Banyaknya respon per detik yang diberikan oleh ONOS akan terus menurun bersamaan dengan jumlah banyaknya switch
yang diberikan.
Dari Grafik 2 dapat disimpulkan bahwa respon yang diberikan oleh ONOS terhadap host
yang berbeda-beda tidak konstan turun ataupun naik. Ini disebabkan karena terjadi traffic congetstion. Traffic congetstion muncul karena percobaan jumlah host bervariasi hanya menggunakan satu switch, maka data traffic
hanya melewati satu link saja. Namun seiring dengan banyaknya host yang diberikan hasil respon per sekon yang diberikan oleh ONOS akan terus menurun. Ini dibuktikan dari hasil respon per sekon saat percobaan 150 host
menurun sebesar ±72% dibandingkan dengan saat percobaan dengan host sebanyak 25 host.
Dari Grafik 3 dapat disimpulkan bahwa kontroler ONOS dapat memberikan respon per detik diatas 80000 respon per detik pada jumlah
switch dan host sebanyak 10 switch dan 20 host
serta 20 switch dan 40 host. Namun saat percobaan dengan 30 switch dan 60 host ONOS hanya mampu memberikan ±5% respon per detik dari percobaan sebelumnya, dan terus menurun hingga percobaan terakhir.
4.3 Pengujian Latency
Pengujian latency dimaksudkan untuk menghitung latency pada topologi jaringan Internet2 dengan membuat skenario percobaan antara source dan destination yang berbeda-beda. Perhitungan latency diambil dari rata-rata sebuah percobaan pengiriman paket ICMP (ping) dengan 10 iterasi. Percobaan dilakukan
pada perhitungan cost geo-Distance dan
linkMetric. Source dan destination untuk skenario percobaan dapat dilihat pada Tabel 12.
Tabel 12 Tabel skenario pengujian latency
Dari hasil pengujian yang telah dilakukan, data dikelompokkan menjadi sebuah tabel. Tabel hasil pengujian latency dengan menggunakan fungsi geoDistance dapat dilihat pada tabel 13, dan tabel hasil pengujian latency dengan menggunakan fungsi linkMetric dapat dilihat pada tabel 14.
Tabel 13 Tabel latency dengan fungsi geoDistance
Tabel 14 Tabel latency dengan fungsi linkMetric
Nilai latency yang lebih kecil berarti lebih baik. Dapat disimpulkan bahwa rata-rata latency
menggunakan fungsi geoDistance lebih baik dibanding menggunakan rata-rata latency
menggunakan fungsi linkMetric. Ini disebabkan
path yang dilewati pada saat menggunakan fungsi linkMetric sebagian besar lebih panjang dibandingkan dengan path saat menggunakan fungsi geoDistance. Sehingga latency yang didapat dengan path yang lebih panjang bersifat lebih besar karena waktu yang diperlukan untuk mengirim paket menjadi semakin lama. Fungsi
4.4 Pengujian Convergence
Convergence atau konvergensi adalah sebuah perhitungan kecepatan sebuah kontroler SDN dapat melakukan pemulihan path saat salah satu link atau jalur terjadi fail path atau terputus. Dalam skenario pengujian ini akan dilakukan sebuah link-down pada hasil shortest path-nya. Kemudian dengan menggunakan wireshark
dihitung berapa lama waktu yang diperlukan sampai kontroler dapat melakukan pemulihan
ping dari source dan destination yang telah ditentukan pada Tabel 15. Pada pengujian ini perhitungan cost untuk menentukan shortest path yang digunakan adalah geoDistance.
Tabel 15 Tabel skenario pengujian convergence
Dari hasil pengujian yang telah dilakukan, data hasil waktu convergence dikelompokkan dalam bentuk tabel yang bisa dilihat pada Tabel 16.
Tabel 16 Tabel hasil pengujian convergence
Dari hasil Tabel 16 dapat disimpulkan bahwa rata-rata waktu convergence yang dibutuhkan pada topologi Internet2 dengan menggunakan kontroler ONOS serta algoritme Dijkstra adalah sebesar 1,405s.
Pengujian shortest-path setelah dilakukan
fail-path menggunakan metode seperti pengujian algoritme Dijkstra, yaitu dengan membanding hasil shortest-path dengan tabel Dijkstra. Hasil pengujian dapat dilihat pada tabel 17 dan 18.
Tabel 17 Tabel path sebelum terjadi fail-path
Tabel 18 Tabel path setelah terjadi fail-path
Sehingga dapat dikatakan shortest-path
saat sebelum dan sesudah mengalami fail-path sama dengan hasil shortest-path yang dihitung menggunakan tabel Dijkstra.
5. KESIMPULAN
Sesuai dengan rumusan masalah yang diangkat setelah melalui tahapan perancangan, implementasi dan pengujian serta analisis pengujian maka dapat ditarik kesimpulan bahwa sistem telah dilaksanakan dengan baik dan telah berhasil. Berikut adalah rangkuman dari hasil penelitian:
1. Performa routing yang berbasis algoritme Dijkstra shortest-path (perjalanan node) pada jaringan SDN yang menggunakan kontroler ONOS menghasilkan latency
sebesar 0,092 ms dengan menggunakan fungsi geoDistance serta latency sebesar 0,097 ms dengan menggunakan fungsi
linkMetric. Dapat disimpulkan bahwa
latency akan semakin besar nilainya bersamaan semakin panjangnya path yang digunakan untuk berkomunikasi antar host.
2. Performa kontroler SDN ONOS saat menjalankan routing berbasis algoritme Dijkstra serta ketika menanggapi suatu kegagalan pada link jaringan dapat ditarik kesimpulan bahwa:
b. ONOS kurang baik digunakan pada jaringan yang membutuhkan infrastruktur dengan jumlah host diatas 25 yang menghasilkan respon dibawah 50000 respon per detik.
c. ONOS baik digunakan pada jaringan yang membutuhkan infrastruktur dengan jumlah kombinasi 20 switch
dan 40 host yang menghasilkan respon diatas 80000 respon per detik.
d. Rata-rata waktu convergence kontroler ONOS yang dibutuhkan untuk mendapatkan jalur yang baru adalah sebesar 1,405s.
e. Performa routing algoritme Dijkstra
shortest-path pada jaringan SDN yang menggunakan kontroler ONOS saat sebelum dan sesudah mengalami fail-path sama dengan hasil shortest-path
yang dihitung menggunakan tabel Dijkstra.
6. DAFTAR PUSTAKA
Aris Saputra, I., M., R. R. & Naning Hertiana, S., 2016. Uji Performansi Algoritme Floyd-Warshall pada Jaringan Software Defined Network (SDN), Bandung: PPET - LIPI .
[Diakses 20 Juli 2017].
Berde, P. et al., 2014. ONOS: Towards an Open, Distributed SDN OS, Chicago: Open Networking Laboratory, NEC Corporation of America, Create-Net.
Bonaventure, O., 2013. Computer Networking : Principles, Protocols and Practice.
[Online]
Available at:
http://cnp3book.info.ucl.ac.be/2nd/html/e xercises/network.html
[Diakses 20 Juli 2017].
Chao, H. J. & Liu, B., 2006. High Performance Switches and Routers. s.l.:s.n.
Foundation, O. N., t.thn. Software-Defined Networking (SDN) Definition. [Online]
Available at:
https://www.opennetworking.org/sdn-resources/sdn-definition
[Diakses 10 Februari 2016].
Hu, F., Hao, Q. & Bao, K., 2014. A Survey on Software-Defined Network and OpenFlow: From Concept to
Implementation. IEEE
COMMUNICATION SURVEYS &
TUTORIALS, VOL. 16, NO. 4, FOURTH QUARTER 2014, p. 2181.
Jiang, J.-R., Huang, H.-W., Liao, J.-H. & Chen, S.-Y., 2014. Extending Dijkstra’s Shortest
Path Algorithm for Software Defined Networking. Jhongli City, Taiwan, Department of Computer Science and Information Engineering National Central University.
Karami, F. & Akhtarkavan, D. E., 2015. Improving OSPF Protocol based Latency : A new algorithm based on Dijkstra by using OSPF existing Metrics in SDN networks. Ciência e Natura, Volume 37, p. 344−348.
Kim, W., Li, J., Won-Ki Hong, J. & Suh, Y.-J., 2016. OFMon: OpenFlow Monitoring System in ONOS Controllers, Korea: Department of Computer Science and Engineering.
Kolasani, A., Lara, A. & Byrav, R., 2014. Network Innovation using OpenFlow: A Survey. Communications Surveys & Tutorials, 16(1).
Kurose, J. F. & Ross, K. W., 2012. Computer Networking A Top-Down Approach. 6th penyunt. s.l.:s.n.
Lamping, U., Sharpe, R. & Warnicke, E., 2014.
Wireshark User’s Guide. [Online]
Available at:
https://www.wireshark.org/docs/wsug_ht ml_chunked/
[Diakses 12 07 2017].
Mahajan, R., Wetherall, D. & Anderson, T., 2005. Negotiation-Based Routing Between Neighboring ISPs, Washington: USENIX Association Berkeley.
Morris, J., 2004. Data Structures and
Algorithms. [Online]
Available at:
https://www.cs.auckland.ac.nz/software/ AlgAnim/
[Diakses 10 2 2016].
Muhammad, R. B., t.thn. Dijkstra's Algorithm.
[Online]
Available at:
http://www.personal.kent.edu/~rmuham ma/Algorithms/MyAlgorithms/GraphAlg or/dijkstraAlgor.htm
[Diakses 10 Februari 2016].
Muntaner, G. R. d. T., 2012. Evaluation of OpenFlow Controllers. s.l.:s.n.
OmniSecu, 2014. What is OSPF Metric value Cost and OSPF default Cost Reference
Bandwidth. [Online]
Available at:
http://www.omnisecu.com/cisco- certified-network-associate-ccna/what-is- ospf-metric-value-cost-and-ospf-default-cost-reference-bandwidth.php
[Diakses 20 Juli 2017].
ON.LAB, 2014. Introducing ONOS - a SDN network operating system for Service Provider, s.l.: s.n.
Shah, S. A. et al., 2013. An Architectural Evaluation of SDN Controllers. Pakistan: School of EECS, National University of Sciences and Technology (NUST).
Sonba, A. & Abdalkreim, H., 2014. Performance Comparison Of the state of the art Openflow Controllers. Master's
Programme in Computer Network
Engineering.
Stancu, A. L. et al., 2015. A Comparison between Several Software Defined
Networking Controllers. s.l.,
Telecommunication in Modern Satellite, Cable and Broadcasting Services (TELSIKS).
Xu , W. & Rexford, J., 2006. MIRO: Multi-path Interdomain Routing, Pisa: ACM.
Yahya, W., Basuki, A. & Jiang, . J.-R., 2015. The Extended Dijkstra’s-based Load Balancing for OpenFlow Network.
International Journal of Electrical and Computer Engineering (IJECE), 5(2), pp. 289-296.
Yu, H. et al., 2015. Zebra: An East-West Control Framework For SDN Controllers.
International Conference on Parallel Processing, p. 610.
