BAB III ANALISA DAN PERANCANGAN 3.1 ANALISA PERANCANGAN MODE GATEWAY Mode Gateway pada penelitian ini terdiri dari satu buah gateway yang terhubung dengan satu buah host dan satu buah router dengan media penghubung adalah kabel atau wired dapat di lihat pada Gambar 3.1. gw rtr hs Gambar 3.1. Model Jaringan Kabel (Wired) Dibuat juga script untuk konfigurasi gateway pada jaringan ad hoc hybrid. Tujuan dari pembuatan script ini adalah agar semua paket data dari node yang berada pada jaringan ad hoc bisa diteruskan ke jaringan infrastruktur (LAN atau internet) dan sebaliknya. 3.2 ALGORITMA GATEWAY AODV-UU Algoritma gateway merupakan dasar sistem bekerjanya mode gateway pada AODV-UU yang berasal dari file aodv_rreq, aodv_rrep, dan aodv_rerr. Berikut akan dijelaskan bagaimana algoritma gateway pada protokol routing AODV-UU: 1) Membuat RREQ - node asal menyebarkan RREQ 2) Menerima RREQ - jika bukan RREQ yang sama a. buat reserve router ke node asal - jika node tidak memiliki rute ke tujuan 31
32 a. menyebar ulang (rebroadcast) RREQ b. tinggikan (increment) hop count - jika node memiliki rute ke tujuan a. buat RREP b. unicast RREP 3) Menerima RREP - jika hop count RREP lebih kecil dari yang ada pada tabel routing - atau jika destination sequence pada tabel routing lebih kecil dari RREP a. perbaharui tabel routing - jika node bukan node tujuan a. reunicast RREP dengan memanfaatkan reverse route b. tinggikan (increment) hop count 4) Membuat RERR - jalur (link) terputus atau node berada diluar jangkauan a. node menyebarkan RERR 5) Menerima RERR - untuk semua node tujuan yang tidak dapat dijangkau a. jika next hop adalah sumber RERR, perbaharui tabel routing - jika terdapat rute ke node tujuan tidak dapat dijangkau a. sebarkan RERR 3.3 PROSES GATEWAY PADA AODV-UU Proses gateway pada AODV-UU akan dijelaskan proses apa saja yang akan terjadi, yaitu proses gateway pada AODV-UU yang berasal dari jaringan wired ke jaringan ad hoc. Penanganan paket pada AODV-UU serta paket data dan pesan kontrol AODV ditangani secara terpisah. 3.3.1 Penanganan Paket
33 Penanganan paket (packet handling) AODV-UU mampu membedakan antara paket data dan pesan kontrol AODV, dan menanganinya secara terpisah menggunakan modul perangkat lunak yang berbeda. Gambar 3.2. Penanganan paket pada AODV-UU. Paket data dan pesan kontrol AODV ditangani secara terpisah. 3.3.2 Kedatangan Paket Ketika sebuah paket melintasi stack protokol, paket tersebut ditangkap oleh netfilter hook yang telah diatur oleh modul kernel AODV-UU, kaodv. Paket non- IP selalu diterima, karena paket ini tidak memiliki hubungan dengan AODV-UU. Umumnya paket yang dibangkitkan selalu diantrikan, sebab sebuah rute harus ditentukan. Kontrol pesan AODV yang masuk juga selalu diterima, karena paket ini yang akan diproses pada soket UDP yang terpisah. Sedang paket yang masuk dalam antarmuka jaringan (network interface) lainnya, tetapi tidak diproses kemudian.
34 3.3.3 Pemrosesan Paket Jika paket yang masuk adalah kontrol pesan AODV, verdict yang diterima dikembalikan ke modul libpq sehingga paket tersebut akan berakhir di soket UDP kontrol pesan AODV, diterima atau dikirim keluar, tergantung dari kondisi paket tersebut apakah paket incoming atau outgoing. 3.3.4 Pemrosesan Paket Data Jika tujuan dari paket (ditentukan oleh alamat IP tujuan) adalah host yang sedang dikunjungi, maka paketnya merupakan paket broadcast, atau mode internet gateway telah di-enable-kan dan paket bukan merupakan paket broadcast, maka paket akan diterima. Ini berarti bahwa paket dalam kondisi seperti ini akan ditangani layaknya paket biasa oleh sistem operasi. Selanjutnya, paket akan diteruskan, dimasukkan dalam antrian atau dibuang. Tabel routing internal dari AODV-UU digunakan untuk mengecek apakah rute yang aktif sekarang masih ada atau tidak. Jika rute masih ada, maka paket di-set dan diteruskan ke hop berikutnya. Dalam hal ini, paket di-generate secara lokal. ID paket yang unik daberikan dan akan digunakan untuk antrian paket yang tidak langsung sampai AODV-UU memutuskan sebuah aksi, dan route discovery dibuat. Jika paket tidak dibangkitkan (generate) secara lokal, dan tidak ada rute yang ditemukan, maka paket akan dibuang dan pesan RRER dikirimkan ke sumber. 3.3.5 Pemrosesan AODV Control Message AODV control message diterima pada soket UDP (port 654) dan selanjutnya diproses. Tipe dari field AODV diperiksa, pesan dikonversi menjadi tipe message corresponding, dan selanjutnya fungsi correct handler dijalankan.
35 3.3.6 Pengiriman AODV Control Message Setiap AODV control message yang dibangkitkan oleh AODV-UU dikirimkan pada soket UDP. Ketika pesan ditangkap oleh netfilter untuk membangkitkan paket secara local kembali, NF_IP_LOCAL_OUT, diantrikan oleh kernel AODV dan diterima oleh modul packet_input dari AODV-UU melalui libpq. Modul packet_input akan mengembalikan sebuah message kembali libpq, dan paket selanjutnya akan ditangkap oleh post-routing dari netfilter, NF_IP_POST_ROUTING. Paket tersebut akan kembali diarahkan untuk memastikan penggunaan informasi routing, dan dikirim keluar oleh sistem. 3.3.7 Proses AODV Mengirim Permintaan Proses mengirim permintaan pada AODV-UU, akan dimulai dengan menanyakan rute apa yang tersedia. Jika, ada rute yang tersedia maka AODV-UU akan melakukan proses penerusan pesan. Sedangkan jika rute tidak tersedia maka akan menyimpan pesan dalam antrian serta mengajukan permintaan rute. Proses mengirim permintaan Rute yang tersedia? Penerusan pesan Simpan pesan di antrian, ajukan permitaan rute Berhenti Gambar 3.3. Proses Mengirim Permintaan (http://jist.ece.cornell.edu/docs/040421-swans-aodv.pdf)
36 3.3.8 Proses AODV Menerima Event Pada proses AODV-UU menerima event akan melakukan pengecekan jenis pesan, yang selanjutnya pesan tersebut dipecah berdasarkan jenis pesanya. Setelah proses pengecekan jenis pesan maka pesan terebut akan memperbarui rute ke pengirim, memperbarui tabel rute, prekursor dan daftar keluar, serta menghapus rute. Proses menerima event Mengecek tipe pesan Pesan RREQ Pesan RREP Pesan RERR Update rute ke pengirim (jika ada) Update tabel rute, prekursor & daftar keluar Menghapus rute yang terkena Tujuan? Pengirim? Setidaknya satu dihapus? Memiliki rute fresh enough? Penerusan RREP ke hop selanjutnya Mengirim pesan antrian Penerusan RREP ke prekursor Mengirim RREP Jika tidak ada buffer penerusan RREQ ke neighbors Berhenti Gambar 3.4. Proses Menerima Event (http://jist.ece.cornell.edu/docs/040421- swans-aodv.pdf)
37 3.4 KONFIGURASI GATEWAY AODV-UU PADA OTcl Setiap agen routing AODV-UU misalnya (satu per mobile node) dikonfigurasi secara individual dengan menetapkan nilai-nilai variabel konfigurasi dari OTcl. Contoh: set mobilenode1_ [$ns_ node] ; # membuat mobile node $mobilenode1_ random-motion 0 ;# menonaktifkan gerak acak set r [$mobilenode1_ set ragent_] ;# mendapatkan agen routing $r set debug_ 1 ;# mengkonfigurasi agen routing $r set rt_log_interval_ 1000 $r set log_to_file_ 1 Ulangi prosedur ini untuk setiap mobile node dalam script skenario simulasi sesuai dengan yang dibutuhkan. Variabel-variabel konfigurasi yang tersedia adalah: debug_ Cetak pesan log pada output standar (stdout) expanding_ring_search_ Memperluas jangkauan untuk mencari RREQs hello_jittering_ Jittering pesan HELLO llfeedback_ Menggunakan link layer feedback yang bukan HELLOs local_repair_ Menggunakan perbaikan lokal log_to_file_ Menuliskan log pesan ke logfile optimized_hellos_ Hanya digunakan HELLOs ketika ada rute aktif ratelimit_ Menggunakan rate limiting untuk RREQs dan RERRs receive_n_hellos_ Menerima N HELLOs sebelum merawat sebagai neighbor (Harus ditetapkan untuk setidaknya 2 jika menggunakannya) rreq_gratuitous_ Berlaku beralasan Flag di semua RREQs rt_log_interval_ Secara periodik log routing tabel ke logfile routing tabel, nilai interval dalam msecs (0 =
38 unidir_hack_ wait_on_reboot_ internet_gw_mode_ off) (Tergantung pada log_to_file_ setting) Mendeteksi dan menghindari link searah 15 detik menunggu direboot delay Jalankan node ini sebagai gateway Jika tidak disebutkan, pengaturan variabel untuk 0 berarti "off" dan 1 berarti "on". Secara umum, nilai-nilai variabel-variabel ini harus ditetapkan sebelum simulasi dimulai. kni, sebelum "$ ns_run" baris pada akhir script OTcl. Harap dicatat bahwa tidak ada pengecekan error dilakukan pada nilai-nilai variabelvariabel ini. Mengubah ke nilai-nilai aneh dan dianulir kemungkinan akan memberikan hasil yang tidak diharapkan. Nilai default dapat ditemukan difile "ns- 2.26/tcl/lib/ns default.tcl".