Metode baru untuk pengontrol-ke-pengontrol komunikasi dalam arsitektur SDN terdistribusi  

Abstrack

Software Defined Networking (SDN) merupakan teknologi yang menjanjikan memisahkan bidang kontrol dari bidang data di perangkat jaringan dan memungkinkan untuk kemampuan program, fleksibilitas, dan efisiensi dalam jaringan. Mengadopsi ini Teknologi untuk pusat data, cloud, dan jaringan WAN dapat menyederhanakan jaringan pengelolaan. Namun, pada awalnya SDN tidak dirancang untuk didistribusikan arsitektur dan tidak dapat menangani sejumlah besar data yang berasal dari perusahaan besar jaringan. Kami bertujuan, dalam makalah ini, untuk menyediakan arsitektur baru yang terdiri dari beberapa pengontrol SDN, di mana setiap pengontrol menggunakan antarmuka khusus untuk berkomunikasi dengan pengontrol tetangga. Selain itu, kami menyediakan beberapa mode untuk sesuaikan komunikasi ini. Terakhir, kami menunjukkan bukti konsep awal demonstrasi desain kami.

1. Pendahuluan

Sejak kemunculan produk SDN dalam beberapa tahun terakhir, infrastruktur jaringan baru berbasispada arsitektur SDN diusulkan. Mereka terdiri dari tiga lapisan: lapisan data(Sakelar yang mendukung aliran terbuka), lapisan kontrol (pengontrol SDN), dan lapisan aplikasi(Jasa). Pemisahan fungsi ini bermanfaat untuk banyak jenis jaringan,seperti jaringan perusahaan, cloud, seluler, dan nirkabel, menurut Lara et al. (2014).Memang, ini memungkinkan kemudahan manajemen dengan menggunakan pengontrol terpusat untuk semua perangkat yang mendasari. Apalagi penggunaan teknik pemrograman pada aplikasinya lapisan dapat memberikan layanan inovatif baru. Kekurangan SDN awal arsitektur adalah bahwa ia memusatkan semua kecerdasan dalam satu pengontrol, yang menjadi asatu titik kegagalan (SPOF) dan menimbulkan masalah kurangnya skalabilitas dan buruk pertunjukan. Oleh karena itu, kebutuhan akan beberapa pengontrol menjadi perlumengatasi masalah SPOF dan meningkatkan kinerja.

Dua kategori utama desain bidang kontrol dengan beberapa pengendali telah diusulkan dalam literatur (Nunes et al., 2014; Benamrane et al., 2015). Kategori pertama adalah bidang kontrol terpusat secara logis, tempat kumpulan pengontrol bekerja sama untuk bertindak sebagai satu pengontrol terpusat. Ini dilakukan dengan menyinkronkan status jaringan di antara pengontrol yang berbeda dan memberikan tampilan jaringan yang konsisten untuk aplikasi kontrol.Banyak studi penelitian telah dikhususkan untuk kategori ini; khususnya, berbeda teknik untuk mencapai sinkronisasi ini telah diusulkan dan digunakan, menghasilkan implementasi yang berbeda dari bidang kontrol terpusat secara logis, seperti yang akan kita lihat dibagian selanjutnya. Kami mencatat bahwa kami telah berkontribusi pada penelitian tentang kategori ini oleh studi tentang biaya sinkronisasi antara pengontrol dalam hal penundaan dan overhead(Benamrane et al., 2016). Menerapkan banyak pengontrol di bidang kontrol tentunya bermanfaat untuk penyeimbangan beban, toleransi kesalahan, keamanan, kinerja, dan skalabilitas.Namun, memastikan kontrol terpusat secara logis membutuhkan sinkronisasi ekstensifantara pengontrol yang dapat menghasilkan penggunaan bandwidth yang substansial dan latensi tinggi,terutama untuk jaringan terdistribusi besar. Jadi, kategori pertama tidak disesuaikan dengan jenis jaringan yang terakhir.

