BAB 3 PERANCANGAN SIMULASI

Transkripsi

1 BAB 3 PERANCANGAN SIMULASI Bab ini membahas mengenai keseluruhan metode simulasi yang digunakan pada Tugas Akhir ini. Simulasi dilakukan dengan menggunakan ns-2 versi 2.33 yang dijalankan di atas Cygwin. Gambar 3.1 menunjukkan proses simulasi tersebut : Gambar 3.1 Diagram simulasi 3.1 Simulator ns-2 Ns-2 merupakan simulator discrete event, di mana laju pertambahan waktu bergantung pada waktu terjadinya suatu event yang telah diatur oleh scheduler. Event pada ns-2 adalah sebuah objek pada hierarki C++ yang memiliki ID unik, waktu penjadwalan tertentu, dan pointer ke suatu objek yang mengatur event tersebut. Ns-2 berbasis pada dua bahasa pemrograman : C++ yang digunakan sebagai simulator berbasis objek, dan interpreter Otcl (ekstensi Tcl berbasis objek) yang digunakan untuk menjalankan skrip user. Ada beberapa tahap dalam membuat simulasi pada ns-2 : 18

2 Inisialisasi dan terminasi simulator ns Inisialisasi dilakukan dengan mendeklarasikan suatu variabel baru sebagai instance dari kelas Simulator pada awal skrip tcl yang digunakan. Ini bertujuan agar seluruh metode kelas Simulator dapat digunakan dalam merancang simulasi. Kemudian, untuk mengakhiri simulasi, dilakukan pemanggilan prosedur finish pada waktu simulasi yang diinginkan. Pendefinisian node jaringan, link, metode antrian, dan topologi Pendefinisian link dilakukan setelah mendefinisikan node jaringan untuk menghubungkan node-node tersebut. Tiap link dapat diatur untuk menggunakan link satu arah atau link dua arah. Pendefinisian link juga mencakup metode penanganan overflow antrian paket di link tersebut. Selanjutnya, didefinisikan mengenai mekanisme perutean trafik dari node pengirim ke node penerima. Pendefinisian agen dan aplikasi yang digunakan Agen dan aplikasi digunakan untuk menjalankan trafik yang akan disimulasikan. Trafik dihasilkan oleh komponen aplikasi tertentu, yang kemudian dijalankan oleh agen. Ada dua tipe dasar aplikasi di ns-2 : traffic generator dan komponen aplikasi tersimulasi. Traffic generator menghasilkan trafik dengan selang waktu antar paket mengikuti pola distribusi tertentu, misalnya pareto dan eksponensial. Untuk aplikasi tersimulasi, ns-2 menyediakan aplikasi FTP dan telnet. Agen merupakan representasi endpoint penghasil ataupun penerima paket layer network. Agen juga digunakan di dalam implementasi protokol pada berbagai layer. Agen tersebut kemudian dihubungkan pada node tertentu yang telah dibuat, sehingga node tersebut dapat menjadi penerima/pengirim trafik aplikasi tertentu. Membuat penjadwalan event simulasi Setiap event di dalam simulasi harus dijadwalkan waktu kejadiannya. Penjadwalan tersebut dapat dilakukan secara otomatis (misalnya dengan menggunakan random variable generator) atau secara manual. 19

3 3.2 Pemodelan INHERENT Detail topologi INHERENT yang digunakan Penulis dalam Tugas Akhir ini dapat dilihat pada Lampiran 1. Setiap node yang terdapat pada peta tersebut merupakan sebuah domain. Yang dimaksud dengan domain berkaitan dengan multicast tersebut adalah sekumpulan link dengan router-router yang dikelilingi oleh border multicast router[1]. Setiap domain memiliki kebijakan administratif terhadap jaringannya sendiri, yang bersifat otonom terhadap domain lain. Dalam Tugas Akhir ini, policy routing yang diterapkan masing-masing node INHERENT (melalui konfigurasi BGP) tidak dimasukkan. Hal ini untuk menyederhanakan kompleksitas simulasi. Pada ns-2, penomoran node dimulai dari angka 0. Oleh karena itu, dilakukan translasi nama node INHERENT ke dalam bentuk numerik. Pemetaan nomor node model yang digunakan di dalam simulasi terhadap nama node sebenarnya, sebagai referensi untuk skrip tcl yang dibuat Penulis di bagian lampiran : Tabel Pemetaan nomor node terhadap nama node INHERENT No. Node 0 Banda Aceh 1 Medan 2 Padang 3 Jambi 4 Pekanbaru 5 Bengkulu 6 Palembang 7 Bandar Lampung 8 Serang 9 Jakarta (UI) 10 Jakarta (DIKTI) 11 Bandung 12 Semarang 13 Jogja 14 Surabaya 15 Malang No. Node 16 Pontianak 17 Palangkaraya 18 Banjarmasin 19 Samarinda 20 Makassar 21 Kendari 22 Palu 23 Gorontalo 24 Manado 25 Denpasar 26 Mataram 27 Kupang 28 Ternate 29 Ambon 30 Manokwari 31 Jayapura Gambar 3.2 merupakan visualisasi model INHERENT. Legenda pada gambar tersebut menunjukkan keterangan kapasitas tiap-tiap link INHERENT. 20

