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 nonIP 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 ?
Ya
Tidak
Simpan pesan di antrian, ajukan permitaan rute
Penerusan pesan
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 RERR
Pesan RREQ Pesan RREP
Update rute ke pengirim (jika ada)
Update tabel rute, prekursor & daftar keluar
Menghapus rute yang terkena
Tujuan ?
Pengirim ?
Setidaknya satu dihapus?
Ya
Tidak Tidak
Ya
Ya Memiliki rute “fresh enough” ?
Ya
Mengirim RREP
Penerusan RREP ke hop selanjutnya
Mengirim pesan antrian
Penerusan RREP ke prekursor
Tidak
Jika tidak ada buffer penerusan RREQ ke neighbors
Tidak
Berhenti
Gambar 3.4. Proses Menerima Event (http://jist.ece.cornell.edu/docs/040421swans-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
off) (Tergantung pada log_to_file_ setting) unidir_hack_
Mendeteksi dan menghindari link searah
wait_on_reboot_
15 detik menunggu direboot delay
internet_gw_mode_
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. Yakni, 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 "ns2.26/tcl/lib/ns default.tcl".
