buku-komunitas-sdn-rg.pdf

Table of Contents 1. Pengantar 2. Pengantar SDN 3. Pengantar OpenStack i. Virtualisasi dan Hypervisor 4. Pengantar NFV 5. Testbed OF@ITB 6. SDN & IoT 7. Network Hypervisor i. FlowVisor ii. OpenVirtex (OVX) 8. Open Network OS - ONOS 9. Mininet i. Mininet - Eksperimen Topologi ii. Mininet - Eksperimen OVS iii. Mininet - Eksperimen Kontroler 10. Topik Riset SDN dan Cloud 11. Video Multicast OF v1.0 12. Cara Kontribusi 13. Kontroler OpenDaylight 14. Topik Khusus i. Integrasi SDN-LTE ii. Desentralisasi Bidang Kontrol iii. FortNOX iv. Avant Guard - Flow Management v. Visual Home Sharing vi. SDN Seluler vii. OF Hibrid

Buku Komunitas SDN-RG Buku ini merupakan kumpulan artikel-artikel yg ditulis oleh anggota komunitas SDN-RG ITB. Nantinya akan disusun menjadi buku yg lebih sistematis dan terorganisasi dengan lebih baik, dan mungkin akan dibuat terpisah. Buku Komunitas SDN-RG bersifat umum, untuk semua materi yg terkait dengan Software Defined Network (SDN), Network Function Virtualization (NFV), Virtualisasi, Cloud dan sejenisnya. Format artikel bisa seperti layaknya artikel blog. Hak cipta tetap berada pada para penulis masing-masing artikel. Karya derivatif (tidak sejenis) diperkenankan selama sesuai dengan kaidah CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Editor Eueung Mulyana ([email protected])

Kontributor TBA

Pengantar SDN Aris Cahyadi Risdianto, Muhammad Arif & Eueung Mulyana Software Defined Network (SDN) adalah istilah yang merujuk pada konsep/paradigma baru dalam mendisain, mengelola dan mengimplementasikan jaringan, terutama untuk mendukung kebutuhan dan inovasi di bidang ini yg semakin lama semakin kompleks. Konsep dasar SDN adalah dengan melakukan pemisahan eksplisit antara control dan forwarding plane, serta kemudian melakukan abstraksi sistem dan meng-isolasi kompleksitas yg ada pada komponen atau sub-sistem dengan mendefinisikan antar-muka (interface) yg standard. Beberapa aspek penting dari SDN adalah : 1. Adanya pemisahan secara fisik/eksplisit antara forwarding/data-plane dan control-plane 2. Antarmuka standard (vendor-agnosic) untuk memprogram perangkat jaringan 3. Control-plane yang terpusat (secara logika) atau adanya sistem operasi jaringan yang mampu membentuk peta logika (logical map) dari seluruh jaringan dan kemudian memrepresentasikannya melalui (sejenis) API (Application Programming Interface) 4. Virtualisasi dimana beberapa sistem operasi jaringan dapat mengkontrol bagian-bagian (slices atau substrates) dari perangkat yang sama.

Mengapa SDN? Sebelumnya telah disinggung tentang inovasi. Dalam hal ini terkait dengan kebutuhan inovasi untuk bidang jaringan yg semakin kompleks. Termasuk diantaranya adalah fakta-fakta dan kebutuhan berikut: 1. Virtualisasi dan Cloud: Komponen dan entitas jaringan hybrid - antara fisik bare metal dan yg virtual 2. Orchestration dan Scalability: Kemampuan untuk mengatur dan mengelola ribuan perangkat melalui sebuah point of management 3. Programmability dan Automation: Kemampuan untuk mengubah behaviour (perilaku) jaringan serta untuk dapat melakukan perubahan terebut secara otomatis (sebagai contoh adalah kemampuan troubleshooting, perubahan policy dan lain-lain) 4. Visibility: Kemampuan untuk dapat memonitor jaringan, baik dari sisi sumber daya, konektivitas dan lain-lain. 5. Kinerja: Kemampuan untuk memaksimalkan penggunaan perangkat jaringan, misalnya optimasi bandwidth, load balancing, traffic engineering dan lain-lain (berhubungan dengan Programmability dan Scalability)

Arsitektur SDN Dalam konsep SDN, tersedia open interface yg memungkinkan sebuah entitas software/aplikasi untuk mengendalikan konektivitas yg disediakan oleh sejumlah sumber-daya jaringan, mengendalikan aliran trafik yg melewatinya serta melakukan inspeksi terhadap atau memodifikasi trafik tersebut. Gambar berikut menunjukan arsitektur SDN beserta komponen dan interaksinya.

Arsitektur SDN dapat dilihat sebagai 3 lapis/bidang: infrastruktur (data-plane / infrastructure layer): terdiri dari elemen jaringan yg dapat mengatur SDN Datapath sesuai dengan instruksi yg diberikan melalui Control-Data-Plane Interface (CDPI) kontrol (control plane / layer): entitas kontrol (SDN Controller) mentranslasikan kebutuhan aplikasi dengan infrastruktur dengan memberikan instruksi yg sesuai untuk SDN Datapath serta memberikan informasi yg relevan dan dibutuhkan oleh SDN Application aplikasi (application plane / layer): berada pada lapis teratas, berkomunikasi dengan sistem via NorthBound Interface (NBI) Bidang Management & Admin bertanggung-jawab dalam: inisiasi elemen jaringan, memasangkan SDN Datapath dengan SDN Controller, atau menkonfigurasi cakupan (coverage) dari SDN Controller dan SDN App. Arsitektur SDN spt dijelaskan di atas, dapat berjalan paralel dengan jaringan non-SDN, fitur yg sangat berguna untuk migrasi secara bertahap menuju jaringan SDN.

Abstraksi Jaringan Konsep layer (lapis enkapsulasi) merupakan contoh dan satu-satunya abstraksi jaringan sebelum era SDN. Konsep layer ini juga hanya terbatas meng-abstraksi-kan data-plane: tidak ada konsep serupa untuk control-plane. Setiap kebutuhan baru untuk kontrol jaringan, dilakukan melalui mekanisme (protokol). Tidak ada yg salah dengan hal ini, selama kita mampu mengelola kompleksitas (mastering complexity). Walaupun demikian, dengan cara ini, semakin lama akan semakin banyak mekanisme (protokol) yg menyebabkan jaringan berkembang semakin kompleks dan tidak mudah untuk dikelola. Dalam jangka panjang, kompleksitas akan menghalangi (atau setidaknya, memperlambat) inovasi. we must then shift our attention from mastering complexity to extracting simplicity... [Shenker, 2011]

Yg terakhir merujuk pada proses pemodelan dan abstraksi bidang kontrol jaringan. Menurut Shenker, SDN control plane memerlukan setidaknya 3 jenis abstraksi (SDN v1 & v2) : 1. Forwarding Abstraction : bertujuan untuk menjadikan mekanisme forwarding yg fleksibel dan tidak bergantung pada jenis perangkat (vendor neutrality). 2. State Distribution Abstraction : bertujuan untuk medapatkan global network view dan menangani semua proses state dissemination/collection. Abstraksi ini dilakukan oleh NOS (Network Operating System) yg merupakan sistem terdistribusi, berkomunikasi dengan elemen jaringan untuk membuat network view. Aplikasi/control-program menggunakan network-view ini untuk menghasilkan konfigurasi setiap elemen jaringan. 3. Specification Abstraction : bertujuan untuk mendapatkan abstract network view yg merupakan fungsi dari global network view. Abstraksi ini dilakukan oleh Network Hypervisor (Nypervisor) yg menterjemahkan abstract ke global network view. Dengan Nypervisor, aplikasi/control-program dapat berinteraksi dengan jaringan seolah-olah seperti single-device. Dalam istilah Shenker, SDN v1 adalah gabungan antara NOS dengan abstraksi forwarding. SDN v2 sudah termasuk Network Hypervisor.

SDN dan OpenFlow Sering ada yg keliru beranggapan bahwa OpenFlow (OF) adalah sinonim SDN. OpenFlow hanya merupakan salah satu komponen dari arsitektur SDN. OF merupakan pionir standard terbuka untuk protokol komunikasi antara control dan forwarding plane (i.e. Southbound APIs).

Penutup Beberapa hal yg perlu diingat: SDN bukan (tidak terkait langsung dengan) mekanisme/protokol komunikasi baru! Dengan kata lain, SDN kompatibel dengan teknologi yg sudah ada e.g. MPLS (forwarding), OSPF (state distribution), BGP (operator control) dll. Bicara tentang SDN, lebih terkait dengan modularitas dan fleksibilitas; terutama karena membawa kultur modular programming ke dunia networking Dengan SDN, network engineer/scientist dapat membuat fungsionalitas yg lebih kompleks secara lebih mudah, cepat dan handal, tanpa harus meng-invent atau mengoperasikan protokol komunikasi baru Abstraksi diperlukan untuk memilih fokus; dengan abstraksi setiap challenges (fungsionalitas) menjadi modular dan mudah ditelusuri Abstraksi adalah fundamental, sedangkan implementasi SDN adalah ephemeral (termasuk OF, controller dll.) Aplikasi dikembangkan di atas abstraksi (model abstrak) jaringan Masa depan jaringan terletak pada abstraksi yg tepat (cleaner abstraction), bukan melulu dengan membuat protokol terdistribusi yg kompleks Berkaca dari (r)evolusi sistem operasi, konsep SDN akan terus berkembang, untuk menemukan abstraksi yg tepat, efisien dan sederhana (make it work, then make it simple)

Referensi 1. SDN Architecture Overview, Open Networking Foundation ONF, December, 2013 2. The Future of Networking, and the Past of Protocols , Scott Shenker, 2011

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Pengantar OpenStack Ady Saputra, Adrie Taniwidjaja & Eueung Mulyana OpenStack merupakan platform perangkat lunak untuk cloud, baik publik maupun privat. Inisiatif OpenStack dimulai tahun 2010 oleh Rackspace dan NASA. Relatif muda dibandingkan dengan beberapa inisiatif cloud lain seperti CloudStack atau OpenNebula.

Definisi OpenStack adalah sistem operasi cloud yg mengelola sumber-daya a.l. komputasi, penyimpan dan jaringan, yg tersedia pada infrastruktur fisik seperti dalam sebuah fasilitas pusat-data (data-center). Admin atau pengguna dapat mengendalikan dan melakukan provisioning atas sumber-daya ini melalui dashboard / antar-muka web. Developer dapat mengakses sumber-daya tersebut melalui sejumlah API standard. TL;DR OpenStack: Platform cloud sumber terbuka (open-source), untuk cloud publik maupun privat Platform IaaS (Infrastructure as a Service) yg mengatur sumber-daya a.l. compute, storage, network Sistem operasi cloud yg massively scalable Proyek dan komunitas open-source besar, didukung dan diikuti oleh banyak pihak, baik individu maupun industri

Rilis OpenStack Codename

Rilis Terakhir

Status

Juno

Oct 16, 2014

Stable, Security-Supported

Icehouse

Oct 2, 2014

Security-Supported

Havana

Sep 22, 2014

EOL

Grizzly

Mar 20, 2014

EOL

Folsom

Apr 11, 2013

EOL

Essex

Oct 12, 2012

EOL

Diablo

Jan 19, 2012

EOL

Cactus

Apr 15, 2011

Deprecated

Bexar

Feb 3, 2011

Deprecated

Austin

Oct 21, 2010

Deprecated

Intro Video

Arsitektur OpenStack dirancang dengan aristektur modular, terdiri dari komponen-komponen berikut: Horizon - OpenStack Dashboard Nova - OpenStack Compute (komputasi) Neutron - OpenStack Networking (jaringan) Swift - OpenStack Object Storage (penyimpan) Cinder - OpenStack Block Storage (penyimpan blok) Keystone - OpenStack Identity (layanan identitas) Glance - OpenStack Image Ceilometer - OpenStack Telemetry (billing) Heat - OpenStack Orchestration Trove - OpenStack Database

Nova Kontroler compute seperti Nova, merupakan komponen utama dari sistem IaaS, karena entitas ini yg mengatur proses dan alokasi CPU untuk setiap VM. Karakteristik Nova: Component based architecture: memudahkan penambahan fitur dan dan/atau perubahan skema (behaviour) Highly available: dapat menyesuaikan dengan penambahan beban komputasi (scale) Fault-Tolerant: proses yg terisolasi untuk menghindari kegagalan karena efek domino (cascading failures) Recoverable: kegagalan akan mudah di-diagnosis, di-debug dan ditanggulangi Open Standard: menjadi implementasi referensi untuk API yg community-driven API Compatibility: API yg kompatibel dengan sistem-sistem populer seperti Amazon EC2

Neutron Fungsi utama Neutron adalah untuk menyediakan Network connectivity as a service i.e. Neutron merupakan sistem untuk melakukan provisioning jaringan yg melibatkan entitas virtual (VM). Termasuk kedalam fungsi ini, antara lain, mengatur jaringan/subnet, router, load-balacer, gateway, floating IP. Neutron juga merupakan elemen yg (akan) banyak bersentuhan dengan konsep SDN.

Cinder

Cinder menyediakan layanan penyimpan blok (persistent) untuk digunakan oleh compute instances. Cinder didisain untuk bekerja-sama dengan komponen OpenStack, terutama compute dan dashboard. Cinder memungkinkan admin/pengguna untuk mengatur kebutuhan terhadap media penyimpan dan dapat digunakan untuk skenario-skenario pemakaian yg sensitif atau yg membutuhkan kinerja tinggi seperti: penyimpan database, expandable file systems, akses raw pada penyimpan blok, snapshot management e.g untuk backup/restorasi.

Horizon Horizon merupakan implementasi (ofisial untuk konsep) dashboard OpenStack. Horizon menyediakan antar-muka web untuk semua layanan OpenStack termasuk Nova, Swift, Keystone dll. Horizon dibuat menggunakan platform Django dengan konsep yg extensible dan mengunakan komponen-komponen reusable.

Referensi 1. OpenStack.org , The OpenStack Foundation 2. Official OpenStack Documentation 3. OpenStack Wiki 4. Getting Started With OpenStack, Kenneth Hui (Rackspace), Dan Radez (RedHat), 5. Cloud Foundry and OpenStack – Marriage Made in Heaven !, Animesh Singh, Egle Sigler, Jason Anderson, CF Summit, June 2011.

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Virtualisasi dan Hypervisor Teknologi Virtualisasi adalah landasan bagi tumbuh dan berkembangnya OpenStack. Pada hakikatnya OpenStack tidak lain adalah suatu kerangka kerja bagaimana mengatur dan mendayagunakan teknologi virtualisasi yang berkembang terus agar penggunaannya baik dalam skala kecil maupun dalam skala yang luar biasa besar tetap terkontrol dan mudah dilakukan.

Definisi Virtualisasi Virtualisasi adalah membuat versi maya (virtual) dari suatu sumber daya (resource) sehingga pada satu sumber daya fisik dapat dijalankan atau disimpan beberapa sumber daya maya sekaligus, dengan syarat unjuk kerja masing-masing sumber daya maya itu tidak berbeda signifikan dengan sumber daya fisiknya. Hingga saat ini sumber daya yang terlah dapat divirtualisasikan antara lain adalah perangkat keras komputer (hardware), media penyimpan data (storage), operating system (os), layanan jaringan (networking) dan daftar ini masih bertambah terus. Virtualisasi ini dimungkinkan karena perkembangan teknologi hardware yang sedemikian pesat sehingga kemampuan sebuah sumber daya fisik berada jauh di atas tuntutan penggunaannya sehinga sebagian besar waktu atau kapasitasnya tidak terpakai (idle). Kapasitas atau kemampuan lebih ini didayagunakan dengan menjalankan atau menyimpan beberapa sumber daya maya (tergantung pada kemampuan dan kapasitas sumber daya tersebut dan beban kerjanya) sehingga dapat menghasilkan efisiensi yang lebih tinggi.

Definisi Hypervisor Secara teknis virtualisasi diwujudkan dengan menambahkan satu bagian (layer) perangkat lunak (software) yang disebut dengan nama hypervisor. Hypervisor ini berfungsi sebagai Virtual Machine Manager (VMM) yaitu bagian yang melakukan abstraksi dari perangkat keras fisik menjadi perangkat keras virtual dalam rangka mendistribusikan beban kerja dari semua mesin virtual (VM) ke masing-masing perangkat keras secara proporsional.

Virtualisasi pada keluarga komputer yang berarsitektur x86 Pada awalnya virtualisasi pada keluarga komputer yang berarsitektur x86 dianggap sulit direalisasikan karena prosesor x86 memiliki arsitektur yang dapat digambarkan dengan bagan seperti di bawah ini :

Prosesor x86 membagi tingkatan akses menjadi 4 tingkat yang dinamai Ring 0, 1, 2, dan 3. Ring 0 adalah satu-satunya tingkatan yang memungkinkan dijalankannya perintah-perintah untuk mengakses memori atau perangkat keras lainnya secara langsung. Ring yang lain tidak dapat menjalankan perintah-perintah untuk mengakses memori dan perangkat keras secara langsung. Software yang dijalankan pada Ring 1, 2, dan 3 dibatasi aksesnya ke hardware untuk alasan keamanan sistem yang ketat. Akses hardware dari Ring selain Ring 0 akan diseleksi terlebih dahulu dan apabila diijinkan akan didelegasikan melalui Ring 0 dengan mendapatkan pengawalan yang sangat ketat. Idealnya virtualisasi dapat dilakukan dengan mudah dengan cara menempatkan hypervisor pada Ring 0 dan OS minimal di Ring 1. Akan tetapi OS perlu mengakses memori dan perangkat keras lainnya secara langsung. Dalam kondisi biasa OS menempati Ring 0 dan tidak ada masalah. Bila OS harus digeser ke Ring 1 maka timbul masalah akses. Sehingga tantangan terbesar virtualisasi dalam keluarga komputer yang berarsitektur x86 adalah bagaimana membuat sebuah hypervisor yang dapat dijalankan di Ring 0 akan tetapi tidak menghalangi akses dari OS yang digeser dari Ring 0 ke Ring 1. Ada beberapa cara yang dilakukan untuk mewujudkan hal tersebut yang mengakibatkan pada akhirnya muncul beberapa jenis hypervisor juga. Implikasinya ada tiga macam teknologi virtualisasi yang saat ini bersaing di pasar, yaitu : Virtualisasi Total dengan cara translasi biner Paravirtualisasi dengan modifikasi OS Virtualisasi dengan bantuan perangkat keras.

Virtualisasi Total dengan cara translasi biner virtualisasi total sementara ini adalah cara virtualisasi yang paling sulit. Implementasinya adalah dengan membuat hypervisor yang beroperasi di Ring 0 dan menggeser OS ke Ring 1. Setiap perintah yang mengakses memori atau perangkat keras lainnya yang dijalankan di Ring 1 dihadang terlebih dahulu agar supaya tidak menimbulkan "error" dengan cara ditranslasikan menjadi perintah yang efeknya sama seperti yang dikehendaki tetapi dijalankan oleh hypervisor yang berada di Ring 0. Sementara itu aplikasi yang dijalankan di Ring 3 karena tidak mengandung perintah yang mengakses memori atau hardware secara langsung dapat dieksekusi langsung tanpa interverensi dari hypervisor. Bagannya dapat dilihat seperti di bawah ini :

Keunggulan utama teknologi ini adalah tidak perlu ada perubahan pada guest OS dan dapat dijalankan di semua jenis prosesor x86 tanpa perlu fitur khusus. Contoh implementasi dari teknologi ini adalah pada hypervisor vMWare ESX dan Microsoft Virtual Server.

Paravirtualisasi Berbeda dengan virtualisasi total yang tidak memerlukan perubahan pada guest OS maka pada paravirtualisasi teknologi hypervisor yang diimplementasikan adalah dengan cara mengubah kernel dari guest OS menjadi kernel yang memahami virtualisasi. Hal ini dilakukan dengan mengubah perintah-perintah yang mengakses memori dan perangkat keras secara langsung menjadi sebuah hypercall yaitu perintah yang mengakses hypervisor (virtualization layer) yang mengatur implementasi virtualisasi. Karena teknologi ini perlu mengubah kernel guest os maka pada awalnya paravirtualisasi tidak dapat menjalankan Windows sebagai guest OS, karena Windows adalah OS yang tidak open source. Bagan dari paravirtualisasi dapat dilihat pada gambar di bawah ini :

Teknologi paravirtualisasi ini kita jumpai pada xen yang antara lain dipergunakan oleh Oracle VM Server dan Citrix Xen Server. Untuk mengatasi kendala menjalankan Windows sebagai guest os maka akhir-akhir ini xen mengadopsi juga