4 Gambar Visualisasi model INHERENT Pemodelan fisik INHERENT dideskripsikan Penulis di dalam file topologi.tcl (Lampiran 6). skrip Seluruh link simulasi menggunakan mode duplex karena bersifat link dua arah. Pendefinisian link dalam bentuk numerik yang digunakan dalam penelitian ini ditampilkan pada Tabel 3.2. Tabel Pemetaan link INHERENT yang digunakan pada penelitian ini No. Link Node Terhubung

5 Node riil di Internet memiliki manajemen antrian serta penjadwalan dalam menangani aliran paket yang melalui node tersebut. Pada ns-2, antrian (qeueuing) menunjukkan lokasi di mana paket dapat ditahan sementara ataupun langsung didrop. Penjadwalan paket merujuk pada proses pemilihan paket mana yang harus dilayani (diforward) atau yang harus didrop. Di samping itu, terdapat juga manajemen buffer paket, yang merupakan metode pengaturan okupansi dari suatu antrian paket tertentu. Pada penelitian ini, metode manajemen buffer yang digunakan adalah metode drop tail. Drop tail merupakan metode manajemen buffer yang paling sederhana, di mana paket yang datang pertama kali akan lebih dahulu dilayani, atau sering disebut FIFO (first in first out). Apabila ada paket yang datang saat buffer sedang penuh, maka paket tersebut akan langsung didrop. Metode drop tail ini dipilih Penulis karena dalam penelitian ini, tidak dilakukan pembahasan mengenai pengaruh penerapan QoS (quality of service) pada pengujian mulicast. Untuk mengukur delay per link INHERENT, Penulis menggunakan paket ICMP untuk melakukan pengetesan pada jaringan nyata INHERENT. Pertama, Penulis menggunakan traceroute untuk mengetahui jalur yang akan ditempuh ke suatu node INHERENT. Kemudian, dilanjutkan dengan melakukan ping sebanyak 20 paket ke setiap node yang dilalui traceroute tersebut, mengambil selisih waktu rata-rata RTT (round trip time) ping untuk dua node yang berjarak satu hop, dan membagi dua. Nilai tersebut diambil sebagai delay link yang digunakan sebagai parameter dalam pemodelan ini. Seperti dijelaskan pada Bab 2, perutean multicast bergantung kepada tabel routing yang digunakan oleh routing unicast pada router tersebut. Pada ns-2, tabel routing unicast per node tersebut dihitung dengan menggunakan algoritma SPF (shortest path first) dari Dijkstra[6] sebelum simulasi trafik dijalankan. Error rate pada jaringan juga disimulasikan dalam penelitian ini. Untuk link satelit, diskenariokan bahwa error yang terjadi dilakukan berdasarkan distribusi uniform dengan nilai maksimum sebesar 20%. Untuk link E2, digunakan pemodelan error 22