Dalam konteks ini, kategori kedua desain bidang kendali yang digunakan secara logis pengontrol terdistribusi diusulkan untuk memperluas SDN untuk jaringan multi-domain besar seperti jaringan WAN. Bertentangan dengan desain terpusat secara logis di mana masing-masing pengontrol harus memiliki pandangan global tentang jaringan untuk mengambil keputusan, dalam desain yang didistribusikan secara logis,setiap pengontrol hanya memiliki pandangan dari domain yang menjadi tanggung jawabnya; itu bisa memakan waktu keputusan untuk domain ini dan mendistribusikan hanya informasi yang diperlukan kepada yang lainpengendali. Karena jaringan WAN dicirikan oleh biaya tinggi dan latensi karena kompleksitas infrastruktur dan protokol yang menangani lalu lintas (misalnya, BGP danMPLS), komunikasi antara pengontrol adalah yang terpenting secara logis arsitektur SDN terdistribusi yang ditujukan untuk jaringan WAN. Sayangnya, sedikit penelitian difokuskan pada komunikasi ini, yang kami sebut pengontrol-ke-pengontrol(C-to-C) komunikasi. Ini memotivasi kami untuk mengatasi masalah ini dan berkontribusi padaupaya penelitian untuk pengembangan bidang kontrol terdistribusi secara logis yang dapat memperluas SDN ke jaringan WAN. Oleh karena itu, kami mengusulkan dalam makalah ini metode baru untukKomunikasi C-to-C berdasarkan antarmuka khusus yang menyediakan beberapa mode(pemberitahuan, layanan, dan penuh) untuk bertukar informasi antara pengontrol terdistribusi.Perhatikan bahwa, sejauh pengetahuan kami tidak ada antarmuka standar untuk C-to-C komunikasi sampai hari ini.

Makalah ini disusun sebagai berikut: Bagian 2 menyajikan karya terkait ituperlakukan arsitektur SDN terdistribusi. Bagian 3 menjelaskan strategi kami untuk berbagi informasiantar pengontrol. Bagian 4 menunjukkan implementasi dan hasil awal yang diperoleh daridesain kami. Kami menyimpulkan makalah dengan ringkasan dan beberapa perspektif di Bagian 5

2. Related Work

Pada bagian ini, kita membahas proposisi yang paling dikenal untuk mengimplementasikan pengontrol SDN dijaringan terdistribusi.