teknologi virtualisasi dengan bantuan perangkat keras sebagai bagian dari teknologi paravirtualisasinya. Kelebihan utama dari teknologi paravirtualisasi ini adalah mengubah kernel guest os lebih mudah daripada membuat translasi biner seperti pada teknologi virtualisasi total, selain itu perbedaan unjuk kerja dari mesin virtual dan tidak sangat kecil (hampir tidak ada perbedaan).

Virtualisasi dengan bantuan perangkat keras Ini adalah teknologi virtualisasi yang baru saja dikembangkan semenjak hadirnya processor yang memiliki kemampuan atau dukungan terhadap teknologi virtualisasi seperti teknologi VT-x pada prosesor Intel atau teknologi AMD-V pada prosesor AMD. Dukungan dari prosesor terhadap teknologi virtualisasi ini adalah pengambilalihan tugas menghadang perintah-perintah yang mengakses memori atau perangkat keras secara langsung yang dilakukan pada teknologi virtualisasi total dengan implementasi melalui software menjadi salah satu fitur perangkat keras hardware. Bagan nya dapat dilihat seperti berikut :

Dengan demikian tidak diperlukan lagi translasi biner atau perubahan pada kernel guest os. Fitur dukungan hardware dari prosesor ini menjadi tumpuan bagi tumbuh dan berkembangnya teknologi virtualisasi di masa depan. Di awal perkembangannya unjuk kerja dari teknologi virtualisasi dengan bantuan perangkat keras ini memang masih belum sempurna yaitu dalam hal unjuk kerjanya masih belum mampu melebihi teknologi virtualisasi total, namun kita berharap ke depan secara berangsur-angsur hal tersebut akan menjadi lebih baik mengingat bahwa secara teknologi fitur ini adalah yang paling ideal dalam mendukung teknologi virtualisasi. Satu hal yang paling menggembirakan dengan teknologi virtualisasi dengan dukungan hardware ini adalah munculnya hypervisor yang berkode sumber terbuka secara total yaitu kvm sehingga membuka kemungkinan bagi semakin cepatnya teknologi virtualisasi ini akan berkembang. KVM adalah hypervisor yang paling dominan dalam lingkungan OpenStack.

Referensi 1. Understanding Full Virtualization, Paravirtualization, and Hardware Assists, vMWare Technical Paper 2. Virtualization, Wikipedia

Pengantar NFV Eueung Mulyana Konsep NFV (Network Functions Virtualization) berawal dari para operator/telco yg mencari jalan untuk mempercepat implementasi layanan baru jaringan untuk mendukung strategi bisnis dan pertumbuhan pendapatan mereka. Salah-satu hambatan signifikan yg mereka rasakan adalah ketergantungan terhadap hardware-based appliance.

Pra NFV Pada jaringan operator tradisional, setiap fungsi (jaringan) spesifik biasanya dilakukan oleh appliance dengan perangkat keras proprietary. Software dan hardware dalam appliance (sengaja dibuat) tidak bisa dipisahkan dan tergantung satu sama lain. Contoh dari appliance yg dimaksud antara lain adalah: perangkat DPI (Deep Packet Inspection), CDN (Content Distribution Network) Appliance, Router, Firewall, Load-Balancer, NAT (Network Address Translators), Session Border Controller, Mobile Base Station Controller, Mobile Packet Gateway, DNS (Domain Name System) dll.

Inisiatif NFV Ketika banyak orang sudah sangat terbiasa dengan server virtual, kemudian mulai ada yg mempertanyakan: mengapa Network Function (NF) harus masih tergantung pada hardware tertentu? Bukankah, apabila NF dapat berjalan pada perangkat yg lumrah dan mudah didapat (i.e. commodity hardware), implementasi NF pada jaringan akan lebih cepat, mudah dan murah? NFV adalah konsep yg dimunculkan untuk membuat NF yg dapat diimplementasikan seluruhnya secara software, dan kemudian untuk dijalankan pada industry-standard hardware. Secara umum, industry-standard hardware menunjuk pada server-server umum (e.g. Intel x86) yg tersedia di pasar beserta kelengkapannya (e.g. switch ethernet standard). Dengan konsep ini, sebuah NF (e.g. Session Border Controller) dapat didistribusikan ke operator (hanya) sebagai software. Yg perlu dilakukan oleh operator ini, hanyalah melakukan prosedur instalasi pada infrastruktur data-center mereka (cukup dengan perangkat standard e.g. rack-mounted / blade-server yg saling terhubung dengan switch ethernet).

Physical vs. Virtual NF Keterbatasan NF secara fisik: Fragmented non-commodity HW Instalasi fisik per appliance per site Utilisasi aset rendah Pengembangan HW relatif lambat dan sulit dilakukan proses kontinu (deploy, upgrade, etc.) Untuk pemain baru, barrier-to-entry untuk pengembangan HW relatif lebih sulit Keterbatasan lain (pemilihan vendor, fitur modularitas, dll.)

Keuntungan NF virtual (NFV): Flexible, extensible Utilisasi aset tinggi Dapat melakukan proses kontinu (deploy, upgrade) Modular Kondusif untuk iklim kompetisi, barrier-to-entry relatif lebih rendah Ekosistem inovatif

TL;DR - NFV

Fungsi jaringan (NF) secara (pure) software Memisahkan / menghilangkan ketergantungan NF terhadap perangkat proprietary Menggunakan teknologi virtualisasi standard Dapat berjalan pada commodity / industry-standard hardware :-D

Referensi 1. What is NFV?, SDNcentral 2. A Guide to NFV and SDN, Martin Taylor, Metaswitch Networks, 2014 3. Utilizing OpenStack to Meet Telco Needs, Toby Ford (AT&T), Mats Karlsson (Ericsson), 2014 4. SDN and NFV for Carriers,MP Odini (HP), 2013

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Testbed OF@ITB Pories Ediansyah H & Affan Basalamah

Pendahuluan Tujuan utama Menyediakan testbed untuk penelitian openflow ITB Untuk pribadi, sebagai network openflow dengan mensimulasikan network kampus ganesha ITB Fitur yang harus dimiliki testbed Peneliti dapat melakukan penambahan atau pemanjangan jaringan Peneliti dapat mendesain topologi sendiri tanpa mengganggu peneliti lain Peneliti dapat menggunakan openflow versi 1.0 hingga versi 1.4 Peneliti dapat mengontrol trafik menggunakan controllernya sendiri

Komponen 3 Node switch : Menggunakan kernel linux debian versi 3.10 Terdapat VM management menggunakan proxmox Routing menggunakan quagga Openflow switch menggunakan OpenVSwitch v2.3.0 Support openflow 1.0 hingga 1.4 1 Controller : Menggunakan OS CentOS 6.5 Integrated framework java 1.7, Python 2.6, Perl 5.10 Controller openflow Ryu, Beacon, Opendaylight Service Provider, dan Floodlight

Komponen (Detil) Server Node 1 (PAU) CPU : Xeon 3.47GHz @ 4 core RAM : 8GB DDR3 Disk : 128 GB Server Node 2 (Labtek 8) CPU : Xeon 3.10GHz @ 4 core RAM : 8GB DDR3 Disk : 1 TB Server Node 3 (Labtek 5) CPU : Xeon 2.20GHz @ 4 core RAM : 8GB DDR3 Disk : 128 GB

Server Controller (Labtek 5) CPU : Xeon 2.20GHz @ 2 core RAM : 4GB DDR3 Disk : 40 GB

Arsitektur Umum Terhubung dgn tunnel vxlan melalui IP publik Pemisahan path controller dan openflow switch Per-Node memiliki kemampuan untuk membuat VM untuk memperpanjang networknya Routing antar node menggunakan protocol routing OSPF Arsitektur - Per-Node

Deskripsi Topologi 1 Digunakan untuk mempelajari software openflow switch (openvswitch) dan openflow controller Topologi ini dapat digunakan untuk menyederhanakan permasalahan yang ada di openflow Topologi - Logical

Eksperimen Pengenalan OF Researcher dapat membuat openflow switch tersendiri Setiap interface openflow dapat mensetting controller sendiri-sendiri (1 interface, 1 controller) OF Controller dapat di install berbagai macam software controller Penggunaan CLI User dapat membuat interface openflow dengan cara : Jalankan perintah ovs-vsctl add-br [interface_OF] Menambahkan port dengan cara ovs-vsctl add-port [interface_OF] [port_OF] Contoh penggunaan ada di startup system yang berada di /etc/network/interfaces dimana ovs_options merupakan command ovs-vsctl dalam script startup User dapat mensetting OF controller dengan cara : Jalankan perintah ovs-vsctl set-controller [interface_OF] tcp:[IP_controller]:[Port_Controller] Contoh penggunaan ada di /etc/rc.local Topologi - Switching

Topologi - Routing

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

SDN & IoT Eueung Mulyana Emang nyambung? Apa hubungannya? Untuk me-refresh ingatan, atau bagi yg belum mafhum, IoT (Internet of Things) adalah konsep Internet (masa depan) yg diperluas dengan memasukan benda-benda (things) "cerdas" sebagai sumber dan tujuan informasi. Bahkan, mereka seolah-olah saling "berbicara" satu sama lain. Sebagai ilustrasi, pada era IoT, skenario berikut adalah hal yg lumrah :-p otong: Gan, ane disuruh manasin aer, pakai mode apa nih? juragan: Pakei mode moderat tong! beban lagi berat, lagi banyak yg narik .. biar si bos gak kebobolan juga bayar tagihan Skenario di atas adalah skenario fiktif di sebuah smart home, otong mewakili pemanas air, juragan mewakili meteran listrik, kedua-duanya bukan orang :-D ... (pis, mohon maaf untuk yg namanya [mirip-mirip] otong.. :-D..) Secara konsep, IoT lebih luas dari sekedar M2M (Machine to Machine) seperti dalam contoh. IoT melibatkan cloud dalam interaksi antar partisipan, baik itu things maupun orang. Dan kalau sudah ada cloud, mestinya SDN tidak jauh-jauh amat. SDN menyediakan framework sentralisasi kontrol bagi sistem yg berjaringan, ideal untuk operator atau siapapun yg berkepentingan untuk mengelola things yg tersebar posisinya tapi aktif berkomunikasi (satu sama lain). In other words, ideal, cocok untuk IoT.

SDN + IoT Implementasi IoT yg umum adalah dengan menyambungkan sensor/aktuator lokal dengan cloud. Sensor yg terhubung dengan kontroler lokal merekam dan mengirimkan data ke cloud, melalui home gateway dan jaringan operator. Cloud dapat melakukan analisis data yg dikirim dan kemudian mengirimkan perintah kepada aktuator. Skema ini sesuai untuk kondisi data yg besar/banyak, keterkaitan antar data ketat atau untuk kondisi dimana konstrain waktu tidak terlalu krusial. Cloud dapat pula mendelegasikan (sebagian) fungsi analisis dan decision making ke gateway atau provider edge router. Skema ini dapat dipakai apabila terdapat konstrain waktu yg cukup ketat. Cara ini juga dikenal sebagai fog computing (teknologi cloud tersebar) .. Di sisi lain, SDN menyediakan mekanisme dimana "perintah" dapat dikomunikasikan dari sistem kontrol ke sistem aktuasi, misalnya dari cloud ke gateway. Dengan menggunakan fungsi kecerdasan/pemrosesan di cloud, cost untuk gateway dapat direduksi. Misalnya, fungsi router dan dhcp server dapat di-cloud-kan (e.g. via SDN controller). Contoh lain: 2 buah things yg terhubung ke 2 gateway berbeda perlu berkomunikasi satu sama lain. Apabila operator mengimplementasikan hirarki secara ketat, proses komunikasi berjalan lewat atas, bisa jadi via cloud. Dengan SDN, cloud dapat mengirimkan perintah untuk menginisiasi link horisontal (i.e. flow entry) antar gateway yg dapat digunakan langsung oleh kedua things untuk berkomunikasi.

Referensi 1. SDN, IoT Make 1 Soup, Joseph Byrne (Freescale), June, 2014

Lisensi

CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Network Hypervisor Untuk melakukan virtualisasi dalam jaringan diperlukan suatu lapisan abstraksi jaringan (network abstraction layer) yang berguna untuk melakukan pembagian (slicing) dari perangkat-perangkat jaringan atau resources jaringan. Lapisan ini seperti halnya dengan hypervisor pada umumnya, yang terletak diantara perangkat lunak (software) dan perangkat keras (hardware) dalam suatu PC, namun network hypervisor terletak antara control path dan forwarding path dari suatu perangkat jaringan. Ada dua generasi atau versi yang network hypervisor yang dikembangkan oleh ON Lab dari Standford University yaitu FlowVisor dan OpenVirtex (OVX).

Referensi 1. FlowVisor: A Network Virtualization Layer, OpenFlow Consortium, October, 2009

FlowVisor Seperti halnya dengan lapisan virtualisasi pada komputer, FlowVisor berada diantara lapisan fisik perangkat keras jaringan dan perangkat lunak yang mengontrolnya. Begitu juga dengan sistem operasi yang menggunakan sekumpulan instruksi untuk mengontrol perangkat keras yang ada dibawahnya, FlowVisor menggunakan OpenFlow untuk mengontrol perangkat jaringan yang ada dibawahnya karena dengan OpenFlow mengekspose paket-paket control forwarding dari switch untuk entitas terprogram (programmable entity) seperti OpenFlow Controller.

FlowVisor dapat digambarkan sebagai OpenFlow controller dengan spesial fungsi yaitu dijadikan sebagai transparent proxy antara OpenFlow Switch dan beberapa OpenFlow Controller. Kemudian FlowVisor akan membuat potongan (slices) yang lengkap dari sebuah resource jaringan dan memberikan potongan-potongan tersebut ke controller yang berbeda-beda. Potongan-potongan tersebut dapat didefinisikan dengan berbagai macam kombinasi port dari switch (layer 1), asal/tujuan dari alamat atau type ethernet (layer 2), asal/tujuan dari alamat IP atau type (layer 3), dan asal/tujuan dari alamat port TCP/UDP atau ICMP code/type (layer 4). Sekumpulan dari definisi ini bisa disebut sebagai "FlowSpace" dari spesifik potongan (slice) tersebut. Salah satu pentingnya fungsi dari FlowVisor yaitu memaksa setiap potongan (slice) tersebut terisolasi, sehingga tidak bisa saling mempengaruhi seperti controller dari slice satu tidak bisa mengontrol trafik dari slice yang lainnya.

Referensi 1. FlowVisor: A Network Virtualization Layer, OpenFlow Consortium, October, 2009 2. FlowVisor Wiki, OpenNetworkingLab, June, 2013

OpenVirtex (OVX) Seperti halnya dengan FlowVisor, OpenVirtex juga merupakan platform virtualisasi jaringan yang mengijinkan untuk melakukan pengaturan topologi jaringan dan pengalamatan yang unik dengan tetap memberikan kontrol penuh dari jaringan virtual yang berbasiskan OpenFlow. Pada intinya, teknologi ini ingin memperkenalkan sebuah konsep baru yaitu jaringan virtual yang terprogram (Programmable Virtual Network). OVX juga berada diantara perangkat keras fisik yang ada dibawahnya dan controller jaringan virtual, yang pada akhirnya akan memberikan: kemampuan untuk membuat jaringan virtual yang terisolasi dengan topologi yang spesikasi khusus kemungkinan membangun Network Operating System kemampuan menggunakan seluruh ruang pengalamatan (address space) kemampuan mengubah topologi jaringan yang sedang beroperasi kemungkinan melakukan recover dari failure fisik

Referensi 1. OpenVirtex: Programmable Virtual Networks, ONLAB US, December, 2014

Open Network OS - ONOS Eueung Mulyana ONOS (Open Network Operating System) merupakan sistem operasi jaringan SDN yg terbuka (open source), ditujukan terutama untuk jaringan operator. ONOS diprakarsai dan dibuat oleh ON.Lab dengan kerja-sama lintas sektor, baik operator, vendor maupun universitas. ONOS baru (akan) diluncurkan ke publik tanggal 5 Desember 2014.

ONOS dan Operator ONOS diperkenalkan sebagai OS jaringan SDN yg multi-entitas dan terdistribusi, serta dirancang untuk HA, kinerja tinggi, skalabitas dan abstraksi NB/SB yg konsisten (dan semakin baik). Atribut kunci yg (katanya) membuat ONOS cocok untuk jaringan operator, adalah: NB: Menyediakan "Application Intent Framework" sebagai NBI untuk aplikasi. AIF adalah framework (policy-driven) yg dapat digunakan oleh devs/ops sebagai bahasa high-level tanpa harus dipusingkan dengan bagaimana implementasinya di jaringan NB: Menyediakan informasi struktur (graph) seluruh jaringan sebagai bagian dari abstraksi NB Core: Sistem terdistribusi dengan implikasi HA, HP dan scale-out SB: Menyediakan abstraksi SB untuk discovery, konfigurasi dan programmability; mendukung OF dan sejumlah interface/divais lainnya

Use Cases Contoh penggunaan ONOS di operator: Kontrol dan optimasi jaringan core optik via SDN secara multi-layer Implementasi jaringan hibrid SDN-IP dengan peering transparan antar (pulau) SDN dan (pulau) IP/Internet NFaaS (Network Function as a Service), salah satu pendekatan NFV yg skalabel, fleksibel dan intuitif Segment Routing (WAN-based)

Referensi 1. ONOS - An Experimental Open-Source Distributed SDN OS, ON.LAB/ONRC, September, 2013 2. SDN Adoption in Service Provider Networks, ON.LAB/ONRC, November, 2014

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Video Multicast OF v1.0 Coming soon ...

Mininet - Eksperimen Topologi Dwina Fitriyandini Siswanto, Siti Amatullah Karimah Pada Mininet sudah terdapat beberapa topologi bawaan yang dapat langsung digunakan dengan menggunakan perintah (command) tertentu. Beberapa topologi bawaan tersebut antara lain topologi single, tree dan linear.

Pada eksperimen ini dilakukan pembangunan topologi diluar ketiga topologi diatas atau bisa disebut dengan topologi bebas atau custom topology.

Topologi Bebas (Custom Topo) Membuat custom topology dapat dilakukan dengan 2 cara, yaitu secara manual dengan menulis kode python atau membuat konfigurasi topologi menggunakan GUI editor seperti Virtual Network Description (vnd) kemudian diexport ke bentuk file yang dapat di-running oleh mininet. Membuat custom topology manual pada mininet 1. Buatlah file .py dari topologi yang diinginkan kemudian simpan di folder mininet/custom/ 2. Setelah membuat file .py kemudian run custom topology yang telah dibuat menggunakan command : $ sudo mn -custom --topo mytopo --mac --switch ovsk --controller remote

Membuat custom topology dengan vnd pada via situs http://www.ramonfontes.com/vnd/ 1. Buatlah topologi yang diinginkan 2. Klik File>Export>Export to mininet, kemudian ubah format file menjadi .py 3. Pada mininet, copy file ke dalam folder mininet/examples 4. Buat agar file vnd dapat dieksekusi oleh mininet dengan $ chmod +x 5. Jalankan file menggunakan command $ sudo ./ Ketika membuat custom topology pada vnd, terdapat beberapa fitur pendefinisian yang dibawa oleh vnd. Diantaranya sebagai berikut :

Menjalankan POX Controller Sebelum menjalankan custom topology jalankan controller yang digunakan. Pada eksperimen ini controller yang digunakan ialah POX controller. Berikut contoh cara menjalankan POX controller dalam mininet:

cd /home/ubuntu/pox && ./pox.py log.level --DEBUG forwarding.tutorial_I2_hub

Eksperimen Custom Topology Pada eksperimen ini dibuat 5 custom topology yang masing-masingnya dibangun menggunakan 2 cara yang dijelaskan sebelumnya yakni secara manual dan juga mengunakan vnd. Berikut 5 jenis topologi yang dibangun,

1. 01_custom_topo

Menjalankan custom topology yang telah dibuat di mininet

Menjalankan custom topology yang telah dibuat di vnd

2. 02_custom_topo

3. 2d_mesh_topo

4. 2d_torus_topo

5. full_connect_topo

Penjelasan Source Code Mininet Topology Berikut ini sedikit penjelasan mengenai source code pembentukan topologi pada mininet, berdasarkan topologi yang di generate oleh vnd.

Baris pertama diawali dengan simbol #! yang diikuti oleh pathname (/usr/bin/python) dari Python interpreter agar script Python dapat dieksekusi oleh sistem operasi Unix. 'Statement from' pada Python memungkinkan kita meng-import atribut secara spesifik dari modul kedalam namespace yang digunakan.