6 serupa, dengan nilai maksimum mencapai 5%. Untuk link STM-1, medium fisik yang digunakan adalah serat fiber. Karena error rate pada medium tersebut cukup kecil, maka error rate pada link tipe medium tersebut tidak disimulasikan. Parameter lengkap dari simulasi error pada tiap link dapat dilihat pada Lampiran Simulasi Multicast Ns-2 memerlukan beberapa persyaratan dari kelas Simulator sebelum membuat topologi. Maka, setiap file tcl simulasi multicast dimulai dengan perintah berikut : set ns [new Simulator] $ns multicast Pengalokasian alamat grup multicast dilakukan secara otomatis oleh ns-2 dengan menggunakan perintah set group [Node allocadr]. Seluruh simulasi yang dilakukan pada penelitian ini menggunakan satu buah grup multicast saja. Hal ini untuk memudahkan melakukan analisis. Aplikasi yang menggunakan multicast serta agen protokol transport yang dipasangkan ke node pengirim dan node penerima. Aplikasi multicast yang digunakan dalam penelitian ini adalah aplikasi trafik CBR (Constant Bit Rate) untuk mensimulasikan aplikasi video conference sebagai aplikasi yang paling banyak memanfaatkan metode multicast. Protokol transport yang digunakan adalah UDP. Alamat tujuan dari trafik tersebut adalah alamat grup multicast yang ditentukan secara otomatis oleh ns-2. Untuk mensimulasikan adanya noise acak pada waktu pengiriman paket, maka flag random_ aplikasi CBR diaktifkan. Node penerima multicast dikonfigurasi menggunakan agen LossMonitor. LossMonitor merupakan suatu agen penerima paket yang menyimpan statistik tentang trafik yang menuju agen tersebut, baik paket yang diterima maupun paket yang hilang. Implementasi multicast di ns-2 mengasumsikan link bersifat duplex. Agar dapat mengetahui dari arah link mana suatu paket diterima, simulator multicast mengkonfigurasi link dengan pemberi label interface pada ujung tiap link, di mana paket akan dilabeli dengan suatu ID yang unik. Kemudian, yang disebut sebagai incoming interface adalah interface yang menerima paket dengan ID unik tersebut. 23

7 Multicast adalah metode pengiriman trafik dari sumber trafik ke suatu kelompok penerima. Sumber trafik tersebut dapat berjumlah satu atau lebih. Apabila hanya terdapat satu pengirim trafik multicast, maka disebut transmisi multicast one-to-many. Apabila terdapat sekelompok sumber pengirim pada suatu grup multicast tertentu, maka disebut transmisi multicast many-to-many. Kondisi terburuk dari mode many-tomany adalah seluruh node berperan sebagai sumber sekaligus penerima. Sesuai dengan penjelasan di atas, skenario simulasi yang digunakan di dalam penelitian ini ada dua, yaitu simulasi trafik multicast one-to-many dan many-to-many. Kedua skenario tersebut dikenakan terhadap simulasi BGMP dan simulasi PIM-SM, sehingga keseluruhan terdapat empat skenario simulasi yang dilakukan. Simulasi dalam penelitian ini terbatas pada pengiriman trafik multicast sesuai dengan protokol routing multicast yang digunakan. Event yang berkaitan dengan protokol yang berkaitan dengan metode keanggotaan node penerima (IGMP ataupun MLD) tidak disimulasikan Simulasi PIM-SM Simulasi protokol PIM-SM di ns-2 dilakukan dengan menggunakan centralized multicast[6]. Keterbatasan implementasi protokol ini di ns-2 adalah tidak disimulasikannya proses pembangunan koneksi multicast, seperti pengiriman paket Join dan Prune. Komponen terpenting dari simulator centralized multicast adalah sebuah agen komputasi terpusat (centralized computation agent). Agen tersebut digunakan untuk membuat pohon forwarding serta rute multicast untuk keseluruhan topologi. Setiap agen CtrMcast akan memproses perintah berkaitan dengan keanggotaan grup secara dinamis, dan meneruskannya ke agen komputasi terpusat untuk membuat ulang rute multicast. Dalam implementasi di dunia nyata, pertukaran informasi routing multicast antar domain dilakukan dengan menggunakan MBGP. Tujuan pertukaran informasi routing multicast tersebut adalah untuk membentuk pohon distribusi multicast antar domain. Karena simulator multicast ns-2 melakukan penghitungan rute multicast dengan menggunakan agen komputasi terpusat sebelum simulasi dimulai, maka MBGP tidak digunakan di dalam Tugas Akhir ini. 24

