Implementasi Routing Berbasis Algoritme Dijkstra Pada Software Defined Networking Menggunakan Kontroler Open Network Operating System

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer Vol. 2, No. 7, Juli 2018, hlm. 2531-2541

e-ISSN: 2548-964X http://j-ptiik.ub.ac.id

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: [email protected], [email protected], [email protected] Abstrak Software Defined Networking 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 control plane 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 kekurangan yang signifikan. Contohnya seperti konfigurasi komponen yang sulit karena menggunakan konfigurasi tingkat rendah (low level configuration) dan perangkat visual yang terbatas (Yu, et al., 2015). Sehingga

1. PENDAHULUAN Jaringan komputer saat ini telah menjadi jaringan yang sukses, namun masih memiliki Fakultas Ilmu Komputer Universitas Brawijaya

2531

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer

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 Fakultas Ilmu Komputer, Universitas Brawijaya

2532

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.1 Software 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 Ada beberapa macam protokol standar yang digunakan untuk SDN dalam aplikasi nyata. Salah satunya adalah protokol standar yang paling populer disebut OpenFlow. OpenFlow adalah protokol yang memungkinkan pelaksaan konsep SDN baik hardware maupun software. Sebuah fitur yang terpenting dari OpenFlow adalah bahwa para ilmuwan dapat memanfaatkan perangkat keras yang ada untuk merancang protokol baru dan menganalisa kinerja perangkat keras tersebut. Sekarang hal ini menjadi bagian dari router dan switch yang tersedia secara komersial.


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.

2533

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

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 Highperfomance 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 Fakultas Ilmu Komputer, Universitas Brawijaya

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 throughput: switch yang dibuat oleh CBench secara emulasi akan mencoba untuk mengirim paket data sebanyak-banyaknya ke kontroler. Yang nantinya akan digitung oleh CBench berapa respon yang diberikan oleh kontroler setiap kali membalas paket data yang dikirimkan switch.


 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).

2534

3. PERANCANGAN SISTEM 3.1 Perancangan Topologi

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).

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 linkweight 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 geoDistance Link Weight GeoDistance link weight 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

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). Fakultas Ilmu Komputer, Universitas Brawijaya

Untuk mendapatkan real-distance atau jarak sebenarnya dengan menggunakan Latitude dan Longitude, kontroler ONOS menggunakan


rumus pada Persamaan (1) untuk menentukan jarak sebenarnya.

2535 Tabel 2 Weight pada setiap link

𝑠. 𝑙𝑎𝑡 = 𝑆𝑜𝑢𝑟𝑐𝑒 𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒 𝑠. 𝑙𝑜𝑛 = 𝑆𝑜𝑢𝑟𝑐𝑒 𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒 𝑑. 𝑙𝑎𝑡 = 𝐷𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛 𝐿𝑎𝑡𝑖𝑡𝑢𝑑𝑒 𝑑. 𝑙𝑜𝑛 = 𝐷𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛 𝐿𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒 𝑒𝑎𝑟𝑡ℎ. 𝑟𝑎𝑑 = 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.

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

Gambar 4 Peta asli topologi Internet2

3.3 Perancangan linkMetric Link Weight LinkMetric link 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.

3.4 Perancangan Fail-path Pada perancangan fail-path terdapat lima macam bentuk pemutusan link dengan sourcedestination 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 link yang terjadi fail-over yang digambarkan dengan garis putus-putus berwarna hitam.

Fakultas Ilmu Komputer, Universitas Brawijaya


2536

Gambar 6 Hasil path geoDistance dari h1 ke h2 Gambar 5 fail-path h1 ke h2

Pada Gambar 5 dilakukan pemutusan failpath 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.

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.

Tabel 5 Tabel fail-path

Gambar 7 Hasil path h1 ke h2 dalam bentuk Web-UI

4.

PENGUJIAN DAN ANALISIS

Algoritme Dijkstra dapat dibuktikan dengan membuat tabel Dijkstra seperti pada Gambar 8.

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 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. Untuk hasil pembuktian algoritme Dijkstra yang lain dapat dilihat pada Tabel 7 dan Tabel 8.


Tabel 7 Hasil pengujian algoritme Dijkstra pada fungsi Geo Distance

2537

Tabel 10 Flow Setup Delay dengan host bervariasi

Tabel 11 Flow Setup Delay dengan host dan switch bervariasi Tabel 8 Hasil pengujian algoritme Dijkstra pada fungsi Link Metric

Berikut adalah grafik hasil pengujian yang dilihat pada Grafik 1, 2 dan 3.

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.

Grafik 1 Grafik hasil pengujian flow setup delay dengan switch bervariasi

Tabel 9 Flow Setup Delay dengan switch bervariasi

Grafik 2 Grafik hasil pengujian flow setup delay dengan host bervariasi



2538

pada perhitungan cost geo-Distance dan linkMetric. Source dan destination untuk skenario percobaan dapat dilihat pada Tabel 12. Tabel 12 Tabel skenario pengujian latency

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 berbedabeda. Perhitungan latency diambil dari rata-rata sebuah percobaan pengiriman paket ICMP (ping) dengan 10 iterasi. Percobaan dilakukan Fakultas Ilmu Komputer, Universitas Brawijaya

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 geoDistance memiliki latency sebesar 0,092 ms sedangkan linkMetric memiliki latency sebesar 0,097 ms.


2539

Tabel 17 Tabel path sebelum terjadi fail-path

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 18 Tabel path setelah terjadi fail-path

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

Sehingga dapat dikatakan shortest-path saat sebelum dan sesudah mengalami fail-path sama dengan hasil shortest-path yang dihitung menggunakan tabel Dijkstra. 5.

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:

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.

KESIMPULAN

a.


ONOS baik digunakan pada jaringan yang membutuhkan infrastruktur dengan jumlah switch 25 hingga 75 dengan menghasilkan respon diatas 100000 respon per detik.


b.

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.

6.

ONOS kurang baik digunakan pada jaringan yang membutuhkan infrastruktur dengan jumlah host diatas 25 yang menghasilkan respon dibawah 50000 respon per detik.

Performa routing algoritme Dijkstra shortest-path pada jaringan SDN yang menggunakan kontroler ONOS saat sebelum dan sesudah mengalami failpath sama dengan hasil shortest-path yang dihitung menggunakan tabel Dijkstra.

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 . Azhar, M. F. A., 2013. Azuharu ~ Another Dream: Berbagi Ilmu Berbagi Pengalaman - Pengertian Latency di Dalam Jaringan. [Online] Available at: http://azuharu.net/jaringan/pengertianlatency/ [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] Fakultas Ilmu Komputer, Universitas Brawijaya

2540 Available at: https://www.opennetworking.org/sdnresources/sdn-definition [Diakses 10 Februari 2016].

Hu, F., Hao, Q. & Bao, K., 2014. A Survey on Software-Deﬁned 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. McKeown, N. et al., 2008. OpenFlow: Enabling Innovation in Campus Networks. ACM SIGCOMM Computer Communication Review.


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/ciscocertified-network-associate-ccna/what-isospf-metric-value-cost-and-ospf-defaultcost-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. Fakultas Ilmu Komputer, Universitas Brawijaya

2541

Yu, H. et al., 2015. Zebra: An East-West Control Framework For SDN Controllers. International Conference on Parallel Processing, p. 610.

Implementasi Routing Berbasis Algoritme Dijkstra Pada Software Defined Networking Menggunakan Kontroler Open Network Operating System

Recommend Documents