def topology() : merupakan sintaks yang digunakan untuk mendefinisikan fungsi ‘topology’ dimana pada akhir namespace, fungsi ini dipanggil melalui sintaks ‘topology()’. net = Mininet ( controller=RemoteController, link=TCLink, switch=OVSkernelSwitch ) •controller=RemoteController Mendefinisikan controller yang di kontrol diluar Mininet. •link=TCLink Menspesifikasikan link sebagai TC yang digunakan untuk memodifikasi parameter link. •switch=OVSkernelSwitch Penggunaan OVS (Open v Switch) untuk menyediakan fungsi switching pada lingkungan virtualisasi hardware dan juga mendukung berbagai macam protokol standar pada jaringan komputer.

Setelah jaringan dibentuk, perintah 'start()' digunakan untuk menjalankannya. Kemudian sistem dapat menjalankan beberapa task yang berguna diantaranya melakukan tes basic connectivity, bandwidth test dan juga menjalankan mininet CLI. Metode 'net.stop()' dipanggil untuk melakukan shut down pada jaringan setelah seluruh tes atau aktivitas yang diinginkan dijalankan.

Referensi 1. TBA 2. ...

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Mininet - Eksperimen OVS Bagus Aditya, Hamzah U. Mustakim

Macam-macam Flow Matching pada Topologi Mininet Tanpa Controller Terdapat beberapa macam flow matching yang bisa dilakukan pada mininet. Pada topologi yang akan dibuat, terdapat 3 host dan 1 buah switch ovsk. Kemudian pada switch tersebut ditambahkan flow untuk melakukan komunikasi antar host. Pada simulasi kali ini dilakukan beberapa kasus flow matching. Yaitu Port based, MAC Address Based, IP Based, dan Transport Protocol Based pada simple HTTP server.

PORT BASED FLOW MATCHING (L1)

Port Based Membuat single topologi dengan 3 host tanpa menghubungkan ke controller Pada mesin yang sudah terinstall mininet / VM Mininet yang bisa didownload dari website resmi mininet, lakukan perintah di bawah ini : sudo mn --mac --topo single,3 --switch ovsk --controller=remote

*** Creating network *** Adding controller Unable to contact the remote controller at 127.0.0.1:6633 *** Adding hosts: h1 h2 h3 *** Adding switches: s1 *** Adding links: (h1, s1) (h2, s1) (h3, s1) *** Configuring hosts h1 h2 h3 *** Starting controller *** Starting 1 switches s1 *** Starting CLI:

Kemudian untuk melihat network interface yang terhubung pada host dan switch dengan command seperti berikut : mininet> net

maka muncul tampilan interface network pada tiap node seperti di bawah ini

h1 h1-eth0:s1-eth1 h2 h2-eth0:s1-eth2 h3 h3-eth0:s1-eth3 s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:h3-eth0 c0

Untuk menampilkan informasi pada setiap node yang ada, dengan comand dibawah ini: mininet> dump

Maka akan muncul tampilan dibawah ini:





Untuk melihat flow-table pada switch1 gunakan comand seperti dibawah ini: sudo ovs-ofctl dump-flows s1

Selanjutnya akan didapat tampilan flow-table seperti dibawah ini.

NXST_FLOW reply (xid=0x4):

Flow table di atas terlihat masih kosong. Hal ini dikarenakan kita belum menambahkan flow pada switch1 sehingga antar host belum bisa saling berkomunikasi. Untuk menambahkan flow pada switch-1 berdasarkan port yang tersedia, lakukan command di bawah ini Add flow at Port 1 sudo ovs-ofctl add-flow s1 in_port=1,action=output:2

Command di atas adalah menambahkan flow pada port 1 dengan keluaran pada port 2 pada s1 Kemudian kita bisa melihat flow table yang telah dimasukkan, sudo ovs-ofctl dump-flows s1

NXST_FLOW reply (xid=0x4): cookie=0x0, duration=3.237s, table=0, n_packets=0, n_bytes=0, idle_age=3, in_port=1 actions=output:2

Skenario 1 Pada skenario 1 ini kita akan mencoba melakukan tes komunikasi dari host 1 ke host 2 dengan mengirimkan sebuah paket ICMP. Lakukan Xterm pada h1,h2, dan h3. Kemudian untuk menampilkan paket yang berada pada eth0-nya kita gunakan command: pada h1 : tcpdump -ne -i h1-eth0 pada h2 : tcpdump -ne -i h2-eth0 pada h3 : tcpdump -ne -i h3-eth0 Kemudian, lakukan ping dari h1 ke h2 : h1 ping -c 1 h2

Pada h1 akan didapat dumping paket dibawah ini:

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:53:04.725955 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 06:53:05.724128 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 06:53:06.724140 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt

Selanjutnya kita lihat dumping paket pada h2

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:53:04.726225 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 06:53:04.726239 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 06:53:05.724183 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 06:53:05.724199 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 06:53:06.724203 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt

06:53:06.724220 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt

dari hasil dumping paket pada kedua host di atas, maka bisa dituliskan sequence diagram seperti di bawah ini:

participant h1 participant s1 participant h2 participant h3 h1->s1:ARP Request s1-->h2:ARP Request h1->s1:ARP Request s1-->h2:ARP Request h1->s1:ARP Request s1-->h2:ARP Request h2-->s1:ARP Reply h2-->s1:ARP Reply h2-->s1:ARP Reply

Skenario 2 Masih menggunakan 1 flow table yang sama, kita lakukan tes komunikasi dari h2 ke h1. Jangan lupa untuk xterm h1,h2 dan h3, kemudian amati paket yang datang dan keluar di setiap interface host dengan melakukan dumping. mininet> h2 ping -c 1 h1

Kita hanya akan menemukan paket ICMP Request dan ARP Request pada h2 saja, seperti yang terlihat di bawah ini :

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:55:54.707010 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 4 06:55:59.720120 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 06:56:00.720102 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 06:56:01.721048 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt

Maka bisa dituliskan sequence diagram seperti di bawah ini :

participant h1 participant s1 participant h2 participant h3 h2->s1:ICMP Request h2-->s1:ARP Request h2-->s1:ARP Request h2-->s1:ARP Request

Terlihat s1 belum bisa meneruskan paket dari h2 ke h1. Hal ini dikarenakan kita belum menambahkan flow dari port2 ke port1 Tahap selanjutnya kita akan menambahkan flow pada port2 ke port1 pada s1 Tambahkan flow pada port2 ke port1 pada s1 menggunakan command berikut sudo ovs-ofctl add-flow s1 in_port=2,action=output:1

Maka untuk mengecek flow table menggunakan command berikut : sudo ovs-ofctl dump-flows s1

Didapatkan flow table di bawah ini :

NXST_FLOW reply (xid=0x4): cookie=0x0, duration=376.441s, table=0, n_packets=9, n_bytes=378, idle_age=131, in_port=1 actions=output:2

cookie=0x0, duration=2.199s, table=0, n_packets=0, n_bytes=0, idle_age=2, in_port=2 actions=output:1

Skenario 1 Sama seperti skenario 1 sebelumnya, kita akan melakukan tes komunikasi antara h1 ke h2. Jangan lupa untuk melakukan xterm h1, h2 , dan h3 untuk mengamati paket yang melewati interface tiap host. Setelah itu lakukan command ping : h1 ping -c 1 h2

Maka tcpdump pada h1 diperoleh:

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:57:54.375670 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 06:57:54.377215 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 06:57:54.377226 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 4 06:57:54.378185 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 425 06:57:59.385383 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 06:57:59.385404 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Dan tcpdump pada h2 diperoleh:

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:57:54.375946 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 06:57:54.375975 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 06:57:54.377700 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 4 06:57:54.377722 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 425 06:57:59.384967 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 06:57:59.386119 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Kita bisa tuliskan sequence diagram sebagai berikut:

participant h1 participant s1 participant h2 participant h3 h1->s1: ARP Request s1-->h2:ARP Request h2-->s1:ARP Reply s1->h1: ARP Reply h1->s1: ICMP Request s1-->h2:ICMP Request h2-->s1: ICMP Reply s1->h1:ICMP Reply h2-->s1: ARP Request s1->h1:ARP Request h1->s1:ARP Reply s1-->h2: ARP Reply

Kita bisa melihat pada sequence diagram di atas, komunikasi sudah bisa terjadi antara h1 dan h2, paket ICMP Reply dari h2 sudah bisa diteruskan ke h1. Skenario 2 Sama seperti skenario 2 sebelumnya, kita lakukan tes komunikasi dari h2 ke h1: h2 ping -c 1 h1

Pada h1 didapatkan tcpdump berikut :

root@mininet-vm:~# tcpdump -ne -i h1-eth0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:59:56.034737 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 4 06:59:56.034764 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 429 07:00:01.048952 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 07:00:01.049462 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 07:00:01.049477 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt 07:00:01.050306 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt

Pada h2 didapatkan tcpdump berikut:

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:59:56.034503 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 4 06:59:56.035333 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 429 07:00:01.048925 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 07:00:01.049321 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 07:00:01.049349 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 07:00:01.050253 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Maka dapat dituliskan sequence diagram berikut:

participant h1 participant s1 participant h2 participant h3 h2-->s1: ICMP Request s1->h1:ICMP Request h1->s1: ICMP Reply s1-->h2:ICMP Reply h1->s1:ARP Request s1-->h2: ARP Request h2-->s1: ARP Request s1->h1:ARP Request h1->s1:ARP Reply s1-->h2: ARP Reply h2-->s1: ARP Reply s1->h1:ARP Reply

Tes komunikasi dari h2 ke h1 juga sudah bisa berhasil. ICMP Reply dari h1 sudah bisa diteruskan ke h2.

MAC BASED FLOW MATCHING (L2)

FLow Matching Based on MAC Address Selanjutnya, kita akan melakukan flow matching berdasarkan MAC Address. Jangan lupa lakukan sudo ovs-ofctl delflows s1 untuk menghapus flow table sebelumnya yang telah dibuat.

Pada percobaan pertama, kita hanya tambahkan flow dari MAC Address h1 ke port2 pada s1 sudo ovs-ofctl add-flow s1 dl_src=00:00:00:00:00:01,actions=output:2

Kita bisa lihat hasil flow table dari command di atas : sudo ovs-ofctl dump-flows s1

NXST_FLOW reply (xid=0x4): cookie=0x0, duration=3.233s, table=0, n_packets=0, n_bytes=0, idle_age=3, dl_src=00:00:00:00:00:01 actions=output:2

Skenario 1 Pada skenario 1 ini kita akan mencoba melakukan tes komunikasi dari host 1 ke host 2 dengan mengirimkan sebuah paket ICMP. Lakukan Xterm pada h1,h2, dan h3. Kemudian untuk menampilkan paket yang berada pada eth0-nya kita gunakan command: pada h1 : tcpdump -ne -i h1-eth0 pada h2 : tcpdump -ne -i h2-eth0 pada h3 : tcpdump -ne -i h3-eth0 Kemudian, lakukan ping dari h1 ke h2 : h1 ping -c 1 h2

Pada h1 akan didapat dumping paket dibawah ini:

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:22:04.953627 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 2 17:22:09.960860 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:22:10.960859 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:22:11.961977 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt

Selanjutnya kita lihat dumping paket pada h2

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:22:04.954317 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 2 17:22:04.954365 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 265 17:22:09.960887 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 17:22:09.961260 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:22:09.961287 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 17:22:10.960928 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:22:10.960948 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 17:22:11.962057 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:22:11.962079 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt

Maka dapat dituliskan sequence diagram berikut:

participant h1 participant s1 participant h2 participant h3 h1->s1:ICMP Request h1->s1:ARP Request s1-->h2:ARP Request h1->s1:ARP Request s1-->h2:ARP Request h1->s1:ARP Request s1-->h2:ARP Request s1-->h2:ICMP Request h2-->s1:ICMP Reply h2-->s1:ARP Reply h2-->s1:ARP Reply h2-->s1:ARP Reply

Skenario 2 Masih menggunakan 1 flow table yang sama, kita lakukan tes komunikasi dari h2 ke h1. Jangan lupa untuk xterm h1,h2 dan h3, kemudian amati paket yang datang dan keluar di setiap interface host dengan melakukan dumping. Maka didapatkan dumping paket hanya pada h2 seperti di bawah ini

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:23:37.849256 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2

17:23:42.856869 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 17:23:43.856866 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 17:23:44.856858 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt

Bisa dituliskan sequence-diagramnya sebagai berikut :

participant h1 participant s1 participant h2 participant h3 h2->s1:ICMP Request h2-->s1:ARP Request h2-->s1:ARP Request h2-->s1:ARP Request

Tahap selanjutnya kita akan menambahkan flow pada MAC Address h2 ke port1 pada s1 Tambahkan flow menggunakan command berikut sudo ovs-ofctl add-flow s1 dl_src=00:00:00:00:00:02,actions=output:1

Maka flow-table menjadi seperti di bawah ini:

sudo ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=3.896s, table=0, n_packets=0, n_bytes=0, idle_age=3, dl_src=00:00:00:00:00:01 actions=output:2 cookie=0x0, duration=13.064s, table=0, n_packets=0, n_bytes=0, idle_age=13, dl_src=00:00:00:00:00:02 actions=output:1

Skenario 1 Sama seperti skenario 1 sebelumnya, kita akan melakukan tes komunikasi antara h1 ke h2. Jangan lupa untuk melakukan xterm h1, h2 , dan h3 untuk mengamati paket yang melewati interface tiap host. Setelah itu lakukan command ping : h1 ping -c 1 h2 Maka pada h1 didapat paket dumping di bawah ini :

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:17:24.812247 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 2 17:17:24.813084 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 256 17:17:29.817741 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:17:29.818296 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 17:17:29.818312 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt 17:17:29.819142 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt

Dan pada h2 didapat paket dumping di bawah ini :

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:17:24.812482 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 2 17:17:24.812507 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 256 17:17:29.817770 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 17:17:29.818108 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:17:29.818164 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 17:17:29.819058 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Maka bisa ditulis sequence-diagram berikut:

participant h1 participant s1 participant h2 participant h3 h1->s1: ICMP Request s1-->h2:ICMP Request h2-->s1: ICMP Reply s1->h1:ICMP Reply h1->s1: ARP Request s1-->h2:ARP Request h2-->s1:ARP Reply s1->h1: ARP Reply h2-->s1: ARP Request s1->h1:ARP Request h1->s1:ARP Reply s1-->h2: ARP Reply

Terlihat ICMP Reply sudah bisa diteruskan ke h1 Skenario 2 Sama seperti skenario 2 sebelumnya, kita lakukan tes komunikasi dari h2 ke h1: h2 ping -c 1 h1

Pada h1 didapat dumping paket berikut :

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:19:05.147539 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2 17:19:05.147565 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 259 17:19:10.152869 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:19:10.153440 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 17:19:10.153466 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt 17:19:10.154335 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt

Pada h2 didapat dumping paket berikut :

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:19:05.147295 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 2 17:19:05.148178 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 259 17:19:10.152841 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 17:19:10.153258 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 17:19:10.153293 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 17:19:10.153707 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Maka dapat ditulis sequence-diagramnya:

participant h1 participant s1 participant h2 participant h3 h2-->s1: ICMP Request s1->h1:ICMP Request h1->s1: ICMP Reply s1-->h2:ICMP Reply h1->s1:ARP Request s1-->h2: ARP Request h2-->s1: ARP Request s1->h1:ARP Request h1->s1:ARP Reply s1-->h2: ARP Reply h2-->s1: ARP Reply s1->h1:ARP Reply

Terlihat bahwa ICMP Reply sudah bisa diteruskan ke h2

Flow Matching Based IP (L3)

IP Based Flow Matching Selanjutnya, kita akan melakukan flow matching berdasarkan IP Address Jangan lupa lakukan sudo ovs-ofctl del-flows s1 untuk menghapus flow table sebelumnya yang telah dibuat.

Tambahkan flow di bawah ini :

sudo ovs-ofctl add-flow s1 priority=500,dl_type=0x800,nw_src=10.0.0.0/24,nw_dst=10.0.0.0/24,actions=normal sudo ovs-ofctl add-flow s1 arp,nw_dst=10.0.0.1,actions=output:1 sudo ovs-ofctl add-flow s1 arp,nw_dst=10.0.0.2,actions=output:2

Maka akan terlihat flow table di bawah ini :

mininet@mininet-vm:~$ sudo ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=55.291s, table=0, n_packets=0, n_bytes=0, idle_age=12, arp,arp_tpa=10.0.0.2 actions=output:2 cookie=0x0, duration=59.466s, table=0, n_packets=0, n_bytes=0, idle_age=15, arp,arp_tpa=10.0.0.1 actions=output:1 cookie=0x0, duration=35.08s, table=0, n_packets=0, n_bytes=0, idle_age=27, priority=500,ip,nw_src=10.0.0.0/24,nw_dst=10.0.0.0/24 actio

Pada flow table terlihat bahwa pada s1 akan meneruskan paket arp ke h1 pada port1 dan ke h2 pada port2 dan juga s1 akan bertindak secara normal untuk meneruskan paket dari ip address 10.0.0.0/24 ke 10.0.0.0/24 (melihat berdasarkan ip address) Skenario 1 h1 ping -c 1 h2 Maka tampilan dumping paket pada h1 sebagai berikut

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:13:59.851916 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 1 08:13:59.853213 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 177 08:14:04.858758 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 08:14:04.858780 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Maka tampilan dumping paket pada h2 sebagai berikut

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:13:59.852170 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 1 08:13:59.852198 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 177 08:14:04.858413 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 08:14:04.859596 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Maka bisa dituliskan sequence diagram di bawah ini :

participant h1 participant s1 participant h2 participant h3

h1->s1:ICMP Request h1->s1:ARP Request h2-->s1:ICMP Reply s1->h1:ICMP Reply h2-->s1:ARP Request s1->h1:ARP Request h1->s1:ARP Reply s1-->h2:ARP Reply

Skenario2 Kemudian kita akan melakukan tes komunikasi dari h2 ke h1 dengan mengirim sebuah paket ICMP h2 ping -c 1 h1

Maka hasil dumping paket pada h1 sebagai berikut

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:15:18.845775 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 1 08:15:18.845801 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 180 08:15:23.850420 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 08:15:23.850944 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 08:15:23.850959 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt 08:15:23.851765 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt

Dan hasil dumping paket pada h2 sebagai berikut

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:15:18.845473 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo request, id 1 08:15:18.846388 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 180 08:15:23.850396 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.1 tell 10.0.0.2, lengt 08:15:23.850803 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, lengt 08:15:23.850830 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 00:00:00:00:00:02, lengt 08:15:23.851181 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype ARP (0x0806), length 42: Reply 10.0.0.1 is-at 00:00:00:00:00:01, lengt

Maka bisa dituliskan sequence diagram di bawah ini :

participant h1 participant s1 participant h2 participant h3 h2-->s1:ICMP Request s1->h1:ICMP Request h1->s1:ICMP Reply s1-->h2:ICMP Reply h2-->s1:ARP Request s1->h1:ARP Request h1->s1:ARP Request s1-->h2:ARP Request h2-->s1:ARP Reply s1->h1:ARP Reply h1->s1:ARP Reply s1-->h2:ARP Reply

TRANSPORT BASED FLOW MATCHING WITH SIMPLE HTTP SERVER

FLow Matching Based on Transport Based Selanjutnya, kita akan melakukan flow matching berdasarkan Transport Based dan mencoba mengaplikasikan request paket ke http server yang diinstall di salah satu host. Jangan lupa lakukan sudo ovs-ofctl del-flows s1 untuk menghapus flow table sebelumnya yang telah dibuat.

Menambahkan flow data pada switch dari HTTP server. sudo ovs-ofctl add-flow s1 arp,actions=normal sudo ovs-ofctl add-flow s1 priority=500,dl_type=0x800,nw_proto=6,tp_dst=80,actions=output:1 sudo ovs-ofctl add-flow s1 priority=800,ip,nw_src=10.0.0.1,actions=normal

NXST_FLOW reply (xid=0x4): cookie=0x0, duration=336.177s, table=0, n_packets=22, n_bytes=1680, idle_age=168, priority=500,tcp,tp_dst=80 actions=output:1 cookie=0x0, duration=335.335s, table=0, n_packets=22, n_bytes=3472, idle_age=168, priority=800,ip,nw_src=10.0.0.1 actions=NORMAL cookie=0x0, duration=336.237s, table=0, n_packets=0, n_bytes=0, idle_age=336, arp actions=NORMAL