Kategori solusi pertama menerapkan bidang kontrol terpusat secara logis menggunakan beberapa pengontrol, yang berbagi kelebihan jaringan dan menyinkronkan data di antaranya pengendali. Proyek Onix (Koponen et al., 2010) merancang jaringan menggunakan empat komponen: Pengontrol Onix, adalah komponen inti, infrastruktur fisik (sakelar danrouter), infrastruktur konektivitas (saluran kontrol), dan logika kontrol (jaringan tingkah laku). Ini menyebarkan semua pengontrol di bawah cluster yang sama di mana status masing-masing pengontrol disimpan dalam struktur data basis informasi jaringan (NIB). Dua konsistensi model disediakan untuk mereplikasi NIB melalui pengontrol Onix, yang direplikasi database transaksional dan tabel Hash Terdistribusi (DHT). Juga, Hyperflow Tootoonchian dan Ganjali (2010) menyediakan bidang kontrol terpusat secara logis dengan menggunakan dua komponen utama, komponen Kontroler [aplikasi NOX (Gude et al., 2008)] dan Sistem propagasi acara (model publikasi / langganan). Sistem propagasi acara menggunakan WheelFS (Stribling et al., 2009) sebagai sistem file terdistribusi, untuk sinkronisasi tampilan seluruh jaringan pengontrol antara pengontrol. Selanjutnya, Opendaylight(http://www.opendaylight.org) mengusulkan mode cluster, yang dapat terdiri dari dua atau lebih banyak pengontrol yang bekerja bersama untuk memberikan tingkat ketersediaan, keandalan, danskalabilitas. Mereka memilih Akka (http://akka.io/) untuk menyinkronkan data antara beberapa pengendali. Metode yang dijelaskan sebelumnya digunakan untuk menyeimbangkan jaringan local biaya antara pengontrol. Namun, mereka tidak disesuaikan dengan distribusi ganda domain karena kurangnya fleksibilitas.

Kategori kedua memberikan solusi untuk pengontrol SDN yang didistribusikan secara logis.Baik dengan mengusulkan antarmuka terintegrasi untuk komunikasi C-to-C seperti SDNinterface (SDNi) (Yin et al., 2012) dan East-West Bridge (EW-Bridge) (Lin et al., 2015)mekanisme atau dengan DIstributed SDN COntrol plane (DISCO) (Phemius et al., 2014). ItuSDNi diusulkan oleh IETF dalam versi draf untuk menutupi kekurangan SDN di beberapa domain. Proposisi implementasi yang serius diberikan oleh layanan konsultasi TATA(TCS; http://www.tcs.com/Pages/default.aspx), dengan mengusulkan BGP sebagai protokol untuk melaksanakan SDNi. Kami mencatat bahwa komunitas ODL menyelidiki solusi ini. EW-Bridge mengatasi masalah yang sama di beberapa domain tetapi dimiliki oleh administrator yang berbeda. Itu menggunakan tiga modul baru untuk membuat tampilan jaringan global dan menjamin integritas data antara pengontrol dan modul ini adalah: Virtualisasi Jaringan, Jembatan Timur-Barat,dan Perpanjangan LLDP. Modul Virtualisasi Jaringan memungkinkan abstrak sijaringan fisik ke jaringan virtual untuk setiap domain, yang digunakan modul EW-Bridge mempublikasikan / berlangganan model untuk menyinkronkan data antara pengontrol, dan LLDPModul ekstensi memungkinkan EW-Bridge untuk mendukung pengontrol dari vendor yang berbeda. Terakhir,DISCO mengusulkan saluran kontrol khusus yang disebut ‘agen’ yang digunakan untuk memisahkan bidang kontrol menjadi intra-domain dan antar-domain, yang mempromosikan fleksibilitas dan presisi saat pengontrol beroperasi. Untuk mendemonstrasikan solusinya, mereka menggunakan beberapa kasus seperti gangguan topologi antar domain, permintaan layanan prioritas ujung ke ujung, danmigrasi mesin virtual.

Proposisi yang disebutkan dalam kategori pertama tidak dapat menangani distribusi besararsitektur seperti jaringan WAN, jadi kami memilih arsitektur kategori kedua,yang lebih disesuaikan dengan domain terdistribusi yang dapat dikelola oleh berbagai pihakoperator. Kami menjelaskan cara baru untuk merancang dan mengimplementasikan antarmuka khusus untuk C-to-Ckomunikasi dan menyediakan beberapa mode untuk bertukar notifikasi serta layanan antar pengontrol

3. C-to-C communication for distributed SDN architecture

Komunikasi antara pengontrol memiliki efek signifikan pada keseluruhan jaringan diarsitektur terdistribusi. Ini bisa menjadi kelemahan arsitektur jika dirancang denganteknik yang salah. Dua jenis teknik komunikasi input / output (I / O) adalahtersedia: model I / O pemblokiran dan non-pemblokiran input / output (Nio). Model I / O menggunakan beberapa utas untuk berkomunikasi dengan banyak pengontrol, yang menghabiskan lebih banyak sumber daya dan membutuhkan sinkronisasi penuh antar utas. Namun, model Nio dapat menggunakan satu utas untuk berkomunikasi dengan beberapa pengontrol berdasarkan selektor, dan hindari proses sinkronisasi dan kelebihan beban beberapa utas. Selektornya adalah dianggap sebagai komponen inti dari model Nio, ia menangani beberapa secara bersamaan koneksi dengan memeriksa setiap saat apakah soket siap untuk I / O. Kami memilih Nio model untuk merancang komunikasi C-to-C karena menunjukkan kinerja yang baik dibandingkan dengan blok I / O. Netty menggunakan TCP sebagai protokol transport, sehingga file kegagalan komunikasi seperti kehilangan paket ditangani oleh mekanisme TCP.

Dalam fase desain kami, kami mempertimbangkan dua aspek:

• Modularitas: Antarmuka kami benar-benar modular, kami merancang 4 modul dasar (konsumen,produser, pengumpul data dan pembaru database). Modularitas ini memungkinkan kita untuk mengaktifkan atau nonaktifkan modul apa pun secara terpisah, yang dapat memfasilitasi pengujian efek amodul atau mempersonalisasi perilaku setiap pengontrol. Misalnya untuk menyimpan file konsumsi bandwidth sangat rendah, pengontrol hanya dapat mengaktifkan konsumen dan modul pembaru database, dan nonaktifkan yang lain. Dengan demikian, pengontrol dapat melacak semuaperubahan domain tetangga, dan bertindak sebagai sistem pemantauan jaringan.Selain itu, modularitas mengisolasi masalah jika terjadi kegagalan dan memungkinkan filefleksibilitas untuk memprogram layanan baru.

• Kinerja: Pengontrol SDN menangani sejumlah besar aliran setiap detik, kami ambil mempertimbangkan perilaku ini. Untuk meningkatkan jumlah paket yang ditangani itu berasal dari pengontrol jarak jauh, kami memisahkan pengirim (Produser) dari penerima(Konsumen). Jadi, tidak ada penundaan laju karena kerancuan saluran di antara keduanya modul.

Model cluster digunakan untuk banyak pengontrol SDN terdistribusi, seperti ODL, yangbmelakukan sinkronisasi data antar pengontrol dengan cara yang sama dan tanpa memperhatikan sifat jaringan atau layanan yang dibutuhkan. Akibatnya, sejumlah besar data bisa jadi dikirim ke pengontrol lain, yang di satu sisi tidak diperlukan sepanjang waktu untuk semua pengontrol, dan di sisi lain, keduanya mengonsumsi bandwidth dan memengaruhi file throughput pengontrol (lebih detail diberikan di Bagian 4). Oleh karena itu, kita perlu melakukannya menyesuaikan komunikasi ini tergantung pada layanan apa yang perlu dicapai. Karenanya, kami menyediakan beberapa mode sinkronisasi yang berguna untuk berbagai skenario dan infrastruktur

• Mode pemberitahuan: Ini digunakan untuk memberi tahu pengontrol lain bahwa ada perubahan yang terjadi dijaringan di bawah tanggung jawab pengontrol, perubahan ini bisa menjadi barusakelar yang terhubung dan terputus, flow_mod baru dipasang ke sakelar, atau perangkat yang baru ditemukan. Mode ini berguna untuk mengelola dan mengaudit jaringan.
• Mode layanan: Ini bermanfaat untuk aplikasi yang membutuhkan tampilan terpusat dari jaringan dan kualitas transmisi, khususnya firewall, QoS, dan penyeimbang beban.Ini menyinkronkan informasi tentang tabel aliran, tabel meteran, bandwidth tautan, tautan status, dan kebijakan yang diterapkan untuk semua tetangga.
• Mode penuh: Ini menggabungkan dua mode yang ditentukan sebelumnya, dan menambahkan lebih banyak detail seperti Packet_in, Packet_out, dan Port_status. Salah satu aplikasinya mode adalah untuk pengontrol yang sangat sensitif, yang dapat mencerminkan semua perubahan dan itu berlakulayanan untuk pengontrol tetangga.

Ada banyak tindakan jaringan yang memicu pertukaran pesan antar pengontrol.Misalnya, dalam kasus modifikasi status infrastruktur yang mendasarinya(switch dan host), pesan dikirim ke semua pengontrol yang dikonfigurasi dinotifikasi atau mode penuh. Contoh lain adalah ketika kegagalan satu pengontrol terjadi, apemberitahuan dikirim ke pengontrol tetangga untuk memperingatkan bahwa pengontrol di jaringantidak lagi tersedia. Dengan demikian, administrator diperingatkan untuk mengatasi masalah tersebutdan mengambil keputusan yang tepat. Selain itu, menggunakan mode layanan, pengontroltetap mendengarkan jaringan lokal dan menyinkronkan kebijakan layanan dengan semua yang tertarikpengendali. Selain itu, untuk bergabung dengan daftar pengontrol, setiap pengontrol memicu halopesan ke pengontrol tetangga potensial untuk membentuk grup.Di antarmuka kami, setiap pengontrol dapat memilih kumpulan pengontrol yang akan digunakan pertukaran informasi. Selain itu, mode sinkronisasi dapat berbeda daripengontrol ke orang lain tergantung pada posisinya di jaringan dan peran yang dimainkannya. UntukMisalnya, protokol OSPF mengkategorikan router pada beberapa jenis seperti area Backbone,Area rintisan, dan area yang tidak terlalu pendek (NSSA). Jadi, tipe dikonfigurasi tergantung yang manaarea yang dikelola router. Oleh karena itu, merancang antarmuka C-to-C baru dengan mode dapat ditambahkan lebih banyak fleksibilitas untuk pengontrol SDN.

Gambar 1 Arsitektur antarmuka komunikasi pengontrol-ke-pengontrol (lihat versi online untuk warna)

Kami merancang antarmuka yang disesuaikan antara pengontrol. Karena tidak ada standar protokol untuk komunikasi ini, kami merancang di satu sisi metode baru untuk mengumpulkan datadari satu pengontrol, dan kami mengirimkannya ke koleksi pengontrol mereka. Di samping itu,pengendali jarak jauh menggunakan informasi tersebut, dan mereka memperbarui status mereka berdasarkan apainformasi yang mereka terima. Pada Gambar 1, kami menyajikan arsitektur antarmuka baru ini,disusun oleh empat modul penting, tetapi lebih banyak opsi dapat ditambahkan dengan mempertimbangkan aspek modular dari antarmuka kami. Di bawah ini, kami menjelaskan peran masing-masing modul.

• Konsumen: Ini membuat saluran dengan produsen dari tetangga lain, dan itu menunggu data yang diterima. Ini adalah modul runnable pertama di antarmuka, dan itu mendengarkan pemberitahuan atau perubahan apa pun yang terjadi pada tetangga lain.
• Database updater: Setelah menerima informasi baru dari konsumen, update database terjadi.• Database collector: Ketika mode pertukaran dipilih, modul ini terkumpul parameter jaringan yang akan diekspor ke pengontrol tetangga. Itu informasi berbeda dari satu mode ke mode lainnya, misalnya, mode notifikasi akanpaparkan informasi berikut kepada produsen. Sakelar: Dpid, status (terhubung,terputus), Perangkat: alamat IP / Mac, status (atas, bawah), atau Arus: flow_mod.
• Produser: Ini memainkan peran kebalikan dari konsumen; itu memberi tahu semua tetangga kapan perubahan terjadi pada jaringan yang dikendalikannya.
• xKonfigurasi: Kami juga menggunakan file konfigurasi yang memusatkan semua pengaturan menjadi satufile, seperti alamat IP dari semua pengontrol tetangga, mode pertukaran yang dipilih(Notification, Services, atau Full), dan port mendengarkan konsumen.

Empat modul dasar yang menyusun antarmuka berinteraksi dengan pengontrol operasional untuk melakukan tindakan tertentu, tetapi interaksi ini berbeda dari satu modul ke modul lainnya. Sebagai sebuah contoh: modul pengumpul data berkomunikasi dengan fungsi dan layanan internal yang menyusun pengontrol dan memasukkan hasilnya ke modul produsen. Modul ini adalah dianggap sebagai modul eksternal; itu mengirimkan semua informasi ke pengendali jarak jauh itumenyusun koleksinya. Antarmuka kami dirancang untuk arsitektur beberapa pengontrol, dan setiap pengontrol memainkan dua peran penting pada saat bersamaan; itu konsumen dan produsen. Semua modul tetap aktif sepanjang waktu, dan dianggap sebagaimodul I / O asinkron, yang berarti bahwa semua perubahan mendengarkan dipertimbangkan asinkron. Kami juga mencatat bahwa modul lain pada gambar didesain dalam pengontrol lampu sorot, tetapi antarmuka kami dapat diintegrasikan ke pengontrol lain, dengan modifikasi kecil, karena modularitasnya.

4. Implementasi dan evaluasi

Pada bagian ini, kami menunjukkan demonstrasi bukti konsep awal proposal kami, oleh mengimplementasikan antarmuka dan membandingkan hasil set komunikasi C-to-C kami kemode notifikasi dengan mode pengelompokan ODL.

• Implementasi

Langkah pertama dalam mengimplementasikan proposal kami adalah memilih pengontrol SDN. Banyak pilihan tersedia secara komersial atau open source. Karena kami fokus pada kinerja, pengontrol multi-utas bisa menjadi pilihan yang baik. Kami memilih Floodlight(http://www.projectfloodlight.org/floodlight/) sebagai pengontrol SDN, karena ini adalah pengontrol dewasa, mendukung multi-utas, dan mengumpulkan komunitas yang sangat besar. Lampu sorot multithread, yang berarti semua modul aman untuk thread. Jadi, kami mengikuti aturan ini dan mengimplementasikan antarmuka kami ke dalam multi-threaded dengan menggunakan kelas thread dan antarmuka yang dapat dijalankan. Langkah kedua adalah memilih teknologi yang menangani file komunikasi antar pengontrol. Kami memilih Netty (asynchronous event-drivenaplikasi jaringan) sebagai kerangka kerja jaringan non-pemblokiran karena sangat kuat(benchmark kinerja) dan fleksibel.

• Evaluasi

Testbed kami diilustrasikan pada Gambar 2, disusun oleh Floodlight Controller dan jaringan disediakan oleh Lantz et al. (2010). Kami memilih emulator GNS3 (http://www.gns3.com/)untuk menghubungkan semua VM ke internet. Untuk tujuan sinkronisasi waktu, kami menggunakan NTP protokol yang dianggap sebagai langkah primordial untuk melakukan penelitian kami. Kami mencatat bahwa semua hasil yang ditampilkan dalam makalah ini tergantung pada perangkat lab (Intel Xeon 2.67Ghz CPU dengan 8 inti logis dan memori 14.0GB di RAM, java 1.7 untuk semua VMS, VM Floodlight memiliki Memori 1GB dan 1 CPU, Mininet VM memiliki memori 2GB, 1 CPU, versi mini-net2.1.0+, Open vSwitch 1.4.6, dan OpenFlow 1.1) digunakan untuk menangani percobaan.Untuk menunjukkan efisiensi desain kami, kami membandingkan antara proposal kamidan mode cluster ODL. Kami menghitung dua parameter penting yang dapat memengaruhi pertunjukan dalam arsitektur terdistribusi. Parameter ini kelebihan beban dan penundaan.Kelebihan beban didefinisikan sebagai tingkat informasi dalam Kbit / s yang dipertukarkan pengendali. Penundaan adalah waktu yang diperlukan agar ‘pemberitahuan’ pesan sampai pada waktunya tujuan.

Gambar 2 Lingkungan emulasi (lihat versi online untuk warna)

Kami menjalankan dua skenario; yang pertama berisi dua pengontrol ODL di bawah cluster yang sama,dan yang kedua menjalankan dua pengontrol lampu sorot yang dilengkapi dengan antarmuka C-to-C kami. Disetiap skenario, kami mempertimbangkan topologi ring dan linier (Gambar 3). Untuk mengevaluasioverload, kami menangkap semua paket yang dipertukarkan antara setiap pengontrol untuk setiap kombinasi( C i sumber ke tujuan C i +1 atau tujuan C i ke sumber C i +1 , i : nomor pengontrol ( C ))dan kami menghitung jumlah dan jumlah paket yang dipertukarkan di antara semuanyapengendali. Selanjutnya kami menghitung dan menganalisa delay, untuk parameter ini kamipilih tiga peristiwa: ‘Host baru’, ‘Tombol baru’, dan ‘Flow_mod baru’. Misalnya, jika C imemiliki host baru, penundaan akan menjadi waktu yang diperlukan untuk mendeteksi baru inihost jarak jauh dan menambahkannya ke basis jaringannya [persamaan (1)]. Kami menghasilkan – sebagai lalu lintaspola – satu sekarang mengalir per detik menggunakan aliran TCP.

DelayCi+1 ( Event )  = TimeCi+1( Event )   − TimeCi ( Event )

Pengontrol ditempatkan di tempat yang sama, dan tautan antara host dan sakelar ada setel ke 1 Gbps untuk bandwidth dan 30ms untuk penundaan. Selain itu, seluruh eksperimenmembutuhkan waktu 60 detik.

Gambar 3 (a) Cincin (b) Topologi linier (lihat versi online untuk warna)

• Hasil dan diskusi

Dalam kasus topologi linier [Gambar 3 (a)], kami menyatakan bahwa pertukaran ODL1.0861 paket, dengan 4.023 Mbits overload selama 60 detik, sedangkan yang dimodifikasi Floodlight hanya menampilkan 832 paket, dengan 74 Mbits kelebihan beban di antara pengontrol. Jugadalam topologi ring [Gambar 3 (b)], ODL menukar 10.714 paket dengan 4.022 Mbits kelebihan beban antar pengontrol. Sedangkan lampu sorot yang dimodifikasi menunjukkan 611 paket dan54 Mbits overload, penurunan yang signifikan dari overload terlihat pada antarmuka kami untuk keduanya topologi karena kami tidak membagikan semua objek yang terdeteksi seperti yang dilakukan ODL. Tapi, kami menggunakanpesan untuk memberi tahu orang lain bahwa ada acara baru. Menggunakan mode lain dapat meningkatkan jumlah paket dan kelebihan beban antara pengontrol, tetapi tidak akan sebanyak ODL.

Parameter penting kedua untuk dievaluasi adalah penundaan, di bawah ini kami sajikan aperbandingan antara dua jenis pengontrol untuk kedua topologi. Gambar 4 (a) menunjukkan variasi penundaan untuk kedua pengontrol selama percobaan. Dalam penemuan sakelar wilayah, ODL menunjukkan penundaan penting (55 md) sementara proposal kami tidak melebihi15 ms. Ini karena ODL berbagi objek sakelar yang berisi banyak detail, dan dibutuhkan lebih banyak waktu untuk berbagi sakelar dari pada host dan aliran. Di wilayah penemuan Host dan Arus, kami dapat melihat perbedaan yang signifikan antara ODL dan proposal kami. Untuk ODL, penundaan bervariasi dari 9 ms hingga 35 ms, tetapi untuk antarmuka kami variasinya cukup minimal dan bervariasi dari 1ms hingga 13 ms, karena kami berbagi data yang sama apa pun peristiwa yang terjadi (hostatau mengalir). Pengamatan yang sama telah terdeteksi pada topologi linier, lihat Gambar 4 (b),yang menegaskan bahwa menggunakan beberapa pengontrol dengan mode pertukaran dapat secara signifikan mengurangi beban berlebih dan penundaan, dan meningkatkan kinerja. Selanjutnya kami catat bahwa dalam topologi yang terhubung lemah antara domainnya [Gambar 3 (a)], jugasebagai topologi yang sangat terhubung antar domainnya [Gambar 3 (b)], proposal kami menunjukkan hasil yang baik terlepas dari sifat jaringannya.

Figure 4    Delay representation for ODL and C-to-C interface using, (a) ring (b) linear topologies

5. Kesimpulan

Kami menyediakan dalam makalah ini metode baru untuk merancang dan mengimplementasikan antarmuka komunikasi C-to-C antara beberapa pengontrol SDN dengan menggunakan teknik Nio alih-alih metode cluster. Kami juga mengusulkan untuk memisahkan fungsionalitas antarmuka C-to-C menjadi beberapa mode, di mana setiap mode memiliki peran khusus untuk dimainkan dalam arsitektur. Hasilnya menunjukkan bahwa metode kami meningkatkan kecepatan dan fleksibilitas jaringan, dan secara signifikan meningkatkan kinerja jaringan secara keseluruhan dengan mengurangi kelebihan beban dan penundaan antar pengontrol. Kami bermaksud untuk mengevaluasi lebih banyak parameter dan memperluas pekerjaan kami untuk mendukung lebih banyak layanan, selanjutnya kami berencana untuk menerapkan antarmuka ini di tempat pengujian nyata untuk menunjukkan efisiensinya dalam lingkungan yang produktif.

References

Akka, Framework [online] http://akka.io/ (accessed 6 October 2016).

Benamrane, F., Ben Mamoun, M. and Benaini, R. (2015) ‘Performances of OpenFlow-based software-defined networks: an overview’, Journal of Networks, Vol. 10, No. 6, pp.329–337.

Benamrane, F., Ros, F. and Ben Mamoun, M. (2016) ‘Synchronisation cost of multi-controller deployments in software-defined networks’, International Journal of High Performance Computing and Networking, Vol. 9, No. 4, pp.291–298.

Floodlight, OpenFlow Controller [online] https://floodlight.atlassian.net/wiki/spaces/floodlight controller (accessed 6 October 2016).

GNS3 [online] http://www.gns3.com/ (accessed 6 October 2016).

Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N. and Shenker, S. (2008)

‘NOX:   towards   an   operating   system   for   networks’,   ACM   SIGCOMM   Computer

Communication Review, Vol. 38, No. 3, pp.105–110.

Koponen,  T.,  Casado,  M.,  Gude,  N.,  Stribling,  J.,  Poutievski,  L.,  Zhu,  M.,  Ramanathan,  R., Iwata, Y., Inoue, H., Hama, T. and Shenker, S. (2010) ‘ONIX: a distributed control platform for large-scale production networks’, Vol. 10, pp.1–6.

Lantz, B., Heller, B. and McKeown, N. (2010) ‘A network in a laptop: rapid prototyping for software defined networks’, Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, p.19.

Lara,  A.,  Kolasani,  A.  and  Ramamurthy,  B.  (2014)  ‘Network  innovation  using  OpenFlow:

a survey’, IEEE Communications Surveys and Tutorials, Vol. 16, No. 1, pp.493–512.

Lin, P., Bi, J. and Wang, Y. (2015) ‘WEBridge: west east bridge for distributed heterogeneous

SDN NOSes peering’, Security and Communication Networks, Vol. 8, No. 10, pp.1926–1942.

Netty, ‘Home’ [online] http://netty.io/ (accessed 6 October 2016).

Netty, ‘Performance’ [online] http://www.techempower.com/benchmarks/

#section=data-r9&hw=i7&test=plaintext (accessed 6 October 2016).

Nunes, B.A.A., Mendonca, M., Nguyen, X.N., Obraczka, K. and Turletti, T. (2014) ‘A survey of software-defined networking:  past,  present, and future  of programmable  networks’,  IEEE Communications Surveys and Tutorials, Vol. 16, No. 3, pp.1617–1634.

OpenDaylight, An Open Source Community and Meritocracy for Software Defined Networking

[online] http://www.opendaylight.org (accessed 6 October 2016).

Phemius, K., Bouet, M. and Leguay, J. (2014) ‘Disco: distributed multi-domain SDN controllers’,

Network Operations and Management Symposium (NOMS), pp.1–4.

Stribling, J., Sovran, Y., Zhang, I., Pretzer, X., Li, J., Kaashoek, M.F. and Morris, R. (2009)

‘Flexible, wide-area storage for distributed systems with WheelFS’, Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation NSDI0, Vol. 9, pp.43–58.

Tootoonchian, A. and Ganjali, Y. (2010) ‘HyperFlow: a distributed control plane for OpenFlow’, Proceedings of the Internet Network Management Conference on Research on Enterprise Networking, p.3.

TSC, IT Services, Consulting [online] http://www.tcs.com/Pages/default.aspx (accessed 6 October

2016).

Yin, H., Xie, H., Tsou, T., Lopez, D., Aranda, P. and Sidi, R. (2012) ‘SDNi: a message exchange protocol   for   software   defined   networks   (SDNs)   across   multiple   domains’,   Internet Engineering Task Force, Internet Draft.

Dikirimkan oleh Dr. Eng. Antoni Wibowo