8 Setiap node INHERENT diasumsikan tidak memiliki RP sendiri, sehingga menggunakan suatu RP terpusat. Meskipun kondisi ini bertentangan dengan konsep otonom pada domain, namun kondisi INHERENT yang merupakan jaringan pendidikan berbeda dengan kondisi interkoneksi ISP komersial yang masingmasingnya saling berkompetisi. Dengan adanya suatu RP terpusat ini, maka dapat diasumsikan bahwa penggunaan MSDP tidak diperlukan. Ns-2 tidak dapat melakukan pemilihan RP secara otomatis. Sehingga, pemilihan RP harus dilakukan secara manual. RP yang digunakan adalah node 11. Pemilihan ini didasarkan pada lokasi node tersebut yang terletak di tengah topologi INHERENT. Pemilihan node 11 sebagai RP tersebut tidak berarti bahwa node 11 merupakan RP yang paling optimal. Hal tersebut untuk kesamaan seluruh simulasi saja, disamping adanya keterbatasan ns-2 yang belum mendukung fitur auto RP. Pemilihan RP yang paling optimal tidak dibahas di dalam penelitian ini, karena berada di luar batasan masalah. Cara untuk mengaktifkan routing centralized multicast adalah berikut : set mproto CtrMcast set mrthandle [$ns mrtproto $mproto] Untuk mengkonfigurasikan RP secara statik, digunakan perintah berikut : $mrthandle set_c_rp $n(11) Dalam Tugas Akhir ini, tidak dilakukan pembahasan mengenai skenario adanya kegagalan pada RP. Oleh karena itu, tidak diperlukan pengkonfigurasian kandidat RP Simulasi BGMP Protokol BGMP disimulasikan di ns-2 dengan memanfaatkan BST.tcl[6] yang telah disediakan ns-2. File tersebut tidak secara khusus mensimulasikan protokol BGMP. Namun karena Tugas Akhir ini memfokuskan pada pembahasan pembentukan pohon distribusi multicast, di mana BGMP menggunakan mode BST, maka penggunaan BST.tcl sudah memenuhi kebutuhan yang diperlukan dalam Tugas Akhir ini. Fungsi pengalokasian alamat multicast yang dilakukan oleh MASC pada implementasi dunia nyata telah dilakukan oleh ns-2 secara otomatis. Oleh karena itu, MASC tidak digunakan di dalam simulasi. 25

9 Metode BST pada diaktifkan dengan perintah berikut : $ns mrtproto BST Pemilihan root domain BGMP dilakukan secara statik. Untuk memudahkan perbandingan kinerja dengan PIM-SM, root domain tersebut diletakkan pada node 11. Untuk mendefinisikan root domain secara statik, digunakan perintah berikut : BST set RP_($group) $n(11) Skenario Trafik Multicast One-to-Many Skenario ini untuk mensimulasikan trafik multicast dari satu sumber ke banyak penerima. Contoh dari trafik one-to-many adalah aplikasi pendistribusian file secara multicast. Skenario one-to-many pada Tugas Akhir ini menggunakan node sumber yang sama, yaitu node 14, untuk semua simulasi skenario ini. Node 14 akan mulai mengirimkan trafik multicast sejak detik 0 waktu simulasi. Pada skenario ini, semua node INHERENT akan menjadi penerima trafik multicast dari node 14. Setiap node akan bergabung ke dalam grup multicast secara urut, mulai dari node 0 sampai dengan node 31. Selisih masuk grup setiap node berurutan adalah 0,5 detik waktu simulasi. Skenario tersebut diimplementasikan dengan konfigurasi berikut pada Lampiran 2 dan 3 : set z 1 for {set i 0} {$i <= 31} {incr i} { $ns at [expr 0.5 * $z] "$n($i) join-group $rcvr $group" incr z } Hal yang sama juga berlaku saat seluruh node mengakhiri penerimaan trafik multicast. Dimulai pada detik 40 waktu simulasi, node 0 diikuti secara berurutan oleh node selanjutnya akan meninggalkan grup multicast dengan selang waktu 0,25 detik. Implementasi skenario tersebut pada Lampiran 2 dan 3 : set z 1 for {set i 0} {$i <= 31} {incr i} { $ns at [expr * $z] "$n($i) leave-group $rcvr $group" incr z } Skenario Trafik Multicast Many-to-Many Contoh dari trafik many-to-many adalah untuk aplikasi video confrerence. Skenario many-to-many dalam Tugas Akhir ini mensimulasikan skenario terburuk dalam 26