mininet> h1 python -m SimpleHTTPServer 80 & mininet> h2 wget -O - h1

--2014-11-04 08:21:54-- http://10.0.0.1/ Connecting to 10.0.0.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 848 [text/html] Saving to: ‘STDOUT’ Directory listing for / Directory listing for / .bash_history .bash_logout .bashrc .cache/ .gitconfig .nano_history .profile .rnd .wireshark/ .Xauthority install-mininet-vm.sh mininet/ of-dissector/ oflops/ oftest/ openflow/ pox/ 0K 100% 29.2M=0s 2014-11-04 08:21:54 (29.2 MB/s) - written to stdout [848/848]

Kemudian didapat hasil dumping paket pada h1

root@mininet-vm:~# tcpdump -ne -i h1-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:21:54.832433 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 74: 10.0.0.2.56089 > 10.0.0.1.80: Flags [S], seq 08:21:54.832461 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 74: 10.0.0.1.80 > 10.0.0.2.56089: Flags [S.], se 08:21:54.833131 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.836282 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 172: 10.0.0.2.56089 > 10.0.0.1.80: Flags [P.], s 08:21:54.836357 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.0.0.1.80 > 10.0.0.2.56089: Flags [.], ack 08:21:54.838179 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 83: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], se 08:21:54.838219 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.838487 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 103: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.838524 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.838704 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 103: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.838740 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.838880 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 106: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.838909 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839000 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 87: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], se 08:21:54.839023 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839204 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 68: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], se

08:21:54.839244 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839426 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 914: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.839463 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839626 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.0.0.1.80 > 10.0.0.2.56089: Flags [F.], se 08:21:54.845386 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [F.], se 08:21:54.845413 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.0.0.1.80 > 10.0.0.2.56089: Flags [.], ack

Dan juga didapat hasil dumping paket pada h2

root@mininet-vm:~# tcpdump -ne -i h2-eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on h2-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:21:54.832188 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 74: 10.0.0.2.56089 > 10.0.0.1.80: Flags [S], seq 08:21:54.833081 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 74: 10.0.0.1.80 > 10.0.0.2.56089: Flags [S.], se 08:21:54.833120 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.836260 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 172: 10.0.0.2.56089 > 10.0.0.1.80: Flags [P.], s 08:21:54.836371 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.0.0.1.80 > 10.0.0.2.56089: Flags [.], ack 08:21:54.838199 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 83: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], se 08:21:54.838214 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.838501 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 103: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.838518 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.838720 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 103: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.838734 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.838893 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 106: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.838904 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839009 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 87: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], se 08:21:54.839018 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839222 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 68: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], se 08:21:54.839237 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839443 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 914: 10.0.0.1.80 > 10.0.0.2.56089: Flags [P.], s 08:21:54.839457 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [.], ack 08:21:54.839690 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.0.0.1.80 > 10.0.0.2.56089: Flags [F.], se 08:21:54.845351 00:00:00:00:00:02 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.0.0.2.56089 > 10.0.0.1.80: Flags [F.], se 08:21:54.845440 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.0.0.1.80 > 10.0.0.2.56089: Flags [.], ack

Maka, dapat dituliskan flow diagramnya

Sequence Diagram Http Request Protocol TCP Base flow matching h2 wget -O - h1

participant h2 participant s1 participant h1 participant h3 h2->s1:SYN s1-->h1:SYN h1-->s1:ACK s1->h2:ACK h2->s1:ACK s1-->h1:ACK h2->s1:PUSH s1-->h1:PUSH h1-->s1:ACK s1->h2:ACK h1-->s1:PUSH s1->h2:PUSH h2->s1:ACK s1-->h1:ACK h1-->s1:PUSH s1->h2:PUSH h2->s1:ACK s1-->h1:ACK h1-->s1:PUSH s1->h2:PUSH h2->s1:ACK s1-->h1:ACK h1-->s1:PUSH s1->h2:PUSH h2->s1:ACK s1-->h1:ACK

h1-->s1:PUSH s1->h2:PUSH h2->s1:ACK s1-->h1:ACK h1-->s1:PUSH s1->h2:PUSH h2->s1:ACK s1-->h1:ACK h1-->s1:PUSH s1->h2:PUSH h2->s1:ACK s1-->h1:ACK h1-->s1:FIN s1->h2:FIN h2->s1:FIN s1-->h1:FIN h1-->s1:ACK s1->h2:ACK

Referensi 1. TBA 2. ...

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Mininet - Eksperimen Kontroler Erlangga Ervansyah, TBA

Reference Controller Buat topologi di mininet root@ubuntu:~#mn --topo single,3 --mac --switch ovsk

Melalui perintah diatas, Mininet memproses topologi dengan komposisi sebagai berikut: 1 node controller referensional (c0) 3 buah node host (h1,h2,h3) 1 buah node switch open vswitch (s1) Melihat informasi node di topologi mininet> dump

Dari command dump, didapatkan informasi ip address dan pid number untuk masing-masing node Melihat interaksi antar node di topologi mininet> net

Dari command net, didapat informasi hubungan antar host dan switch. Diperoleh gambaran topology sebagai berikut ("SDN by Ken Gray & Thomas D. Nadeau") :

Tes koneksi antar host mininet> h1 ping -c 3 h2 atau mininet> pingall

Command ping (h1 ping h2) berguna untuk mengecek koneksi antar host, adapun atribut -c untuk menentukan jumlah paket yang akan dikirimkan untuk inisiasi Command pingall untuk generate tes koneksi semua host yang terhubung Melihat informasi paket di wireshark buka terminal baru / remote ke host mininet: root@ubuntu:~#wireshark

Proses wireshark diatas di capture ketika mininet sedang memproses topologi baru

Proses wireshark diatas di capture saat host h1 melakukan icmp ping ke host h2 (controller reference) Berikut skema sequence diagram untuk topologi (Controller Referensional)

POX Controller Aktifkan controller POX root@ubuntu:~# cd /pox root@ubuntu:~/pox# ./pox.py log.level --DEBUG misc.of_tutorial

atau root@ubuntu:~/pox# python ./pox.py forwarding.l2_learning

Perbedaan kedua command diatas : 1. Command pertama (log.level --DEBUG misc.of_tutorial) saat proses controller di terminal dimatikan maka proses controller di mininet juga langsung mati 2. Command kedua (forwarding.l2_learning) saat proses controller di terminal dimatikan, proses controller di mininet tidak langsung mati. Proses masih tetap berjalan namun setelah beberapa detik (sekitar 8 detik) proses controller mati. Buat topologi di mininet root@ubuntu:~# mn --topo single,3 --mac --switch ovsk controller=remote

Controller bisa diberikan ip secara manual dengan menyisipkan beberapa informasi seperti contoh berikut : "- controller=remote,ip=10.0.0.10,port=6633" Melihat informasi paket di wireshark

Proses wireshark diatas di capture saat membuat topologi di mininet

Proses wireshark diatas di capture saat host h1 melakukan icmp ping ke host h2 (controller pox misc.of_tutorial)

Proses wireshark diatas di capture saat host h1 melakukan icmp ping ke host h2 (controller pox forwarding.l2_learning) Sequence diagram untuk topologi controller menggunakan POX

Analisis wireshark di kedua Controller Berdasarkan kedua gambar wireshark diatas, terdapat perbedaan antara Controller referensional dan Controller POX. Wireshark pada controller reference, setiap paket tercantum satu informasi. Sedangkan pada Controller POX, setiap paket diantaranya terdapat lebih dari satu informasi, contohnya paket no. 21 dan 29 Pada proses ping antar dua host, pada controller pox (of_tutorial) tidak terdapat paket FlowMod yang lewat karena program ini dijalankan bertindak sebagai hub Sedangkan untuk controller reference dan pox (l2_learning) ada paket FlowMod yang lewat karena program ini dijalankan agar bertindak sebagai switch Selain proses ini, perlakuan tiap controller masih relatif sama

Referensi 1. TBA 2. ...

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Topik Riset SDN dan Cloud ACR, EM

Summary Automation and Scalability White Box / Function / Container Control and Orchestration Visibility and Analytics Testing / Measurement / Benchmarking

Automation and Scalability DevOps (Development & Operations) Resources Abstraction & Scheduler Tools / Players: Chef, Puppet, Apache Mesos ....

White Box/VM/Container Box/Switches Provision Function Definition Customized Application Tools / Players: MAAS, Juju, Cobbler, Docker

Control and Orchestration Tag/Steer/Map Traffic Start/Stop/Adjust Container Tools / Players: FlowVisor, OpenVirteX, FloodLight, ODL, OpenStack, Andromeda, POX ...

Visibility and Analytics Network Tapping & Visualization Log Management & Analysis Tools / Players: ElasticSearch, Kibana, LogStash, networktap, opengraphiti, ...

Testing / Measurement / Benchmarking Flow Sampling Interoperability Test OpenFlow/SDN Standard Tools / Players: sFlow, NetFlow, OFTest, OF Conformant, PlugFest, Cloud Spectator, Zenoss, ...

Referensi

1. TBA 2. ...

Lisensi CC Attribution-NonCommercial-NoDerivatives (Lisensi)

Cara Kontribusi Seperti tersurat dalam namanya, Buku Komunitas SDN-RG bersifat open-source untuk open-contribution. Untuk yg belum terbiasa dengan git & github, berikut langkah-langkah kontribusi secara garis besar. 1. Masuk ke akun github anda! Kalau belum punya, daftar via https://github.com/join 2. Kunjungi repo buku komunitas di https://github.com/SDN-RG/community-book 3. Fork (seperti ilustrasi di bawah)

4. Perhatikan petunjuk dengan garis merah. Setelah operasi fork selesai, tampilan kurang-lebih seperti berikut.

5. Lakukan Pull Request (PR), apabila anda sudah selesai dan siap untuk integrasi.

kalau anda langsung coba tanpa melakukan apa-apa, hasilnya spt berikut:

kalau sudah ada commit baru:

status dan interface PR di forked-repo:

Editor Walaupun bisa dilakukan manual dengan sembarang text-editor, akan lebih mudah untuk menulis dan melakukan preview melalui editor gitbook. Unduh editor untuk sistem operasi yg sesuai di https://github.com/GitbookIO/editor/releases

Kontroler OpenDaylight Dimas Riswanto

OpenDaylight Project

OpenDaylight Project adalah sebuah proyek open source kolaboratif di Linux Foundation yang bertujuan untuk mempercepat adopsi Software-Defined Networking (SDN) dan menciptakan pondasi yang solid untuk Network Function Virtualization (NFV) dengan pendekatan yang lebih transparan untuk mendorong inovasi baru dan mengurangi risiko. Linux Foundation Collaborative Projects sendiri merupakan proyek perangkat lunak didanai secara independen yang bertujuan untuk memanfaatkan kekuatan pengembangan kolaboratif untuk bahan bakar inovasi di industri dan ekosistem. OpenDaylight Project didirikan oleh para pemimpin industri jaringan pada 8 April 2013 dan terbuka untuk semua pihak. Komunitas OpenDaylight mengembangkan kerangka SDN yang umum dan terbuka, terdiri dari berbagai kode dan cetak biru. OpenDaylight didukung oleh banyak vendor jaringan ternama di dunia, diantaranya Microsoft, IBM, Cisco, Huawei, Ericsson, dan lain-lain. Vendor-vendor yang berkontribusi pada OpenDaylight Project terbagi atas Platinum, Gold, dan Silver Members bergantung pada besar kontribusinya. Beberapa proyek yang termasuk pada OpenDaylight Project yaitu OpenDaylight Controller, OpenDaylight Virtual Tenant Network (VTN), Open DOVE, OSCP Project, YANG Tools, LISP Flow Mapping, OVSDB (Open vSwitch Database), dan dlux (openDayLight User eXperience) [5].

OpenDaylight Controller OpenDaylight Controller adalah sebuah proyek open source dengan Controller platform yang modular, pluggable, dan fleksibel. Kontroler ini diimplementasikan pada perangkat lunak dan ditampung dalam Java Virtual Machine (JVM)-nya sendiri. Dengan demikian, OpenDaylight dapat digunakan pada perangkat keras dan platform sistem operasi apapun yang mendukung Java. OpenDaylight mengekspos open northbound API yang digunakan oleh aplikasi. OpenDaylight mendukung kerangka OSGi dan bidirectional REST untuk northbound API. Kerangka OSGi digunakan untuk aplikasi yang akan berjalan di address space yang sama dengan kontroler sementara REST (web based) API digunakan untuk aplikasi yang tidak berjalan di address space yang sama (atau bahkan tidak pada mesin yang sama) dengan kontroler. Algoritma dan logika bisnis berada pada aplikasi. Aplikasi ini menggunakan kontroler untuk mengumpulkan data jaringan, menjalankan algoritma analisis, dan kemudian menggunakan kontroler untuk menerapkan aturan baru, jika ada, ke seluruh jaringan. Southbound interface mampu mendukung beberapa protokol (sebagai plugin terpisah), misalnya OpenFlow 1.0, OpenFlow 1.3, BGP-LS, dll Modul ini terhubung secara dinamis ke dalam Service Abstraction Layer (SAL). SAL mengekspos layanan perangkat dengan modul sisi “utara”. SAL juga menentukan bagaimana memenuhi permintaan layanan terlepas dari protokol yang dipakai antara kontroler dengan perangkat jaringan [6]. OpenDaylight Controller dinamai berdasarkan nama-nama elemen pada tabel periodik. Versi pertama dari OpenDaylight yaitu Hydrogen dirilis 10 bulan setelah OpenDaylight Project didirikan. Sekarang, versi kedua yang diberi nama Helium telah beredar dengan menawarkan perbaikan-perbaikan berupa [7]: 1. Peningkatan clustering dan high-availability support untuk kontroler inti. 2. Akuntansi, otorisasi dan autentikasi untuk peningkatan keamanan.

3. Antarmuka pengguna yang baru, yaitu dlux (the openDayLight User eXperience), yang dapat berjalan terpisah dari perangkat lunak OpenDaylight selama ada koneksi IP. 4. Dukungan untuk Apache Karaf container, sehingga memungkinkan operator jaringan untuk menyesuaikan instalasi, hanya menggunakan fitur yang mereka perlukan. 5. Integrasi lebih dalam dengan OpenStack, termasuk perbaikan yang signifikan terhadap proyek Open vSwitch Database (OVSDB), dan pratinjau teknologi fitur OpenStack seperti Security Group, Distributed Virtual Router dan Load Balancing-as-a-Service.

Referensi Open Daylight Project OpenDaylight User Guide. OpenDaylight Project, San Fransisco, CA, 2014 OpenDaylight COntroller: Helium Release Plan

SDN integration in LTE mobile backhaul network Siti Amatullah Karimah Abstrak Tantangan utama pada jaringan mobile masa depan ialah bagaimana meningkatkan throughput dalam mendukung meningkatnya trafik jaringan. Software Defined Network merupakan teknologi baru yang diharapkan dapat mengatasi permasalah tersebut, namun sejauh ini SDN hanya di integrasikan pada arsitektur jaringan 4G, tanpa adanya perubahan mendasar. Dalam paper ini dijabarkan mengenai jaringan mobile 4G dimana pendekatan Software Defined Network dapat digunakan untuk mendesain ulang arsitektur saat ini. Dalam paper ini dibahas didalamnya jalur migrasi yang dapat digunakan untuk menjamin terjadinya fase transisi tersebut. Tujuannya bukanlah untuk jangka pendek namun untuk memenuhi kebutuhan throughput masa depan dengan membenahi jaringan transport pada mobile backhaul dan memindahkan sebagian besar elemen jaringan LTE saat ini ke cloud. Pendekatan ini akan menghilangkan adanya core network yang dikenal saat ini dan menggantikannya dengan menyederhanakan jaringan akses yang dibentuk oleh base station (eNodeB) yang saling terhubung melelui jaringan backhaul yang dikendalikan oleh SDN switch yang berada di cloud yang bekerja bersama dengan elemen jaringan LTE lainnya. I. Introduction Diperkirakan bahwa pada tahun 2017 jumlah perangkat mobile akan melebihi jumlah keseluruhan penduduk dunia. Dan juga diperkirakan bahwa layanan video akan meningkat signifikan yang berimbas pada permintaan peningkat kapasitas jaringan LTE dengan ukuran yang lebih kecil. Ukuran kecil dari sel LTE ini akan berimbas pada banyaknya jumlah base station yang dibutuhkan sehingga membutuhkan jaringan bakhaul dengan konektivitas yang lebih tinggi. Peningkatan jumlah base station ini berdampak pada kebutuhan akan penyederhanaan jaringan akses. Salah satu solusi penyederhanaan jaringan akses ini ialah menggunakan teknologi SDN. Integrasi dengan teknologi SDN diharapkan dapat meningkatan fleksibilitas yang diperlukan dan manajemen resource yang optimal untuk mengakomodasi kebutuhan jaringan mobile dimasa depan. SDN yang di implementasikan di jaringan mobile dinamakan Software Defined Mobile Network (SDMN). Proyek yang sama sebenarnya pernah dilakukan dalam hal pengintegrasian jaringan LTE dan SDN dengan mempertahankan arsitektur LTE yang ada. Yang membedakannya dengan paper ini ialah, paper ini menjabarkan perubahan arsitektur jaringan LTE yang terintegrasi dengan jaringan SDN dengan proses migrasi yang lancar. II. LTE Mobile Networks and SDN Overview Jaringan mobile terdiri dari layer fisik dan juga logic. Layer fisik dibentuk oleh switch jaringan (L2), router (L3)dan juga link fisik dengan topologi dan teknologi yang berbeda-beda seperti pada gambar 1.

Logical Layer Terdiri dari elemen jaringan (eNodeB, MME, S/P-GW, HSS, dll) yang menjalankan fungsi : o Attachment o Mobility o Transport Data o Implementasi Control Plane Physical layer Menyediakan fungsi konektivitas dan transportasi yang dibutuhkan pada logical layer.

Access Network Terdiri dari sebagian besar eNodeB yang menyediakan radio access kepada UE. Backhaul Terdiri dari seluruh switch jaringan yang berfungsi mengagregasi trafik dari access network dan juga menyedikan konektivitas dengan core network. Network element Mengimplementasikan seluruh koneksi mobility dan juga fungsi billing yang berlokasi di core network. Mobility merupakan critical function pada jaringan mobile. Teknologi baru apapun harus dapat memastikan reabilitas dan low latency yang pantas pada proses handover. Mobility di jaringan LTE dilakukan menggunakan metode yang berbedabeda bergantung pada apakah target eNodeB baru berada pada Tracking Area ID (TAI) yang berbeda atau tidak. TAI akan berasosiasi dengan Mobility Management Entitiy (MME) yang sama. Pada umumnya fungsi mobility dilakukan menggunakan interface S1-MME yang telah didefinisikan antara eNodeB dan MME. Pada skenario yang dibahas pada paper ini, fungsi mobility dilakukan menggunakan interface X2 yang didefinisikan antar eNodeB. Gambar 2 akan mendeskripsikan control functionality yang akan mengatur proses handover berdasarkan interface S1-MME antar logical element (eNodeB, MME dan S/P-GW) dimana perubahan pada MME dibutuhkan.

Masalah mendasar pada protocol IP dari sudut pandang mobility adalah bahwa alamat IP mengidentifikasi node dan akan menyesuaikan IP yang dimiliki berdasarkan IP subnet ia berada. Solusi yang ditawarkan untuk mengatasi hal ini ialah disedikannya tunneling pada alamat IP user didalam GTP tunnel yang dibangun antara eNodeB dan S/P-GW. GTP tunnel akan memberikan identitas unik setiap traffic flow yang mendapatkan penanganan QoS yangberbeda-beda antara UE dan PDN GW. Traffic Flow Template (TFT) digunakan untuk melakukan mapping atau pemetaan trafik ke EPS bearer yang sesuai. GTP Tunneling Endpoint Identifier (TEID) secara jelas akan mengidentifikasi tunnel endpoint termasuk didalamnya tiap paket data user ,memisahkan trafik berdasarkan user dan juga memisahkan bearer dari user seperti yang terlihat pada Gambar 3.

Kapanpun UE berpindah ke eNodeB baru, GTP tunnel harus dibangun ulang antara eNodeB baru dengan S/P-GW dimana inner data flow akan tetap menjaga alamat IP user asli (tidak perlu mengubah-ubah alamat IP). Proses handover di inisiasi dan di atur melalui interface S1 seperti pada Gambar 4. MME akan tanggap terhadap proses mobility dan akan berkomunikasi dengan S/P-GW untuk membangun ulang GTP tunnel antara eNodeB baru dan S/P-GW.

A. SDN Overview Telah dipahami bersama bahwa jaringan pada masa depan akan memerlukan kepekaan yang tinggi terhadap layanan-layanan yang muncul dan juga kepekaan terhadap optimasi penggunaan resource jaringan. Semua hal ini dapat dicapai dengan bantuan teknologi Software Defined Network (SDN). SDN diperkirakan akan menjadi key enabler pada pengembangan infrastruktur jaringan telekomunikasi dalam menghadapi perkembangan jaringan mobile masa depan yang mendasari lahirnya Software Defined Mobile Network (SDMN). SDMN pada dasarnya merupakan pendekatan networking/jaringan dimana control plane akan dipisahkan dari hardware jaringan telekomunikasi secara spesifik untuk kemudian diberikan kepada software application yang bernama controller. Fitur yang ada pada SDMN akan menyederhanakan kerja router maupun switch dengan cara memindahkan CP ke server tersentralisasi yang bekerja sebagai controller. Controller memiliki seluruh kontrol jaringan dimana ia dapat mereduksi kongesti dengan menambahkan fungsi traffic management dan optimized resource allocation yang akan mengalokasi resource secara optimal. Gambar 5 memperlihatkan interkasi antara controller dan switch-**switch pada jaringan berbasis SDN. Interkasi ini berdasarkan API yang telah terdefinisikan dengan baik seperti OpenFlow. SDN membuat perangkat jaringan seperti switch dan router bersifat “programmable” atau dapat di program dengan fungsionalitas tertentu. Oleh karenanya SDN diharapkan dapat meningkatkan data throughput akibat dari penyederhanaan kerja switch. Pendekatan yang dilakukan pada paper ini ialah untuk mempersingkat kerja dari perangkat jaringan agar perangkat-perangkattersebut dapat lebih fokus dalam manajemen forwarding data (fungsi-fungsi yang biasa dijalankan oleh router diambil alih oleh adanya controller).

Teknologi SDN akan memungkinkan beberapa kemungkinan skenario sebagai berikut : Pemisahan individual traffic flow untuk membagi resource yang tersedia dalam mendukung berbagai macam Mobile Virtual network Operator (MVNO). Mengoptimalkan proses re-direction flow kepada layanan/aplikasi yang spesifik. Mengefisienkan manajemen dan penggunaan resource. Walaupun begitu, SDMN diperkirakan akan memiliki permasalah dalam efisiensi mobility management dan juga skalabilitas dalam menangani ratusan ribu flow user pada tiap radio access network (eNodeB). Sejauh ini dapat diambil kesimpulan bahwa SDMN memilik fungsionalitas tambahan dibanding SDN yang diperuntukkan untuk fixed network dimana SDMN akan mengakomodasi kebutuhan tambahan jaringan mobile sepeti halnya mobility management, efisiensi proteksi terhadap air interface dan perangkat mobile dari trafik yang tidak diinginkan, dan juga penggunaan tunneling pada proses transportasi paket secara berkala. III. Software Defined Networks Integration in LTE Integrasi SDN menjadi SDMN membutuhkan beberapa desain arsitektur sebagai berikut : • Lokasi SDMN controller • MME : Tanggap terhadap mobility • S/P-GW : mengkontrol jaringan transport • Distribusi controller • single controller • many controller Kedua model distribusi controller diatas akan diletakkan dekat dengan access network namun memiliki hierarki topologi tersendiri antar controller di access network namun akan tetap tersentralisasi di core network. Integrasi antara SDN dan elemen jaringan LTE baik sebagai bagian dari MME mapun S/P-GW harus dapat mengakomodir efisiensi pada proses handover. Tujuannya ialah untuk menjaga basis alamat IP UE dan penggunaan SDMN untuk meningkatkan fleksibilitas arsitektur jaringan LTE. Gambar 6 memperlihatkan arsitektur LTE saat ini dimana terdapat beberapa opsi pengintegrasiannya dengan SDN controller.

Gambar 7 mendeskripsikan salah satu opsi pengintegrasian SDN ke arsitektur LTE. Opsi ini terdisi dari pemisahan (decoupling) S/P-GW menjadi logical dan data plane. Bagian logical pada S/P-GW (S/P-GWc) menyediakan alokasi alamat IP kepada UE dan menjalankan TFT kepada data flow user. Bagian data plane dari S/P-GW (S/P-GWu) menyediakan terminasi GTP tunnel dan menahan (anchoring) GTP tunnel selama proses handover. Hal ini dibiarkan berlangsung sementara seluruh elemen jaringan dijaga agar tidak terpengaruh terhadap proses handover tersebut dan MME tetap dapat berinteraksi dengan S/P-GWc.

Gambar 8 menunjukkan integrasi SDN dan arsitektur LTE opsi kedua, dimana opsi ini akan mengizinkan SDN controller menerima mobility event langsung dari MME agar dapat langsung menerapkan rule baru pada node switching untuk dapat mengoptimasi routing path/jalur perutean.

IV. Migration Path of SDN Integration in LTE Integrasi fungsionalitas SDN controller dan MME menyediakan integrasi yang mulus dalam jangka panjang namun menjadi solusi buruk bagi jaringan mobile SDN saat ini karena keharusannya menambahkan kebutuhan-kebutuhan spesifik jaringan

mobile dimana data plane harus dioptimasi untuk kecepatan tinggi dan pemrosesan yang dilakukan pada flow-level (menggunakan OpenFlow). Pada SDMN, control plane dipisahkan dari elemen dasar jaringan ke server yang tersentralisasi. Maka, pada proses migrasi ini, tujuannya ialah memindahkan controller dan fungsionalitas S/P-GW kedalam elemen jaringan yang sama dengan MME. Oleh karenanya, fungsionalitas S/P-GW menjadi terhapuskan dan digantikan oleh SDN berbasis jaringan packet switched. Penambahan ini akan menambahkan fleksibilitas jaringan dalam menerima trafik dengan throughput yang besar, mengoptimalkan manajemen jaringan dan memungkinkan dilakukannya traffic engineering. Gambar 9 memperlihatkan integrasi mobility dengan SDN controller yang dimasukan ke dalam bagian dari elemen jaringan MME.

Mobility merupakan critical aspect dari jaringan mobile yang membutuhkan fungsionalitas tersendiri secara spesifik pada elemen jaringan. Hubungan yang erat antara SDN controller dan MME, dalam fungsi waktu akan mengefisienkan penangan proses mobility yang dilakukan oleh SDN controller. Integrasi ini menyediakan meanajemen handover yang efisien pada SDMN. OpenFlow controller akan menambahkan dan mengurangi flow dari flow table sesegera mungkin ketika handover terjadi untuk kemudian dilaporkan ke MME. Masukan pada *flow table diantarany Packet Header yang berfungsi mendefinisikan flow, action untuk mendefinsikan pemrosesan paket dan juga statistiknya. Disamping integrasi MME dan SDN controller paper ini pun menggambarkan penggunaan teknologi 802.1ad untuk melakukan proses double tagging pada switch* Ethernet seperti pada Gambar 10.

Double tagging ini akan mengizinkan penggunan lebih dari 2^12 service tag sebagai outer tunnel dan 2^12 customer tag sebagai inner tunnel. (total 2096 inner dan outer tunnel). Outer VLAN ini dapat digunakan untuk membangun tunnel antar eNodeB dan router IP yang berlokasi pada segmen Ethernet yang sama menyediakan akses ke internet publik. Outer VLAN yang dibangun dari eNodeB dapat dimasukkan ke dalam Mobile Virtual Network Operator (MVNO) yang berbeda pada area dengan 400 eNodeB.

Integrasi fungsionalitas controller dengan MME dan S/P-GW kedalam satu elemen jaringan yang sama akan menyederhanakan fungsionalitas jaringan. Hal ini akan menyebabkan gangguan selanjutnya dimana data plane diatur dari satu elemen MME/Controller. Evolusi menuju arsiterktur ini dapat dilakukan dimana MME akan menjaga interfacenya dalam menerima signaling dari interface S1-MME. MME akan menangani proses standar (yang biasa dilakukannya) dan membangun GTP tunnel antara eNodeB lama dan S/P-GW. Secara bersamaan MME akan memiliki fungsionalitas SDN yang akan membangun komunikasi antara model baru eNodeB dan IP router secara langsung pada layer 2 tanpa adanya GTP tunneling. Pada skenario yang dipaparkan, pada MME yang sama, ketika menerima signaling dari eNodeB berbasis SDN melalui interface S1-MME akan membangun koneksi dengan switch SDN yang diterminasi melalui L2 menggunakan interface TUN. Networking stack yang digunakan pada data plane diperlihatkan pada Gambar 12. Radio layer di terminasi pada eNodeB dimana GTP digunakan mengikuti S-GW dan P-GW yang menyediakan jembatan kepada internet publik.

Penggunaan 802.1ad pada backhaul dan integrasi antara MME dan SDN controller mengizinkan penghapusan GTP tunnel. Hal ini akan menghasilkan penyederhanaan stack pada eNodeB yang menterminasi radio layer melalui keseluruhan jaringan pada backhaul seperti yang digambarkan pada Gambar 13. Maka dari itu, S/P-GW disederhanakan setelah menghilangkan GTP dan terdiri dari Ethernet switch sederhana dan IP router yang menuju internet publik. Pada arsitektur ini mobility dilakukan oleh SDN controller.

Arsitektur ini mengantarkan pada optimasi pada jaringan transport dan juga menjadikan control plane memiliki skalabilitas yang akan mengkonvergensikan kedalam satu elemen jaringan MME dengan fungsionalitas SDN controller yang tertanam didalamnya. MME pada akan menjaga networking stack mereka seperti yang terlihat pada gambar 14. Perubahan pada data plane terjadi bersamaan dengan penjagaan proses signaling pada MME untuk mendukung eNodeB lama agar dapat melakukan transisi yang baik dan lancar. MME akan dapat mengatur elemen jaringan yang dimilikinya seperti eNodeB dan S/P-GW namun integrasi dengan SDN akan menjadikan fungsi GTP dihilangkan.

Elemen-elemen pada jaringan mobile LTE pada umumnya berlokasi pada core network, dimana pengintegrasian SDN dengan topologi seperti ini membuat jaringan tidak memilki skalabilitas. Maka dari itu, pada arsitektur yang ditawarkan oleh paper ini ialah membuat agar elemen-elemen jaringan dapat berlokasi sedekat mungkin dengan eNodeB di backhaul. Hal ini membuat access network bersifat standalone dimana koordinasi terhadap beberapa acces network akan dilakukan menggunakan database yang tersentralisasi dan handover antar MME yang berada pada tiap access network tetap dilakukan menggunakan interface S1. Signaling networking stack yang dikenal akan tetap sama dalam berinteraksi dengan elemen jaringan LTE yang lama seperti S/P-GW dan juga MME yang ada pada jaringan serti yang terlihat pada Gambar 15.

Dalam hal penyederhanaan arsitektur jaringan LTE yang terintegrasi dengan SDN, maka permasalahan skalabilitas haruslah dipecahkan. Solusi yang dipaparkan adalah dengan memindahkan elemen jaringan LTE pada arsitektur baru dimana MME akan digabungkan dengan SDN controller pad access network seperti yang terlihat pada Gambar 16.

Arsitektur ini mengizinkan penggunaan 802.1ad untuk tiap access network dalam menyediakan penyederhanaan arsitektur LTE dimana beberapa pecahan-pecahan fungsi jaringan akan diserahkan kepada virtual operator menggunakan VLAN. V. Conclusions

Paper ini memaparkan integrasi antara teknologi LTE dengan SDN dengan membuat penggabungan fungsionalitas antara MME dengan SDN controller. Hal ini mengenalkan arsitektur baru dimana jaringan transport akan disederhanakan dan akan berbasis switch. Control plane pun akan disederhanakan dengan melakukan penggabungan elemen jaringan LTE seperti MME, S/P-GW yang digabungkan ke dalam satu komponen jaringan. Selain itu, elemen jaringan LTE baru ini, dimana terdapat fungsi SDN controller didalamnya dapat di virtualisasikan dan beberapa instance nya dapat di diambil oleh data center untuk melakukan penyederhanaan pada data plane. Pengimplementasian sistem ini telah diuji cobakan dimana source code yang digunakan akan tersedia untuk pengembangan selanjutnya. Hasil dari uji coba menunjukkan kecocokan pengintegrasian elemen jaringan LTE dengan SDN controller yang dijalankan diatas cloud dapat meningkatkan throughput setelah mengurangi adanya overhead dan mencegah terjadinya fragmentasi ketika GTP-U dihilangkan dari user plane antara eNodeB dan S/P-GW.

REFERENSI Costa-Requena, J. , SDN integration in LTE mobile backhaul network, IEEE International Conference Information Networking (ICOIN), Phuket 2014

D-SDN : Decentralizing SDN’s Control Plane Dwina Fitriyandini Siswanto (23213311) EL5244 Pemrograman Perangkat Jaringan Decentralize-SDN (D-SDN) adalah suatu kerangka kerja yang memungkinkan distribusi control plane pada SDN, baik secara fisik maupun logis, dengan mendefinisikan hirarki kontrol dari main controller (MC) dan secondary controller (SC). Konsep dari kerangka kerja ini lahir karena konsep SDN saat ini, termasuk Open-Flow, lebih cocok untuk “managed networks”. SDN mengusung konsep kontrol tunggal dan tersentralisasi yang dinilai tidak cocok untuk internet heterogen yang terdiri dari beragam autonomously administered network, seperti contohnya jaringan yang infrastructure-less dan selforganizing.

D-SDN Perbedaan utama antara main controller (MC) dan secondary controller (SC) adalah dalam hal hirarki. Sebelum SC dapat bertindak sebagai SDN controller, MC harus melakukan autorisasi dan delegasi terhadap SC. Sehingga SC diberi tanggung jawab untuk melakukan kontrol terhadap switch SDN yang berada dalam sub-domain dari domain MC. Sebagai gambaran dapat dilihat pada ilustrasi berikut ini,

Dalam konsep D-SDN, dengan menggunakan control plane terdesentralisasi, GW1 dan GW2 dapat berperan sebagai SC setelah dilakukan autorisasi dan delegasi oleh Main Controller yang berperan sebagai MC. Sehingga flow yang tiba di node dalam client network α dan β tidak perlu melalui MC dan dapat ditangani secara langsung oleh SC. Proses delegasi kontrol oleh MC terhadap SC dilakukan dengan Control Delegation message yang terdiri dari Check-in Request dan Check-in Response. Pada Check-in Request, SC mengirimkan request kepada MC agar dapat diautorisasi untuk berperan sebagai controller, kemudian MC merespon dengan mengirimkan Check-in Response kepada SC yang berisi apakah request diterima sehingga autorisasi dan delegasi dapat dilakukan atau request ditolak.

Implementasi Proses implementasi dilakukan dalam suatu testbed dimana node yang digunakan merupakan SDN-enabled mobile nodes. Implementasi meliputi server-side dan client-side. Keamanan yang digunakan adalah Identity Based Criptography (IBC) yang memerlukan Trusted Third Party (TTP) untuk membangkitkan private key. Dalam hal ini MC dapat berperan sebagai TTP. Tabel 1 berikut adalah deskripsi protokol-protokol dari komponen D-SDN yang digunakan untuk melakukan komunikasi.

Setup Secara public key diturunkan dari identitas, TTP melakukan pemetaan node identity, IDx, ke sebuah titik pada kurva elips, Px. TTP membangkitkan suatu master secret key, s, dan mengkalkulasi private key dari tiap-tiap node agar memenuhi Sx=sPx. Authenticated Key Agrrement Prosedur Authenticated Key Agreement, AKA, memiliki tujuan utama untuk menghindari public key encryption. Hal ini berarti, jika dua node sepakat menggunakan suatu kunci melalui public key cryptography maka kedua node tersebut dapat menggunakan shared key untuk kerahasiaan dan autentifikasi data. Handshaking Dalam prosedur handshaking, setelah requesting node (RN) mengirimkan sebuah request ke authenticator, RN harus merespon challenge yang dikirmkan oleh authenticator agar identitas perangkat dapat diverifikasi. Proses ini memungkinkan RN dan authenticator untuk mengkomputasi shared key. Availability Framework dapat diunduh di sini

Evaluasi Evaluasi dilakukan dengan menggunakan 2 use case, yaitu Secure Capacity Sharing dan Public Safety Networks. Secure Capacity Sharing adalah skenario dimana node pada infrastructure-less network mencoba terhubung ke internet melalui node yang lain. Public Safety Networks adalah skenario dilakukannya desentralisasi kontrol pada layanan tanggap darurat.

Secure Capacity Sharing Merujuk pada Gambar 1 sebuah node di client network, sebut saja requesting node (RN), ingin terkoneksi ke internet dan mengakses World Wide Web. Namun karena berada di luar jangkauan AP terdekat maka RN tidak dapat terhubung ke infrastruktur jaringan yang ada. Sebuah node yang lain, gateway node 1 (GW1) menawarkan gateway service kepada RN agar dapat terkoneksi ke internet melaluinya. Langkah-langkah Secure Network Capacity Sharing dapat dilihat pada Gambar 2 dibawah ini.

Gateway discovery GW mengirimkan pesan periodik yang berisi info mengenai kapabilitas gateway. Kemudian user memilih kandidat GW yang paling sesuai, dan mengirimkan request ke GW tersebut. Handshaking GW merespon request dari user kemudian mulai menginisiasi prosedur handshaking untuk melakukan autentifikasi node. User check-in GW mengirimkan request ke main controller agar dapat diautentifikasi sebagai secondary controller. Apabila user mendapatkan GW yang lebih sesuai maka user tersebut dapat mengirimkan request ke GW tersebut dan melakukan prosedur handshaking. Kemudian MC dapat melakukan flow creation di GW baru dan flow removal di GW lama. Peristiwa ini dinamakan secure handover. Kemulusan dalam handover menjadi tujuan dan parameter keberhasilan dalam Secure Network Capacity Sharing, selain peningkatan performa diantara gateway.

Public Safety Networks Public Safety Networks (PSN) diciptakan untuk mendeteksi dan/atau menangani bencana. Dengan melakukan desentralisasi control plane, Public Safety Network yang mengakomodasi D-SDN menghasilkan fleksibilitas, interoperabilitas, reliabilitas dan deployment yang cepat dalam keadaan krisis. Skenario PSN dapat dilihat pada gambar 3 dibawah ini dimana mobil merupakan GW yang dapat berperan sebagai SC terhadap agen aktor yang berbeda-beda, contohnya seperti pemadam kebakaran, polisi dan lain-lain.

Berikut ini adalah skenario untuk menangani kejadian link failure dengan cara mengimplementasikan toleransi pada failure. Pada skenario ini SCi merupakan controller yang aktif dan SCj akan mengambil alih peran SCi ketika SCi mengalami failure. 1. Beberapa SC yang ada mengirimkan pesan Hello kepada perangkat-perangkat yang ada. 2. SCi mengalami failure. 3. Protokol election diantara SC dibangkitkan, untuk memilih SC yang dapat mengambil alih peran SCi. 4. SC yang terpilih, SCj, mengirimkan request administrasi ke perangkat-perangkat dan mengambil alih peran sebagai controller. 5. Perangkat-perangkat melakukan konfirmasi dengan mengirimkan pesan Role Reply bahwa peran controller telah diserahkan ke SCj. Dari hasil eksperimen yang dilakukan, waktu minimum yang dibutuhkan untuk melakukan pemulihan dari suatu failure adalah 2,3 detik.

Kesimpulan D-SDN adalah sebuah kerangka kerja yang mendukung distribusi kontrol dengan mendefinisikan hirarki controller dimana main controller dapat mendelegasikan fungsi controller kepada secondary controller. Diharapkan dengan fungsi desentralisasi SDN control plane, D-SDN dapat mengakomodasi kebutuhan berbagai macam layanan dan aplikasi jaringan baik jaringan eksisting ataupun jaringan di masa depan.

Referensi M.A.S. Santos et al., ''Decentralizing SDN’s Control Plane,'' in IEEE 39th Conference on Local Computer Networks, Edmonton, AB, 2014, pp. 402-405.

A Security Enforcement Kernel for OpenFlow Networks Bagus Aditya

SDN Security Challenge