10 pengiriman trafik multicast, yaitu bahwa semua node akan berperan sebagai penerima trafik multicast, sekaligus juga sebagai penerima trafik dari node lain. Namun, Penulis mengalami kegagalan dalam menskenariokan seluruh node untuk menjadi sumber multicast. Ns-2 mengalami error apabila node 31 disertakan sebagai sumber multicast. Oleh karena itu, skenario many-to-many dalam penelitian ini menjadikan node 0 sampai dengan node 30 sebagai sumber trafik multicast. Pada simulasi skenario ini, semua node sumber multicast dijalankan bersamaan pada waktu yang sama, yaitu detik 0 waktu simulasi. 3.4 Trafik Latar Trafik latar merupakan simulasi trafik unicast yang ada di INHERENT, yang menjadi pengiring trafik multicast. Ada dua tipe protokol transport yang digunakan di dalam trafik latar, yaitu protokol UDP dan TCP. Karena Penulis tidak bisa mendapatkan data lengkap statistik trafik INHERENT, maka Penulis membuat trafik latar berdasarkan [8], yang disesuaikan dengan kondisi di INHERENT. Dalam menjalankan trafik latar ini, digunakan variabel acak untuk menentukan waktu mulai pengiriman trafik dan waktu berhentinya, serta pemilihan node sumber dan node penerima, dengan mengikuti distribusi uniform. Variabel acak tersebut diperoleh dengan menggunakan fitur RNG (Random Number Generator) yang disediakan ns- 2[7] Trafik Berbasis UDP Waktu mulai simulasi trafik UDP di antara rentang waktu detik 1 sampai dengan detik 15. Kemudian, waktu selesai simulasi trafik UDP di antara selang detik 35 sampai dengan detik 45. Ada dua jenis trafik UDP yang digunakan Penulis dalam penelitian ini, yaitu trafik UDP berbasis distribusi eksponensial dan trafik UDP berbasis distribusi pareto. Detail konfigurasi trafik latar UDP dapat dilihat pada Lampiran 8. Trafik UDP Eksponensial Trafik eksponensial akan menghasilkan trafik berdasarkan distribusi eksponensial on/off. Paket dikirimkan dengan rate konstan selama selang waktu on, dan tidak ada paket yang terkirim selama selang waktu off. Selang waktu on dan off tersebut ditentukan berdasarkan distribusi eksponensial. 27

11 Pada penelitian ini, ukuran paket trafik eksponensial dibuat konstan sebesar 256 byte, dengan rate sebesar 512 kb. Rata-rata waktu on (burst time) generator diset 100 ms, dengan rata-rata waktu off (idle time) sebesar 50 ms. Pengirim dan penerima trafik UDP eksponensial dipilih sedemikian rupa sehingga setiap link mendapatkan aliran tipe trafik ini. Terdapat 10 buah node sumber,dan 13 node penerima, di mana setiap node sumber akan mengirimkan trafik ke seluruh node penerima. Trafik UDP Pareto Seperti halnya trafik eksponensial, trafik pareto menghasilkan trafik dengan metode on/off yang nilainya diambil dari distribusi pareto. Variabel shape yang digunakan untuk distribusi pareto ini adalah 1,5. Parameter trafik pareto lain yang digunakan dalam penelitian ini juga sama dengan parameter trafik eksponensial. Pengirim dan penerima trafik UDP eksponensial dipilih sedemikian rupa sehingga setiap link mendapatkan aliran trafik ini. Terdapat 10 buah node sumber,dan 16 node penerima, di mana setiap node sumber akan mengirimkan trafik ke seluruh node penerima. Node pengirim didesain berbeda dengan node pengirim trafik eksponensial Trafik Berbasis TCP FTP (file transfer protocol) digunakan sebagai aplikasi trafik berbasis TCP. Agen TCP yang digunakan adalah agen TCP Linux, yang merupakan implementasi TCP pada kernel Linux. Agen TCP Linux tersebut dipilih karena sebagian besar aplikasi FTP dijalankan di atas server dengan operating system GNU/Linux. Waktu mulai koneksi FTP dibuat secara acak antara detik 5 sampai dengan detik 25. Waktu selesai koneksi dipilih di dalam rentang detik 30 sampai 40. Detail konfigurasi trafik latar TCP dapat dilihat di lampiran 9. 28