SDN memberikan fasilitas pada layer kontrol dengan menyediakan programmable network untuk membuat suatu flow policy sesuai kemauan. Tantangan keamanan di suatu programmable network yang paling utama adalah mendeteksi, efisiensi, dan rekonsiliasi konflik dari flow rules yang diakibatkan oleh suatu Dynamic Open Flow (OF) Application. FortNOX adalah suatu software yang dikembangkan untuk menyediakan role-based authorization dan mengatasi kendala keamanan pada NOX controller . FortNOX memungkinkan kontroler NOX untuk bisa mengetahui adanya kontradiksi pada flow rule secara real time, dan mengimplementasikan algoritma baru yang lebih baik. Aturan keamanan jaringan pada switch OF adalah suatu fungsi bagaimana suatu aplikasi OF yang ada akan bereaksi terhadap stream yang datang dari flow request. FortNOX Enforcement Kernel merupakan suatu kernel enforcement policy (disebut FortNOX) adalah sebuah extension dari kontroler OpenFlow NOX. FortNOX menggabungkan sebuah live rule conflict detection engine, yang akan memediasi semua request dari Flow Rule insertion. Sebuah rule conflict dikatakan ada pada saat rule candidate akan mengaktifkan atau menonaktifkan network flow setelah diperbolehkan oleh existing rule. Analisis rule conflict dilakukan menggunakan sebuah algoritma baru, dimana kita sebut alias set rule reduction. Ketika konflik terdeteksi, FortNOX dimungkinkan untuk memilih untuk menerima atau menolak rule baru, tergantung pada rule insertion requester yang beroperasi pada otorisasi keamanan yang lebih tinggi dari pemilik dari conflicting rule yang telah ada. FortNOX mengimplementasikan role-based authentication untuk menentukan otorisasi keamanan dari setiap aplikasi OF dan memaksa menggunakan prinsip dari least privilege untuk memastikan integritas dari proses mediasi.

Misal, suatu skenario sederhana , yang kita sebut dynamic flow tunneling, pada gambar 1 di atas yang terdiri dari 3 host, satu OF switch dan satu OF controller. Sebuah firewall (hal ini bertindak sebagai suatu contoh aplikasi OF Security) memiliki rule untuk memblok paket dari luar host 10.0.0.2 ke web service (port 80) yang berjalan di host 10.0.0.4. Sekarang misalkan bahwa juga terdapat beberapa aplikasi OF lainnya menambahkan menambahkan tiga buah flow rule baru ke OF controller yang disambungkan oleh petunjuk GOTO TABLE. Rule pertama memodifikasi IP address sumber dari suatu paket ke 10.0.0.1, jika paket dikirimkan dari 10.0.0.2 ke 10.0.0.3 (port80). Final rule secara otomatis memperbolehkan forwarding paket dari 10.0.0.1 ke 10.0.0.4 pada port 80. Di kasus ini, jika host 10.0.0.2 mengirimkan paket ke port 80 pada host 10.0.0.3, paket ini dapat membypass firewall karena ini tidak secara langsung ke host 10.0.0.4 namun ke 10.0.0.3. Namun,paket ini pada akhirnya akan dikirim ke host 10.0.0.4 oleh OF Controller walaupun ada firewall yang melarang trafik ini.

Hal ini dengan jelas telah menunjukkan bahwa firewall yang ada bisa dihindari secara sederhana dengan menambahkan beberapa OF flow rule. Ilustrasi di atas adalah hal sederhana, tantangan sebenarnya adalah memastikan bahwa semua aplikasi OF tidak melanggar security policies di jaringan nyata yang besar dengan banyak OF switch, aplikasi OF yang berbeda-beda, dan security policies yang kompleks. Melakukan pekerjaan semacam ini jika dikerjakan secara manual jelas kesalahan yang rawan dan berbahaya. FortNOX mengembangkan kemampuan dari NOX OpenFlow Controller dengan menyediakan non-bypassable policybased flow rule enforcement terhadap flow rule insertion request dari aplikasi OpenFlow. Tujuan utamanya adalah untuk meningkatkan kemampuan NOX untuk menerapkan batasan network flow (flow rule) yang dihasilkan oleh aplikasi security OF untuk memprogram ulang switch dalam menanggapi suatu ancaman yang dirasakan. Sekali flow rule di insert ke FortNOX oleh aplikasi security, tak satupun aplikasi OF lain, yang dapat menginsert flow rules ke jaringan OF yang bertentangan dengan rule tersebut. FortNOX mengatasi rule conflict dengan melihat peran otorisasi menggunakan flow rule yang telah digitally signed, dimana boleh tidaknya aplikasi yang meminta insert flow rule nya berdasarkan pada penetapan privilege untuk flow rule baru.

Implementasi FortNOX

Gambar di atas mengilustrasikan komponen yang membentuk FortNOX extension ke NOX. Di tengah NOX layer, terdapat sebuah interface yang disebut send_openflow_command(), yang bertanggungjawab untuk menyampaikan flow rule dari aplikasi OF ke switch. Sebuah role based source authentication modul menyediakan validasi digital signature untuk tiap flow rule insertion request, dan menetapkan prioritas yang sesuai pada flow rule baru atau memberikan prioritas terendah jika tidak ada signature yang tersedia. Conflict analyzer bertanggungjawab untuk mengevaluasi tiap flow rule baru terhadap flow rule yang lama sesuai aggregate flow table. Jika conflict analyzer telah memutuskan bahwa calon flow rule yang baru konsisten dengan flow rule yang telah ada, maka akan diteruskan ke switch dan disimpan di aggregate flow table, yang dikelola oleh state table manager. FortNOX menambahkan flow rule timeout callback interface ke NOX, yang akan mengupdate aggregate flow table saat switch melihat ada rule yang kadaluwarsa. Terdapat interface tambahan yang dapat memungkinkan FortNOX menyediakan enforced flow rule mediation. Yang

pertama adalah IPC Proxy, yang memungkinkan sebuah legacy native C OF application dipakai dalam proses yang terpisah, dan secara ideal dioperasikan dari non-privileged account yang terpisah. Interface proxy menambahkan sebuah ekstensi digital signature yang memungkinkan aplikasi ini untuk masuk dan meminta rule insertion, yang kemudian memungkinkan FortNOX untuk menentukan pemisahan rule berdasarkan signature. Melalui proses pemisahan ini, kita dapat menerapkan prinsip least privilege pada operasi infrastruktur kontrol. Melalui mekanisme proksi, aplikasi OF dimungkinkan untuk meminta flow rule insertion baru, namun permintaan ini dimediasi secara terpisah dan independen oleh conflict resolution service yang dioperasikan dalam kontroler. Role-based Source Authentication

FortNOX mengenali 3 peran otorisasi yang membuat flow rule insertion request. Peran pertama adalah seorang administrator, dimana rule yang di insert akan mendapatkan prioritas tertinggi pada skema resolusi conflict di FortNOX. Kedua, adalah aplikasi security OF, yang dimungkinkan membuat suatu flow rule yang akan menentang security policy di jaringan yang telah dibuat oleh administrator berdasarkan ancaman terbaru yang diterima, misal suatu flow yang mencurigakan. Flow insertion dari aplikasi security ini akan berada di bawah prioritas rule yang dibuat oleh administrator. Dan yang ketiga adalah aplikasi OF yang tak berkaitan dengan security berada pada prioritas terakhir. Alias set rule reduction

Untuk mendeteksi suatu konflik antara rule yang baru dengan rule yang sudah ada pada OpenFlow, source & destination IP Adrress, port dan wildcard perlu dikonversi semuanya termasuk rule candidate juga yang dijadikan suatu representasi yang disebut Alias Reduced Rules (ARRs) dan kemudian baru dianalisis konfliknya. Saat initial alias set dibuat, ARR tersebut memuat IP address rule pertama, network mask, dan port. Jika action dari rule menyebabkan field substitution via sebuah set action, maka hasilnya ditambahkan ke set alias, yang kemudian digunakan untuk mengganti kriteria dari ARR. Kemudian barulah bisa dilakukan analisis berpasangan antara calon ARR terhadap ARR yang ada. Jika ada intersection antara source dan address set, maka digunakanlah gabungan antara masing-masing set tersebut sebagai rule alias set selanjutnya. Contoh : diberikan suatu OF security rule (equation 1) a --> b drop packet, maka rule turunannya adalah (equation 2) (a) --> (b) drop packet (source alias diubah ke (a) dan destination alias menjadi (b) ). Untuk calon rule set adalah : (equation 3) 1. a --> c set (a --> a') 2. a'--> c set (c --> b) 3. a'--> b forward packet maka intermediate alias set nya adalah : (equation 4) a --> c set (a-->a') (a,a')(c) a'--> c set (c-->b) (a,a')(c,b) a'-->b forward packet (a,a')(c,b) forward packet maka turunan dari rule nya adalah (equation 5) (a,a') --> (c,b) forward packet Rule Set Conflict Evaluation

FortNOX telah menunjukkan alias set rule reduction pada kandidat rule. Validitas pengecekannya ini kemudian ditunjukkan antara kandidat ARR cRule dan set dari ARRs yang merepresentasikan active flow rule fRule sebagai berikut : 1. Skip semua cRule/fRule pair yang tidak cocok dengan prototipe 2. Skip semua cRule/fRule pair yang action keduanya baik forward atau drop paket. 3. Jika cRule alias set berpotongan dengan fRule, maka bisa disimpulkan terjadi sebuah konflik. Dengan demikian, berdasarkan flow description di persamaan 2 dan calon rule set di persamaan 5 mengasumsikan bahwa kedua rule adalah protokol TCP, kandidat rule yang pertama telah melewati 2 pengecekan awal. Namun, untuk pemeriksaan ketiga, karena source dan destination alias set menghasilkan (a) dan (b), kandidat rule dinyatakan bertentangan. Penyelesaian Konflik

Saat terdeteksi konflik antara existing rule di aggregate flow table dan candidate flow rule, sifat dari candidate rule dievaluasi berdasarkan peran otorisasinya. Jika sumber dari flow rule insertion request beroperasi pada otorisasi peran yang lebih tinggi daripada rule yang konflik di aggregate flow table, kandidat rule yang baru akan menimpa rule yang ada. Rule yang ada dibersihkan dari kedua aggregate flow table dan switch, dan candidate rule dimasukkan ke keduanya. Jika source dari insertion request adalah source yang otorisasi perannya lebih rendah dari rule yang bertentangan dalam aggregate flow table, maka candidate rule( yang baru ditolak, dan kesalahan dikembalikan ke aplikasi. Dan jika source dari insertion requester beroperasi dengan otorisasi sama dengan conflicting rule di aggregate flow table, maka FortNOX

memungkinkan administrator untuk menentukan hasil. Secara default, rule baru ini akan menggantikan rule sebelumnya. State Table Manager

State Table Manager dan modul Flow Rule Timeout Callback mengelola keadaan semua flow rule yang aktif yang diberlakukan oleh FortNOX, serta sifat dari rule itu sehubungan dengan switch flow table dan peran otorisasi produser rule tersebut. Ketika flow rule berhasil dimasukkan ke dalam switch, ARR disimpan dalam aggregate flow table. Rule dihapus melalui timer eksplisit yang disediakan melalui Security Directives Translator, atau saat ditemui dalam konflik dengan candidate rule yang di insert dari produser yang beroperasi level otorisasi yang lebih tinggi. Security Directive Translation

Security Directive Translation adalah suatu python interface yang memediasi suatu set dari high-level threat mitigation directives ke flow rules, yang digitally signed dan disampaikan kepada FortNOX. Security directive translator yang ada menerapkan tujuh security directives : block, deny, allow, redirect, quarantine, undo, constraint dan info. Block menerapkan filter full duplex di antara CIDR Block dan jaringan internal, dimana penggunaan utama untuk perintah ini adalah untuk melakukan blacklist.

Reference : P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu. A Security Enforcement Kernel for OpenFlow Networks. In Proceedings ACM SIGCOMM Workshops on Hot Topics in Software Defined Networking (HotSDN), August 2012

AVANT-GUARD: Scalable and Vigilant Switch Flow Management in Software-Defined Networks Erlangga Ervansyah (23213302) EL5244 Pemograman Perangkat Jaringan

1. Pendahuluan Sebagai perusahaan jaringan dan pusat kontrol data yang saat ini terus berkembang dalam segi ukuran dan kompleksitas, mereka membuat peranan dalam hal administratif lebih besar dari siapapun, sehingga permintaan layanan harus ditingkatkan atau otomatisasi dalam merancang pada baik sistem komputer maupun sumber daya jaringannya. Komunitas riset jaringan menyatakan bahwa salah satu pendekatan untuk memenuhi tantangan ini terletak dalam prinsip SoftwareDefined Network (SDN). Dengan melakukan proses decoupling logika kontrol dari implementasi tertutup serta eksklusif pada perangkat jaringan konvensional, SDN memungkinkan peneliti dan praktisi sekitar untuk merancang suatu fungsi baru untuk jaringan yang lebih inovatif juga protokol yang menangani jaringannya memproses jauh lebih mudah dan fleksibel. Struktur OpenFlow adalah salah satu yang diwujudkan pada konsep SDN. Dalam beberapa tahun terakhir, OpenFlow(OF) telah melatarbelakangi ide penelitian dalam eksplorasi dunia akademik jaringan untuk implementasi referensi standar SDN dimana teknologi ini menjadikan pergerakan momentumnya berperan cukup besar dalam industri saat ini. OpenFlow (OF) menyediakan banyak tema penelitian baru bagi komunitas keamanan jaringan. Sebagai contoh, OF dapat menawarkan beberapa penyederhanaan yang cukup dramatis dalam proses desain dan integrasi dalam konteks aplikasi keamanan jaringan ke jaringan yang berukuran besar. Sayangnya, potensi OpenFlow untuk memberikan kemajuan berarti bagi negara yang mengandalkan pertahanan jaringannya harus ditahan oleh pernyataan bahwa OpenFlow sendiri memiliki tantangan yang serius dalam bidang keamanan. Paper ini, dijelaskan beberapa solusi yang berpotensi baik untuk dua tantangan keamanan. Pertama, jaringan OpenFlow kekurangan skalabilitas antara data plane maupun control plane. Hal ini memungkinkan serangan yang ditargetkan oleh entitas eksternal yang membangun inbound stream pada flow request menyebar di jalur komunikasi antara controller dan switch, yang kita sebut sebagai serangan control plane. Kedua, OpenFlow menawarkan dukungan yang sangat terbatas untuk aplikasi monitoring pada jaringan yang mencari pelacakan halus dari operasi dalam data plane, sehingga membuatnya sulit memperoleh dukungan terhadap banyak aplikasi keamanan yang membutuhkan akses cepat terhadap perubahan penting dalam pola trafik jaringan. Tantangan Skalabilitas. penyebab utama tantangan skalabilitas terletak pada pengoperasian protokol OpenFlow dibawah perangkat switch, yang memisahkan control plane dari data plane untuk mengaktifkan kinerja kontrol yang terpusat. ketika switch OpenFlow menerima paket yang memiliki alur yang baru dan dirinya tidak memiliki kecocokan dengan alur yang ada, maka switch akan meneruskan paket ke kontroler OpenFlow. Controller merespon dengan satu atau lebih aturan aliran yang menunjukkan bagaimana cara memproses flow yang akan datang yang juga memenuhi kriteria yang cocok pada flow sebelumnya, dan ini dirancang untuk menengahi permintaan flow yang melewati dirinya, sehingga menyebabkan halangan untuk proses scalling jaringan. Pada saat yang sama, data plane juga menerima serangan karena switch memiliki sumber daya yang terbatas untuk flow inisiasi khusus protokol transport (TCP / UDP) sampai controller menangani flow-nya. Oleh karena itu, control plane yang diserang juga memiliki implikasi langsung untuk kemampuan operasional pada data plane. Jenis serangan seperti DDoS dan network scanning, yang ditangani serius oleh komunitas keamanan, menimbulkan potensi ancaman baru untuk skalabilitas, baik pada lapisan kontrol terpusat OpenFlow maupun SDN pada umumnya. Responsiveness Challenge. Tantangan ini muncul berlandaskan dari kebutuhan untuk akses cepat ke pola aktivitas data plane. Aplikasi network monitoring bertugas mengumpulkan statistik jaringan untuk beberapa kebutuhan seperti pelacakan flow dan jaringan dengan statistik paket yang luas ataupun juga bisa untuk mengukur aktivitas berbagai entitas komunikasi melalui switch (misalnya, untuk mengidentifikasi serangan DoS, yang berdampak pada data plane). Teknologi Openflow SDN hanya memungkinkan suatu aplikasi untuk secara eksplisit menerima dan menelaah informasi dari setiap switch. Antarmuka ini tidak cukup untuk aplikasi monitoring yang membutuhkan pemantauan statistik pada data plane untuk melacak dan menanggapi kondisi berbahaya atau penurunan performansi suatu sistem. Selain itu, meskipun aplikasi keamanan sering membutuhkan pemeriksaan isi paket yang cocok dengan beberapa kriteria. Karena hal inilah, OpenFlow menawarkan mekanisme untuk memfasilitasi kebijakan tersebut. Untuk mengatasi hal-hal tersebut, dikembangkanlah suatu ekstensi keamanan khusus untuk OpenFlow yang disebut AVANT-GUARD. Ada beberapa isu penting yang kita

fokuskan melalui proses pengembangan ini. Pertama, menentukan jenis kecerdasan yang akan ditambahkan ke bidang data. Kedua, perlu adanya teknik yang efektif untuk menampilkan jaringan statistik untuk control plane. Ketiga, perlu dikembangkan mekanisme baru yang dapat bereaksi cepat terhadap serangan yang terdeteksi. Akhirnya, implementasi ini harus meminimalkan perubahan pada protokol OpenFlow.

2. Desain Sistem Untuk mengatasi beberapa masalah yang telah dijabarkan sebelumnya, AVANT-GUARD dibangun sebagai ekstensi keamanan pada Openflow data plane. Berikut merupakan desain infrastruktur dari sistem AVANT-GUARD. Arsitektur Keseluruhan. AVANT-GUARD memiliki modul jaringan sebagai berikut: 1) Connection Migration (CM); dan 2) Actuating Triggers (AT). Diagram konseptual untuk AVANT-GUARD pada bidang data. Terinspirasi oleh proxy SYN yang menangani koneksi TCP, perlu diterapkan migrasi koneksi untuk menyaring TCP yang gagal terkirim di bidang data ke kontrol Pesawat. Proses ini bekerja sama dengan tabel akses untuk memelihara informasi sesi TCP pada bidang data yang selanjutnya mengirimkan rincian sesi ke control plane. Proses ini juga memungkinkan koleksi informasi status jaringan dan informasi payload paket lebih efisien dari data plane sebelumnya. Selain itu, proses ini juga menawarkan flow berupa aktivasi aturan, yaitu, kemampuan untuk mengaktifkan flow aturan ketika beberapa peristiwa terjadi. Connection Migration(CM). Tujuan dari proses CM adalah untuk meningkatkan mutu data plane untuk membedakan sumber-sumber yang akan mengantarkan koneksi TCP dari sumber yang tidak diterimanya. Untuk melakukan hal ini, handshaking data plane ke proxy TCP diperpanjang, menambahkannya dengan flow request untuk control plane yang telah menyelesaikan proses handshaking. Proses migrasi koneksi dalam diagram terdiri dari empat tahap: (i) klasifikasi, (ii) laporan, (iii) migrasi, dan (iv) relay. Setiap tahap dan transisi di antara mereka ditunjukkan dalam Gambar 2. Ketika sumber memulai sambungan, Modul Connection Migration(CM) terlibat pada sumber di handshaking stateless TCP menggunakan SYN cookies. Koneksi ditambahkan pada tahap klasifikasi. Setelah proses handshaking selesai, CM memberitahu control plane dari flow request, untuk mentransisi koneksi ke tahap laporan. Jika control plane memungkinkan proses migrasi, CM menginisiasi host tujuan dengan TCP handshaking, untuk mentransisi koneksi ke tahap migrasi. Kemudian, jika tujuan merespon, CM memberitahu control plane, dan koneksi akan memasuki tahap laporan. Akhirnya, jika control plane memungkinkan data plane untuk menyampaikan paket, CM akan menyelesaikan langsung hubungan antara sumber dan

tujuan, dan koneksi pun beralih ke tahap relay.

Actuating Triggers(AT). proses ini memungkinkan data plane untuk melaporkan status jaringan secara asinkron dan informasi payload ke control plane. Selain itu, AT dapat digunakan untuk mengaktifkan flow condition di beberapa flow yang telah ditetapkan, yaitu kondisi untuk membantu control plane mengelola aliran data di jaringan tanpa terdapat penundaan. Penggerak pemicu AT terdiri dari empat operasi utama. Pertama, control plane perlu menentukan kondisi statistik trafik. Kedua, meregistrasikan kondisi ini dari control plane terhadap bidang data. Ketiga, data plane memeriksa kondisi sambil mengumpulkan aliran data secara lokal dan flow secara statistik untuk menentukan apakah kondisi telah dipenuhi. Keempat, ketika data plane telah menentukan bahwa kondisi ini dipenuhi, mungkin terdapat dua perlakuan 1) memicu callback event ke control plane untuk menunjukkan bahwa kondisi ini dipenuhi, atau 2) memasukkan flow baru ke dalam flow tabel tertentu.

Gambar 3: Contoh Skenario Modul Actuating Triggers(AT)

3. Implementasi Sistem AVANT-GUARD tidak lain adalah sebuah switch berbasis software dengan referensi OpenFlow (atau disebut software OF switch). Acuan ini mengikuti OpenFlow spesifikasi 1.0.0, dan berfungsi sebagai data plane. Sumber kode diubah oleh penyusun materi dalam implementasi ini, untuk mendukung modul CM dan AT. Secara khusus, algoritma packet_receive

disusun ulang dalam perangkat lunak switch OF untuk merespon upaya koneksi baru dengan SYN / ACK. Jika algoritma packet_receive menerima TCP ACK (atau, jika cocok dengan SYN cookies yang dihasilkan sebelumnya), paket tersebut memerlukan izin dari control plane untuk memulai modul CM. Saat proses menerima izin, OF switch yang telah dikonfigurasikan tadi akan memulai proses koneksi TCP ke host tujuan yang sebenarnya. Untuk menyampaikan paket TCP berikutnya melalui CM, ditambahkan pula beberapa fungsi algoritma untuk memodifikasi nomor ACK atau SEQ yang sesuai dengan masing-masing paket TCP. Terdapat tiga unsur yang ditambahkan. Switch dimodifikasi untuk dapat memeriksa setiap kali terdapat update counter untuk setiap aliran (atau variabel lain). Jika nilai counter memenuhi suatu kondisi yang didefinisikan oleh control plane, switch menghasilkan sinyal kembali ke control plane. Untuk menerapkan aktivasi aturan pada flow, dibangun sebuah struktur data yang dapat menahan flow aturan yang telah ditetapkan. Untuk membangun fungsi AVANT-GUARD, sepuluh perintah baru OpenFlow ditambahkan, seperti yang tercantum dalam Tabel 1. Perintah-perintah ini dilaksanakan baik perangkat lunak switch OF maupun controller POX.

Tabel 1: Command OpenFlow Baru pada data plane AVANT-GUARD



Gambar 4: Desain infrastrukture hardware untuk (a). Switch OpenFlow pada SDN Tradisional; (b). Switch OpenFlow pada AVANT-GUARD Data Plane SDN. Pertama, perhatikan arsitektur data plane pada SDN seperti pada Gambar 4 (A). Arsitektur ini mengikuti implementasi NetFPGA dari switch OpenFlow oleh penemunya. Implementasi ini terdiri dari enam modul utama: (i) input arbiter, yang bertugas meneruskan paket berdasarkan logika yang dijalankan; (ii) parse header, yang mem-parsing-kan header paket; (Iii) exact match lookup , yang mentelusuri aturan pada flow (w/o wildcard) untuk diterjemahkan kedalam paket; (iv) lookup wildcard, mentelusuri aturan pada flow (dengan wildcard) untuk paket; (V) arbiter, yang memutuskan operasi apa yang akan digunakan dalam sebuah paket (forward atau drop); dan (vi) packet editor, yang bertugas meneruskan atau mengubah paket. Aturan Flow disimpan dalam TCAM atau SRAM (diluar ASIC), dan counter menyimpan nilai-nilai statistik untuk setiap flow aturan yang melekat pada TCAM atau SRAM. Implementasi ini meninjau perangkat keras yang dipakai menggunakan skenario berikut. Pertama, jika data plane menerima paket, komponen lookup memeriksa TCAM/SRAM untuk melihat apakah flow aturan untuk penanganan paket ini ada atau tidak. Jika benar ada, data plane meneruskan paket tersebut ke arbiter. Jika tidak, ia meminta control plane melalui antarmuka CPU. Implementasi Connection Migration(CM): Untuk menerapkan CM dalam hardware, kita perlu mengubah tiga komponen di bidang data dan menambahkan dua struktur data baru ke dalam data plane. Arsitektur data-pesawat baru yang disajikan dengan CM tertera pada Gambar 4 (B). Header parser dimodifikasi untuk mengekstrak TCP flag, dan arbiter dimodifikasi untuk memaksa editor paket untuk memulai inisiasi CM atau membalas dengan paket TCP SYN/ACK. Modul ini dapat melakukan CM atau menjawab permintaan sambungan dengan mengirimkan SYN/ACK. Data plane ini harus bisa mengubah nomor ACK atau SEQ pada masing-masing paket untuk menemukan perbedaan nomor SEQ terhadap SYN (SYN dari inisiator koneksi ke data plane) dan bagian dalam koneksi (SYN dari data plane ke tujuan migrasi). Perbedaan nilai ini akan disimpan dalam satuan delta ACK/SEQ, dan jumlah nilai ini adalah sama dengan jumlah koneksi yang sedang bermigrasi. Implementasi Actuating Triggers(AT): Untuk menerapkan AT di hardware, penulis menambahkan dua struktur pada data plane, yang telah ditunjukkan pada Gambar 4 (B). Semua kondisi untuk AT ini secara kolektif diberi label "Condition" di gambar. Selain itu, flow aturan yang telah ditetapkan dapat dijalankan dengan menambahkan komponen yang sama untuk flow aturan (TCAM dan SRAM). Untuk implementasi dengan sensitif akan besar biaya, ruang penyimpanan TCAM/SRAM dapat dibagi untuk flow aturan ini (tidak ditunjukkan dalam Gambar).

4. Evaluasi Network Saturation Attack. Contoh Skenario: Ruang pengujian untuk percobaan ini ditunjukkan pada Gambar 5. Terdiri atas switch OpenFlow (data plane) dimana AVANT-GUARD telah dijalankan; controller jaringan POX; server yang menjadi host untuk layanan web; user client normal yang terhubung dengan server untuk proses HTTP request; dan penyerang

yang melakukan TCP SYN flood attack.

Gambar 5: Skenario Network Saturation Attack

Gambar 6: Persentase Paket Berhasil Terkirim ke Webserver dari Klien Normal Dalam skenario ini, kita mengukur response time, atau waktu yang dibutuhkan user client normal untuk mengambil halaman data dari server. Proses ini dilakukan dalam dua kondisi, yaitu dengan dan tanpa serangan TCP SYN flood attack dalam jaringan OpenFlow. Penyerang membangkitkan 1.000 koneksi per detik ke server, dan ini diulangi lebih dari 500 detik untuk mengukur waktu respon rata-rata. Hasil pengujian menunjukkan waktu respon rata-rata dirangkum pada Tabel 2. Klien normal dapat mengambil halaman web dalam 0,4 detik, tetapi tidak mendapatkan respon apapun selama ada TCP SYN flood attack karena muncul efek control plane maupun data plane yang tersaturasi seperti disebutkan sebelumnya. Namun, AVANT-GUARD efektif dapat mempertahankan jaringan dari serangan ini, memungkinkan klien yang normal untuk mengambil halaman web tanpa masalah, karena data plane ini secara otomatis dan transparan mengklasifikasikan dan menghilangkan upaya koneksi TCP asing dari penyerang. Pengukuran overhead proses CM pada koneksi TCP normal

saat tanpa serangan menggunakan setup eksperimental yang ditunjukkan pada Gambar 12. Dari Tabel 2, kita dapat melihat bahwa biaya overhead yang disebabkan oleh CM pada koneksi TCP yang normal minimal (1,86%). Untuk lebih menunjukkan efek dari serangan saturasi pada trafik normal secara rinci, penyusun mengubah tingkat kirim-terima serangan saturasi jaringan selama 0-800 per detik, dan juga mengirim permintaan dari 10 klien normal ke web server pada saat yang sama. Hasilnya ditunjukkan pada Gambar 6, dan kita dapat dengan mudah mengamati bahwa permintaan dari klien normal yang tidak dikirim ke web server ketika serangan saturasi jaringan yang terjadi dengan switch OpenFlow (hampir 0% ketika serangan banjir mengirimkan lebih dari 100 paket per detik). Namun, dengan AVANT-GUARD, semua permintaan dari klien normal dapat dikirim ke server web, bahkan saat jaringan di bawah serangan saturasi jaringan. Network Scanning Attack. Contoh Skenario: Metode pengujian yang dilakukan adalah bagaimana sistem menangkal jaringan dari serangan pemindaian jaringan, dan ruang lingkup pengujian ini ditunjukkan pada Gambar 7. Pada tes ini, kami menggunakan Nmap [24] untuk memindai semua port jaringan di file server (10.0.0.2) yang hanya membuka jaringan Port 10000.

Gambar 7: Skenario Network Scanning Attack Jika AVANT-GUARD dijalankan, data plane secara otomatis mempertahankan informasi tentang upaya koneksi TCP di tabel akses dan informasi sesi laporan ke control plane, yang dapat dengan mudah mendeteksi upaya pemindaian dengan menerapkan algoritma scan-detection sederhana. Aplikasi ini hanya perlu meminta data plane untuk melaporkan informasi tentang upaya sambungan TCP. Hasil deteksi ditandai dengan tanda garis merah pada Gambar 8 dan hasil deteksi pada Nmap tanpa dan dengan AVANT-GUARD masing-masing di gambar 9 dan 10.

Gambar 8: Hasil Proses Scan-detection

Gambar 9: Hasil Deteksi pada Nmap Tanpa Menggunakan AVANT-GUARD

Gambar 10: Hasil Deteksi pada Nmap Dengan AVANT-GUARD Network Intrusion Attack. skenario serangan ditunjukkan pada Gambar 11. Dalam skenario ini, penyerang (10.0.0.1) mengirimkan serangan RPC buffer overflow ke host lain dalam jaringan (10.0.0.2).

Gambar 11: Skenario Network Intrusion Attack Di sini kita mengasumsikan dua hal: (i) control plane sudah diminta oleh data plane untuk memberikan paket yang dikirim ke 10.0.0.2 dan (ii) aplikasi keamanan memiliki pengenal atas serangan itu. Di skenario pengujian, aplikasi menggunakan aturan berbasis snort untuk mendeteksi payload yang bahaya. Hasilnya ditunjukkan pada Gambar 12, di ditemukan bahwa aplikasi keamanan telah mendeteksi serangan dengan tepat dan akurat, seperti yang ditunjukkan pada tanda garis merah di gambar.

Gambar 12: Hasil Deteksi Network Intrusion

5. Kesimpulan Dalam paper ini, AVANT-GUARD dapat diusulkan, menjadi suatu struktur terbaru untuk memajukan keamanan dan ketahanan jaringan OpenFlow dengan keterlibatan yang lebih besar dari lapisan data plane. Tujuan dari AVANTGUARD adalah untuk membuat aplikasi keamanan SDN yang lebih terukur dan responsif terhadap ancaman apapun di jaringan. Tantangan utama yang ditemukan adalah hambatan oleh antarmuka dari control plane oleh data plane yang dapat dimanfaatkan musuh. Metode migrasi koneksi (CM) memungkinkan data plane untuk melindungi control plane dari serangan saturasi tersebut. Tantangan kedua adalah masalah responsif. Aplikasi keamanan SDN membutuhkan akses statistik jaringan yang cepat dari data plane. Maka dari itu, terdapat penggerak pemicu (AT) yang secara otomatis memasukkan aturan aliran ketika jaringan berada di bawah tekanan. Implementasi software AVANT-GUARD menunjukkan bahwa overhead minimal yang dikenakan oleh peranan keamanan AVANT-GUARD, dengan keterlambatan peningkatan koneksi yang jauh lebih sedikit yaitu 1% pada overhead, saat data plane memberikan ketahanan di SDN.

6. Referensi Seungwon Shin et al., ''AVANT-GUARD: Scalable and Vigilant Switch Flow Management in Software-Defined Networks,'' in CCS '13 Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security, pp. 413-424 .

Multi-Home Network dan Visual Home Sharing Berbasis SDN Cokorda Gde Kresna Dhita 1. Pendahuluan Saat ini, digital living berkembang pesat seiring dengan berkembangnya perangkat elektronik cerdas yang semakin pesat. Hal tersebut merubah hidup kita pada semua hal, termasuk kehidupan dirumah. Perkembangan Home-networking kedepan nya akan memungkinkan anggota keluarga untuk mengakses jaringan rumah dari jarak yang jauh sekalipun. Tetapi keanekaragaman perangkat dan protokol yang digunakan oleh masing masing perangkat yang berbeda – beda timbul sebuah tantangan yaitu masalah interoperability. Pengembangan future home networking kedepannya yang memungkinkan untuk akses jaringan dari jarak jauh akan menimbulkan masalah yaitu fragmentation challenge. Fragmentation challenge tersebut dapat diselesaikan dengan membuat perangkat yang digunakan dalam home network dapat dikonfigurasi maupun diprogram demi fleksibilitas dalam penggunaan perangkat. Koordinasi yang baik akan meningkatkan kepuasan user dalam penggunaan perangkat. Untuk melengkapi fungsi koordinasi tersebut , teknologi yang saat ini dikembangkan , yaitu Software Defined Networking (SDN) menjadi sebuah pilihan yang tepat. SDN memisahkan kontrol dengan fungsi koordinasi dari perangkat yang meneruskan paket – paket.

Pada gambar 1 diatas, diillustrasikan perangkat – perangkat Consumer Electronic (CE) dari prototype SDN-enabled untuk melayani aplikasi multihome multimedia. Pada Home Enviroment diperlukan sedikit konfigurasi , akan tetapi didalam dan diluar dari rumah, akan diperlukan banyak konfigurasi pada dari manajemen home networking, karena terdapat berbagai macam perangkat yang terhubung secara kabel maupun nirkabel. Penggunaan perangkat CE (HomeBox dan ControlBox yang ditunjukkan pada gambar 1) memberikan fleksibilitas yang lebih baik pada konfigurasi perangkat dan packet control dan membebaskan user untuk mengkonfigurasi secara manual berbagai perangkat maupun menginstall aplikasi software untuk memungkinkan interoperabilitas perangkat. 2.Persyaratan Aplikasi Future – Home Networking dan Solusinya Future Home-Networking memerlukan beberapa kriteria dalam pengaplikasiannya. Berikut akan dijabarkan mengenai beberapa kriteria yang diperlukan dalam pengaplikasian SDN-enabled home Network : A. Syarat Fungsional Perangkat CE harus memenuhi persyaratan untuk mengatasi masalah fragmentation challenge dan untuk meningkatkan User Experience (UX) dirumah. Persyaratan tersebut antara lain : Ekstensibilitas Software centric dengan pemrograman perangkat : Tantangan manajemen dan interoperabilitas dalam future home environment dapat diatasi dengan memungkinkan perangkat CE untuk dapat diprogram dan dikonfigurasi secara fleksibel. S. Dengan penggunaan software centric programmability, fleksibilitas dari CE dapay

dilakukan, dan hal ini berdampak pada peningkatkan kepuasan home user. Koordinasi yang Fleksibel dari Beberapa Perangkat: Berbagai perangkat CE yang terhubung dalam Future Home Network akan menimbulkan pentingnya untuk mengembangkan manajemen jaringan dari perangkat – perangkat tersebut, termasuk konfigurasi perangkat yang simpel. Hal tesebut juga memicu hadirnya aplikasi home network yang belum pernah ada sebelumnya. Oleh karena itu , koordinasi yang fleksibel dari perangkat CE penting untuk manajemen dan inovasi aplikasi pada perangkat home network. Interkoneksi Multi-Home dengan Pertimbangan Privasi : Kebutuhan User akan home networking harusnya tidak terbatas pada satu home network, misalkan saat anggota keluarga terpisah untuk bekerja maupun bersekolah diluar lingkungan rumah. Hal tersebut merupakan sebuah tantangan untuk mengintegrasikan beberapa domain home network karena mungkin beberapa home network tersebut memiliki protokol jaringan yang tidak kompatibel dan resource CE yang berbeda beda.Konfigurasi yang tersentralisasi dari perangkat CE dapat menghemat biaya dan waktu tetapi di saat yang sama terdapat ancaman terhadap privasi karena konfigurasi memerlukan visibilitas dari paket. Jadi menyembunyikan isi paket adalah hal yang harus dilakukan untuk melindungi privasi. Visibilitas paket merepresentasikan informasi raw level packet yang digunakan untuk koordinasi yang tersentralisasi. B. Keuntungan dalam pengaplikasian perangkat Home CE berbasis SDN Dengan adanya software-centric, ekstensibilitas dan fleksibilitas dari SDN-Enabled home CE devices dapat memberikan beberapa keuntungan bagi user , antara lain : Berkurangnya Biaya Konfigurasi dan Maintenance Saat ini , perangkat CE harus dipasang, dan dikonfigurasi secara manual. Dengan adanya future home network yang berbasiskan SDN, perangkat CE yang digunakan dapat dikoordinasikan dengan mudah, dalam pemasangan, konfigurasi maupun maintenance dari alat – alat tersebut. Hal ini berdampak pada semakin murahnya biaya untuk pemasangan dan pemeliharaan perangkat. Meningkatnya User Experience dengan Aplikasi yang Inovatif Dengan adanya software-centrik dari jaringan SDN , fungsi – fungsi dari perangkat CE dapat dikonfigurasi sesuai dengan keinginan user. Selain itu, perangkat CE dapat terinterkoneksi ntuk meningkatkan keamanan, performa, maupun adaptasi multimedia. Sebagai contoh, fungsi keamanan pada home gateway dapat dipisahkan dan dipasang pada perangkat CE untuk memastikan keamanan user. 3. Koordinasi Home Networking dengan Perangkat Berbasis SDN Pada bagian ini, akan dibahas bagaimana arsitektur dari perangkat CE dan contoh dari koordinasi jaringan berbasiskan SDN A. Persyaratan Home-networking yang Memuaskan -Ekstensibilitas Perangkat dengan Dataplane yang kaya fitur Digunakan sebuah arsitektur modular untuk meningkatkan ekstensibilitas dari perangkat HomeBox yang berbasiskan software-centric. Komponen software yang terpasang berisikan fungsi dari perangkat yang digunakan. Dataplane maupun forwarding plane dari perangkat homebox mampu memproses paket yang kompleks seperti penyisipan, penghapusan maupun memodifikasi IP header untuk mengintegrasikan beberapa home network. -Home Networking Sesuai dengan Keinginan Jaringan untuk home application dapat dijalankan sesuai dengan keinginan dari user untuk meningkatkan user experience pada extended home network. Penggunaan SDN mampu menyederhanakan paket flow pada jaringan sesuai dengan keinginan user. Interface antara user dengan perangkat CE disediakan oleh sebuah pesan, yaitu Application description (AD) message. - Interkoneksi Multi-Home tanpa Visibilitas Paket Untuk menangkal permasalahan pada privasi paket menuju ControlBox, digunakan SDN-based two tier messaging yang di sediakan oleh pihak ketiga yang bisa dipercaya. Informasi mentah dari setiap paket IP pada home network hanya boleh dibuka pada perangkat homebox yang ada pada jaringan yang sama. B. Arsitektur Sistem Home Network Berbasis SDN

Pada gambar 2 diatas, diilustrasikan interkoneski yang terjadi antara 2 home network dengan menggunakan teknologi SDN. ControlBox berada pada level teratas betanggung jawab untuk konfigurasi dari Homebox untuk mengintegrasikan beberapa home network. Arsitektur dalam perangkat Controlbox mirip dengan Gateway Homebox, hanya perbedaannya ControlBox tidak memiliki data-plane support. AD message diformat untuk menggambarkan packet flow dari field seperti TCP/IP, pemrosesan dan forwarding paket, dan yang lain.AD message dapat memicu komposisi layanan dari home-network dengan megirimkan signal network preferences untuk sebuah packet flow. Semantik dari aplikasi tingkat tinggi , yang dijabarkan pada AD message di terjemahkan kedalam semantic tingkat rendah atau semantic aplikasi yang lebih spesifik. Sebagai contoh, ControlBox dapat membuat message baru yang memiliki semantic aplikasi spesifik yang kemudian dikirmkan ke Gateway Homeboxes untuk dikonfigurasi. Perangkat Gateway Homebox dapat di tafsirkan sebagai controller SDN dengan skala kecil dengan berbagai macam fitur dataplane. Sedangkan pada sisi hardware dari Gateway HomeBox, flow table menyimpan entri dari setiap flow yang memandu “apa dan bagaimana” untuk memproses paket flow.Hal tersebut akan meningkatkan control secara terperinci dan meningkatkan fleksibilitas kontrol. C. Format Message dan SDN based Messaging Dengan adanya AD messaging, home user dapat berinteraksi dengan perangkat SDN. Dan SDN messaging memungkinkan coordinator untuk berinteraksi dengan semua infastrukturnya yaitu semua perangkat yang dikontrol oleh coordinator tersebut. Gateway homebox dapat dianggap sebagai koordinator dari sebuah inrastruktur dan juga merupakan infrastruktur dari Control Box.

Pada Tabel 1 , dijelaskan beberapa jenis message dalam koordinasi centralized home network. Message tersebut dikelompokkan kedalam 2 katagori yaitu control message dan event message. Sebuah koordinator mengontrol semua infrastrukturnya dengan control messge , sedangkan infrastrukturnya menggenerate event message ketika ia menerima event. SDN messaging memberikan berbagai keuntungan dalam home networking, salah satunya adalah flow lantency akan kecil karena delay propagasi antar semua perangkat CE sangat kecil. Untuk keamanan informasi dari home user, Gateway homebox tidak boleh mengirimkan event message , karena message tersebut mungkin menyebabkan bocornya paket – level information, yaitu segment dari IP packet. Untuk pengaturan yang lebih cepat, AD message menggunakan simple character untuk mendeskripsikan perintah. Message tersebut dapat dilihat pada tabel 2 :

Pada gambar 3 diatas , dapa dilihat contoh dari SDN messaging antar perangkat CE ,dimana tiga homebox digunakan bersama dengan sebuah Control Box. Gambar tersebut menjelaskan fungsi dari AD message untuk menghubungkan dua home network dimana setiap rumah memiliki masing – masing sebuah perangkat gateway homebox. Langkah – langkah dari interkoneksi tersebut antara lain : 1. User harus mendeskripsikan IP address dari kedua Gateway homebox (dengan AD message( h=Gateway_HomeBox_I:Gateway_HomeBox_II ) dan jenis link virtual antara keduanya yaitu translasi dari network addressnya (AD message : c=ADDR_TRANS) 2. Untuk kontrol Flow based networking , user dapat mengistruksikan bagaimana sebuah flow akan dikontrol secara spesifik. Sebagai contoh, sebuah flow (AD : f=239.2.2) harus melalui 2 waypoint (AD : d=10.1.1.22:10.1.0.22) sebelum mencapai Gateway HomeBox. Gateway Homebox II akan secara otomatis melakukan koordinasi dalam home network, tanpa adanya interferensi dari Controlbox. Hal tersebut dilakukan dengan pertukaran SDN message dengan cabang - cabang perangkat Homebox. Controlbox masuk kedalam fungsi jaringan saat menerima AD message, dimana message tersebut ditranslasi kedalam message yang lebih spesifik dan kemudian dikirimkan pada kedua Gateway Homebox untuk konfigurasi virtual link. Masing – masing Gateway Homebox kemudian mentranslasikan message tersebut dan meng-generate flow entries dalam dataplane masing-masing. D. Skenario Eksperimen dari Visual Sharing Untuk menunjukkan kinerja dari perangkat CE dengan basis SDN terutama pada performa multi home visual sharing, dilakukan sebuah eskperimen yang dapat pada gambar :

Pada gambar 4 diatas diilustrasikan sebuah skenario multi home visual sharing yang dikoordinasikan dengan SDN. Seorang home user melakukan multicast setelah mengirimkan AD message kepada ControlBox. Setelah menerima AD message (h=Gateway_HomeBox_I: Gateway_HomeBox_II ,c=TUNNEL,f=MCAST_ADDR) tersebut , ControlBox kemudian mengkonfigurasi kedua Gateway Homebox untuk menghubungkan kedua home network. HomeBox II menkonfigurasi semua Homebox dalam home network II dengan menggunakan AD message yang berbeda (h=Gateway_HomeBox_II, c=ADDR_TRANS, f=MCAST_ADDR, d=Transcoder_HomeBox). Transcoder Homebox disini berfungsi sebagai Transcoder. Jalur end to end pada gambar 4 dibagi kedalam 3 bagian berdasarkan perubahan flow information. Perubahan flow information tersebut terjadi karena perangkat Homebox melakukan translasi alamat. Media adaptation service dikoordinasi oleh Homebox II , yang kemudian mentransmisikan konten multimedia kepada perangkat nirkabel. Transcoder kemudian mengubah paket video dan meneruskannya ke perangkat wireless mobile (handphone, tablet dll). Trnascoding diasumsikan dilakukan sebelum transcoder meng-generate paket video.

Pada gambar 5 diatas ditunjukkan gambar hasil dari eksperimen dengan prototype perangkat berbasis SDN. Komputer mengirimkan video stream ke set-top box yang berada pada home network yang berbeda. Dengan munggunakan koordinasi berbasis SDN, home user dapat mengintegrasikan beberapa home network dengan mudah walaupun perangkat dan protokol yang berbeda beda.

Gambar 6 menunjukkan perubahan datarate saat video flow melewati Gateway Homebox I.pada gambar tersebut menjelaskan bahwa perangkat Homebox melakukan flow-based packet processing dan forwarding , dan melakukan packet count monitoring terhadap jaringan. Hasilnya, home user dapat memfasilitasi flexibilitas dan flow level control terhadap pengaturan home network mereka. 4. Kesimpulan Dengan hasil eksperimen yang dilakukan, penggunaan koordinasi yang fleksibel berbasis SDN merupak sebuah solusi yang layak untuk menanggulangi fragmentation challenge pada aplikasi future home networking. Reference : Software-defined Home Networking Devices for Multi-home Visual Sharing, Jinyong Jo et al, August 2014

TOWARD SOFTWARE-DEFINED CELULLAR NETWORK by: Li Erran Li, Z. Moreley Mao, & Jennifer Rexford Hamzah U. Mustakim 1. Pendahuluan Pertumbuhan pesat pengguna smart-phone dan tablet diikuti juga oleh perkembangan jaringan seluler. Insfraksttuktur jaringan yang luas dan bentuk topologi yang kompleks memiliki beberapa kendala dalam proses konfigurasi setiap perangkat yang digunakan, karena menggunakan perangkat dari vendor yang berbeda, sehingga menjadi kurang fleksibel pada proses operasional. Penerapan SDN (Software Difined Network) pada jaringan seluler dapat menyederhanakan desain topologi dan pengelolaan insfrakstuktur jaringan seluler. Selain itu juga memungkinkan operator untuk menambahkan layanan baru kepada pelanggan. 2. Implementasi Konsep SDN yang dipaparkan pada paper ini adalah dengan menambahkan kontroler, switch, dan base-station yang dapat mengoperasikan aplikasi kontroler dengan fungsi sebagai berikut: Mendefinisikan kebijakan dan aturan berdasarkan atribut / identitas pelanggan daripada alamat dan lokasi pelanggan. Melakukan proses kontrol secara real-time melalui local switch agent. Melakukan pemeriksaan terhadap setiap paket data dan header secara mendalam. Mengelola pembagian pada alokasi sumber daya base-station secara remote.

Gambar 1: Arsitektur 4G LTE (Long Term Evolution)

Pada arsitertur jaringan LTE (gambar 1) terdapat beberapa bagian (node) yang memiliki control plane dan data plane dengan fungsi tertentu. Diantara bagian-bagian tersebut adalah: 1. Base-station (eNodeB): berfungsi menghubungkan UE (user equipment) pada jaringan LTE dan meneruskan paket data dari UE kepada jaringan dan sebaliknya. 2. S-GW (Serving Gateway) : sebagai pusat mobilitas UE. Bagian ini selalu memonitor pergerakan UE serta bertugas mengalokasikan frekuensi dan alamat IP. 3. P-GW (Paket Data Gateway) : berfungsi mengatur parameter QoS dan memonitor trafik data yang masuk pada jaringan. Selain itu juga bertugas untuk mengubungkan UE kepada jaringan internet dan jaringan seluler yang lain.

Secara sederhana jaringan LTE dapat disederhanakan seperti gambar dibawah ini (gambar 2) :

Gambar 2 : Arsitertur jaringan LTE secara sederhana

Penerapan SDN pada jaringan seluler akan memberikan solusi dari beberapa masalah utama yang terjadi pada jaringan. Berikut ini adalah beberapa keuntungan yang didapatkan dari penerapan SDN: 1. SDN memberikan proses klasifikasi paket data yang masuk pada jaringan dan memberikan kempuan routing secara fleksibel. Operator dapat memonitor semua trafik secara real-time dan efektif. 2. SDN memberikan protokol yang dapat bekerja pada teknologi seluler yang berbeda sehingga membuat proses mobility management menjadi jauh lebih mudah. 3. SDN memungkinkan proses distribusi parameter QoS dan kebijakan keamanan menggunakan firewall. 4. SDN membuat penerapan jaringan virtual pada jaringan seluler menjadi mudah dengan cara membagi flow-space pada paket headers. 5. SDN dapat memusatkan proses kontrol dari beberapa base-station sehingga dapat menghemat daya listrik dan alokasi radio channel yang digunakan. Dibutuhkan empat ekstensi utama yang perlu ditambahan pada jaringan seluler untuk proses penerapan SDN. Penambahan ekstensi tersebut akan mengubah bentuk arsitektur jaringan seluler seperti berikut ini (Gambar 3):

Gambar 3 : Arsiterkur jaringan SDN seluler

Keempat ekstensi tersebut adalah: 1. Kontroler : Membuat parameter aturan dan kebijakan dalam hal atribut pelanggan. 2. Aplikasi Switch : Local control agent. 3. Perangkat Switch : Memproses dan melakukan klasifikasi paket data secara flesibel berdasarkan header. 4. Base Station : BTS harus mendukung remote control untuk mengatur alokasi sumber daya pada jaringan virtual serta berfungsi untuk manajemen cell secara fleksibel. 3. Kesimpulan Teknolologi SDN dapat membuat jaringan seluler yang kompleks menjadi lebih sederhana dan lebih mudah untuk diatur. Selain itu juga akan memberikan peluang kepada operator untuk membuat berbagai layanan baru kepada pelanggan yang dapat dioperasikan pada jenis jaringan nirkabel yang lain. 4. Referensi E. Li et al.., “Toward Software-Defined Cellular Networks,” Proc. EWSDN, Darmstadt, Germany, 2012.

Deployment and Operation of Wide Area Hybrid Openflow Network Galih Nugraha Nurkahfi Abstrak Pendekatan untuk membangun hybrid wide-area OpenFlow network adalah sesuatu hal yang penting untuk pembangunan secara bertahap dari teknologi OpenFlow ke WAN yang sudah eksis sebelumnya, karena sangat tidak praktis dan efisien untuk membangun wide-area network dengan teknologi OpenFlow secara sekaligus. Disatu sisi yang lain, desain, deployment dan operasional sejenis hybrid OpenFlow network sering kali dibuat dengan intuisi tanpa pengetahuan teknis yang mendalam, dalam tulisan ini dibahas aspek teknis dan arsitektur dari hybrid OpenFlow network secara sistematis, berdasarkan pengalaman penulis paper dalam membangun testbed SDN bernama RISE (Research Infrastructure for large-Scale network Experiments) diatas JGN-X, sebuah testbed jaringan komputer berskala nasional di Jepang.

I. Introduction Teknologi SDN mempunyai beberapa kemampuan, yang menjadi keunggulan sehingga menjadikan teknologi ini menjadi teknologi jaringan komputer masa depan. Teknologi SDN menyediakan fleksibilitas dalam mengatur jaringan, teknologi ini menyediakan kemampuan untuk mengontrol packet forwarding dalam perangkat-perangkat switch dalam satu jaringan komputer yang berada dalam satu administrasi, secara terpusat melalui satu buah controller yang terpusat. Teknologi SDN juga menyediakan fitur untuk membuat slice logical network yang terpisah satu sama lain, yang mengakomodasi keberadaan production network dan experimental network dalam satu physical network. Kedua fitur diatas menyediakan kebutuhan bagi researcher dan developer dalam bidang Future Internet(FI) dan New Generation Network(NwGN) Tulisan ini membahas development dan deployment dari Research Infrastructure for Large Scale Network Experiment(RISE) yang dilakukan oleh beberapa institusi pendidikan dan riset di Jepang. Awalnya establishing testbed ini dilakukan di campus network, karena beberapa alasan: Kampus menyediakan environment percobaan yang lebih real dibandingkan dengan hanya enviromment laboratorium, dengan keberadaan traffic real yang ada. Skala jaringan kampus tidak terlalu besar sehingga lebih mudah dibuat dan dioperasikan. Namun dari sudut pandang deployment teknologi NwGN, network kampus memiliki keterbatasan dari segi skala, maka selanjutnya eksperimen ini dijalankan di lingkungan WAN yang mempunyai skala lebih besar, yaitu dibangun diatas JGN-X, yang merupakan pengembangan dari JGN network(japan gigabit network) yaitu testbed jaringan skala besar milik National Institute of Information and Communications Technology (NICT), yang dijalankan mulai dari tahun 1999, JGN-X sendiri merupakan suatu testbed jaringan yang khusus digunakan untuk mengembangkan NwGN.

Mengapa RISE memanfaatkan keberadaan testbed JGN-X ini, ada dua alasan untuk hal ini: Pihak developer testbed RISE Tidak usah membeli akses WAN yang mahal untuk ‘hanya’ membangun openflow testbed. Adanya keperluan untuk menjalankan hybrid network untuk mensimulasikan transisi dari traditional network ke OpenFlow network(OFN), dalam situasi ini openflow network dibangun diatas traditional network yang sebelumnya sudah ada. Selanjutnya dari hasil deployment dan operasi, maka selanjutnya pihak developer RISE membagi pengetahuan yang diperolehnya kepada pengelola REN(Research education network) yang lain. Untuk hal yang terkait dengan operasional testbed, Operasional dilakukan dengan memberikan network slice dan controller masing-masing kepada para researcher yang mempergunakan testbed ini, untuk menjalankan percobaan layanan.

II. Pertimbangan-pertimbangan untuk mendeploy dan menjalankan RISE Berikut adalah beberapa hal yang menjadi pertimbangan-pertimbangan untuk menjalankan testbed RISE Keamanan Membangun testbed yang digunakan bersama oleh para researcher di kampus harus memperhatikan aspek security, mengingat banyak orang yang mengakses sistem untuk berbagai macam kebutuhan development. Service continuity Teknologi baru yang dibangun, biasanya belum bisa dibuktikan kehandalannya untuk penerapan skala besar dan dalam jangka waktu gyanpanjang, teknologi testbed yang dideploy harus dipastikan bisa dijalankan secara berkelanjutan di sebuah environment jaringan berskala besar. Sisi ekonomi Membangun testbed memerlukan pembelian perangkat-perangkat baru yang mendukung teknologi SDN, dalam hal ini joint research dengan perusahaan yang memproduksi perangkat jaringan untuk menghemat pengeluaran dana, bisa dilakukan, cara ini akan memberikan keuntungan bagi kedua belah pihak, pihak vendor mendapatkan keuntungan dengan terujinya perangkat yang mereka produksi secara scientificsedangkan pihak researcher mendapatkan perangkat untuk keperluan riset secara 'gratis'. Keunggulan Openflow Menghadirkan fleksibilitas dan kemudahan dalam melakukan implementasi infrastruktur jaringan berbasis SDN diatas traditional network, memudahkan manajemen dari satu titik pusat kontrol dan keberadaan fitur network slicing memudahkan virtualisasi jaringan untuk berbagai macam keperluan. Pembangunantestbed harus bisa dilakukan dalam skala yang lebih besar dari sekedar network kampus, karena kelak teknologi ini, memang akan dijalankan diatas jaringan berskala besar, seperti internet ataupun WAN, maka dari itu dibuatlah testbed dengan skala wide area network yaitu RISE.

III. Kebutuhan teknologi untuk membangun Openflow network

di wide area network Berikut adalah apa saja yang diperlukan untuk membangun OpenFlow network dalam skala WAN Fungsi dari openflow Fungsi dasar dari openflow adalah menjalankan kontrol packet forwarding yang sangat fleksibel, namun disatu sisi openflow adalah teknologi yang masih terus berkembang dan memiliki berbagai macam masalah, dalam studi kasus pertama yang diujicobakan diatas OpenFlow network berskala WAN adalah advance traffic engineering. Setiap host di edge OFN menggenerate packet dan traffic engineeringnya dioperasikan oleh Openflow protocol. Tiap users di edge, diberikan akses satu atau lebih physical ports seperti yang terlihat pada gambar, tiap user diberikan satu identifier di layer 2 dengan menggunakan Vlan ID 802.1q vlan tags, dengan keberadaan vlan tags ini kita bisa membuat slicing network berdasarkan users. Vlan tags ini diatur oleh administrator OFN.

Teknik deployment pada openflow network Pada paper ini disebut suatu istilah yaitu Existing virtual network(EVN) untuk sebuah virtual network yang mengakomodasi OpenFlow network, dengan kata lain ini adalah tunnel yang dibuat diatas traditional physical WAN untuk menjalankan OpenFlow Network. Secara teknis tunnel ini yang akan membungkus frame layer 2 dari OpenFlow switch di edge ke OpenFlow switch lain di edge yang bersebrangan tanpa ada modifikasi frame etherent. Ada berbagai macam teknologi untuk menjalankan teknologi wide area ethernet ini, MPLS based atau Ethernet tunneling based, ip based dan lain sebagainya. Topologi tunnel yang dibuat untuk melakukan pemisahan adalah sebagai berikut, dimana dalam satu buah OpenFlow switch dibuat satu buah tunnel untuk memisahkan traffic antar user, hal ini untuk mencegah MAC address learning yang terlalu banyak, diagramnya bisa dilihat pada dua gambar di bawah ini.



OpenFlow packet kemudian diberi identitas tunnel dengan tiga kemungkinan cara seperti terlihat pada gambar dibawah ini.

Wide area Ethernet Ada berbagai macam teknik untuk menerapkan teknologi wide area ethernet, yaitu: i. 802.1q Tagged VLAN Menambahkan 12 bit vlan tag pada header Ethernet, ini adalah implementasi vlan yang umumnya diterapkan untuk segmentasi jaringan virtual . ii. 802.1ad Q-in-Q Melakukan tagging vlan pada frame yang sudah ditag, jadi dalam satu header frame ada dua buah tag vlan, yaitu tag outer dan tag inner. iii. Mac-in-Mac Enkapsulasi sebuah frame dengan header frame yang lain. iv. EoMPLS Ethernet over MPLS, merupakan teknologi (multi protocol label switching)MPLS Layer 2 atau disebut juga virtual private line services(VPLS). Dibawah ini adalah perbandingan antara teknologi-teknologi wide area ethernet, berdasarkan kondisi apakah seorang user dapat menggunakan vlan tagging atau tidak dan juga berdasarkan apakah EVN menjalankan MAC learning atau tidak.

IV. Desain dan deployment RISE Desain RISE Teknologi Ethernet untuk EVN, menggunakan Q-in-Q, 1 vlan untuk mengidentifikasi users ports dan satu

lagi untuk mengidentifikasi tunnel ID antara 1 buah OpenFlow switch ke EVN switch.

Arsitektur dasar RISE Dalam arsitektur dasar RISE, terdapat buah OpenFlow switch dan satu buah switch tradisional pada setiap site di testbed JGN, satu dari dua OpenFlow switch disebut edge OpenFlow switch(E-OFS) dan yang lain disebut distribution Openflow switch(D-OFS)

E-OFS menyediakan koneksi langsung ke user dan menyediakan vlan tagging per user port, frame yang keluar dari E-OFS dan masuk ke D-OFS diberikan vlan tagging sekali lagi dan terbentuklah tunnel antar user domain antar site yang berbeda.

Topologi Rise Berikut adalah gambar topologi RISE yang dibangun diatas testbed JGN-X, gambar topologi ini, hanya menampakan OpenFlow network di sisi edge saja, dari sini bisa kita lihat site-site RISE ada diberbagai kota-kota yang ada di jepang, dan satu site lagi ada di Los Angles Amarika serikat.

V. Kesimpulan Dalam paper ini dikemukakan design, teknologi dan pengembangan RISE, wide area OpenFlow network testbed Pengembangan testbed selanjutnya : Penggunaan MPLS untuk teknologi Tunneling di WAN. Peningkatan Penggunaan dari masing-masing slices jaringan SDN. OpenFlow testbed inter-connections.

VI. Referensi Yoshihiko Kanaumi, Shu-ichi Saito, Eiji Kawai, "Deployment and Operation of Wide-area hybrid Openflow Networks", in IEEE/IFIP 4th Workshop on Management of the Future Internet, 2012