UNIVERSITAS INDONESIA

i

UNIVERSITAS INDONESIA

Analisa Perbandingan Relokasi Rendezvous Point Pada Lingkungan Routing Multicast IPv6 Dengan Menggunakan Bootstrap Router Sebagai Pengatur Relokasi

TESIS Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister

FAHIM NUR CAHYA BAGAR 1006734842

FAKULTAS TEKNIK PROGRAM STUDI TEKNIK ELEKTRO UNIVERSITAS INDONESIA DEPOK 2012

Universitas Indonesia

Analisa perbandingan..., Fahim Nur Cahya Bagar, FT UI, 2012



iv

UCAPAN TERIMA KASIH

Segala puji syukur saya panjatkan kepada Allah Subhanahu wa Ta’ala, karena berkat

rahmat dan hidayah-Nya saya dapat menyelesaikan tesis ini.

Penyusunan tesis ini dilakukan dalam rangka memenuhi salah satu syarat untuk mencapai gelar Magister Teknik Program Studi Jaringan Informasi dan Multimedia pada Fakultas Teknik Universitas Indonesia. Saya menyadari bahwa tanpa bantuan dan bimbingan dari berbagai pihak, dari masa perkuliahan sampai pada penyusunan tesis ini, sangatlah sulit bagi saya untuk menyelesaikan tesis ini. Untuk itu saya mengucapkan terima kasih kepada: 1. Dr. Ir. Anak Agung Putri Ratna, M.Engselaku pembimbing yang telah berkenan meluangkan waktu untuk memberikan bimbingan, saran dan motivasi. 2. Dosen-dosen yang telah mengajarkan ilmu yang sangat bermanfaat. 3. Fauzi Bagar, Nur Asiyah dan Kamal Habibi Bagar selaku keluarga yang tiada hentinya memberikan doa, semangat dan motivasi dalam penyusunan tesis ini 4. Faisol Sidekan, Nasiatul Aisiyah dan Fariziyah Dwi Safitriyang menjadi bagian dari keluarga Penulis dan atas doa, semangat dan motivasi dalam penyusunan tesis ini. 5. Suyono, Ika Yuni Wulansari, dan Khansa Dzakiya Talita yang selalu menjadi keluarga bagi Penulis. 6. Bambi Dentaries Prilanda dan Tivany Angga Dewi yang memberikan motivasi agar penyusunan tesis ini cepat selesai. 7. Toshinori Takabatake dan Amit Bariek atas ide dan saran serta perhatian yang membuat tesis ini menjadi layak. 8. Teguh Imam Burhanuddin dan Elsa Ryan Ramdani teman kost yang selalu memberi dukungan terhadap Penulis. 9. Semua pihak yang tidak dapat Penulis sebutkan satu persatu, yang juga memberikan dukungan dalam penyelesaian tesis ini.



v

Namun demikian, sangat disadari masih terdapat kekurangan karena keterbatasan dan kendala yang dihadapi. Akhir kata, semogaAllah Subhanahu wa Ta’ala membalas kebaikan semua pihak yang telah membantu. Semoga tesis ini bermanfaat bagi perkembangan ilmu dan teknologi. Depok, 15 Januari 2012

Penulis




vii

Fahim Nur Cahya Bagar NPM 1006734842

Dosen Pembimbing Dr. Ir. Anak Agung Putri Ratna M.Eng. Departemen Teknik Elektro

Analisa Perbandingan Relokasi Rendezvous Point Pada Lingkungan Routing Multicast IPv6 Dengan Menggunakan Bootstrap Router Sebagai Pengatur Relokasi ABSTRAK IPv6 sudah semakin banyak digunakan. Segala kelebihan dari protokol internet sebelumnya telah dipunyai oleh IPv6. Hanya saja beberapa teknologi yang ada pada IPv4, tidak bisa serta merta diimplementasikan pada IPv6. Salah satu diantaranya adalah teknologi routing multicast dengan protokol PIM-SM. PIM-SM sendiri memiliki mekanisme dalam menemukan RP untuk lalu lalang trafik. Sayangnya teknologi ini tidak disertakan dengan relokasi RP yang bisa terjadi karena ada C-RP lainnya yang lebih layak walaupun penanganan terhadap failover didalamnya telah diterapkan. Oleh karena itu, diperlukannya penerapan relokasi RP yang dikhususkan pada lingkungan routing multicast IPv6, dimana relokasi tersebut bukan hanya tahan dengan adanya kegagalan pada RP tetapi juga mampu untuk menjaga QoS dan kualitas pada jaringan. Ide perelokasian RP yang ada sebelumnya tidak disertai dengan penjagaan terhadap pengiriman data ketika terjadi relokasi. Selain itu, juga tidak ada fleksibilitas dalam perelokasian RP dimana lokasi RP terbaik ditentukan oleh posisi terbaik berdasarkan optimalisasi jarak/hops pada setiap klien. Beban kerja RP selain sebagai tempat pertemuan aliran data, juga ditambah oleh pengendali relokasi Metode yang diusulkan dengan menambahkan tugas BSR sebagai pengendali relokasi untuk meringankan beban dari RP yang terpilih. Metode ini juga mampu memberikan fleksibilitas posisi relokasi yang dengan penambahan Threshold sebagai pemberian jarak terhadap posisi relokasi, lalu disertai pula dengan penjagaan terhadap pengiriman data ketika terjadi relokasi. Pada simulasi metode ini terlihat bahwa metode ini mampu mengurangi packet loss sampai dengan 54% untuk penghitungan bobot dengan Threshold rendah dan 39% untuk Threshold tinggi dibandingkan dengan proposal relokasi [Ying-Dar, 2002] dan [Sameer, 2009].

Kata Kunci:IPv6, Bootstrap Router, Relokasi Rendezvous Point, QoS, PIM-SM



viii

Fahim Nur Cahya Bagar NPM 1006734842

Counselor Dr. Ir. Anak Agung Putri Ratna M.Eng. The Department of Electrical Engineering

Rendezvous Point Relocation Analysis Comparison On IPv6 Routing Multicast Environment Using Bootstrap Router As Relocation Controller

ABSTRACT

Nowadays, IPv6 has been used widely. Any weakness from previous internet protocol has been overcome in IPv6. But, several technologies in IPv4 can not be implemented as easily as been before in IPv6. One of those is multicast routing with PIMSM protocol. PIM-SM already has its own mechanism to find RP for flowing traffic data. But, this technology itself is not bring its own relocation mechanism that can happen because there is another more suited C-RP though overcoming RP failure is already implemented. Because of those reasons, the needing of RP relocation implementation in special environment, which is IPv6 routing multicast environment, that can be robust to any failure of RP but also can maintain QoS of traffic and quality of network. Ideas to perform RP relocation has been researched since. However, when relocation is occured, it is not complemented with the ability to preserve packet that has been sent in those times. Also, there is no flexibility to choose new RP because new RP location is set from selecting the best position from calculating the best hops from each of its member. In addition to RP load as a rendezvous point for data flow, in previous relocation proposal, RP has task to control relocation process. Proposed method add BSR task as relocation controller to ease chosen RP task. This method also gives the flexibility to relocate RP using Threshold for the provision of selecting RP from several candidates who has close cost from best RP cost and also the ability to preserve packet that has been sent when relocation is occured. In this proposed method, as shown in simulation, it can decrease rate of packet loss up to 54% for low Threshold and 39% for high Threshold compared with previous relocation proposal [Ying-Dar, 2002] dan [Sameer, 2009].

Keywords: IPv6, Bootstrap Router, Rendezvous Point Relocation, QoS, PIM-SM



ix

DAFTAR ISI UCAPAN TERIMA KASIH .................................................................................. iv DAFTAR ISI .......................................................................................................... ix DAFTAR GAMBAR ............................................................................................. xi DAFTAR TABEL ................................................................................................ xiii DAFTAR SINGKATAN ..................................................................................... xiv PENDAHULUAN ................................................................................ 1 BAB 1 1.1 Latar Belakang ......................................................................................... 1 1.2 Rumusan Penelitian .................................................................................. 2 1.3 Batasan Penelitian .................................................................................... 3 1.4 Tujuan Penelitian ...................................................................................... 4 1.5 Metodologi Penelitian .............................................................................. 4 1.6 Sistematika Penulisan ............................................................................... 5 BAB 2 TINJAUAN PUSTAKA ....................................................................... 7 2.1 Internet Protocol Version 6 ...................................................................... 7 2.1.1 Header IPv6 ..................................................................................... 10 2.1.2 Prefiks Tipe Pengalamatan .............................................................. 13 2.2 Protokol Multicast .................................................................................. 14 2.2.1 Protocol Independent Multicast ...................................................... 17 2.2.2 PIM Sparse Mode ............................................................................ 18 Hash Function ................................................................................. 21 2.2.3 2.2.4 Mekanisme Bootstrap Router .......................................................... 22 2.2.5 Hybrid Bootstrap ............................................................................. 25 2.2.6 Proposal Relokasi RP ...................................................................... 28 2.2.7 User Mode Linux ............................................................................ 35 Python ............................................................................................. 35 2.2.8 BAB 3 RANCANGAN SISTEM .................................................................... 37 3.1 Kompilasi Sistem ................................................................................... 37 3.2 Perancangan Model Simulasi ................................................................. 37 3.3 Perancangan Model Aliran Paket ........................................................... 39 3.4 Perancangan Model Virtualisasi ............................................................. 49 3.5 Algoritma Relokasi ................................................................................. 52 3.6 Faktor Skenario Penelitian ..................................................................... 57 3.7 Kriteria Relokasi RP ............................................................................... 58 3.8 Posisi Penelitian ..................................................................................... 60 BAB 4 HASIL SIMULASI DAN ANALISA DATA .................................... 65 4.1 Simulasi Skenario PIM-SM.................................................................... 65 4.2 Simulasi Skenario PIM-SM Terhadap Perubahan Faktor ...................... 68 4.2.1 Faktor Perubahan Ukuran Paket...................................................... 68 4.2.2 Faktor Perubahan Jumlah Pengiriman Paket per Detik................... 70 4.3 Simulasi Skenario PIM-SM Dengan Relokasi ....................................... 72 4.4 Simulasi Skenario PIM-SM Dengan Relokasi Terhadap Perubahan Faktor Threshold ............................................................................................... 74 4.4.1 Faktor Threshold Rendah ................................................................ 74 4.4.2 Faktor Threshold Tinggi ................................................................. 79 4.5 Analisa Perbandingan Antara PIM-SM Tanpa Relokasi, PIM-SM Relokasi dan Hasil Simulasi.............................................................................. 84



x

BAB 5 KESIMPULAN ................................................................................... 86 BAB 6 DAFTAR ACUAN ............................................................................. 87 LAMPIRAN .......................................................................................................... 88



xi

DAFTAR GAMBAR Gambar 2.1 Projeksi dari Konsumsi Sisa Alamat IPv4 yang Dimiliki RIR [3] ..... 7 Gambar 2.2 Perbandingan Header IPv4 dan IPv6 [sumber: Juniper, Maret 2003]. 9 Gambar 2.3 Contoh Pengalamatan IPv6 ............................................................... 10 Gambar 2.4 Header Paket IPv6 ............................................................................. 11 Gambar 2.5 Skema Routing Paket ........................................................................ 15 Gambar 2.6 Format Alamat IPv6 Multicast [tcpguide.com]................................. 16 Gambar 2.7 Pendaftaran Anggota Multicast [4] ................................................... 19 Gambar 2.8 Pengiriman Paket ke Grup Multicast [4] ........................................... 20 Gambar 2.9 Shared RP-Tree dan Shortest Path Tree [4] ...................................... 21 Gambar 2.10 Mekanisme BSR.............................................................................. 23 Gambar 2.11 Hybrid Bootstrap Mechanism ......................................................... 26 Gambar 2.12 Bootstrap Mechanism ...................................................................... 26 Gambar 2.13 Hasil Simulasi Hybrid Bootstrap[6] ................................................ 28 Gambar 2.14 Rasio Beban Jaringan Dengan EEC [8] .......................................... 32 Gambar 2.15 Rasio Beban Jaringan Dengan EC [8] ............................................. 32 Gambar 2.16 Beban Pesan Kontrol Dengan EEC [8] ........................................... 32 Gambar 2.17 Beban Pesan Kontrol Dengan EC [8] .............................................. 32 Gambar 2.18 Waktu Relokasi RP [8].................................................................... 33 Gambar 2.19 Relokasi RP untuk Grup G.[10] ...................................................... 33 Gambar 2.20 Migrasi RP untuk Grup G.[10]........................................................ 34 Gambar 2.21 Efek Interval Lama Waktu Relokasi [10] ....................................... 35 Gambar 2.22 Contoh Kode Python Sederhana ..................................................... 36 Gambar 3.1 Model Topologi pada OMNeT++ ..................................................... 38 Gambar 3.2 Aliran Paket Pada Simulasi ............................................................... 40 Gambar 3.3 Aliran Protokol TCP.......................................................................... 41 Gambar 3.4 Candidate-RP-Advertisement ........................................................... 41 Gambar 3.5 Encoded-Unicast-Address ................................................................. 41 Gambar 3.6 Encoded-Unicast-Group-Address ..................................................... 42 Gambar 3.7 Pemberitahuan hashRP ...................................................................... 42 Gambar 3.8 Query RP_Set Dari DR ..................................................................... 43 Gambar 3.9 Bootstrap Message ............................................................................ 43 Gambar 3.10 Tracing Hops Pseudocode ............................................................... 44 Gambar 3.11 Format Kontrol Jalur DR ke-RP_Set .............................................. 45 Gambar 3.12 Version 2 Multicast Listener Report Message ................................ 46 Gambar 3.13 PIM JOIN ........................................................................................ 46 Gambar 3.14 Encoded-Source Address ................................................................ 47 Gambar 3.15 Pemberitahuan BSR Tentang Alamat RP Yang Baru ..................... 47 Gambar 3.16 Pemberitahuan RP Lama Selesai .................................................... 48 Gambar 3.17 Format Paket Data ........................................................................... 49 Gambar 3.18 Konfigurasi UML Untuk Komputer 32 Bit ..................................... 49 Gambar 3.19 Konfigurasi Networking Untuk UML ............................................. 49 Gambar 3.20 Konfigurasi IPv6 Untuk UML ........................................................ 50 Gambar 3.21 Node UML Dengan Memori 64 MB dan Prosesor 32 bit. .............. 50 Gambar 3.22 Contoh Konfigurasi ospf6d.conf Pada Router R02 ......................... 51 Gambar 3.23 Contoh Konfigurasi zebra.conf Pada Router R02 ........................... 51 Gambar 3.24 Algoritma Transmisi ....................................................................... 52



xii

Gambar 3.25 All Middle Algorithm (3) ................................................................ 55 Gambar 3.26 Aliran Kerja Algoritma Skenario .................................................... 56 Gambar 3.27 Posisi Penelitian Rancangan Skenario ............................................ 61 Gambar 3.28 State Diagram RP Relocation [10] .................................................. 62 Gambar 3.29 RP Relocation Algorithm [10] ........................................................ 62 Gambar 3.30 RP Migration Algorithm [10] .......................................................... 63 Gambar 4.1 Pemilihan hashRP Pada BSR ............................................................ 65 Gambar 4.2 RP menerima PIM-JOIN ................................................................... 66 Gambar 4.3 Packet Loss Tanpa Relokasi: 1 Klien Pada Setiap Router ................ 67 Gambar 4.4 Delay Tanpa Relokasi: 1 Klien Pada Setiap Router .......................... 68 Gambar 4.5 Packet Loss Terhadap Perubahan Ukuran Paket ............................... 70 Gambar 4.6 Delay Terhadap Perubahan Ukuran Paket ........................................ 70 Gambar 4.7 Packet Loss Terhadap Perubahan Jumlah Paket Per Detik ............... 72 Gambar 4.8 Delay Terhadap Perubahan Jumlah Paket Per Detik ......................... 72 Gambar 4.9 Rata – Rata Delay Setiap Paket ......................................................... 73 Gambar 4.10 Rata – Rata Jumlah Packet Loss Setiap Paket ................................ 73 Gambar 4.11 Delay Percobaan Ke-9 Tabel 4.13................................................... 77 Gambar 4.12 Packet Loss Percobaan Ke-9 Tabel 4.13 ......................................... 77 Gambar 4.13 Penggunaan Bandiwidth Pada Node RP ......................................... 78 Gambar 4.14 Packet Loss Percobaan ke-3 Tabel 4.14 .......................................... 81 Gambar 4.15 Delay Percobaan ke-3 Tabel 4.14 ................................................... 82 Gambar 4.16 Penggunaan Bandiwidth Pada Node RP Ditambah R01 ................. 83



xiii

DAFTAR TABEL Tabel 2.1 Projeksi TanggalSemua RIR Kehabisan Alamat IPv4 ............................ 8 Tabel 2.2 Hubungan Antara Prioritas Dengan Aplikasi [RFC 1883] ................... 11 Tabel 2.3Prefiks Tipe Alamat IPv6 ....................................................................... 13 Tabel 2.4Alamat IPv6 Anycast ............................................................................. 14 Tabel 2.5Format Alamat IPv6 Multicast [tcpguide.com] ..................................... 16 Tabel 2.6 Management Information Base (MIB) .................................................. 24 Tabel 3.1Konfigurasi Model Rancangan Skenario ............................................... 38 Tabel 3.2 Tipe Pesan PIM-SM .............................................................................. 48 Tabel 4.1 RP_Set Yang DikirimkanBSR .............................................................. 66 Tabel 4.2Rata – Rata Packet Loss Ketika Pengiriman Paket Data 4096 Bytes .... 69 Tabel 4.3Rata – Rata Delay Ketika Pengiriman Paket Data 4096 Bytes .............. 69 Tabel 4.4 Faktor Perubahan Ukuran Paket Data Terhadap Packet Loss............... 69 Tabel 4.5 Faktor Perubahan Ukuran Paket Data Terhadap Delay ........................ 69 Tabel 4.6Rata Rata Paket Loss Ketika Jumlah Paket 3 Per Detik ........................ 70 Tabel 4.7Rata Rata Delay Ketika Jumlah Paket 3 Per Detik ................................ 71 Tabel 4.8 Faktor Perubahan Jumlah Paket Per Detik Terhadap Packet Loss ....... 71 Tabel 4.9Faktor Perubahan Jumlah Paket Per Detik Terhadap Delay .................. 71 Tabel 4.10 Lama Waktu Algoritma AM Setiap Percobaan .................................. 73 Tabel 4.11 Lama Waktu Relokasi Terjadi Setiap Percobaan ................................ 73 Tabel 4.12 Tabel Cost Pada Simulasi Dengan 7 Klien ......................................... 74 Tabel 4.13Hasil Relokasi Pada Simulasi Dengan Threshold 2 ............................. 75 Tabel 4.14 Rata – Rata Packet Loss Skenario Dengan Proposal [Ying-Dar, 2002] dan [Samer, 2009] ................................................................................................. 76 Tabel 4.15 Hasil Relokasi Pada Simulasi Dengan Threshold 6 ............................ 80 Tabel 4.16Rata – Rata Packet Loss Skenario Dengan Proposal [Ying-Dar, 2002] dan [Samer, 2009] ................................................................................................. 81



xiv

DAFTAR SINGKATAN

RP

: Rendezvous Point

IPv4

: Internet Protocol Version 4

IPv6

: Internet Protocol Version 6

BSR

: Bootstrap Router

C-RP

: Candidate Rendezvous Point

PIM

: Protocol Independent Multicast

SM

: Sparse Mode

QoS

: Quality of Service

C-BSR

: Candidate Bootstrap Router

HC

: Hill Climbing Algorithm

LC

: Longest Path Algorithm

AP

: All Paths Algorithm

AM

: All Members Algorithm

IGMP

: Internet Group Management Protocol

RFC

: Request For Comment

EC

: Estimation Cost

EEC

: Enhanced Estimation Cost

UML

: User Mode Linux



1

BAB 1 PENDAHULUAN 1.1

Latar Belakang Perkembangan IPv6 saat ini sudah mencapai tahap akhir implementasi.

Banyaknya kelemahan dari IPv4 yang telah diatasi dan penyederhanaan protokol dimana salah satunya IPv6 menyediakan Traffic Class yang dapat digunakan untuk mengatur QoS dari suatu layanan trafik data. Perbedaan lainnya adalah alamat bit yang lebih besar yang mampu meliputi seluruh manusia di dunia dan masih tersisa banyak alamat cadangan yang bisa digunakan. Salah satu permasalahan yang ada pada IPv6 adalah metode routing melalui multicast yang mana sering digunakan untuk teknologi streaming atau konferensi masih memiliki banyak kelemahan. Salah satu contoh metode tersebut adalah (Any Source Multicast) yang menggunakan Rendezvous Point (RP). Untuk menghubungkan antara pengirim dan penerima, diperlukan suatu media pencarian yang umumnya menggunakan MSDP (Multi Source Discovery Protocol) akan tetapi MSDP tersebut sudah dianggap tidak manageable / scalable untuk penanganan transmisi data antar-domain pada protokol IPv6 [1]. Beberapa protokol multicast lain pada keluarga Protocol Independent Multicast seperti Sparse Mode (PIM-SM) atau Source Spesific Multicast (PIMSSM) mampu menjadi solusi ketika dibutuhkan suatu multicast antar domain dimana pengirim dan penerima bersifat many-to-many. Permasalahannya adalah PIM-SSM memiliki kelemahan pada kanal (S,G) yang harus dispesifikkan [RFC (Request For Comment) 3569] dimana kanal tersebut terbatas hanya pada 1 pengirim. Sedangkan PIM-SM [RFC 4601] mampu menjembatani banyak pengirim dan banyak penerima. Semua pengirim dan penerima tersebut dijembatani oleh RP (Rendezvous Point) yang menjadi titik utama transmisi data antar domain. Permasalahan terjadi pada bagaimana penerima – penerima tersebut mengetahui alamat lokasi RP berada. Banyak teori dan protokol yang digunakan untuk

1



2

menemukan RP, dua diantaranya adalah Embedded-RP [RFC 3956] (pada lingkungan IPv6 saja) dan Bootstrap Router (BSR) [RFC 5059] yang mana BSR (Bootstrap Router) adalah cara dimana multicast router dapat menemukan dimana grup mapping RP yang dibutuhkan agar transmisi data berfungsi. Mekanisme pada BSR yang dispesifikkan pada RFC 5059 tersebut yang hanya memiliki 1 RP dan 1 Backup-RP ini tahan terhadap failure yang terjadi apabila memiliki kandidat RP lebih dari satu, akan tetapi mekanisme ini tidak menghitung beban multicast router RP sehingga QoS kurang bisa diterapkan dengan baik. BSR tidak didesain untuk memiliki penjagaan QoS jaringan dan relokasi RP ketika ada kandidat RP yang mungkin dinilai mampu menjaga kualitas dengan baik. Penggantian RP dan Backup-RP hanya terjadi ketika terjadi kegagalan RP saja. Dibutuhkan suatu metode baru untuk merelokasi RP secara dinamis sehingga kualitas hubungan many-to-manydapat berjalan dengan baik. Oleh karena itu, diperlukan suatu analisa otomatisasirancangan relokasi Rendezvous Point oleh BSR secara otomatis dengan menggunakan proses pemilihan RP yang dilakukan secara otomatis dan dinamis walaupun tidak ada penambahan atau pengurangan anggota multicast selain untuk menjaga kemungkinan failover tetapi juga mampu menjaga QoS (Quality of Service) trafik multicast pada RPdengan baik agar tidak ada RP yang terbebani secara terus menerus. 1.2

Rumusan Penelitian Mengacu

dari

latar

belakang

penelitian

maka

dirumuskan

permasalahannya yaitu: 1. Bagaimana relokasi RP dilakukan dengan algoritma lokasi distribusi [5] dengan meminimalisir resiko terjadinya packet loss. 2. Bagaimana DR (Designated Router) mendapatkan alamat RP dengan menggunakan mekanisme Hybrid Bootstrap [6] untuk meminimalisir waktu pemrosesan. 3. Bagaimana relokasi RP ketika cost minimal ditambahkan oleh threshold sehingga bandwidth pada RP tidak terlalu besar.



3

4. Bagaimana

algoritma

seleksi

posisi

RP

terbaru

tidak

menyebabkan overhead pada jaringan. 1.3

Batasan Penelitian Menyadari akan luasnya permasalahan yang dihadapi, maka diperlukan

adanya batasan masalah yang jelas. Hal ini penting untuk dilakukan agar penelitian dapat lebih terfokus pada permasalahan yang telah dirumuskan saja.oleh karena itu, batasan penelitian ini adalah sebagai berikut: 1. Semua node Router berlaku sebagai DR bagi klien yang dibawahnya dan juga C-RP (Candidate Rendezvous Point). 2. Semua C-RP punya prioritas yang sama, kecuali dalam data RP_Set yang dikirimkan BSR ke DR untuk mengetahui Hash RP. 3. Semua paket data yang dikirimkan memakai protokol UDP dan semua paket kontrol yang dikirimkan memakai protokol TCP. 4. Alamat multicast yang digunakan pada simulasi hanya satu yaituff00::123. 5. C-RP

tidak

mengirimkan

paket

control

Candidate-RP

advertisement secara periodik, dengan asumsi C-RP tidak akan di-release dari RP-Set selamanya. 6. DR dan Klien tidak mengirimkan paket PIM_JOIN dan Register secara periodik, dengan asumsi keduanya tidak akan di-release dari tabel masing - masing selamanya kecuali untuk melepas diri dari RP lama. 7. DR yang mengirimkan paket ke RP yang terpilih secara otomatis telah melakukan Join//Register pada RP yang terpilih. 8. DR yang dipilih untuk setiap LAN diwakili oleh 1 router yang menjadi gateway dari LAN tersebut. 9. Jalur pengiriman data dari penerima ke pengirim memakai jalur yang dibuat dengan Shared RP-tree.



4

10. Bandwidth tidak dispesifikasikan untuk tiap jalur, diasumsikan semua jalur memiliki bandwidth yang sama. 11. Besar ukuran paket data maksimal yang mampu ditransmisikan pada simulasi UML dalam sekali pengiriman adalah 15900 Byte. 12. Paket data yang dikirimkan memakai tidak menggunakan paket dengan format Register dan paket kontrol Register-Stop tidak diperlukan. 1.4

Tujuan Penelitian Tujuan dariTesisini adalah rancangan skenario dari proses relokasi sistem

multicast pada PIM-SMyang menggunakan mekanisme Hybrid Bootstrap Router pada lingkungan IPv6 dengan pengalokasian router yang berhadapan dengan klien sebagai RP yang akan dirotasi setiap waktu dan mampu untuk menjaga kualitas jaringanyang dimana loss packetberkurang dan mengurangi latency dari kondisi PIM-RP tanpa relokasi dengan menggunakan protokol UDP sebagai protokol pembawa data. Manfaat dari rancangan ini adalah: 

Memberikan kemudahan akses data dengan hubungan many-to-manypada lingkungan routing multicast.



Mengurangi waktu pemrosesan dari proses relokasi yang ada pada mekanisme Bootstrap Router dengan menggunakan fasilitas mekanisme Hybrid Bootstrap.



Memberikan kemampuan sistem untuk menjaga kualitas jaringan seoptimalnya dan mampu untuk mengurangi beban penggunaan RP pada 1 router multicast saja.



Menganalisa tentang pengaplikasian kebutuhan many-to-many dengan menggunakan multicast pada IPv6.

1.5

Metodologi Penelitian Langkah-langkah yang ditempuh dalam pengerjaan Tesis ini adalah

sebagai berikut:



5

1. Studi Literatur Tahap ini merupakan tahapan persiapan yang meliputi pengumpulan informasi perancangan sistem. Studi literatur mengenai IPv6, Multicast, BSR, dan model penentuan RPyang dapat diperoleh baik melalui literatur web, paper, ataupun buku-buku pemrograman yang diperlukan dan juga RFC yang diperlukan agar simulasi dapat merepresentasikan hal yang nyata. Selain itu juga dilakukan penelitian mengenai relokasi RP terbaru yang sudah ada beserta atribut atribut yang diperlukan dalam penentuan RP. 2. Analisa Model Pada tahap ini dilakukan analisis kebutuhan apa saja yang diperlukan agar QoS dapat terjaga di jaringan multicast routing dan perancangan sistem untuk merumuskan solusi yang tepat dalam pembuatan rancangan skenario serta kemungkinan yang dapat dilakukan untuk mengimplementasikan rancangan tersebut. 3. Desain Model Pada tahap ini, desain model matematika ditentukan dan diukur sesuai dengan kebutuhan yang telah dispesifikasikan di awal pengujian. Desain tersebut diolah menjadi bentuk yang memudahkan untuk dibaca dan dianalisa lebih lanjut sehingga konsistensi model tersebut dapat terjaga. 4. Analisa Penelitian Pada tahap ini, dilakukan analisa skenario terhadap kualitas jaringan dan pengukuran kinerja dengan beberapa data yang melibatkan beberapa pengguna untuk kemudian dilakukan perbaikan apabila terdapat kesalahan sehingga dapat dilakukan evaluasi terhadap hasil uji coba tersebut. 1.6

Sistematika Penulisan Laporan ini terdiri dari lima bab dengan sistematika penulisan sebagai

berikut:



6

Bab I

: Pendahuluan Bab ini menjelaskan hal-hal yang melatarbelakangi penelitian ini, diikuti uraian tentang rumusan masalah, tujuan dan manfaat penelitian, batasan dan metode penelitian beserta sistematika penulisan.

Bab II : Tinjauan Pustaka Bab ini menjelaskan tentang teori yang berhubungan dengan penelitian tentang relokasi RP pada lingkungan routing multicast IPv6. Bab III : Rancangan Sistem Bab ini menjelaskan rancangan sistem yang dikembangkan dalam penelitian ini, yaitu perancangan skenario jaringan beserta mekanisme BSR juga RP untuk otomatisasi relokasi, dan juga faktor – faktor yang menjadi acuan jaringan yang berkualitas untuk hubungan many-to-many. Selain itu juga hubungan antara rancangan skenario Tesis dengan penelitian perelokasian RP yang sudah ada. Bab IV : Hasil Simulasi dan Analisa Data Bab ini menampilkan dan menjelaskan hasil simulasi dan juga hasil analisa data simulasi yang telah dilakukan. Bab V : Kesimpulan Bab ini menjelaskan tentang kesimpulan dari analisa yang telah dilakukan, sekaligus menjawab permasalahan sesuai dengan judul tesis ini.



7

BAB 2 TINJAUAN PUSTAKA 2.1

Internet Protocol Version 6 Internet Protocol adalah protokol komunikasi dasar yang digunakan

untuk mengirimkan paket datagram dari pengirim ke penerima dengan hanya menggunakan alamat IP melalui jaringan internetwork IP adalah protokol utama yang membentuk Internet. Pada awalnya, IP digunakan untuk servis datagram connectionless pada Transmission Control Program yang diperkenalkan oleh Vint Cerf dan Bob Kahn pada tahun 1974. Versi utama dari IP, yang saat ini masih digunakan dengan Internet Protocol Version 4 (IPv4) adalah protokol dominan dari Internet, walaupun penerusnya, Internet Protocol Version 6 (IPv6) masih aktif dikembangkan di seluruh dunia. Sejak pertama kali digunakan secara resmi sekitar tahun 1981 setelah publikasi resmi [RFC 791] dari IETF, IP versi 4 (IPv4) telah menjadi inti utama internet sampai saat ini. IPv4 menggunakan alamat data 32-bit yang berarti total address space yang dimiliki (hanya) berjumlah 4294967296 (232). Di awal penggunaan, tidak pernah terpikirkan sebelumnya bahwa address space yang dimiliki oleh IPv4 akan mengalami masalah berupa penipisan (address exhaustion).

Gambar 2.1 Projeksi dari Konsumsi Sisa Alamat IPv4 yang Dimiliki RIR [3]

7



8

Pada tanggal 31 January 2011, InternetAssigned Numbers Authority (IANA), badan internasional yang mengatur tentang penggunaan alamat IPv4, mengumumkan kehabisan alamat IPv4 [2] (Gambar 2.1) lalu disusul dengan pengumuman dari RIR (badan pengatur alamat IPv4 regional) Asia(APNIC) pada tanggal 15 April 2011. Data yang telah diterima [3] yang dijelaskan pada Tabel 2.1, menunjukkan bahwa proyeksi exhaustion semakin dekat dan tinggal menunggu waktu. Oleh karena itu, banyak metode untuk mengatasi exhaustion oleh alamat IPv4, diantaranya adalah pembuatan dan penggunaan teknologi baru, contohnya Classless Inter-Domain Routing (CIDR) pada tahun 1993, Private Address pada tahun 1918 danNetwork Address Translation (NAT). Tabel 2.1 Projeksi TanggalSemua RIR Kehabisan Alamat IPv4

RIR

Projected Exhaustion

Remaining Addresses in

Date

RIR Pool (/8s)

APNIC:

19-Apr-2011

1.2021

RIPENCC:

11-Jul-2012

3.5891

ARIN:

19-Jun-2013

5.7081

LACNIC:

27-Jan-2014

4.1005

AFRINIC:

25-Aug-2014

4.3640

CIDR, private address dan NAT ternyata terbukti masih belum bisa mengatasi penipisan alamat IPv4 yang telah diatur oleh IANA. Oleh karena itu, Internet Engineering Task Force (IETF) mengembangkan IPv6 dan dideskripsikan secara resmi pada tahun 1998 (dikeluarkan format resmi dalam bentuk RFC 2460). IPv6 memiliki alamat data 128-bit, dimana seandainya tiap orang di dunia bisa memiliki lebih dari 5 alamat IP, IPv6 masih memiliki cadangan yang sangat banyak. Salah satu kutipan dari Raúl Echeberría, Ketua Organisasi Number Resource, organisasi payung dari lima RIR, “Deploying IPv6 is now a requirement, not an option.” menjelaskan tentang kebutuhan mendesak untuk



9

segera mengganti IPv4 dengan IPv6. Dimulai dari tahun 1998 sejak pertama kali IPv6 secara resmi menjadi daftar teknologi yang dibutuhkan, IPv6 selalu menjadi topik riset yang menarik terutama penelitian di topik untuk mengatasi permasalahan dalam IPv4 selain dalam hal address space exhaustion, contohnya tentang QoS. Pada Gambar 2.2. terlihat pada header paket IPv6 lebih sederhana akan tetapi memiliki lebih banyak keunggulan ketimbang IPv4. Contohnya adalah TOS pada IPv4 walaupun mampu mengatur kelas paket yang ditransfer akan tetapi tidak akan terpakai kalau tidak ada dukungan dari klien ataupun router yang akan dilewati oleh data, sedangkan traffic class pada IPv6 akan selalu dipakai untuk membedakan kelas paket data yang ditransfer yang artinya IPv6 lebih sadar-QoS daripada IPv4.

Gambar 2.2 Perbandingan Header IPv4 dan IPv6 [sumber: Juniper, Maret 2003]

Banyak perbedaan cara kerja yang diterapkan pada IPv6 dengan cara kerja IPv4 diantaranya selain alamat yang lebih banyak, dan juga jenis – jenis alamat yang lebih lengkap pada Tabel 2.4,selain itu, IPv6 juga tidak menerapkan broadcast sebagaimana IPv4 dalam transmisi ke semua host pada tautan, melainkan menggunakan multicast. Multicast pada IPv6 memiliki beberapa kesamaan dengan multicast pada IPv4, akan tetapi juga memiliki beberapa perubahan dan perbaikan dengan eliminasi beberapa protokol. IPv6 juga menyediakan beberapa teknologi solusi multicast yang baru, dimana sebuah klien dengan IPv6 mampu mengirim data hanya ke seluruh router pada tautan



10

(FF02:0:0:0:0:0:0:2) atau juga ke seluruh router pada area (FF05:0:0:0:0:0:0:2) [RFC 2375].

Gambar 2.3 Contoh Pengalamatan IPv6

IPv6 menggunakan besar alamat sebanyak 128-bit (IPv4 hanya memakai 32-bit) seperti yang terlihat pada Gambar 2.3 dan cukup untuk meliputi setiap penghuni planet di bumi beberapa kali. 128-bit juga menyediakan fleksibilitas dan berbagai tingkat pengalamatan secara hirarki dan routing, dimana fitur tersebut sebenarnya dibutuhkan akan tetapi tidak tersedia dalam IPv4. Pada saat ini, sangat dibutuhkan agar IPv4 dapat berjalan bersama IPv6 sebagai calon IP masa depan, akan tetapi IPv4 dan IPv6 tidak bisa berkomunikasi secara langsung. Perlu adanya pertolongan dari gerbang perantara atau mekanisme transisi lainnya seperti dual-stack. Waktu tenggang sebelum terjadinya transisi total ke IPv6 digunakan para periset untuk membuat protokol yang mana mampu mengatasi berbagai macam kelemahan pada IPv4. 2.1.1

Header IPv6 Pada IPv6 dengan asumsi 1 kata adalah 32-bit, maka seperti yang terlihat

pada Gambar 2.4, paket header IPv6 memiliki 5 kata dari baris paling atas, dimana Version, Traffic Class, Flow Label, Payload Length, Next Header dan Hop Limit termasuk 1 kata. Lalu 2 kata di dalam alamat pengirim dan 2 kata di dalam alamat penerima. Pada IPv6, masing – masing bit memiliki fungsinya yang dijelaskan oleh standar RFC 1883.



11

Gambar 2.4 Header Paket IPv6



Version Bagian 4-bit ini berisi tentang versi IP dimana tertulis angka 6. Bagian ini sama dengan versi header IPv4 yang berisi angka 4. Tabel 2.2 Hubungan Antara Prioritas Dengan Aplikasi [RFC 1883]

Applications

Priorities 0 1 2

Uncharacterized traffic “Filler” traffic (for example, netnews) Unattended data transfer (for example, e-mail)

3 4

Reserved for future purposes Attended bulk transfer (for example, FTP, NFS)

5 6

Reserved for future purposes Interactive traffic (for example, Telnet, X-Windows)

7

Internet control traffic (for example, routing protocols, SNMP)



Traffic Class Bagian 4-bit ini berisi tentang prioritas yang ditentukan oleh 16 nilai yang berbeda. Bagian ini membuat node pengirim data untuk membedakan paket yang dikirimkan dengan prioritas pengiriman yang berbeda. 16 nilai yang mungkin ini dibagi menjadi 2 grup (RFC 1883), dari 0 sampai 7



12

dimana trafik data yang memiliki kelas ini menspesifikasikan prioritas trafik data yang dijelaskan pada Tabel 2.2. Nilai 8 sampai 15 digunakan untuk menspesifikasikan prioritas trafik berdasarkan respon trafik data terhadap congestion. Contohnya prioritas 8 mengasosiasikan paket – paket yang pertama kali dibuang ketika kongesti terjadi, sementara prioritas 15 mengasosiasikan dengan paket – paket yang akan dihilangkan terakhir kali, jika benar – benar dibutuhkan. 

Flow Label Bagian 24-bit di dalam header IPv6 bisa digunakan oleh pengirim untuk memberikan label pada serangkaian paket yang termasuk aliran data yang sama. Aliran data secara khusus diidentifikasikan dengan alamat pengirim dan Flow Label yang tidak kosong. Beberapa macam aliran aktif bisa terjadi dari pengirim ke penerima dengan alamat pengirim yang sama akan tetapi memiliki Flow Label yang berbeda, dan juga trafik data yang tidak memiliki atau berasosiasi dengan aliran manapun (bernilai 0).



Payload Length Bagian 16-bit Payload Length berisi tentang besaran bagian data yang mengikuti header IPv6 tersebut di dalam oktet. Dikarenakan 16-bit memiliki panjang maksimal 64 Kbytes, jika bagian data besaran yang melebihi panjang maksimum tersebut maka ekstensi Payload bisa digunakan dengan menyisipkan angka 0 di dalamnya.



Next Header Bagian 8-bit ini mengidentifikasikan tipe header yang mengikutinya dan terletak di awal bagian data dari paket IPv6. Umumnya bagian ini berisi tentang data lanjutan dari TCP dan UDP, akan tetapi banyak jenis protokol yang bisa menggunakannya. Format yang diadopsi oleh bagian ini secara umum memiliki bagian yang sama pada IPv4 (RFC 17003).



Hop Limit Bagian 8-bit Hop Limit memiliki nilai yang akan dikurangi satu persatu oleh setiap node (secara umum adalah router) yang meneruskan paket. Jika Hop Limit dikurangi sampai 0, maka paket akan dibuang. Fungsi utama dari bagian ini adalah untuk mencegah paket yang melakukan perputaran



13

tidak terhingga dikarenakan kesalahan informasi jalur paket. Diantara 2 IPv6 node, tidak boleh melebihi 255 kali lompatan node atau jalur, yang berarti router yang dilewati tidak boleh lebih dari 254. 2.1.2 Prefiks Tipe Pengalamatan IPv6 prefix mengindikasikan bagian dari alamat yang digunakan untuk routing atau untuk mengidentifikasikan rentang alamat yang sama cara penulisannya

dengan

CIDR

yang

digunakan

pada

IPv4,

semisal

2001:DB80:3FA9::/48mungkin akan merepresentasikan prefix routing di dalam tabel routing IPv6. Tabel 2.3Prefiks Tipe Alamat IPv6

Address Type

Binary Prefix

IPv6 Notation

Unspecified

00...0 (128 bits)

::/128

Loopback

00...1 (128 bits)

::1/128

Multicast

1111 1111

FF00::/8

1111 1110 10

FE80::/10

1111 110

FC00::/7

Link-Local Unicast ULA Global Unicast IPv4-mapped

(everything else) 00...0:1111 1111:IPv4 ::FFFF:IPv4/128

Site-Local Unicast (deprecated) 1111 1110 11 IPv4-compatible (deprecated)

00...0 (96 bits)

FEC0::/10 ::IPv4/128

IPv6 mendukung 3 tipe pengalamatan, yakni: 

Unicast mengidentifikasikan interface tunggal di dalam lingkup alamat yang dijelaskan dalam Tabel 2.3. Paket IPv6 dengan unicast bertujuan untuk pengiriman data ke interface tunggal.



Multicast mengidentifikasikan tidak ada atau lebih dari 1 interface. Paket IPv6 dengan tujuan multicast dikirimkan ke semua interface yang sedang



14

mendengarkan alamat multicast tersebut (Secara garis besar sama dengan multicast pada IPv4). 

Anycast mengidentifikasikan beberapa interface dimana paket IPv6

dengan anycast dikirimkan ke interface terdekat (yang diukur dari jarak routing) yang dispesifikasikan oleh alamat. Sampai saat ini alamat anycast hanya diberikan ke identifikasi router terdekat seperti yang terlihat pada Tabel 2.4. Tabel 2.4Alamat IPv6 Anycast

Decimal

Hexadecimal

Description

Reference

127

0x7F

Reserved

126

0x7E

Mobile IPv6

[RFC2526] and

Home-Agents

[RFC3775]

anycast 1-125

0x01-0x7D

Reserved

0

0x00

Subnet-Router

[RFC4291]

Anycast Address

2.2

Protokol Multicast Protokol Multicast adalah protokol pengiriman pesan atau informasi ke

suatu grup dari alamat pengiriman secara simultan pada satu transmisi dari pengirim yang secara otomatis mereplikasi pesan multicast tersebut pada saat pengiriman (biasanya pereplikasian data dilakukan oleh multicast router). Multicast juga bermaksud pengiriman dalam skala populasi (node jaringan) luas yang secara umum tanpa perlu pengirim mengetahui seberapa banyak atau siapa sajakah penerimanya (Gambar 2.5).



15

Gambar 2.5 Skema Routing Paket

Multicast menggunakan jaringan secara efisien hanya dengan sekali pengiriman, walaupun terdapat sejumlah besar penerima. Node – node inti seperti router yang bertanggung jawab mereplikasi paket untuk menyampaikan data pada sejumlah penerima ketika dibutuhkan. Pada IPv6, pengiriman multicast ditandai dengan prefix FF0x/8 dimana x adalah nilai dari cakupan dari alamat tujuan yang dijelaskan oleh Gambar 2.6 dan Tabel 2.5. Selain itu, multicast pada IPv6 juga pengganti dari metode broadcast yang sebelumnya pada IPv4 digunakan untuk mengirimkan pesan ke semua node yang terdapat pada satu waktu. Kekurangan yang masih harus dihadapi para peneliti adalah konfigurasi beberapa bagian data contohnya seperti pembangunan multicast tree yang digunakan untuk menghubungkan jalur antara pengirim dan penerima. Selain itu juga, perelokasian informasi topologi routing harus diperhitungkan juga, sehingga transmisi data dari pengirim dapat terkirim dengan baik ke penerima. Terdapat sejumlah pilihan routing multicast yang dapat digunakan pada protokol internet sampai saat ini. Diantaranya adalah: 

Any-Source Multicast [RFC 3569]: bentuk tradisional dari multicast dimana banyak pengirim pada 1 kanal / saluran yang sama

dimana

1

sumber

tertentu

dispesifikkan

sehingga

memungkinkan transmisi data dengan hubungan many-to-many terjadi. 

Protocol Independent Multicast: protokol ini adalah protokol yang menyediakan hubungan one-to-many dan many-to-many



16

yang dapat didistribusikan melalui LAN, WAN, dan juga Internet. PIM dijelaskan lagi pada Bab 2.2.1.

Gambar 2.6 Format Alamat IPv6 Multicast [tcpguide.com]

Tabel 2.5Format Alamat IPv6 Multicast [tcpguide.com]

Field

Ukuran

Name

(bits)

(Indicator)

8

Deskripsi

Pada indicator selalu bernilai 1111 1111 (FF dalam heksa) sesuai dengan Alamat Multicast [RFC 2460]

Flags

4

4-bit ini digunakan untuk pengindikasian sifat dari alamat multicast. 000T: T=1 Transient, T=0 Well-known

Scope ID

4



17

Walaupun multicast memiliki protokol sendiri, tetapi kebanyakan diantara pilihan yang telah disebutkan di atas tetap membutuhkan protokol routing sendiri. Mulai dari static routing sampai dengan dynamic routing. Dikarenakan kebutuhan akan tabel routing yang baru, beberapa routing yang ada bahkan memiliki ekstensi tambahan untuk membedakan masing – masing tabel routing untuk dikelola. Contohnya adalah Multiprotocol-extension-BGP (MBGP) [RFC 4760]yang telah mengijinkan tabel topologi Multicast-routing yang berbeda dari tabel routing IPv4-unicast routing. 2.2.1

Protocol Independent Multicast Protocol Independent Multicast (PIM) adalah keluarga dari protokol

Multicast routing untuk IP yang menyediakan distribusi data one-to-many dan many-to-many melalui LAN, WAN, atau Internet. Dinamakan protocolindependent dikarenakan dalam PIMtidak termasuk topologinya sendiri dalam mekanisme deteksi, akan tetapi umumnya menggunakan informasi routing yang disediakan oleh protokol tradisional routing seperti BGP. PIM menyediakan keanggotaan yang berbeda untuk grup yang berbeda. Diantaranya adalah: 

Dense Mode:Berkebalikan dengan SM, protokol ini adalah mode yang membangun jalur terlebih dahulu sebelum mengirimkan data kepada penerima yang telah Join di dalam grup multicast. Sebelum mengirimkan data, multicast routing membanjiri semua jalur / cabang yang ada untuk menemukan semua penerima yang telah menjadi anggota grup multicast (dalam sebagian besar kasus, router yang memiliki jawaban dari paket tersebut), dan mem-Prune setiap cabang yang tidak memiliki jawaban.



Sparse Mode:PIM-SM ini adalah pentransmisian data yang bisa digunakan untuk area yang luas dan antar-domain pada Internet. PIM-SM membangun hubungan 1 arah yang dipusatkan pada RP per grup multicast, dan secara opsional membangun jalur terpendek di antara masing – masing klien. Protokol ini sangatlah cocok ketika dipakai pada jaringan dengan node yang sedikit



18

dimana node – node (termasuk routernya) tersebut telah Join pada grup multicast yang telah ditentukan. PIM berbeda dari protokol multicast lainnya, dimana PIM ini menggunakan model Join/Prune yang jelas. Join/Prune bisa terjadi pada topologi hirarki. Pada PIM-SM setiap dataakan dialokasikan khusus untuk setiap anggota grup multicast per cabang. Sedangkan pada DM, flooding paket terlebih dahulu akan membutuhkan bandwidth besar,dan overheadtentunya akan terjadi dengan membanjiri data ke semua jalur keluar dan walaupun pada akhirnya eksepsi batasan jalur bisa dilakukan ketika tidak ada anggota dari grup multicast yang menjawabnya. 2.2.2

PIM Sparse Mode PIM-SM membutuhkan kemampuan untuk mendapatkan tabel routing

yang dapat digunakan untuk menjelaskan topologi jaringan yang ada. Tabel ini dinamakan Multicast Routing Information Base (MRIB) [RFC2362] [RFC4601]. Jalur pada tabel ini bisa didapatkan dengan cara Unicast maupun disediakan oleh routing protocol seperti MBGP. Seperti yang sudah dijelaskan pada Bab 2.2.1, PIM-SM menggunakan router yang dinamakan Rendezvous Point (RP) yang mana memainkan fungsi utama pada transmisi data. Semua paket yang dikirimkan harus dikirimkan terlebih dahulu pada RP dan paket yang telah diterima RP akan dikirimkan ke semua penerima yang menjadi anggota grup multicast. Seperti semua protokol multicast routing yang mengimplementasikan model servis [RFC 1112], PIM-SM juga harus mampu mengirimkan semua paket data dari pengirimke penerima tanpa pengirim dan penerima mengetahui keberadaan/lokasi dari yang lainnya. Biasanya hal tersebut terjadi dalam 3 tahap, walaupun pengirim dan penerima bisa datang dan pergi pada setiap saat, tiga tahap ini bisa terjadi secara simultan [RFC 4601]. Setiap domain mempunyai kumpulan router yang digunakan sebagai RP (RP-set), dimana setiap grup biasanya mempunyai minimal satu RP yang bisa digunakan setiap saat. Setiap router yang ingin menerima data multicast dari grup tertentu harus mengirimkan pesan Join ke RP pada grup tersebut seperti pada



19

Gambar 2.7. Setiap klien umumnya mempunyai DR yang ketika DR tersebut menerima pesan pendaftaran yang biasanya memakai protokol IGMP atau MLD yang mengindikasikan pendaftaran anggota multicast dari klien tertentu ke grup tertentu, maka DR akan mencari RP dari grup yang dimaksud dengan menggunakan fungsi Hash yang dijelaskan pada Bab 2.2.3 dan mengirimkan pesan PIM-Join pada RP yang terpilih.

Gambar 2.7 Pendaftaran Anggota Multicast [4]

Setelah itu DR menjadi mediasi pengirim data dari pengirim menuju RP yang terpilih untuk setiap (*,G) dimana “*” berarti dari semua pengirim sehingga DR bisa meneruskan aliran data multicast dari RP dan mengembalikan ke klien yang menjadi anggota dari grup multicast tersebut [4]. Inilah fase pertama dari cara kerja PIM-SM yang dinamakan RP Tree [RFC 4601], di mana dalam fase ini penerima multicast memberikan informasi yang isinya adalah kesiapan untuk menerima trafik yang ditujukan untuk grup multicast yang pada akhir fase ini, trafik multicast dienkapsulasi menuju RP dan dari RP tree menuju penerima multicast (Gambar 2.8).



20

Gambar 2.8 Pengiriman Paket ke Grup Multicast [4]

Pada fase kedua: Register-Stop, digunakan RP untuk mencegah DR secara berlebihan mengenkapsulasi paket Register dari pengirim (S) agar RP bisa memakai forwarding yang menggunakan tabel routingsecara native. Ketika RP menerima paket data register yang dienkapsulasi dari S ke grup (G), RP akan menginisiasikan (S,G) Join kea rah S. Pesan Join ini dikirimkan setiap lompatan (PIM Router) dan menginisiasi (S,G) multicast tree state yang digunakan PIMSM agar bisa meneruskan paket ke G jika paket tersebut datang dari S. Ketika RP dalam proses untuk menggabungkan jalur spesifik untuk S, paket data akan terus menerus dienkapsulasi menuju RP, sehingga seandainya ada 2 paket yang sama dari S, dimana yang satu dikirim secara native menggunakan informasi (S,G) multicast tree statedan yang lainnya adalah paket yang dienkapsulasi, maka RP akan menghilangkan paket enkapsulasi dan mengirimkan pesan Register-Stop kembali ke DR yang dimiliki S untuk mencegah DR mengenkapsulasi paket yang tidak perlu [RFC 4601].



21

Gambar 2.9 Shared RP-Tree dan Shortest Path Tree [4]

Walaupun pengiriman pesan multicast melalui shared RP-tree sudah cukup, akan tetapi jika jumlah anggota meningkat, dengan menggunakan jalur bisa saja menjadi tidak optimal lagi. PIM-SM menyediakan metode untuk menggunakan jalur terpendek untuk beberapa atau semua penerima multicast. PIM router bisa melanjutkan menggunakan RP-tree, akan tetapi PIM router juga bisa memilih penggunaan jalur terpendek berdasarkan router. Dalam situasi seperti ini, PIM-SM mengirimkan pesan Join ke node pengirim. Setelah jalur terpendek berdasarkan pengirim telah dibangun, router tersebut bisa mengirimkan pesan Prune ke RP, yang akan menghilangkan router tersebut dari RP-tree sehingga jalur yang digunakan menjadi lebih pendek [4] (Gambar 2.9). 2.2.3

Hash Function Fungsi hash digunakan oleh semua PIM-router didalam domain untuk

memetakan salah satu RP dengan pemetaan group-range-to-RP. Algoritma fungsi ini memerlukan input alamat grup multicast, alamat C-RP dari pemetaan grup, dan memberikan output alamat RP yang digunakan [RFC 4601]. Protokol ini membuat semua DR yang mendaftar di domain yang sama untuk memilih RP yang sama. Fungsi Hash yang digunakan ketika adalah: (

) ( (

(

)

))

( )

dimana C(i)adalah alamat RP dan M adalah hask-mask. Jika BSR yang digunakan, maka hash-mask diberikan didalam pesan Bootstrap. Jika BSR tidak



22

digunakan, maka mekanisme alternative yang menyuplai pemetaan group-rangeto-RP akan memberikan nilainya, apabila tidak ada maka secara default nilai mask yang digunakan adalah 30 bit untuk IPv4 dan 126 untuk IPv6 [RFC 4601]. Untuk keluarga alamat IP selain IPv4, digest 32 bit harus digunakan pada variable C(i) dan G yang mana berasal dari alamat asli RP atau grup [RFC 4601]. Untuk alamat IPv6, direkomendasikan menggunakan alamat IPv4 yang setara dan kompatibel dalam bentuk IPv4, dan melakukan exclusive-ordari setiap bagian sejumlah 32 bit segment dari alamat dalam bentuk IPv6 [RFC 4601]. Sebagai contoh, digestdari alamat IPv6 3ffe:b00:c18:1::10akan dikomputasi sebagaimana berikut (dalam bentuk hexadesimal): 0x3ffe0b00 ^0x0c180001 ^ 0x00000000 ^ 0x00000010 , dimana ^ merepresentasikan operasi exclusive-or[RFC 4601].C-RP dengan hasil tertinggi secara otomatis terpilih menjadi RP. Jika lebih dari satu RP memiliki nilai tertinggi yang sama, maka RP dengan alamat IP yang tertinggilah yang terpilih. 2.2.4

Mekanisme Bootstrap Router Pada dasarnya mekanisme Bootstrap Router (BSR) [RFC 5059] ini

adalah salah satu mekanisme protokol multicast routing di dalam PIM-SM yang menggunakan konsep adanya Rendezvous Point (RP) sebagai tempat pencarian penerima untuk mencari pengirim yang sedang melakukan pengiriman kepada grup multicast tertentu. BSR adalah cara yang ditempuh sebuah multicast router untuk mempelajari pemetaan jalur grup-ke-RP yang diperlukan untuk transmisi data. Mekanisme ini bersifat dinamis dan secara luas digunakan dan juga tahan terhadap failuredari router.



23

Gambar 2.10 Mekanisme BSR

Mekanisme BSR pada awalnya dibuat untuk menyediakan cara dimana sekumpulan RP yang dipetakan untuk tiap grup bisa dibuat dan secara cepat terdistribusi ke semua multicast-router di dalam domain. Pada Gambar 2.10, terlihat bahwa mekanisme BSR ketika pemilihan RP untuk masing – masing domain dan penyebaran data tentang RP kepada masing – masing grup di Router 4 dan 5. BSR menggunakan serangkaian informasi yang bisa mengelola objek – objek pada domain multicast. Informasi tersebut dinamakan Management Information Base (MIB)[RFC 5240] dijelaskan pada Tabel 2.6. Secara garis besar ada 4 tahap kerja mekanisme BSR walaupun di dalam praktek, semua tahap bisa terjadi secara simultan. Tahapan di bawah ini akan menjelaskan tentang mekanisme BSR secara keutuhan [RFC 5059]. 1. BSR Election.

Setiap Kandidat-BSR ditentukan oleh pesan

Bootstrap (BSM). Router di dalam domain membanjiri BSM keseluruh bagian domain. C-BSR yang mendengar prioritas yang lebih tinggi dari dirinya, akan membatasi pengiriman BSM untuk sementara waktu. C-BSR tunggal yang tersisa akan menjadi BSR dan BSM-nya akan menginformasikan semua router lainnya pada domain bahwa router tersebut terpilih menjadi BSR. 2.

C-RP Advertisement. Setiap Kandidat-RP di dalam

domain akan mengirimkan pesan Pemberitahuan-Kandidat-RP (C-RP-Adv) secara periodik di dalam domain. Pesan C-RP-Adv termasuk prioritas dari pemberitahuan C-RP, dan juga daftar rentang kelompok yang diwakili oleh C-RP tersebut. Dengan cara



24

tersebut, BSR akan mempelajari tentang RP yang sedang nyala dan mampu terjangkau. Tabel 2.6 Management Information Base (MIB)

Tabel Management

Jenis Informasi

Information Base

Berisi 1 baris untuk setiap grup prefix alamat multicast yang digunakan router Tabel Candidate-RP

local

untuk

memberitahukan

dirinya

sebagai Candidate-RP (C-RP). Tabel ini terdapat pada router yang dikonfigurasi sebagai Candidate-RP. Berisi 1 baris untuk setiap pemetaan Group-to-RP

Tabel Elected BSR RP-Set

yang

diterima

pada

pemberitahuan C-RP. Tabel ini terdapat pada router yang dipilih sebagai BSR (EBSR). Berisi 1 baris untuk setiap konfigurasi

Tabel Candidate-BSR

Candidate-BSR pada router lokal. Tabel ini

terdapat

pada

router

yang

terkonfigurasi sebagai Candidate-BSR. Berisi 1 baris untuk setiap BSR yang Table Elected-BSR

terpilih. Tabel ini terdapat pada router yang terpilih sebagai BSR.

3. RP-Set Formation. BSR memilih subset dari daftar C-RP yang telah diterima pesan C-RP-Advertisement–nya untuk membentuk RP-Set. Secara umum, cara tersebut dilakukan sedemikian rupa dengan

tujuan

agar

RP-Set

tidak

terlalu

besar

sampai

menyebabkan seluruh router di dalam domain tidak dapat diinformasikan tentangnya, dan juga tidak terlalu kecil sehingga beban tidak terkonsentrasi hanya pada beberapa RP. Dan juga



25

seharusnya membuat usaha menghasilkan RP-Set yang tidak sering berganti. 4. RP-Set Flooding.

Pada BSM yang akan datang, BSR akan

memasukkan informasi mengenai RP-Set. BSM akan dibanjiri ke seluruh domain, untuk memastikan bahwa RP-Set dengan cepat mencapai semua router di dalam domain. BSM dikirimkan berkala untuk menjaga konsistensi akibat restorasi kegagalan. 5. Group-to-RP

Mapping.

Ketika

DesignatedRouter(DR)

menerima BSM, DR tersebut menambahkan Group-to-RP Mapping

yang terdapat di dalam pesan tersebut ke dalam

gabungan dari pemetaan yang didapatkan dari sumber lainnya, semisal

konfigurasi

static

routing,

DR

tersebut

akan

mengkalkulasikan dengan fungsi Hash pada Bab 2.2.3 untuk menemukan pemetaan jalur terakhir dari alamat anggota grup multicast menuju alamat RP dari kumpulan pemetaan tabel routing yang tergantung pada aturan – aturan yang telah dispesifikkan oleh setiap protokol routing dan menggunakan informasi tersebut untuk membangun jalur distribusi dari multicast. Didalam RFC 5059 dijelaskan bahwa jika sebuah domain PIM dibagi, setiap area yang terpisah dari BSR yang lama akan memiliki BSR-nya tersendiri, yang mana akan mendistribusikan RP-Set yang berisi semua RP yang dapat dijangkau di dalam area tersebut. Ketika pembagian tersebut disatukan kembali, maka pemilihan ulang akan berlangsung secara otomatis dan hanya 1 BSR yang boleh melanjukan pengiriman BSM. Selama beberapa waktu dari pembagian atau penyatuan ulang, akan terjadi gangguan pentransmisian paket. Durasi dari periode gangguan tersebut akan terjadi selama waktu round-trip ke seluruh wilayah ditambah nilai BS_Timeout. 2.2.5

Hybrid Bootstrap Mekanisme BSR yang sebenarnya yang telah dijelaskan pada Bab 2.2.4

memerlukan flooding data keseluruh router untuk mencari kandidat RP, beberapa



26

kongesti pada trafik cenderung akan muncul di dalam domain, selain itu juga pemrosesan mekanisme BSR memerlukan waktu yang cukup lama [6]. Dibuat pemrosesan mekanisme baru yang dinamakan Hybrid Bootstrap untuk mempercepat pemilihan BSR [6]. Pada mekanisme BSR pada Gambar 2.12 telah dijelaskan pada Bab 2.2.4. Untuk prosedur tahapan 1 sampai 4, flooding data harus dilakukan kesemua router yang ada pada domain. Akan tetapi, proses – proses tersebut mungkin menyebabkan trafik pada jaringan memiliki kongesti yang akhirnya membuat waktu pemrosesan menjadi lebih lama.

Gambar 2.11 Hybrid Bootstrap Mechanism

Gambar 2.12 Bootstrap Mechanism



27

Hybrid Bootstrap memiliki kesamaan prosedur seperti Bootstrap pada prosedur tahapan 1 sampai 3 seperti yang terlihat pada Gambar 2.11a dan 2.11b adalah prosedur yang sama dengan Gambar 2.12a dan 2.12b.Akan tetapi tahapan 4 seperti yang terlihat pada Gambar 2.11c, untuk memilih 1 RP dari semua C-RP tidak dilakukan oleh DR melainkan oleh BSR. Dikarenakan BSR hanya mengetahui RP-Set pada tahapan 3 dari Gambar 2.11b, BSR bisa memilih RP. Demikian pula, BSR juga bisa memasukkan informasi dari RP kedalam BSM sebelumnya. Dengan cara ini, metode Hybrid Bootstrap dilakukan melalui pesan unicast antara DR dan BSR dengan cara: DR mengirimkan query ke BSR; lalu, BSR mengirimkan BSM yang berisi RP terpilih yang mana alamat RP ini dipilih dengan fungsi Hash (Bab 2.2.3) ke DR. Sehingga oleh karena itu, metode Hybrid Bootstrap tidak membutuhkan flooding data ke semua router pada tahapan 4 dari Gambar 2.8c. Prosedur dari metode Hybrid Bootstrap secara garis besar adalah: 1. BSR Election. Sama dengan metode BSR normal. 2. C-RP Advertisement. Sama dengan metode BSR normal. 3. RP-Set Formation. Sama dengan metode BSR normal. 4. Group-to-RP Mapping. Ketika DR menerima pesan IGMP dari anggota grup

yang termasuk grup multicast, DR akan

mengirimkan query ke BSR; lalu BSR akan mengirimkan BSM yang berisi informasi RP yang dipilih dengan fungsi Hash (Bab 2.2.3) ke DR. Sehingga DR bisa membangun jalur menuju RP yang ada. .



28

Gambar 2.13 Hasil Simulasi Hybrid Bootstrap[6]

Metode Hybrid Bootstrap ini telah dibuktikan mampu mengurangi sampai dengan 40%waktu yang digunakan oleh metode Bootstrap konvensional terlepas dari topologi yang berbeda dan/atau jumlah node yang digunakan (Gambar 2.13). Pada Hybrid Bootstrap, akan terjadi masalah beberapa saat sampai DR penerima mengetahui alamat RP. Dikarenakan BSR yang digunakan untuk menyeleksi RP untuk setiap penerima, BSR bisa memiliki banyak beban ketika banyak penerima menjadi anggota grup multicast dari suatu domain. Di sisi lain, ketika suatu penerima menjadi anggota grup multicast, semua penerima diharuskan mengirimkan query menuju BSR, sehingga overhead komunikasi bisa terjadi. 2.2.6

Proposal Relokasi RP Salah satu kekuatan dari protokol multicast adalah pengiriman data paket

yang bisa tereplikasi dengan sendirinya ketika sebuah Router mengenali alamat tujuan paket tersebut adalah alamat multicast (lihat Gambar 2.6). Dikarenakan konstruksi jalur yang paling minimum sulit dibuat, maka kebanyakan protokol multicast (salah satunya PIM) menggantungkan semua pengiriman data melewati tempat yang berpusat sama (contohnya pada Shared RP-tree). Dibutuhkan suatu pendekatan perhitungan jalur yang dipusatkan di node tertentu dimana node ini bisa menjadi representasi jarak minimum dan juga tidak memerlukan pengetahuan heuristik topologi jaringan yang ada [5]. Salah satu model perhitungan tersebut



29

adalah algoritma Distributed Center-Location [5] yang mana menjadi rujukan pembuatan ekstensi relokasi RP. Pada paper tentang algoritma distributed center-location beberapa protokol pencarian dibandingkan dengan protokol pencarian Hill-Climbing(HC). Protokol HCdigunakan untuk mengetahui bobot(weight) sebuah node dan membandingkannya terus menerus ke node tetangga untuk mencari nilai paling kecil sebuah node dan mengembalikan node dengan nilai paling minimum untuk dibandingkan dengan node (pusat) awal. Sementara untuk model perhitungan bobot node digunakan rumus sebagai berikut: (

)

∑ (

)

∑ (

)

(1)

( )) | | | |

(

(

)

)

{

, dimana S adalah semua anggota grup multicast; dupl(S) adalah jumlah dari duplikasi jarak node pada S; degree(rp) adalah prioritas C-RP (diri sendiri). Rumus ini cukup mudah diterapkan dikarenakan informasi yang dibutuhkan untuk mengkalkulasi semua jarak telah tersedia di dalam tabel routing node masing – masing (hitungan lompatan dari node awal ke node akhir). Kesimpulan yang didapatkan dari paper algoritma distributed center-location adalah ketika kebutuhan akan meminimalisir bobot jalur dari RP tertentu bersifat sangat penting, maka strategi HCbekerja dengan sangat baik dibandingkan strategi pencarian lainnya dan selama tidak ada perubahan jumlah anggota (penerima) secara signifikan (≤ 10% dari total anggota), maka node yang menjadi pemusatan jalur tidak terjadi banyak perubahan [5]. Algoritma distributed center-location (EC) ini diteliti ulang dan dibandingkan dengan beberapa algoritma lain [8] dan dilakukan beberapa peningkatan pada rumusnya (EEC).Rumus (1) diperbaiki menjadi [8]: (2)



30

[∑

[∑ (

(

)

)]

(

| |

)]

| |

| |

Est Costmaxadalah total jumlah node di Nyang merepresentasikan node yang menjadi lompatan selanjutnya (next-hop node); dan total dari setiap bobot minimum dari setiap node pada Ndan kumpulan Sn, dimanaSnadalah kumpulan penerima grup multicast yang lompatan selanjutnya (node downstream dari RP ke penerima tersebut) adalah n ∈ N. Rumus Est Costmin bisa dikalkulasi dari pengurangan jumlah node pada S dari total node di N ditambah dengan total jarak setiap penerima. Algoritma pencarian yang digunakan sebagai perbandingan [8] adalah: a) Hill-Climbing (telah dijelaskan) dengan menggunakan rumus EEC (2). b) Longest Path Algoritma ini hampir mirip dengan HC kecuali node yang diharuskan menghitung bobotnya adalah node yang letaknya paling jauh (jumlah lompatannya) dari RP. Node – node diantaranya (RP dan node terjauh) mengembalikan nilai bobot minimum ke node sebelumnya menuju RP dimana bobot minimum ini juga dibandingkan node sepanjang jalur terjauh. Untuk kasus node terjauh yang tidak unik, maka alamat node terjauh terkecillah yang dikalkulasi menggunakan rumus EEC (2) (termasuk semua lompatan node menujunya). c) All Paths Berkebalikan dengan LP, AP memilih semua node yang menjadi jalur distribusi sebagai C-RP. Oleh karena itu, RP yang terpilih



31

mengirimkan paket multicast ke semua jalur distribusi dengan pesan query dan menunggu jawaban setiap node downstream pada jalur distribusi. Semakin besar jumlah C-RP yang dievaluasi, semakin besar kemungkinan untuk mendapatkan solusi terbaik, dan semakin besar pula waktu pencarian termasuk pertukaran informasi yang dibutuhkan untuk mengkalkulasi rumus EEC (2). d) All Members Pada algoritma AM, daftar C-RP didapatkan dari semua node yang ada pada tabel routing RP yang terpilih. Berkebalikan dengan semua algoritma sebelumnya, sentralisasi perhitungan semua node C-RP dilakukan oleh RP yang terpilih. Informasi routing ini didapatkan ketika klien melakukan Join/Prune pada alamat IP multicast menuju RP sehingga setiap lompatan menuju RP yang terpilih bisa diambil dari paket yang dikirimkan. Ketika RP yang terpilih mendapatkan calon RP yang baru, RP yang terpilih akan mengirimkan data ke semua DR untuk mengganti RPnya. Dikarenakan RP yang terpilih bisa mengukur lompatan ke semua anggota multicast, maka next-hop pada rumus EEC (2) bisa diperbaiki menggunakan uplink-hop (node yang menjadi upstream tiap S) menjadi:

∑

[∑ (

(

)

)]

( )

( )

| |

Kesimpulannya [8] adalah pembandingan performa beberapa algoritma ini mendeskripsikan efek – efek menggunakan beberapa algoritma relokasi RP yang berbeda pada hal beban jaringan di jaringan multicast [8]. Algoritma HC [5] yang digunakan sebagai referensi untuk mengevaluasi performa dari algoritma



(3)

32

lainnya [5], yang mana bisa diklasifikasikan sebagai algoritma sentralisasi dan terdistribusi, dimana algoritma AP dan LP mendistribusikan pesan query menuju semua jalur dan jalur terpanjang dari jalur distribusi dengan tujuan mengkalkulasikan semua bobot dari C-RP, sedangkan AM mengkalkulasikan bobot C-RP dengan menggunakan pesan Join.

Gambar 2.15 Rasio Beban Jaringan Dengan EC [8]

Gambar 2.14 Rasio Beban Jaringan Dengan EEC [8]

Rasio truput data (Gambar 2.14 dan Gambar 2.15) menunjukkan bahwa fungsi algoritma menjadi hal utama, terutama pada algoritma AM [8]. Akan tetapi, beban pesan kontrol tergantung pada lamanya waktu hidup penerima dan seberapa sering terjadinya perubahan anggota grup. Sebagai hasil dari beban jaringan pada Gambar 2.16 dan Gambar 2.17 dapat terlihat bahwa beban meningkat dan menjadi semakin lambat seiring dengan penambahan jumlah anggota multicast [8].

Gambar 2.17 Beban Pesan Kontrol Dengan EC [8]

Gambar 2.16 Beban Pesan Kontrol Dengan EEC [8]

Pada Gambar 2.18, dapat disimpulkan bahwa relokasi RP terbaik untuk jumlah anggota multicast yang sedikit memiliki kemungkinan untuk berubah jauh dari RP sebelumnya, sementara perubahan yang terjadi dari relokasi RP secara dinamis sangat rendah dalam kasus jumlah anggota yang lebih banyak.



33

Gambar 2.18 Waktu Relokasi RP [8]

Dalam Gambar 2.18, OrigWSW (RP statis yang diperoleh karena fungsi Hash – Bab 2.2.3) memilih RP yang terpilih sebagai RP yang terbaik ketika semua node di dalam jaringan adalah anggota. Permasalahan dari beban kontrol yang meningkat dengan menggunakan algoritma relokasi bisa dianggap tidak ada pada kasus waktu hidup yang panjang dari setiap anggota multicast dengan hasil pengurangan frekuensi perubahan grup. Algorithm RPIM-SM ( G ) set_of_sources S; set_of_members R; member_of_G m; relocation_flag rFlag; relocation_timer tr; tree_cost_function TC; Begin while ( 1 ) do case hashRP: if receive 'Join' from a new member m // hashRP found by Hash function if (G.rFlag==true) then unicasts 'NEW_RP(currentRP)' to m // m send 'Join' to currentRP // m send 'Prune' to hashRP endif endif case currentRP: if ( tr expired and S changed ) then newRP = Select C_k from RPset, where TC(C_k) is minimum if reduction of TC(C_k) > q then multicasts 'NEW_RP(currentRP, newRP)' to {hashRP, sources, members} of G endif endif endwhile End Gambar 2.19 Relokasi RP untuk Grup G.[10]



34

Algoritma yang dijelaskan pada paragraf – paragraf sebelumnya hanya menjelaskan tentang bagaimana menemukan kandidat RP terbaik pada jaringan, sementara protokol ekstensi yang mengatur tentang bagaimana relokasi RP dapat terjadi [10] dijelaskan dengan pseudocode pada Gambar 2.19 untuk relokasi RP dan Gambar 2.20 untuk migrasi RP lama ke RP baru. Pseudocode pada Gambar 2.19 menjelaskan kejadian saat RP mencari tahu semua bobot CRP yang ada. hashRP adalah RP yang terpilih oleh fungsi Hash yang dijelaskan pada Bab 2.2.3, dan berfungsi RP yang terpilih pertama. Pada Gambar 2.20 menjelaskan bagaimana proses migrasi RP lama menuju RP baru yang mana setiap anggota multicast (DR yang mempunyai klien anggota multicast) melakukan Join ulang pada RP yang baru dan melakukan Prunepada RP yang lama. Algorithm ChangeRP(currentRP, newRP, G) set_of_members R; member_of_G m; relocation_flag rFlag; Begin if (newRP == hashRP) then G.rFlag = false /* return back to initial RP */ else G.rFlag = true endif G.oldRP=G.RP G.RP=newRP case newRP: send I_AM_RP message to hashRP case source: re-register to the newRP case member: send 'Join' to newRP send 'Prune' to currentRP end Gambar 2.20 Migrasi RP untuk Grup G.[10]



35

Gambar 2.21 Efek Interval Lama Waktu Relokasi [10]

Proposal ekstensi relokasi ini [10] (RPIM-SM) terbukti mampu mengurangi bobot jaringan sebanyak 20% ketika jumlah grup hanya 10. Gambar 2.21 menunjukkan bahwa semakin tinggi waktu yang ditentukan sebagai batas lamanya waktu pencarian bobot C-RP setiap grup, maka semakin lama waktu yang dibutuhkan untuk migrasi dari RP yang lama ke RP yang baru. Proposal [10] ini mengindikasikan bahwa lamanya waktu yang dibutuhkan ketika jumlah node 100 dengan keanggotaan grup yang dinamis membutuhkan sekitar 120 – 150 detik untuk merelokasi posisi RP yang terbaik. 2.2.7 User Mode Linux User-mode Linux (UML) memungkinkan banyak sistem Linux virtual yang dikenal sebagai Guest untuk menjalankan aplikasi didalam sistem Linux normal yang dikenal sebagai Host[9]. Setiap Guest adalah aplikasi normal yang berjalan sebagai proses didalam user space, yang membuat pendekatan tersebut bisa menyediakan pengguna untuk menjalankan banyak mesin Linux virtual pada satu hardware, yang juga menyediakan keamanan dan keselamatan tanpa mempengaruhi konfigurasi lingkungan Host atau stabilitas. 2.2.8

Python Python adalah bahasa pemrogramanInterpreter tingkat tinggi untuk

dengan tujuan bebas yang mana filosofi desainnya dititikberatkan pada kemampuan pembacaan kode yang mudah. Sintaksnya termasuk jelas dan ekspresif, seperti pada Gambar 2.22. Python memiliki library standar yang besar dan komprehensif.



36

>>> class Student: ... def __init__ (self, name, age, gender): ... self.name = name ... self.age = age ... self.gender = gender ... >>> Sue = Student("Susan Miller", 20, "f") >>> print Sue <__main__.Student instance at 0x81a96cc> >>> print Sue.age 20 Gambar 2.22 Contoh Kode Python Sederhana

Python mendukung paradigm pemrograman yang banyak, termasuk object-oriented, imperative dan gaya pemrograman fungsional. Python juga memiliki fitur sistem perekam dinamis dan manajemen memori otomatis, yang sama seperti Scheme, Ruby, Perl, and Tcl. Seperti bahasa dinamis yang lainnya, Python juga seringkali dipakai menjadi bahasa scripting akan tetapi juga digunakan konteks non-scripting dalam jangkauan

yang luas. Dengan

menggunakan alat third-party, kode Python bisa dikemas menjadi program tunggal yang bisa dieksekusi. Interpreter Python tersedia dalam dan didukung oleh banyak sistem operasi.



37

BAB 3 RANCANGAN SISTEM 3.1

Kompilasi Sistem Rancangan skenario analisa relokasi RP ini akan diterapkan dalam

virtualisasi komputer yang digunakan untuk menjalankan aplikasiyang memiliki kebutuhan khusus untuk menjalankan simulasi relokasi PIM-SM dengan mekanisme Hybrid Bootstrap didalamnya. Virtualisasi komputer ini yang digunakan sebagai landasan pengerjaan rancangan skenario ini. Komputeryang digunakan untuk pengerjaan pemodelan rancangan skenario ini memiliki spesifikasi yaitu: a) Laptop dengan processor I7 dan kapasitas memori RAM 4 GB. b) OS: Ubuntu Desktop 12.04 dengan kernel 3.2++. c) Virtualisasi UML (User Mode Linux) [9]: a. Kernel: 32 bit dengan versi 3.0++ →dengan kustomisasi [dijelaskan pada Bab 3.2] b. Distro: Linux Debian Squeeze c. Memori: 64 MB untuk Klien dan 128 MB + 256 MB SWAP untuk Router. d. uml_switch: penghubung jalur antar node UML (yang diasumsikan sebagai Switch pada dunia nyata) d) Bahasa Pemrograman Python 2.7++ dengan library tambahan: ipaddr [7].

3.2 Perancangan Model Simulasi Topologi untuk studi model rancangan skenario pada Tesis adalah topologi dengan masing – masing router seperti yang terlihat pada Gambar 3.1, terhubung satu dengan yang lain melalui Internet. Dengan menggunakan prefixheader alamat IPv6 Global Unicast Address yang telah dispesifikasikan oleh

37



38

RFC 3587, masing – masing router memiliki prefix alamat 2000::/3, dan masing – masing router adalah multicast router yang juga berfungsi sebagai DR dan C-RP.

R01 R02

R04

R03

R05

R06

R07

Gambar 3.1 Model Topologi pada OMNeT++

Total terdapat 15 router C-RP (diwakili dengan bulatan berwarna putih) dan 1 router C-BSR yang secara otomatis menjadi BSR (diwakili dengan bulatan berwarna biru) ditambah workstation yang bisa ditambahkan ke setiap router. Router C-RP yang berhadapan dengan workstation berlaku pula sebagai DR untuk workstation tersebut. Tabel 3.1Konfigurasi Model Rancangan Skenario

Nama R01 R02 R03 R04 R05 R06 R07 Client-R1 Client-R2 Client-R3 Client-R4 Client-R5 Client-R6 Client-R7 BSR

Alamat IPv6 (eth0) 2001:1::1/64 2001:2::2/64 2001:3::3/64 2001:4::4/64 2001:5::5/64 2001:6::6/64 2001:7::7/64 2002:1::9/64 2002:2::9/64 2002:3::9/64 2002:4::9/64 2002:5::9/64 2002:6::9/64 2002:7::9/64 2001::137/64

Alamat IPv6 (eth1) 2002:1::1/64 2002:2::1/64 2002:3::1/64 2002:4::1/64 2002:5::1/64 2002:6::1/64 2002:7::1/64 -

Alamat IPv6 (eth2) 2001:2::1/64 2001:4::2/64 2001:6::3/64 -

Alamat IPv6 (eth3) 2001:3::1/64 2001:5::2/64 2001:7::3/64 -

Dengan program Python untuk mensimulasikan protokol relokasi pada grup multicast, rancangan desain topologi diatas didasarkan oleh standar protokol



39

IPv6, dimana masing – masing workstation akan mengirimkan paket data multicast terus menerusdimulai pada saat workstasion yang termasuk dalam anggota grup multicast. Topologi diatas dipilih agar hasilnya bisa dibandingkan dengan [6] dan [8]. Selain itu pula, topologi ini lebih mudah memperlihatkan proses penyeleksian cost pada skenario yang akan dijelaskan pada Bab 3.4. Untuk proses penelitian, masing – masing router dan workstation memiliki identitas MAC dan alamat IPv6 yang berbeda – beda seperti yang terlihat pada Tabel 3.1. Untuk alamat IPv6 yang digunakan dalam Tesis ini adalah alamat yang termasuk dalam notasi Global Unicast Address (lihat Tabel 3.1). Untuk kolom “Client-Rx” dimaksudkan untuk klien – klien yang ada ditangani oleh DR, dimana alamat yang digunakan berawal 2002:x::0/64 dimulai dari 2002:x::9 sampai dengan batas subnet (x berarti identitas router yang menanganinya). Sedangkan untuk alamat grup multicastnya tersendiri memakai alamat multicast IPv6: ff00::123. 3.3

Perancangan Model Aliran Paket Untuk melakukan simulasi PIM-SM dengan relokasi, aliran data

memerlukan format setiap paketnya. Paket kontrol adalah paket yang khusus berfungsi untuk melakukan fungsi kontrol (semisal paket PIM_JOIN dari DR ke RP yang terpilih), sedangkan paket data adalah paket yang khusus digunakan untuk mengirim data yang bisa diolah oleh klien.



40

Gambar 3.2 Aliran Paket Pada Simulasi

Aliran paket pada simulasi Tesis ini dijelaskan pada Gambar 3.2 yang akan didetilkan pada tahap – tahap yang dijelaskan lebih lanjut. Paket kontrol memerlukan persyaratan penting yaitu kepastian data sampai pada tujuan, selain itu pada umumnya ukuran paket tidak terlalu besar (sebagaimana pada paket data, membutuhkan ukuran paket yang besar). Oleh karena itu aliran paket kontrol menggunakan protokol TCP yang bersifat connection-oriented. Protokol ini digunakan agar paket kontrol dipastikan sampai kepada tujuan. Sedangkan untuk paket data memiliki beberapa kriteria yang berbeda dengan paket kontrol, dimana salah satunya adalah transmisi data diusahakan seminim mungkin hilang di tengah jalan atau di-drop oleh router yang dilewatinya. Paket data ini menggunakan protokol UDP yang bersifat connectionless dikarenakan kekuatan protokol ini pada kesederhanaan pemaketan data dan transmisi yang sekali jalan (pada protokol TCP, transmisi dilakukan beberapa kali, lihat Gambar 3.3). Akan tetapi protokol ini memiliki kelemahan



41

juga, dikarenakan state pengiriman data sangat sederhana maka tidak ada jaminan apakah data yang terkirim telah diterima atau hilang di tengah jalan.

Gambar 3.3 Aliran Protokol TCP

Pada simulasi ini semua paket menggunakan standar Bit. Paket – paket kontrol yang digunakan dari pertama sampai selesai adalah: 1. Deklarasi C-RPadvertisement [RFC 5059 & RFC 4601:Candidate-RPAdvertisement] Pada

saat

pertama

kali

simulasi

dijalankan,

PIM-router

yang

dideklarasikan menjadi RP mengirimkan paket pada Gambar 3.4 dengan ekstensi Gambar 3.5 dan Gambar 3.6kepada BSR untuk mendeklarasikan diri sebagai C-RP yang nantinya dari hasil tersebut BSR akan memilih hashRP dari tabel RP_Set (Gambar 4.1). 4 1 2

PIM Ver=2

8 Type=8

Prefix-Cnt=128

12

16

20

24

Reserved=0

Checksum

Priority=0

Holdtime=0

3

Encoded-Unicast-RP-Address

4

Encoded-Group Address

28

32

28

32

Gambar 3.4 Candidate-RP-Advertisement

4 1

Addr Family=2

8

12

16

20

Encoding Type=0

24 Reserved=0

2 3

Unicast Address

4 5

Gambar 3.5 Encoded-Unicast-Address



42

4 1

8

Addr Family=2

12

16

Encoding Type=0

20

24

28

Reserved

32

Mask Len=128

2 3

Group Address

4 5

Gambar 3.6 Encoded-Unicast-Group-Address

a. Konfirmasi C-RP dari BSR (Orisinil) Konfirmasi ini diberikan dari BSR bahwa BSR sudah mendapatkan paket C-RP advertisement dari C-RP yang mengirim dengan mengembalikan paket yang telah dikirim sebelumnya.(Gambar 3.4). 2. Pemberitahuan pada hashRP (Orisinil) Pemberitahuan pada Gambar 3.7 ini dibuat dikarenakan mekanisme Bootstrap yang dipakai adalah Hybrid Bootstrap tidak menggunakan membanjiri (flooding pada Bab 2.2.4) jaringan dengan RP_Set agar setiap PIM-Router mengetahui daftar C-RP dan RP yang terpilih. Yang menjadi permasalahan adalah ketika C-RP tidak menjadi

RP yang

terpilih, walaupun C-RP menerima paket data dari klien yang menjadi anggota multicast, C-RP tersebut tidak akan melakukan operasi apapun dengan data yang diterimanya. Oleh karena itu dibutuhkan suatu metode tersendiri untuk memberitahu hashRP dari daftar RP_Set. 4 PIM Ver=2

8 Type=10

12

16

20

Reserved=0

24

28

32

Checksum

Gambar 3.7 Pemberitahuan hashRP

3. Query DR pada BSR (Orisinil) Dengan alasan yang sama pada paket kontrol sebelumnya, dikarenakan BSR tidak membanjiri jaringan terus – menerus dengan RP_Set, maka diperlukan suatu metode Query tersendiri sehingga DR bisa mendapatkan RP_Set dan memilih hashRP dari tabel RP_Set tersebutdengan paket pada Gambar 3.8



43

4

8

PIM Ver=2

12

16

20

24

Reserved=0

Type=9

28

Checksum

Gambar 3.8 Query RP_Set Dari DR

a. Pengiriman RP_Set dari BSR [RFC 4601 & RFC 5059:Bootstrap Message] Setelah query dari DR (Gambar 3.9) diterima oleh BSR, maka BSR akan mengirimkan paket RP_Set kepada DR yang meminta. Format paket data yang dikirimkan dijelaskan pada Gambar 3.9 dengan ekstensi Gambar 3.5 (untuk alamat BSR), Gambar 3.6, dan Gambar 3.5 (untuk alamat RP dalam daftar RP_Set).Kolom Hash Mask Length ini digunakan BSR untuk mengkalkulasikan fungsi pada Bab 2.2.3, dimana secara default BSR akan menghitung fungsi tersebut dengan memasukkan nilai 126 sebagai Mask Len. Pesan Bootstrap inilah yang pada mekanisme BSR konservatif yang dikirimkan dengan flooding paket pada jaringan. Kolom kelima sampai ketujuh akan terus diulangi sebanyak nilai yang ada pada kolom RP-Count sampai daftar RP_Set selesai ditulis semua. 4 1 2

PIM Ver=2

8 Type=4

12

16

20

Fragment Tag=Angka_Random

Hash Mask Length=126 Encoded-Unicast-BSR-Address

4

Encoded-Group Address RP-Count=Jumlah_C-RP

32

Frag RP-Cnt=128

BSR Priority=255

Reserved=0


6 7

28

Checksum

3

5

24

Reserved=0

RP-Holdtime=0

RP-Priority=0

Reserved=0

Gambar 3.9 Bootstrap Message

b. DR mengecek semua jalur ke setiap C-RP pada tabel RP_Setdan dikirimkan ke BSR (Orisinil) Setelah DR mendapatkan RP_Set dari BSR, maka yang dilakukan DR adalah mencari semua jalur menuju semua C-RP pada RP_Set, dengan cara menelusuri jalur tersebut dengan paket ICMPv6 dan UDP sampai pada tujuan. Gambar 3.10 menjelaskan bagaimana kode pseudocode penelusuran jalur menuju suatu alamat. Ketika DR



32

44

sudah melakukan probing ke semua C-RP, DR akan mengirimkan hasilnya kedalam paket dengan format pada Gambar 3.11. Format paket ini diberikan tipe 12. Kolom Number of Path menunjukkan banyaknya kolom 3 – 19 diulangi untuk setiap jalur yang ditemukan menuju C-RP. Sedangkan kolom Number of Joined Sources menunjukkan berapa banyak klien yang menjadi anggota multicast yang terdaftar pada DR tersebut. Sedangkan kolom Hops Number diberikan untuk penelusuran jalur yang selalu dimulai dari alamat DR tersebut pada kolom DR Address sampai dengan tujuan. thepath = [] port = 33434 my_addr = DR_Address for dest_addr in RP_Set: max_hops = 30 ttl = 1 thepath = [] while True: recv_socket = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_ICMPV6) send_socket = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) send_socket.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_UNICAST_HOPS, struct.pack('!BBH',ttl,0,0)) recv_socket.bind(("", port)) send_socket.sendto("", (dest_addr, port)) curr_addr = None curr_name = None try: _, curr_addr = recv_socket.recvfrom(512) curr_addr = curr_addr[0] except socket.error: pass finally: send_socket.close() recv_socket.close() if curr_addr is not None: curr_host = "%s (%s)" % (curr_name, curr_addr) else: curr_host = "*" if my_addr[len(my_addr)1]!=curr_addr[len(curr_addr)-1]: thepath.append(curr_addr) ttl += 1 if curr_addr == dest_addr or ttl == max_hops: break PATH.append(thepath) Gambar 3.10 Tracing Hops Pseudocode



45

4 1

PIM Ver=2

8

12

16

20

24

Reserved=0

Type=12

28

Checksum

2

Number of Path=m

Number of Joined Sources=n

3

Hops Number=X

Reserved=0

4 5

DR Address

6 7 8 9

1st Hop

10 11 12 13

……

14 15 16 17

Xth Hop

18 19

Gambar 3.11 Format Kontrol Jalur DR ke-RP_Set

c. BSR mengkalkulasi semua nilai C-RP pada RP_Set dengan algoritma AM dan fungsi (3) [8] 4. Klien mendaftarkan dirinya pada DR[RFC 3810:Version 2 Multicast Listener Report Message] Dikarenakan metode pendaftaran klien untuk menjadi anggota multicast masih dalam tahap pengembangan pada IPv6, maka simulasi ini menggunakan format paket kontrol pendaftaran klien MLDv2 pada IPv4. Format paket tersebut seperti yang digambarkan pada Gambar 3.12. Pada dasarnya, jumlah multicast group yang terdaftar bisa saja banyak, yang mana jumlah tersebut akan ditulis dikolom Nr of Mcast Address Recordssehingga kolom ketiga sampai dengan kolom keenam akan ditulis ulang sebanyak jumlah tersebut yang berisi grup alamat multicast yang didaftarkan pada DR oleh klien. Dikarenakan pada simulasi ini, alamat multicast yang digunakan hanya 1, maka kolom tersebut hanya berisi 1.



32

46

4

8

Type=143

1

12

16

20

24

Reserved=0 Reserved=0

2

28

32

Checksum Nr of Mcast Address Records=1

3 4

Multicast Address Record=ff00::123

5 6

Gambar 3.12 Version 2 Multicast Listener Report Message

5. DR mengirimkan PIM_JOIN dan PIM_PRUNE pada RP yang terpilih [RFC 4601:PIM JOIN] Tahap pengiriman PIM_JOIN dari DR pada RP ini akan dilakukan berulang – ulang mulai dari tahap hashRP terpilih dari RP_Set sampai setiap relokasi RP terjadi. Pada kolom Num groups hanya diisi 1 karena alamat multicast yang digunakan pada simulasi ini hanya 1, sementara untuk Number of Pruned Sources diisi nilai 0 ketika sedang melakukan PIM_JOIN, dan sebaliknya Number of Pruned Sources akan diisi ketika DR melakukan relokasi.Number of Joined Sourcesdan Number of Pruned Sourcesakan diisi sebanyak klien yang mendaftarkan dirinya dengan format di paket kontrol pada Gambar 3.12. Paket pada Gambar 3.13 ini dikirimkan dengan ekstensi pada Gambar 3.14. 4 1

PIM Ver=2

8 Type=3

4 5 6 7

16

20

24

28

32

Checksum

Upstream-Neighbor Address (Encoded-Unicast format)

2 3

12 Reserved=0

Reserved=0

Num groups=1

Holdtime=0

Multicast Group Address (Encoded-Group format) Number of Joined Sources=n

Number of Pruned Sources=0

Joined Source Address 1 (Encoded-Source format) ……

8 9

Joined Source Address n (Encoded-Source format)

Gambar 3.13 PIM JOIN



47

4

8

12

Addr Family=2

1

16

Encoding Type=0

20

24

Reserved=0

| S|W|R|

28

32

Mask Len

2 3

Source Address

4 5

Gambar 3.14 Encoded-Source Address

6. Pemberitahuan alamat RP yang baru dari BSR ke RP yang baru, RP yang lama, semua DR yang terdaftar, dan BSR (Orisinil) Ketika counter waktu sudah habis BSR yang sudah mendaftar semua nilai hash dan juga nilai cost dengan algoritma (3) didalam RP_Set yang telah dimodifikasi akan mengirimkan pemberitahuan kepada RP yang baru terlebih dahulu dengan format Gambar 3.15 dengan ekstensi Gambar 3.5.Sebelumnya BSR memilih alamat RP yang baru pada RP_Set sebagai RP saat ini. Setelah RP yang baru mengembalikan paket dengan format yang sama (Gambar 3.15 dengan ekstensi Gambar 3.5), BSR akan mengirimkan paket dengan format Gambar 3.15 dengan ekstensi Gambar 3.4 kepada RP yang lama sehingga RP yang lama bisa mengirimkan semua datanya kepada RP yang baru. Setelah mengirimkan paket control tersebut ke RP yang lama, BSR akan mengirimkan paket dengan format Gambar 3.15 dengan ekstensi Gambar 3.5 kepada semua DR yang telah tercatat melakukan query RP_Set pada RP yang lama untuk melakukanPIM_PRUNE pada RP yang lama danPIM_JOIN ulang kepada RP yang baru. Pada tahap ini, RP yang baru hanya akan menampung data dari DR sebelum RP yang lama mengirimkan pemberitahuan pada nomor 7. 4 1

PIM Ver=2

8 Type=10

12

16

20

Reserved=0

24

28

32

Checksum


2

Gambar 3.15 Pemberitahuan BSR Tentang Alamat RP Yang Baru

7. Pemberitahuan RP yang lama tidak menerima data lagi ke RP yang baru (Orisinil)



48

Setelah RP yang lama tidak lagi menerima data dari semua anggota multicast, maka RP yang lama akan mengirimkan paket dengan format 3.16 kepada RP yang baru agar RP yang baru dapat melanjutkan kiriman setelah DR melakukan PIM_JOIN ulang kepadanya. RP yang lama setelah mendapatkan format paket Gambar 3.16 akan melanjutkan transmisi data yang sebelumnya ditahan. 4 1

8

PIM Ver=2

Type=13

12

16

20

Reserved=0

24

28

32

Checksum

Gambar 3.16 Pemberitahuan RP Lama Selesai

Untuk tabel RP_Set dikarenakan mekanisme Hybrid

Bootstrap

menggunakan pengiriman unicast kepada DR yang melakukan query dan fungsi perhitungan nilai hash dilakukan oleh BSR maka table RP_Set [RFC 5240:PimBsrCandidateRPEntry] diberikan kolom tambahan yang menyatakan status RP yang terpilih dan juga nilai RP tersebut menurut model matematika (3) dengan algoritma AM. Dengan tambahan tipe yang ada pada kolom kedua setelah PIM_Version dari setiap format paket yang dijelaskan diatas, maka semua format tipe yang belum ada pada RFC 4601 dijelaskan pada Tabel: Tabel 3.2 Tipe Pesan PIM-SM

Nomor Pesan 3 4

9 12 10

Tipe Pesan Join/Prune Bootstrap Candidate-RPAdvertisement Query RP_Set Trace To RP_Set RP Ready

13

RP Finished

8

Tujuan DR --> RP Terpilih BSR --> DR C-RP --> BSR DR --> BSR DR --> BSR BSR --> RP RP Lama --> RP Baru



49

4

8

12

16

1

20

24

28

32

Sending Time

2 3 4

Source Address

5 6 7

Packet Number

Reserved=0

8 9

Padding=REST OF PACKET SIZE

10 11

Gambar 3.17 Format Paket Data

Dan untuk model aliran paket data dari anggota multicast, format paket data ditunjukkan pada Gambar 3.17. 3.4

Perancangan Model Virtualisasi Pada proses perancangan model UML, kernel harus dikustomisasi agar

mampu menjalankan simulasi dengan optimal. Beberapa modul yang harus diaplikasikan adalah: 1. Modul UML, contoh pada Gambar 3.18 CONFIG_UML_X86=y CONFIG_X86_32=y Gambar 3.18 Konfigurasi UML Untuk Komputer 32 Bit

2. Modul Networking, contoh pada Gambar 3.19 CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # CONFIG_XFRM_SUB_POLICY is not set CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_ROUTE_CLASSID=y Gambar 3.19 Konfigurasi Networking Untuk UML



50

3. Modul IPv6 [RFC 2460]; [RFC 3513]; [RFC 4861], contoh pada Gambar 3.20 CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_IPV6_OPTIMISTIC_DAD=y CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_SUBTREES=y CONFIG_IPV6_MROUTE=y CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y CONFIG_IPV6_PIMSM_V2=y Gambar 3.20 Konfigurasi IPv6 Untuk UML

Untuk sistem operasi yang dipilih Penulis adalah Linux dengan distro Debian Squeeze, dikarenakan simulasi didalamnya membutuhkan kemudahan konfigurasi program dan pemrograman yang cepat dan juga sistem operasi yang tidak membawa banyak aplikasi yang tidak perlu (tidak semua sistem operasi Linux memiliki bawaan aplikasi yang sederhana ketika pertama kali menginstal). Setelah UML berjalan seperti pada Gambar 3.21, maka UML telah berhasil dijalankan. Setiap node UML dijalankan dengan memori sebanyak 64 MB.

Gambar 3.21 Node UML Dengan Memori 64 MB dan Prosesor 32 bit.

Permasalahan berikutnya adalah bagaimana setiap node bisa terhubung satu dengan yang lainnya. Ada dua solusi yang bisa diterapkan, static routing atau dynamic routing. Untuk mempermudah jalannya simulasi, dynamic routing diterapkan pada tiap router yang ada, sedangkan static routing diterapkan pada



51

setiap klien yang berhubungan dengan router. Aplikasi Quagga [11] diinstal pada setiap node UML, dimana OSPFv3 dipilih sebagai protokolnya dikarenakan mampu menangani alamat IPv6. password router ! !adapter setup interface eth0 interface eth1 interface eth2 interface eth3 router ospf6 router-id 0.0.0.3 redistribute connected interface eth0 area 0.0.0.0 interface eth1 area 0.0.0.1 interface eth2 area 0.0.0.0 interface eth3 area 0.0.0.0 Gambar 3.22 Contoh Konfigurasi ospf6d.conf Pada Router R02

hostname R02 password router ! interface eth0 description R2R link-detect multicast ipv6 address 2001:2::2/64 ! interface eth1 description R2C link-detect multicast ipv6 address 2002:2::1/64 ipv6 nd prefix 2002:2::0/64 ! interface eth2 description R2R link-detect multicast ipv6 address 2001:4::2/64 ! interface eth3 description R2R link-detect multicast ipv6 address 2001:5::2/64 ! interface lo link-detect ! debug zebra kernel log file /tmp/zebra.log informational Gambar 3.23 Contoh Konfigurasi zebra.conf Pada Router R02



52

Konfigurasi Quagga setiap router diatur seperti pada Gambar 3.22 dan Gambar 3.23, dimana “xx” diganti dengan alamat yang dijelaskan pada Tabel 3.1. Untuk alamat IP dalam node yang sama yang menghadap ke bawah (bukan eth0) diganti dengan alamat node yang menghadap ke node yang dijelaskan pada Tabel 3.1. 3.5

Algoritma Relokasi Pada algoritma relokasi [10] yang telah diteliti dan dijelaskan pada Bab

2.2.6, desain algoritma relokasi dilakukan ketika counter waktu sudah habis, pengecekan anggota dari multicast dilakukan. Jika anggota multicast tersebut berubah, maka proses relokasi dilkukan. Pada skenario Tesis ini, relokasi tidak hanya dilakukan ketika counter waktu sudah habis dan/atau anggota dari multicast berubah akan tetapi modifikasi relokasi terjadi pada saat counter waktu sudah habis walaupun anggota dari multicast tidak berubah. # ARRANGE TIME WAIT BETWEEN PACKET SENDING inter_departure_time = 1./PACKETS_PER_SEC # START PACKET NUMBER FROM 1 packet_count_snd = 1 print "### S: send data" # UDP SOCKET snd_sock6 = socket.socket(socket.AF_INET6,socket.SOCK_DGRAM) # PADDING FOR COMPLETING PACKET AS BIG AS PACKET_SIZE padding='' for j in range (28,PACKET_SIZE): padding = padding+struct.pack('!B',255) source_ip = mpl.checkAddr('eth0') source_binary = socket.inet_pton(socket.AF_INET6,mpl.checkAddr('eth0')) # SEND PACKET AS MANY AS NR_OF_PACKETS for i in range (1,NR_OF_PACKETS+1): # WAIT BETWEEN PACKET time.sleep(inter_departure_time) # USE START TIME, NOT LOCAL TIME send_time = START_TIME + (time.time() - LOCAL_TIME) # SEND PACKET DATA ret = snd_sock6.sendto(struct.pack('!d16sHH',send_time,source_bin ary,packet_count_snd,0)+padding,(FORWARD_IP,FORWARD_PORT)) # LOGGING PACKET SIZE, DESTINATION IP, DESTINATION PORT, SOURCE IP, SEND TIME, PACKET NUMBER # ADD COUNTER packet_count_snd = packet_count_snd+1 Gambar 3.24 Algoritma Transmisi



53

Selain itu pula, akan diukur bandwidth yang digunakan pada setiap node PIMRouter sehingga bisa dianalisa bandwidth yang ada pada setiap RP. Program untuk menjalankan simulasi ini dibagi menjadi 3 hal, kode program pada PIMRouter untuk fungsi DR dan RP, kode program pada Klien untuk fungsi klien anggota multicast, kode program pada BSR untuk fungsi Bootstrap. Secara garis besar, skenario kerja mekanisme ini digambarkan pada Gambar 3.24 dimana terdapat 4 tahap utama dalam setiap kejadian/tahapan dalam relokasi. Tahap – tahap tersebut adalah: 1. Tahap Transmisi: Tahap pada Gambar 3.26 ini mewakili tahapan transmisi pengiriman paket multicast dari setiap S (pengirim paket multicast) ke RP dan sebaliknya dari RP ke setiap S yang termasuk dalam anggota multicast. Transmisi ini bersifat kontinyu dan hanya bisa berlanjut ke tahap selanjutnya jika RP selama periode t (waktu) telah habis untuk paket data multicast dari S yang ditetapkan untuk RP tersebut telah terlewati. 2. Tahap Seleksi: Pada tahap awal ketika DR melakukan query data pada BSR, BSR melakukan perhitungan cost dari setiap C-RP. Tahap ini menggunakan algoritma yang telah diterapkan pada [8] yakni All Members Algorithm (AM) dimana semua pencarian algoritma dilakukan oleh BSR (pseudocode pada Gambar 3.25). Hasil setiap cost C-RP yang telah dihitung oleh BSR, nilai cost C-RP diletakkan

pada

tabel

RP_Set

yang

telah

dimodifikasi.

Sebelumnya, setelah DR melakukan query RP_Set, secara otomatis DR mengirimkan informasi paket yang berisi informasi jumlah Hops/lompatan dari DR ke setiap C-RP pada RP_Set yang telah didapatkan DR dari BSR. Setelah itu DR akan mengirimkan paket HOPS_CHECK pada setiap C-RP kepada BSR agar RP tersebut bisa menghitung bobot semua C-RP termasuk RP itu sendiri.



54

def am_algorithm(TRACE_TABLE,RP_TABLE): for dest in RP_TABLE: print "\n##### C-RP IP %s ######" % dest dupl_uplink = {} dupl_source = {} for ip in RP_TABLE: dupl_uplink[ip] = 0 for ip in RP_TABLE: dupl_source[ip] = 0 dupl_uplink_value = 0 dupl_source_value = 0 max_s2u = 0 source_number = 0 path_u2rp = 0 # SOURCES DUPLICATE DISTANCE for row in TRACE_TABLE: row_value = 0 for column in row: if isinstance(column,int): row_value = column if column[len(column)-1] == dest: for dr in dupl_source: if dr in column: dupl_source[dr] += row_value # UPLINK DUPLICATE DISTANCE for column in row: if isinstance(column,int): continue if column[len(column)-1] == dest: if len(column) == 1 and column[0] == dest: break else: for dr in dupl_uplink: if dr in column: if dr == dest: continue dupl_uplink[dr] += 1 break else: continue # MAX HOPS NUMBER FROM UPLINK TO SOURCES AND SOURCES NUMBER AND NUMBER OF EVERY HOPS FROM RP TO SOURCES for column in row: if isinstance(column,int): source_number += column continue if column[len(column)-1] == dest: path_u2rp += len(column) if max_s2u == 0: max_s2u = len(column) elif max_s2u < len(column): max_s2u = len(column) for ip in dupl_uplink:



55

if dupl_uplink[ip] > 1: dupl_uplink_value += 1 for ip in dupl_source: if dupl_source[ip] > 1: dupl_source_value += 1 print "UPLINK DUPLICATE DISTANCE FOR %s IS %d" % (dest,dupl_uplink_value) print "SOURCES DUPLICATE DISTANCE FOR %s IS %d" % (dest,dupl_source_value) print "MAXIMAL HOPS FROM SOURCES TO UPLINK IS %d" % (max_s2u) print "PATH FROM DR TO RP NUMBER IS %d" % (path_u2rp) print "SOURCES NUMBER IS %d" % (source_number) print "THIS C-RP %s VALUE IS %.2f" % (dest,(max_s2u+dupl_source_value+dupl_uplink_value+path_u2rp+sourc e_number)/2) Gambar 3.25 All Middle Algorithm (3)

3. Tahap Transisi: Tahap ini terjadi ketika BSRyang telah mendapatkan bobot/cost dari setiap C-RP yang ada dan membandingkan antara bobot CRP dengan bobot hashRP saat ini ditambah threshold yang dispesifikasikan secara manual pada BSR untuk mendapatkan lokasi RP terbaik dari setiap RP_Set. Tahap transisi ini membutuhkan BSR saat ini untuk mengirimkan paket NEW_RP pada C-RP yang terpilih menjadi RP baru.Ketika ada lebih dari 1 C-RP yang terseleksi oleh nilai cost yang kurang dari nilai cost sebelumnya (nilai cost RP saat ini ditambah dengan threshold), maka semua C-RP yang terseleksi akan dimasukkan ke dalam himpunan untuk dipilih secara random dari himpunan tersebut CRP yang terpilih. Tahap ini berakhir ketika C-RP yang terpilih mengirimkan paket READY ke BSR yang lama. 4. Tahap Relokasi: Tahap relokasi terjadi ketika C-RP yang baru terpilih telah mengirimkan paket kepada BSR yang menandakan bahwa C-RP tersebut telah siap untuk menjadi RP yang baru (secara default, CRP tidak akan melakukan apa – apa ketika mendapatkan paket multicast dari S ketika C-RP tersebut belum berfungsi menjadi



56

RP). Setelah penerimaan paket READY, BSR akan mengirimkan paket NEW_RP ke RP lama dan semua DR yang telah tercatat ketika melakukan query RP_Set. Selama proses relokasi terjadi, RP akan meneruskan sisa paket yang diterimanya sampai paket terakhir (yang telah ditandai oleh DR sebagai paket terakhir darinya) dari setiap DR, lalu meneruskannya ke RP baru sampai DR tidak tersisa lagi. Sementara pada RP baru akan menahan setiap paket multicast sampai semua paket dari RP lama selesai dikirimkan ulang oleh RP yang baru.

BSR mengirimkan perubahan alamat RP pada RP lama dan semua DR

≤

Gambar 3.26 Aliran Kerja Algoritma Skenario

Bobotpada tahap Seleksi (Gambar 3.25) direpresentasikan sebagai matematika model yang telah ada pada Bab 2.2.6 [8] dimana “S” adalah anggota grup multicast; “rp” adalah RP yang sedang terpilih;“U” adalah kumpulan uplink hop dari S; dan dupl(S) dan dupl(R) adalah jumlah jarak duplikasi node pada S dan U; (3) dimana: ( (

))

( )

( )



57

dan, [∑ (

)]

| |

Pada persamaan (1), cost yang diestimasi adalah cost jumlah dari distribusi tree yang berakar pada C-RP sebagai root dan uplink hop sebagai member juga. Persamaan (3) digunakan untuk mencari lokasi RP terbaik yang mampu mendeteksi jalur yang memiliki banyak S sehingga relokasi RP kemungkinan dilakukan diarah yang paling banyak memiliki anggota multicast S.

* |

(

)+

(4)

Dalam skenario ini, BSR bertugas untuk mendapatkan semua cost ketika DR melakukan query pada BSR pertama kali danthreshold yang bervariasi mulai dari 0 yang berarti perubahan lokasi RP jika dan hanya jika terdapat anggota multicast yang berubah sampai 10 dimana tidak tergantung oleh fungsi waktu. Pada persamaan (4), himpunan kandidat RP yang akan dipilih, ditentukan dengan memilih cost C-RP yang kurang dari nilai minimal cost RP terbaik (posisi terbaik) dan RP yang dipilih sebagai tujuan relokasi diambil secara random dari himpunan kandidat RP tersebut. Semakin tinggi nilai threshold walaupun tanpa ada perubahan pada jumlah anggota multicast, relokasi RP tetap bisa terjadi. Semakin tinggi nilai threshold juga akan menyebabkan relokasi dapat dilakukan semakin jauh dari RP yang terpilih dan sebaliknya, semakin rendah nilai threshold perubahan RP hanya akan terjadi semakin dekat dengan RP yang terpilih. Dalam skenario ini, semua batasan bandwidth untuk setiap C-RP dianggap sama. 3.6

Faktor Skenario Penelitian Pada trafik IPv6 multicast di skenario Tesis ini dengan relokasi PIM-SM

dengan mekanisme Hybrid Bootstrap, faktor – faktor yang akan dianalisa dinilai berdasarkan throughputdan juga kelancaran trafik data. Faktor ini pada berpusat pada beberapa kriteria di bawah ini:



58



Threshold Jumlah threshold diukur mulai dari 0 sampai 10 sehingga dapat dianalisa sejauh apa relokasi RP terjadi.



Counter Waktu Untuk Perelokasian Tempat Counter waktu ini digunakan untuk mengukur apa yang terjadi ketika relokasi RP berubah dalam jangka waktu yang berbeda.



Jumlah Klien dan DR Jumlah klien yang menjadi anggota grup multicast dan DR yang mewakilinya dapat mempengaruhi kriteria relokasi RP yang dapat terjadi.



Ukuran Paket Data Multicast Ukuran paket data multicast yang dikirim oleh setiap anggota multicast akan mempengaruhi pula proses terjadinya relokasi RP yang terjadi.

Standar tersebut akan digunakan untuk penelitian faktor penunjang apa sajakah yang harus diperhitungkan dalam trafik multicast IPv6 pada skenario ini. Dengan menggunakan state diagram pada Gambar 3.25 dengan tujuan agar bisa diketahui apa saja efek yang perlu diperhatikanpada saat relokasi berlangsung. Hubungan rancangan skenario dengan penelitian – penelitian yang ada sebelumnya [6], [8], [9], [10] akan dijelaskan pada Bab 3.8. 3.7

Kriteria Relokasi RP Pada RFC 5059, BSR dijelaskan sebagai mekanisme PIM dalam

pemilihan yang tahan terhadap failure/kegagalan router. Di dalam metode yang akan diusulkan, otomatisasi pemilihan Rendezvous Point memiliki persyaratan yang diajukan Penulis sebagai berikut: o Mekanisme Hybrid Bootstrap yang digunakan dapat dijadikan kelebihan proposal relokasi dikarenakan BSR sebagai pemeran utama proses seleksi dan relokasi.



59

o Pengaturan relokasi RP diatur oleh BSR untuk meminimalisir kongesti yang terjadi, dengan alasan paket query RP_Set yang ditransmisikan oleh DR untuk menemukan RP_Set, dikirimkan secara unicast kepada BSR (Mekanisme Hybrid Bootstrap) o Optimalisasi pemindahan RP satu ke yang lain yang memiliki resiko minimal terjadinya packet loss ketika relokasi berlangsung. o Masing – masing domain diwakili oleh Router (kecuali router BSR) yang menjadi C-RP sekaligus DR untuk workstation terdekatnya. o Faktor penunjang yang diteliti sebelumnya menjadi tolak ukur persyaratan model relokasi RP yang baru. o Penambahandan/atau pengurangan kumpulan set perintah pada protokol mekanisme Bootstrap. Kriteria yang harus diperhatikan pada otomatisasi ini, dimulai dari penilaian dan pengukuran terhadap: i. Packet Loss dan Delay Ketika pemindahan 1 RP ke RP yang lainnya, memungkinkan untuk terjadinya hilangnya paket. Hal ini akan dianalisa berdasarkan penilaian faktor penunjang yang telah dianalisa pada Sub Bab sebelumnya.Packet loss sendiri akan diukur pada setiap paket yang dikirimkan oleh klien yang termasuk anggota grup multicast tersebut. ii. Network Load Batasan beban jaringan yang terjadi pada RP sehingga harus diganti dengan kandidat-RP yang lainnya dan beban jaringan kandidat-RP yang diajukan harus memenuhi kriteria yang akan dianalisa pada Tesis ini. iii. Reaction Time



60

Waktu reaksi ini tergantung oleh waktu pemrosesan dan delay pada setiap router yang ada. Waktu reaksi ini bisa dibagi menjadi dua hal; waktu pencarian dan waktu pemberitahuan adanya RP baru. Waktu pencarian akan berakhir ketika RP yang baru menerima pesan kontrol dari RP yang lama atau BSR. Waktu pemberitahuan adalah waktu yang digunakan untuk pengiriman alamat RP yang baru kepada setiap anggota multicast dimana dalam skenario ini DR-lah yang berfungsi untuk mengganti jalur tersebut. 3.8

Posisi Penelitian Gambar 3.27 menunjukkan posisi penelitan dibandingkan dengan

penelitan terdahulu yang menjadi dasar referensi maupun penelitian dari pembuatan rancangan skenario untuk Tesis. Pada penelitian Ying Dar, 2001[10] mengusulkan mekanisme relokasi RP yang menjadi ekstensi pada lingkungan PIM-SM multicast routing. Penelitian ini meneliti tentang usaha untuk mendapatkan lokasi inti RP dengan menggunakan fungsi estimasi tree cost yang bertujuan untuk mengevaluasi kesesuaian dari CRP. Pengaruh adanya klien/sourceyang melakukan Join dan Prune, membuat RP merelokasi dirinya secara periodik. Ketika relokasi RP telah ditentukan, RP sebelumnya melakukan transmisi secara multicast informasi pesan NEW_RP ke semua anggota multicast untuk memberitahukan Join ulang pada RP yang baru. Pada paper tersebut, aliran kerja protokol digambarkan dengan Gambar 3.28. Oleh karena itu, jalur distribusi baru bisa dibuat dengan cost minimal. Algoritmanya sendiri bisa terlihat pada Gambar 3.29 untuk relokasi RP sedangkan Gambar 3.30 menunjukkan algoritma migrasi RP lama ke RP baru. Algoritma tersebut menjadi dasar perancangan skenario relokasi pada penelitian ini hanya saja dikhususkan untuk lingkungan multicast routing IPv6. Untuk penelitian Hybrid Bootstrap [6] sendiri telah dijelaskan pada Sub Bab 2.2.5, dimana Hybrid ini meminimalisir flooding yang terjadi ketika BSR memberikan lokasi RP pada klien. Sedangkan untuk penelitian Samer, 2009 [8]



61

meneliti tentang lokasi RP yang paling optimal yang mana tergantung pada pemancar transmisi data atau anggota lainnya dari grup multicast. Penelitian ini mencari solusi lokasi RP paling optimal dengan beberapa algoritma yang ada, yaitu: algoritma Longest Path (LC), algoritma All Paths (AP), dan algoritma All Members (AM).

Gambar 3.27 Posisi Penelitian Rancangan Skenario



62

Gambar 3.28 State Diagram RP Relocation [10]

Gambar 3.29 RP Relocation Algorithm [10]



63

Gambar 3.30 RP Migration Algorithm [10]

Sedangkan algoritma Hill-Climbing (HC) sendiri dipakai untuk mengevaluasi performa dari algoritma – algoritma yang diusulkan. Pada penelitian ini [8], beberapa evaluasi performa yang diukur adalah Rasio Beban Jaringan, Beban Kontrol, Waktu Reaksi, dan Fungsi Objektif. Penelitian tersebut memiliki

kesimpulan

bahwa

penilaian

dari

rasio

data

throughput

menunjukkanFungsi Objektif memiliki peran yang besar terutama pada AM. Akan tetapi, Beban Kontrol tergantung pada lama waktu hidup penerima dan frekuensi perubahan dari grup multicast tersebut. Ketika posisi terbaik lokasi RP dalam jumlah anggota yang sedikit bisa sangat berubah, kemungkinan yang dihasilkan dari relokasi RP yang dinamis sangatlah rendah pada kasus dengan anggota yang lebih besar. Permasalahan yang dikarenakan peningkatan Beban Kontrol dengan menggunakan algoritma relokasi yang dinamis bisa tidak diperdulikan dalam kasus waktu hidup anggota yang panjang, yang menghasilkan berkurangnya frekuensi perubahan grup multicast. Penelitian tersebut juga menunjukkan bahwa algoritma relokasi RP yang dinamis bisa menghasilkan beban jaringan yang lebih rendah dibandingkan algoritma pemilihan RP yang statis, akan tetapi butuh pesan kontrol tambahan. Untuk penelitian analisa ini sendiri menggunakan asumsi – asumsi yang telah dijelaskan pada Bab 3.3 dan 3.5 yang dihasilkan dari referensi penelitian –



64

penelitian sebelumnya [6], [8], [9], [10]. Perbedaan utamanya adalah dalam penelitian analisa rancangan ini menggunakan BSR sebagai pemain utama perelokasian RP dalam lingkungan khusus multicast routing IPv6 dengan memperhitungkan beberapa faktor yang diperlukan agar transmisi data many-tomany dapat berfungsi dengan baik. Fitur tambahan / modifikasi yang diberikan pada Tesis ini dibandingkan penelitian yang telah dijelaskan sebelumnya adalah: 1. Format paket kontrol yang ada pada relokasi sebelum – sebelumnya dijelaskan lebih rinci dengan penambahan format paket kontrol baru yang telah dijelaskan pada Bab 3.3 2. Threshold sebagai penambahan fleksibilitas pemilihan kandidat RP baru ketika relokasi terjadi, dimana semakin kecil nilai threshold semakin baik posisis relokasi yang terjadi dan sebaliknya. 3. Pengiriman data dari RP lama ke RP baru selama relokasi terjadi, dan RP yang baru menahan paket data dari semua DR sebelum data dari RP lama selesai dikirimkan ulang yang ditandai dengan pengiriman

paket

yang

menandakan

RP

lama

sudah

menyelesaikan tugasnya dan menonaktifkan diri sebagai RP (dan kembali menjadi C-RP). 4. Pengaplikasian Hybrid Bootstrap dan juga peranan BSR sebagai pemain

utama

terjadinya

relokasi

dengan

tujuan

untuk

mengurangi waktu pemrosesan PIM-SM beserta relokasinya.



65

BAB 4 HASIL SIMULASI DAN ANALISA DATA 4.1

Simulasi Skenario PIM-SM Simulasi ini bertujuan untuk menganalisa dan menjadikan standar yang

menjadi acuan untuk menghitung paket data yang hilang dan latency/delay ketika relokasi berlangsung. Simulasi ini juga digunakan untuk melihat pengaruh yang terjadi ketika ukuran paket, jumlah paket yang dikirimkan perdetik terhadap kualitas jaringan pada UML dan juga pengaruhnya terhadap delayyang terjadi pada hasil yang diterima setiap sumber. Simulasi ini dibuat dengan rancangan setiap DR memiliki minimal 1 anggota multicast yang terdaftar sampai berjumlah lebih dari 1 secara merata disetiap DR.Simulasi ini dibagi menjadi dua bagian, yang pertama perbedaan jumlah pengiriman per detik dimulai dari sekali per detik sampai seterusnya sehingga bisa dilihatpeningkatan packet lossdan delay pada jaringan, sedangkan yang kedua adalah perbedaan jumlah besaran paket yang dikirim setiap detiknya.

Gambar 4.1 Pemilihan hashRP Pada BSR

Pada Gambar 4.1 menjelaskan bahwa BSR selalu memilih hashRP pada node R07, walaupun node R07 memiliki nilai yang sama dengan beberapa node lain (lihat Tabel 4.1) akan tetapi R07 memiliki nilai alamat IPv6 yang tertinggi (Bab 2.2.3). Setelah BSR memilih hashRP, maka BSR akan segera mengirim

65



66

paket data yang berisi informasi bahwa C-RP (R07) tersebut telah terpilih menjadi hashRP. Tabel 4.1 RP_Set Yang DikirimkanBSR Address Type 2 2 2 2 2 2 2

Address Group Address 2001:1::1 ff00::123 2001:5::5 ff00::123 2001:2::2 ff00::123 2001:6::6 ff00::123 2001:3::3 ff00::123 2001:4::4 ff00::123 2001:7::7 ff00::123

Group Prefix Bidir Adv Timer Priority Adv Interval 128 0 0 0 0 128 0 0 0 0 128 0 0 0 0 128 0 0 0 0 128 0 0 0 0 128 0 0 0 0 128 0 0 0 0

Holdtime Status 0 1 0 1 0 1 0 1 0 1 0 1 0 1

Storage Type Permanent Permanent Permanent Permanent Permanent Permanent Permanent

Value 1315778617 1434872301 1315778617 1434872301 1315778617 1434872301 1434872301

Pada mekanisme bootstrap konvensional, setelah tahap ini BSR akan membanjiri jaringan dengan pesan Bootstrap yang berisikan RP_Set. Sedangkan pada Tesis ini (Hybrid Bootstrap Mechanism Bab 2.2.4), terlihat pada Gambar 4.2, BSR akan menunggu DR untuk melakukan request pada BSR dan BSR akan mengirimkan RP_Set pada DR yang meminta lalu DR akan mengirimkan PIM_JOIN pada hashRP yang terpilih dari RP_Set yang diberikan oleh BSR.

Gambar 4.2 RP menerima PIM-JOIN

Gambar 4.3dan Gambar 4.4menggambarkan simulasi PIM-SM tanpa relokasi dengan pengiriman paket sebesar 15.9 kbps. Dapat disimpulkan bahwa semakin jauh posisi klien dengan RP yang terpilih akan mengakibatkan semakin besar pula paket yang hilang ditengah jalan. Gambar 4.2 memperlihatkan bahwa dalam simulasi PIM-SM tanpa relokasi, dikarenakan jarak paling jauh dari RP



67

yang terpilih yaitu R07 maka yang mengalami kehilangan paket terbesar adalah klien C01R04 dan C01R05. Sedangkan C01R07 hampir tidak mengalami banyak kehilangan paket dikarenakan posisi klien C01R07 berhubungan langsung dengan lokasi RP. Pada Gambar 4.4 membuktikan bahwa latency setiap paket data yang diterima mendekati1 detik yang menandakan pengiriman paket data dengan protokol UDP dengan kecepatan 15.9 kbps tidak layak untuk kualitas transmisi jaringanpada UML yang menjadi simulasiTesis ini. Simulasi PIM-SM tanpa relokasi dengan 1 klien masing – masing router dan kecepatan pengiriman paket 15.9 kbps membuktikan kebutuhan diharuskannya relokasi RP sehingga paket yang hilang menjadi berkurang. Hasil simulasi untuk skenario ini bisa dilihat pada Lampiran IVdengan 50 paket pertama yang diterima C01R01 dari setiap klien dengan pengiriman 1 paket per detik.

Gambar 4.3 Packet Loss Tanpa Relokasi: 1 Klien Pada Setiap Router



68

Gambar 4.4 Delay Tanpa Relokasi: 1 Klien Pada Setiap Router

4.2

Simulasi Skenario PIM-SM Terhadap Perubahan Faktor Simulasi ini menjelaskan tentang kondisi normal yang terjadi pada PIM-

SM tanpa relokasi dengan faktor penelitian (Bab 3.6) yang diubah. Faktor Threshold tidak dijadikan faktor simulasi karena faktor tersebut adalah tambahan – tambahan yang dilakukan Penulis sebagai persyaratan relokasi. Sebagai tambahan faktor yang dapat dijadikan acuan disini adalah faktor banyaknya jumlah data yang dikirim pada setiap detik. Dalam setiap simulasi terhadap perubahan faktor akan dihubungkan dengan jumlah packet loss dan delay/latency untuk setiap klien, dengan asumsi masing – masing router membawahi 1 klien yang menjadi anggota multicast. 4.2.1

Faktor Perubahan Ukuran Paket Pada simulasi untuk menganalisa pengaruh faktor ukuran paket terhadap

potensi packet loss dan delay yang terjadi pada setiap klien. Besar paket yang dikirim dimulai dari 2048 Bytes, 4096 Bytes,8192 Bytes dan 15900 Bytes setiap detiksebagai batas maksimal yang mampu dikirimkan pada simulator UML. Tabel 4.2 dan Tabel 4.3 merepresentasikan packet loss dan delay yang diterima dan dikirim oleh setiap klien anggota multicast ketika ukuran paket sebesar 4096 Bytes.



69

Tabel 4.2Rata – Rata Packet Loss Ketika Pengiriman Paket Data 4096 Bytes

RECV\SND C01R01

C01R02

C01R03

C01R04

C01R05

C01R06

C01R07

C01R01

14.50

14.50

11.50

12.75

12.00

14.25

13.00

C01R02

7.50

8.75

9.00

6.50

8.50

9.50

8.25

C01R03

5.00

5.75

3.25

4.25

7.00

6.75

5.75

C01R04

10.25

10.50

10.00

12.25

12.25

11.00

8.75

C01R05

12.50

13.75

12.75

12.50

11.75

13.25

12.00

C01R06

8.75

8.50

9.50

8.50

9.50

9.00

9.00

C01R07

1.00

0.50

1.00

1.00

0.25

0.50

0.00

Tabel 4.3Rata – Rata Delay Ketika Pengiriman Paket Data 4096 Bytes

RECV\SND C01R01

C01R02

C01R03

C01R04

C01R05

C01R06

C01R07

C01R01

0.79

0.85

0.83

0.82

0.79

0.78

0.75

C01R02

0.72

0.75

0.72

0.71

0.76

0.74

0.73

C01R03

0.73

0.72

0.73

0.69

0.75

0.70

0.76

C01R04

0.76

0.77

0.79

0.76

0.78

0.73

0.72

C01R05

0.80

0.81

0.79

0.77

0.80

0.76

0.77

C01R06

0.75

0.76

0.78

0.75

0.78

0.73

0.75

C01R07

0.58

0.57

0.58

0.70

0.60

0.59

0.55

Tabel 4.4 memperlihatkan rata – rata packet loss

dan Tabel 4.5

memperlihatkan rata – rata delay untuk setiap pengirim (anggota multicast) ketika mengirimkan paket data dengan ukuran tertentu. Dari Tabel 4.4 dan Tabel 4.5 dapat disimpulkan bahwa semakin kecil ukuran paket semakin kecil jumlah paket yang hilang ketika dikirimkan. Tabel tersebut juga menunjukkan adanya indikasi bahwa packet loss akan semakin tinggi untuk setiap klien walaupun klien tersebut berhadapan langsung dengan RP yang terpilih (pada kasus ini adalah C01R07 karena R07 telah terpilih menjadi hashRP). Tabel 4.4 Faktor Perubahan Ukuran Paket Data Terhadap Packet Loss

PACKET SIZE LOSS RATE

2048 B 5.08 %

4096 B 8.55 %

8196 B 18.69 %

15900 B 30.94 %

Tabel 4.5 Faktor Perubahan Ukuran Paket Data Terhadap Delay

PACKET SIZE DELAY RATE

2048 B 0.69s

4096 B 0.74s

8196 B 0.65s

15900 B 0.67s



70

Sedangkan Gambar 4.5 menunjukkan adanya kenaikan packet loss yang signifikan untuk setiap penambahan ukuran paket dan Gambar 4.6 menunjukkan tidak adanya pengaruh ukuran paket terhadap delay pengiriman paket terutama perubahan ukuran paket tetap tidak melebihi batas 200ms untuk transmisi datanya.

Gambar 4.5 Packet Loss Terhadap Perubahan Ukuran Paket

Gambar 4.6 Delay Terhadap Perubahan Ukuran Paket

4.2.2 Faktor Perubahan Jumlah Pengiriman Paket per Detik Simulasi pada PIM-SM tanpa relokasi pengaruh faktor perubahan jumlah pengiriman paket per detik terhadap potensi packet loss dan delay yang terjadi pada setiap klien. Jumlah data yang dikirimkan setiap detik bervariasi mulai dari 1 paket per detik, 2 paket per detik, 3 paket per detik, 5 paket per detik, dan 10 paket per detik dengan besaran paket yang dikirimkan adalah 2048 Bytes. Tabel 4.6 dan Tabel 4.7 merepresentasikan packet loss dan delay yang diterima dan dikirim oleh setiap klien anggota multicast ketika paket data yang dikirimkan 3 paket per detik. Tabel 4.6Rata Rata Paket Loss Ketika Jumlah Paket 3 Per Detik

RECV\SND C01R01

C01R02

C01R03

C01R04

C01R05

C01R06

C01R07

C01R01

8.5

8

8.75

6.75

8.75

8

9.25

C01R02

14

11.75

15

12.75

13

14

14

C01R03

4.75

6.25

8.75

7

6

6

6.25

C01R04

13

11.75

13.25

12.5

14

16.5

16.25

C01R05

13.75

10.5

14.75

13.75

15.25

13.25

13.75

C01R06

8.25

7.5

9.25

7.25

10

8.5

7.75

C01R07

0

0.25

0.25

0.25

0.25

0.25

0



71 Tabel 4.7Rata Rata Delay Ketika Jumlah Paket 3 Per Detik

RECV\SND C01R01 C01R01 C01R02

C01R02

C01R03

C01R04

C01R05

C01R06

C01R07

0.644031 0.667494 0.654891 0.647657 0.666709 0.648319 0.608775 0.64264 0.673224

0.65046 0.652775 0.675928

0.65551 0.636586

C01R03

0.694406 0.730141 0.697573 0.720027 0.713909 0.708941 0.669646

C01R04

0.655147 0.670979 0.668022 0.667021 0.675071 0.669339 0.641204

C01R05

0.648772 0.655233 0.647647 0.627169 0.681104 0.630558 0.616658

C01R06

0.646092 0.660462 0.660967 0.659017 0.661136 0.658631 0.627348

C01R07

0.693067 0.704088 0.700257 0.710505 0.714723 0.701751 0.658408

Tabel 4.8 memperlihatkan rata – rata packet loss dan Tabel 4.9 memperlihatkan rata – rata delay untuk setiap pengirim (anggota multicast) ketika mengirimkan paket ukuran 2048 Bytes dengan kecepatan pengiriman tertentu per detik. Dari Tabel 4.8 dan Tabel 4.9 dapat disimpulkan bahwa semakin kecil ukuran paket semakin kecil jumlah paket yang hilang ketika dikirimkan. Tabel tersebut juga menunjukkan adanya indikasi bahwa packet loss akan semakin tinggi untuk setiap klien walaupun klien tersebut berhadapan langsung dengan RP yang terpilih (pada kasus ini adalah C01R07 karena R07 telah terpilih menjadi hashRP). Tabel 4.8 Faktor Perubahan Jumlah Paket Per Detik Terhadap Packet Loss

PACKET SIZE LOSS RATE

1/s 5.08 %

2/s 6.14 %

3/s 9.17 %

5/s 14.04 %

10/s 30.63 %

Tabel 4.9Faktor Perubahan Jumlah Paket Per Detik Terhadap Delay

PACKET SIZE DELAY RATE

1/s 0.69 S

2/s 0.65 s

3/s 0.67 s

5/s 0.75 s

10/s 0.86 s

Sedangkan Gambar 4.5 menunjukkan walaupun ada indikasi turunnya packet loss ketika data yang dikirimkan dari 1 per detik ke 2 paket per detik, akan tetapi terlihat adanya kenaikan packet loss yang signifikan untuk setiap penambahan jumlah paket yang dikirimkan per detik dan Gambar 4.6 menunjukkan tidak adanya pengaruh ukuran paket terhadap delay pengiriman paket terutama perubahan ukuran paket tetap tidak melebihi batas 200ms untuk transmisi datanya



72

Gambar 4.7 Packet Loss Terhadap Perubahan Jumlah Paket Per Detik

4.3

Gambar 4.8 Delay Terhadap Perubahan Jumlah Paket Per Detik

Simulasi Skenario PIM-SM Dengan Relokasi Dengan hasil pada skenario Bab 4.2, untuk skenario relokasi PIM-SM diambil

ukuran paket sebesar 2048 Bytes dan jumlah pengiriman 2 paket per detik sebagai tolak ukur data yang akan dibandingkan dengan hasil PIM-SM dengan relokasi. Sebagaimana yang sudah dijelaskan pada Bab 3.5, ketika BSR menerima semua hasil jalur dari DR ke semua CRP pada RP_Set setelah DR mendapatkan hasil RP_Set dari BSR, maka BSR akan menghitung semua jalur dengan algoritma AM. Pada Lampiran:Hasil Algoritma AM Pada BSR, ditujunkan nilai cost setiap C-RP pada RP_Set dengan algoritma AM. Pada simulasi ini, skenario PIM-SM dengan relokasi disimulasikan dengan 1 klien pada masing – masing DR dengan paket 2048 Bytes dan paket dikirimkan 1 kali per detik dengan threshold 0 (sesuai dengan algoritma AM). Tabel 4.10 menunjukkan lama waktu setiap percobaan yang dilakukan dengan 7 DR dimana masing – masing DR memiliki 1 klien yang terdaftar sebagai anggota multicast. Semakin banyak jalur dan jumlah DR yang melakukan query pada BSR, semakin lama waktu yang dibutuhkan BSR untuk menghitung cost setiap C-RP yang ada pada RP_Set.Tabel 4.11 menunjukkan lama waktu yang dibutuhkan simulasi untuk melakukan relokasi mulai dari pengiriman advertisement oleh BSR ke RP yang baru sampai RP yang lama telah selesai dari tugasnya.Pada proposal relokasi sebelumnya waktu yang digunakan untuk relokasi PIM-SM yang sebelumnya dibahas pada Bab 3.8 dan Bab 2.2.6 adalah:

Sementara pada simulasi ini, dikarenakan perhitungan cost setiap C-RP pada RP_Set tidak akan dihitung ulang kecuali jika ada DR yang melakukan Query pada BSR, sehingga waktu relokasi lebih efisien dibandingkan penelitian – penelitian sebelumnya.



73 Tabel 4.10 Lama Waktu Algoritma AM Setiap Percobaan

Percobaan Waktu (ms)

1 8.75

2 13.84

3 54.80

4 30.63

5 56.77

6 42.54

7 42.85

8 52.00

9 47.16

10 9.58

11 31.83

9 6.73

10 7.21

11 7.64

Tabel 4.11 Lama Waktu Relokasi Terjadi Setiap Percobaan

Percobaan Waktu (s)

1 5.96

2 11.24

3 10.2

4 8.7

5 6.9

6 13.1

7 8.6

8 9.2

Pada simulasi ini, relokasi dilakukan setelah paket ke-37 dikirimkan oleh setiap klien. Gambar 4.9 dan Gambar 4.10 menunjukkan packet loss dan delay pada simulasi relokasi PIM-SM dengan masing – masing 1 klien yang terdaftar sebagai anggota multicast pada 7 DR. Dalam Gambar 4.9 dapat terlihat bahwa terjadi penurunan delay secara signifikan ketika relokasi sudah terjadi dan sesaat sebelum relokasi terjadi terjadi peningkatan delay pada simulasi. Sementara dalam Gambar 4.10, setelah pengiriman paket 37 terjadi penurunan packet loss dikarenakan threshold adalah 0 maka posisi terbaiklah yang selalu dipilih oleh BSR..

Gambar 4.9 Rata – Rata Delay Setiap Paket

Gambar 4.10 Rata – Rata Jumlah Packet Loss Setiap Paket



74 4.4

Simulasi Skenario PIM-SM Dengan Relokasi Terhadap Perubahan Faktor Threshold Simulasi dengan merubah faktor threshold ini dibuat untuk menganalisa pengaruh

threshold pada kejadian relokasi pada PIM-SM. Pada simulasi ini, dibuat suatu skenario threshold yang perpindahannya mendekati relokasi RP yang paling baik (atau dengan threshold 0). Pada simulasi ini, ukuran paket yang dikirimkan disamakan dengan tolak ukur yang telah dijelaskan diatas yakni 2048 Bytes dengan pengiriman 2 paket per detik. Percobaan dilakukan beberapa kali untuk melihat bandwidth usage pada Router yang memiliki andil sebagai RP dan semua node PIM Router. Pada simulasi ini, Threshold yang dipilih dengan nilai 2 yang mewakili nilai faktor threshold rendah karena nilai ini selain dekat dengan nilai 0, selain itu pula cost terdekat dengan C-RP yang paling optimal adalah 15 (lihat Tabel 4.12) dan juga nilai Threshold 6 sebagai nilai faktor Theshold tinggi yang menunjukkan perpindahan bisa dilakukan ke seluruh node C-RP pada simulasi. Tabel tersebut

didapatkan

setelah

mengirimkan

jalurnya

DR

ke

setiap

RP_Set

pada

BSR.Dikarenakan nilai 2 dan 6 bisa merangkul beberapa dan semua C-RP pada RP_Set oleh karena itu, Threshold tersebut digunakan. Tabel 4.12 Tabel Cost Pada Simulasi Dengan 7 Klien

C-RP 2001:1::1 2001:2::2 2001:3::3 2001:4::4 2001:5::5 2001:6::6 2001:7::7

cost AM algorithm 14 15 15 19 19 19 19

Pada simulasi ini, relokasi dilakukan setiap 60 detik pada BSR sehingga dari total waktu simulasi, BSR bisa merelokasi RP sampai 3 kali. Faktor 2 bisa dianggap faktor Threshold terendah dan faktor 6 bisa dianggap sebagai faktor threshold tinggi. 4.4.1 Faktor Threshold Rendah Hasil setiap percobaan dan lama waktu setiap relokasi dijelaskan pada Tabel 4.13. Dalam simulasi faktor threshold rendah dengan nilai 2 dalam beberapa kali percobaan, hasil himpunan NEW_RP yang akan selalu dipilih adalah:2001:1::1, 2001:2::2, dan 2003:3::3.



75 Tabel 4.13Hasil Relokasi Pada Simulasi Dengan Threshold 2

Percobaan 1

2

3

4

5

6

7

8

9

10

11

RP lama

RP baru

2001:7::7 2001:2::2 2001:2::2 2001:7::7 2001:2::2 2001:1::1 2001:7::7 2001:1::1 2001:2::2 2001:7::7 2001:3::3 2001:2::2 2001:7::7 2001:2::2 2001:2::2 2001:7::7 2001:3::3 2001:2::2 2001:7::7 2001:1::1 2001:3::3 2001:7::7 2001:1::1 2001:2::2 2001:7::7 2001:2::2 2001:2::2 2001:7::7 2001:3::3 2001:1::1 2001:7::7 2002:2::2 2001:1::1

2001:2::2 2001:2::2 2001:3::3 2001:2::2 2001:1::1 2001:3::3 2001:1::1 2001:2::2 2001:3::3 2001:3::3 2001:2::2 2001:2::2 2001:2::2 2001:2::2 2001:2::2 2001:3::3 2001:2::2 2001:1::1 2001:1::1 2001:3::3 2001:3::3 2001:1::1 2001:2::2 2001:1::1 2002:2::2 2001:2::2 2001:1::1 2001:3::3 2001:1::1 2001:1::1 2002:2::2 2001:1::1 2001:1::1

Lama Relokasi (s) 6.79 10.64 7.38 8.11 12.64 8.18 5.44 11.13 9.14 4.39 5.03 11.84 6.18 8.73 5.56 9.78 8.67 7.22 5.59 11.61 5.61 18.77 9.19 9.54 9.99 5.67 17.91

Pada kasus relokasi yang dilakukan sebelumnya [8] dan [10], data yang ditransmisikan pada saat terjadinya relokasi tidak dihiraukan, sementara pada skenario simulasi ini data yang terkirim pada saat terjadinya relokasi yang telah diterima oleh RP lama saat relokasi dimulai, akan lebih dahulu dikirimkan kepada RP yang baru sampai RP yang lama tidak menerima data lagi. Jika dilihat dari Tabel 4.1 dimana paket data dengan ukuran 2048 B dengan pengiriman 2 paket per detik akan mengalami rata – rata 6.14% packet loss,



76 maka dari percobaan pada Tabel 4.13, rata – rata packet loss yang terjadi dihitung dengan rumus:

(

)

; dimana n adalah jumlah relokasi yang terjadi. Tabel 4.14 memperlihatkan rata – rata yang terjadi pada masing – masing percobaan dibandingkan dengan rata – rata packet loss yang harusnya terjadi ketika relokasi tanpa pengiriman data. Tabel 4.14 Rata – Rata Packet Loss Skenario Dengan Proposal [Ying-Dar, 2002] dan [Samer, 2009]

Percobaan

Packet Loss Tesis

1 2 3 4 5 6 7 8 9 10 11

6.60 7.66 6.87 6.93 6.30 7.16 7.50 6.91 7.54 6.98 7.29

Packet Loss Sebenarnya 13.72 18.37 16.90 12.02 8.33 17.77 16.58 16.76 16.74 14.28 20.74

Salah satu contoh hasil delay simulasi percobaan nomor 4 pada Tabel 4.13 ketika relokasi dijelaskan pada Gambar 4.11 dimana rata – rata delay yang terjadi pada simulasi di atas UML tidak mencapai lebih dari 2 detik.



77

Gambar 4.11 Delay Percobaan Ke-9 Tabel 4.13

Pada Gambar 4.12, terlihat bahwa packet loss terjadi packet loss yang besar antara paket 17 – paket 20 dan antara paket 181 – paket 281. Gambar 4.12 menunjukkan bahwa ketika relokasi terjadi masih ada kemungkinan untuk terjadi packet loss walaupun RP lama mengirimkan semua paket kepada RP yang baru dahulu sebelum menonaktifkan dirinya sebagai RP saat ini dan menyerahkan fungsi RP kepada C-RP yang terpilih. Packet loss juga menjadi berkurang seiring dengan jauhnya transmisi data dari waktu (sebelum dan sesudah) relokasi. Pada penggunaan hashRP (sesaat sebelum direlokasi ketika paket ke-1 sampai paket ke-23 diterima oleh setiap klien), jumlah packet loss menjadi meningkat seiring dengan banyaknya transmisi data pada simulasi, akan tetapi seiring dengan relokasi, jumlah packet loss tersebut tidak lagi setinggi ketika hashRP digunakan.

Gambar 4.12 Packet Loss Percobaan Ke-9 Tabel 4.13



78

Gambar 4.13 Penggunaan Bandiwidth Pada Node RP



79 Paket kontrol (In) pada Gambar 4.13 menggambarkan paket kontrol multicast sampai ke hal lain yang termasuk didalam virtualisasi UML seperti Quagga yang sudah dijelaskan pada Bab 3.4. Sementara untuk aktifitas penggunaan bandwidth pada pengiriman data setiap node-router ditunjukkan pada Gambar 4.13 yang mana aktifitas paket kontrol yang khusus digunakan PIM-Router itu sendiri yang diwakili oleh garis biru dan aktifitas paket data yang dikirimkan oleh klien anggota multicast diteruskan oleh PIM-Router menuju RP dan sebaliknya, dari RP menuju PIM-Router. Pada Gambar 4.13:R07 memperlihatkan kenaikan yang signifikan dari node tersebut ketika pertama kali terpilih menjadi hashRP sampai posisi tersebut direlokasi ke node R01 (Tabel 4.13 Percobaan ke-4) dimana kenaikan tersebut secara signifikan mencapai 10 MB/s. Walaupun RP telah berhasil direlokasikan dari node R07 ke node R03, masih terlihat di R07 masih terjadi kenaikan. Hal ini disebabkan oleh paket data yang sampai pada R07 ketika relokasi terjadi, ditahan dan dikirimkan ke router yang baru terlebih dahulu ke RP yang baru (R03) ketika relokasi sudah selesai. Sedangkan pada Gambar 4.13:R03 peningkatan penggunaan bandwidth untuk paket data mencapai hampir 35 KB/s, hal ini disebabkan oleh penggunaan hashRP R07 yang mana jalurnya melewati R03, selain itu pula relokasi selanjutnya adalah R03 sehingga semua paket data harus melalui R03 terlebih dahulu. 4.4.2 Faktor Threshold Tinggi Pada faktor Threshold tinggi ini dipakai nilai 6 dikarenakan nilai ini bisa mencakup semua node yang ada pada simulasi ini. Hasil percobaan dan lama waktu setiap relokasi dijelaskan pada Tabel 4.15. Tabel 4.15 menunjukkan relokasi yang jauh membuat beberapa waktu relokasi menjadi lambat walaupun tidak semuanya menjadi lambat walaupun posisi relokasi berbeda jauh dari lokasi RP lama. Ketergantungan minimal lama waktu terhadap jarak antara RP baru dan RP lama disebabkan karena proses relokasi diatur oleh BSR sepenuhnya.Dengan asumsi yang sama pada Bab 4.4.2 dimana kasus relokasi yang dilakukan sebelumnya [8] dan [10], data yang ditransmisikan pada saat terjadinya relokasi tidak dihiraukan, sementara pada skenario simulasi ini data yang terkirim pada saat terjadinya relokasi yang telah diterima oleh RP lama saat relokasi dimulai, akan lebih dahulu dikirimkan kepada RP yang baru sampai RP yang lama tidak menerima data lagi, maka dari percobaan pada Tabel 4.15, rata – rata packet loss yang terjadi dihitung dengan rumus:

(

)



80 ; dimana n adalah jumlah relokasi yang terjadi. Tabel 4.16 memperlihatkan rata – rata yang terjadi pada masing – masing percobaan dibandingkan dengan rata – rata packet loss yang harusnya terjadi ketika relokasi tanpa pengiriman data. Tabel 4.15 Hasil Relokasi Pada Simulasi Dengan Threshold 6

Percobaan 1

2

3

4

5

6

7

8

9

10

11

RP lama

RP baru

2001:7::7 2001:1::1 2001:7::7 2001:7::7 2001:6::6 2001:6::6 2001:7::7 2001:5::5 2001:5::5 2001:7::7 2001:1::1 2001:2::2 2001:7::7 2001:7::7 2001:1::1 2001:7::7 2001:4::4 2001:7::7 2001:7::7 2001:7::7 2001:5::5 2001:7::7 2001:3::3 2001:2::2 2001:7::7 2001:6::6 2001:4::4 2001:7::7 2001:5::5 2001:6::6 2001:7::7

2001:1::1 2001:7::7 2001:3::3 2001:6::6 2001:6::6 2001:4::4 2001:5::5 2001:5::5 2001:4::4 2001:1::1 2001:2::2 2001:6::6 2001:7::7 2001:1::1 2001:7::7 2001:4::4 2001:7::7 2001:7::7 2001:7::7 2001:5::5 2001:1::1 2001:3::3 2001:2::2 2001:1::1 2001:6::6 2001:4::4 2001:4::4 2001:5::5 2001:6::6 2001:3::3 2001:2::2

2001:2::2 2001:5::5 2001:5::5 2001:6::6

Lama Relokasi (s) 12.12 9.88 6.79 18.69 18.17 5.44 4.28 11.05 17.03 6.90 15.76 25.89 20.18 19.95 13.78 8.56 16.99 5.69 13.11 10.08 15.04 23.31 4.91 9.67 9.38 21.31 7.96



81 Tabel 4.16Rata – Rata Packet Loss Skenario Dengan Proposal [Ying-Dar, 2002] dan [Samer, 2009]

Percobaan 1 2 3 4 5 6 7 8 9 10 11

Packet Loss Tesis 12.65 8.32 8.19 10.50 14.96 12.76 13.05 11.64 8.98 13.21 11.87

Packet Loss [6] [8] 18.66 16.97 10.37 21.35 18.34 23.59 15.85 21.70 17.06 22.61 22.94

Sebagai contoh untuk analisa hasil simulasi, dari Tabel 4.15 diambil uji kasus percobaan nomor 3 dimana salah satu relokasi berpindah dari R07 ke R05 yang jaraknya sangat jauh. Pada kasus ini bisa diteliti efek apa saja yang ditimbulkan dari relokasi yang posisinya berlawanan ataupun jauh dari RP awal. Gambar 4.14 menunjukkan delay dari percobaan ke-4 Tabel 4.15. Gambar 4.14 menjelaskan tentang paket data yang hilang mulai dari paket dengan nomor 54 sampai dengan paket dengan nomor 62 ketika relokasi dari R07 ke R05 terjadi. Walaupun relokasi berjalan dengan sukses tetapi paket tersebut hilang sesaat sebelum relokasi selesai. Sementara delay pada percobaan ke-3 ini dijelaskan dengan Gambar 4.15.

Gambar 4.14 Packet Loss Percobaan ke-3 Tabel 4.14



82

Gambar 4.15 Delay Percobaan ke-3 Tabel 4.14

Pada Gambar 4.15 dapat terlihat adanya delay pada paket dengan nomor yang sama yang dijelaskan sebelumnya. Sedangkan kenaikan sesaat sebelum puncak delay pada Gambar 4.15, hasil tersebut didapatkan dikarenakan paket dengan nomor 48 sampai dengan paket denga nomor 53 adalah paket yang sempat dikirimkan R07 sesaat sebelum memberitahu BSR bahwa relokasi sudah selesai. Delay ini disebabkan oleh waktu tempuh yang cukup jauh yang diukur dengan:

Paket kontrol (In) pada Gambar 4.16 menggambarkan paket kontrol multicast sampai ke hal lain yang termasuk didalam virtualisasi UML seperti Quagga yang sudah dijelaskan pada Bab 3.4. Sementara untuk aktifitas penggunaan bandwidth pada pengiriman data setiap node-router ditunjukkan pada Gambar 4.16 yang mana aktifitas paket kontrol yang khusus digunakan PIM-Router itu sendiri yang diwakili oleh garis biru dan aktifitas paket data yang dikirimkan oleh klien anggota multicast diteruskan oleh PIM-Router menuju RP dan sebaliknya, dari RP menuju PIM-Router.



83

Gambar 4.16 Penggunaan Bandiwidth Pada Node RP Ditambah R01

Sama seperti pada Bab Faktor Threshold Rendah, pada Gambar 4.16:R07 memperlihatkan kenaikan yang signifikan dari node tersebut ketika pertama kali terpilih menjadi hashRP sampai posisi tersebut direlokasi ke node R05 (Tabel 4.14 Percobaan ke-3) dimana kenaikan tersebut secara signifikan mencapai hampir 10 MB/s. Ketika proses relokasi terjadi dari R07 ke R05, terlihat pada Gambar 4.16:R05 bahwa sesaat terjadi penurunan bandiwidth untuk paket pengiriman data sebelum pada akhirnya terjadi lonjakan tinggi terhadap paket data yang dikirimkan. Jatuhnya garis merah pada Gambar 4.16:R05 sesaat sebelum terjadinya relokasi disebabkan oleh perpindahan relokasi yang mengakibatkan turunnya bandiwidth pada pengiriman paket data dikarenakan R05 menunggu relokasi selesai. Pada Gambar 4.16:R04 ketika relokasi terjadi lonjakan drastis yang tinggi pada garis Universitas Indonesia


84 merah. Hal ini dikarenakan pengiriman data dari RP lama (R05) ke RP baru (R04) ketika relokasi terjadi. Dikarenakan jarak dan lompatan yang dekat antara RP lama (R05) dengan RP baru (R04) menyebabkan paket data yang terjebak diantara waktu relokasi berhasil diselamatkan menuju R04 sebelum akhirnya dikirimkan kembali pada semua DR. 4.5

Analisa Perbandingan Antara PIM-SM Tanpa Relokasi, PIM-SM Relokasi dan Hasil Simulasi Dalam PIM-SM tanpa relokasi, RP selalu dipilih berdasarkan nilai hash value yang

dijelaskan pada Bab 2.2.3, yang artinya selama topologi jaringan tidak diganti, maka hampir dapat dipastikan hanya ada 1 alamat IP yang selalu menjadi hashRP. Sementara hashRP tidak dipilih berdasarkan perhitungan jarak terbaik ke setiap anggota multicast. Sementara PIM-SM Relokasi yang telah ada sebelumnya memiliki beberapa kelemahan dibandingkan simulasi diatas: 1. PIM-SM Relokasi [5],[8] dan [10] tidak memiliki kemampuan yang baik untuk menahan overhead pada jaringan yang disebabkan entah karena mekanisme Bootstrap Router sendiri yang selalu mengirimkan pesan Bootstrap via flooding atau pesan kontrol algoritma seperti pada contoh algoritma Hill-Climbing pada Bab 2.2.6. 2. PIM-SM Relokasi setiap mencapai tahap seleksi selalu melakukan perhitungan dari awal lagi, sedangkan hasil simulasi menunjukkan bahwa perhitungan algoritma yang ada pada Tesis ini dapat berkurang dikarenakan cost dari setiap C-RP disimpan didalam tabel lokal RP_Set pada BSR. 3. Mekanisme Hybrid Bootstrap mampu menyederhanakan proses pendaftaran atau pengunduran suatu anggota multicast. Pada hasil simulasi, protokol UDP sebagai pembawa pesan data memiliki peran yang baik walaupun dengan adanya packet loss yang cukup besar, hal ini dikarenakan yang tidak memiliki protokol UDP tidak memiliki cara untuk mengembalikan paket yang hilang atau rusak ditengah jalan. Pada dunia nyata, packet loss yang dijelaskan pada hasil simulasi tidak akan sebesar itu dikarenakan keterbatasan virtualisasi UML itu sendiri.Secara perhitungan dari percobaan – percobaan yang terjadi, relokasi pada topologi dengan faktor Threshold rendah mampu mengurangi paket yang hilang sampai dengan 54 % pada simulasi



85 ini sedangkan relokasi pada topologi dengan faktor Threshold tinggi mampu mengurangi paket yang hilang sampai dengan 39%. Jika pada algoritma relokasi sebelumnya, posisi terbaik selalu dipilih sebagai relokasi, sedangkan pada algoritma relokasi yang ada pada simulasi ini tidak selalu memilih posisi terbaik. Hal ini bisa jadi menguntungkan dikarenakan algoritma relokasi yang telah dijelaskan dalam Tesis ini hanya terbatas pada Hops / Lompatan pada setiap node klien yang termasuk dalam anggota multicast. Terlihat dari Gambar 4.13 dan Gambar 4.16, R01 sebagai posisi terbaik pada simulasi ini walaupun tidak menjadi RP saat ini tetap menggunakan resource bandwidth yang cukup tinggi dikarenakan letaknya yang menjembatani dua area. Simulasi ini telah membuktikan proses pengurangan packet loss yang diakibatkan relokasi yang terjadi dengan cara sesaat relokasi selesai, RP lama mengirimkan semua paket data yang diterimanya ke yang baru dan paket data dari semua DR yang sudah meregistrasikan dirinya lagi (PIM_JOIN) ke RP baru, akan dikirim setelah semua paket dari RP lama dikirim terlebih dahulu ke semua DR yang teregistrasi. Hal ini menyebabkan berkurangnya packet loss (terutama jika jarak antar RP baru dan RP lama dekat) dan menyebabkan terjadinya delay yang lama.



86

BAB 5 KESIMPULAN 1. Pada pengiriman data dengan menggunakan protokol UDP, pengaturan ukuran paket dan jarak waktu antar tiap paket harus diatur terlebih dahulu dikarenakan protokol ini tidak memiliki penjagaan sebagaimana protokol TCP. 2. Pada kasus penggunaan Threshold yang rendah, paket yang hilang mampu dikurangi sampai dengan 54% sedangkan untuk penggunaan Threshold yang tinggi, paket yang hilang mampu dikurangi sampai dengan 39%. 3. Protokol mekanisme Hybrid Bootstrap yang menggunakan BSR sebagai pengambil RP_Set oleh DR, dapat juga dikembangkan lebih lagi pada proses relokasi dengan menggunakan BSR sebagai pemeran utama. 4. Nilai Threshold ini bisa diatur dengan kebutuhan spesifikasi data, semakin kecil nilai Threshold semakin baik relokasi RP dilihat dari lompatan pada setiap node anggota multicast. Dan semakin besar nilai Threshold dapat menyebabkan perelokasian yang jauh dari tempat RP lama, yang berarti bisa menambah waktu pengiriman data diakibatkan delay pada transmisi data yang jauh.

86



87

BAB 6 DAFTAR ACUAN [1] 6DISS, “IPv6 Multicast”, “South-East Europe Workshop #2”, 28Juni2007, Plovdiv, Bulgaria. [2] ICANN, “Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied”, 3 Februari 2011. [3] URL http://www.potaroo.net/tools/ipv4/index.html, 26 November 2011, diambil pada 23 November 2011. [4] Banikazemi, Mohammad, “IP Multicasting: Concepts, Algorithms, and Protocols, IGMP, RPM, CBT, DVMRP, MOSPF, PIM, MBONE”, Washington University, URL http://www.cse.wustl.edu/~jain/cis788-97/ftp/ip_multicast/index.htm, diambil pada 20 November 2012. [5] Thaler, D. G. and Ravishankar, C. V.: “Distributed Center-Location Algorithms”, IEEE Journal Communications, vol. 15, no. 3, 1997. [6] Takabatake, T, A hybrid bootstrap mechanism for multicast routing in PIM-SM, Desember 2007. [7] URL https://code.google.com/p/ipaddr-py/, “Python IP address manipulation library”, diambil pada Agustus 2012. [8] Samer Sulaiman, Albdelfattah Haidine, Ralf Lehnert, ”Performance Evaluation of Center Search Algorithms Used for Dynamic Rendezvous Point Relocation”, 2009 [Samer, 2009]. [9] URL http://user-mode-linux.sourceforge.net/, “Run Linux inside itself”, diambil pada Agustus 2012. [10] Ying-Dar Lin, Nai-Bin Hsu, Chen-Ju Pan, ”Extension of RP Relocation to PIM-SM Multicast Routing”, Agustus 2002 [Ying-Dar, 2002]. [11] Quagga,“Routing

Software

Suite,

GPL

licensed”,

URL

http://www.nongnu.org/quagga/, diambil pada Agustus 2012.

87



88

LAMPIRAN HASIL 50 PAKET PERTAMA PIM-SM TANPA RELOKASI 06:09:56,329 06:09:56,434 06:09:56,441 06:09:57,664 06:09:57,665 06:09:57,666 06:09:57,667 06:09:57,714 06:09:57,798 06:09:57,956 06:09:58,398 06:09:58,401 06:09:58,466 06:09:58,468 06:09:58,471 06:09:58,973 06:09:59,422 06:09:59,650 06:09:59,650 06:10:00,125 06:10:03,091 06:10:03,092 06:10:03,093 06:10:03,094 06:10:03,096 06:10:04,751 06:10:04,752 06:10:04,752 06:10:04,753 06:10:04,753 06:10:05,115 06:10:06,566 06:10:06,567 06:10:06,567 06:10:06,567 06:10:06,568 06:10:06,585 06:10:06,750 06:10:06,750 06:10:07,237 06:10:08,090 06:10:08,091 06:10:09,330 06:10:09,332 06:10:09,337 06:10:09,338 06:10:09,693 06:10:09,695 06:10:09,697 06:10:09,699 06:10:09,871

15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900

2002:3::9 2002:4::9 2002:5::9 2002:7::9 2002:2::9 2002:5::9 2002:1::9 2002:1::9 2002:5::9 2002:4::9 2002:6::9 2002:1::9 2002:7::9 2002:5::9 2002:3::9 2002:4::9 2002:7::9 2002:1::9 2002:5::9 2002:4::9 2002:5::9 2002:2::9 2002:3::9 2002:6::9 2002:4::9 2002:5::9 2002:7::9 2002:7::9 2002:1::9 2002:6::9 2002:3::9 2002:3::9 2002:1::9 2002:7::9 2002:4::9 2002:7::9 2002:2::9 2002:3::9 2002:1::9 2002:4::9 2002:2::9 2002:7::9 2002:5::9 2002:3::9 2002:6::9 2002:4::9 2002:1::9 2002:6::9 2002:3::9 2002:4::9 2002:5::9

1356329396 1356329397 1356329397 1356329398 1356329398 1356329398 1356329398 1356329398 1356329398 1356329398 1356329398 1356329399 1356329399 1356329399 1356329399 1356329399 1356329400 1356329400 1356329400 1356329400 1356329403 1356329403 1356329403 1356329403 1356329403 1356329405 1356329405 1356329405 1356329405 1356329405 1356329405 1356329407 1356329407 1356329407 1356329407 1356329407 1356329407 1356329407 1356329407 1356329407 1356329408 1356329408 1356329409 1356329409 1356329409 1356329409 1356329410 1356329410 1356329410 1356329410 1356329410

88

0.937005 1.111608 1.137067 1.281623 0.364253 1.353741 1.326102 0.363375 0.478447 0.614012 0.082645 0.041835 0.071368 0.14276 0.143959 0.624797 0.012914 0.288478 0.314676 0.766936 2.752289 2.774092 2.735614 2.755988 2.737528 2.402822 3.329267 2.329055 2.37249 1.379536 0.689918 1.135816 1.162631 1.134396 1.131029 0.134509 0.148139 0.312914 0.337845 0.798756 2.658786 0.651267 1.827791 0.885226 0.892301 0.88097 0.26132 0.240406 0.234111 0.218941 0.360729

1 1 1 2 3 2 2 3 3 3 4 4 4 4 4 4 5 5 5 5 6 6 6 6 6 8 7 8 8 9 10 11 11 11 11 12 12 12 12 12 11 13 13 14 14 14 15 15 15 15 15



89

06:10:09,872 06:10:10,808 06:10:10,810 06:10:10,812 06:10:10,813 06:10:10,815 06:10:11,564 06:10:11,882 06:10:11,883 06:10:11,909 06:10:11,941 06:10:12,683 06:10:12,796 06:10:12,797 06:10:12,798 06:10:13,095 06:10:13,273 06:10:13,902 06:10:13,904 06:10:13,905 06:10:13,906 06:10:14,078 06:10:14,080 06:10:15,725 06:10:15,725 06:10:15,726 06:10:15,727 06:10:15,898 06:10:15,899 06:10:15,900 06:10:17,210 06:10:17,212 06:10:17,213 06:10:17,959 06:10:17,960 06:10:17,961 06:10:17,963 06:10:17,964 06:10:20,119 06:10:20,122 06:10:20,124 06:10:20,126 06:10:20,128 06:10:20,131 06:10:20,745 06:10:20,746 06:10:20,764 06:10:20,820 06:10:21,186 06:10:21,317 06:10:22,051 06:10:22,053 06:10:22,055 06:10:22,376 06:10:22,378 06:10:23,163 06:10:23,166

15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900

2002:2::9 2002:1::9 2002:7::9 2002:6::9 2002:4::9 2002:2::9 2002:7::9 2002:4::9 2002:1::9 2002:3::9 2002:2::9 2002:5::9 2002:6::9 2002:3::9 2002:5::9 2002:7::9 2002:4::9 2002:3::9 2002:6::9 2002:1::9 2002:7::9 2002:2::9 2002:4::9 2002:1::9 2002:2::9 2002:5::9 2002:6::9 2002:5::9 2002:3::9 2002:2::9 2002:1::9 2002:2::9 2002:7::9 2002:6::9 2002:5::9 2002:3::9 2002:7::9 2002:4::9 2002:5::9 2002:4::9 2002:5::9 2002:6::9 2002:2::9 2002:4::9 2002:1::9 2002:2::9 2002:7::9 2002:3::9 2002:6::9 2002:5::9 2002:2::9 2002:6::9 2002:4::9 2002:3::9 2002:1::9 2002:3::9 2002:4::9

1356329410 1356329411 1356329411 1356329411 1356329411 1356329411 1356329412 1356329412 1356329412 1356329412 1356329412 1356329413 1356329413 1356329413 1356329413 1356329413 1356329413 1356329414 1356329414 1356329414 1356329414 1356329414 1356329414 1356329416 1356329416 1356329416 1356329416 1356329416 1356329416 1356329416 1356329417 1356329417 1356329417 1356329418 1356329418 1356329418 1356329418 1356329418 1356329420 1356329420 1356329420 1356329420 1356329420 1356329420 1356329421 1356329421 1356329421 1356329421 1356329421 1356329421 1356329422 1356329422 1356329422 1356329422 1356329422 1356329423 1356329423

0.408849 0.376088 0.351327 0.355389 0.325528 0.348047 0.100197 0.385763 0.441587 0.437627 0.467515 1.165229 0.332686 0.322004 0.273873 0.62996 0.76747 0.426852 0.432879 0.452796 0.432014 0.59436 0.564859 1.264938 1.235703 1.189377 0.245543 0.356436 0.415645 0.406077 0.742111 0.714486 0.725719 0.447768 0.405225 0.4708 0.471268 0.417037 1.550233 1.567959 0.550419 1.604574 0.613007 0.574821 0.216935 0.218265 0.235616 0.292471 0.660304 0.710335 0.519038 0.52364 0.48532 0.845237 0.847183 0.62392 0.593703

15 16 16 16 16 16 17 17 17 17 17 17 18 18 18 18 18 19 19 19 19 19 19 20 20 20 21 21 21 21 22 22 22 23 23 23 23 23 24 24 25 24 25 25 26 26 26 26 26 26 27 27 27 27 27 28 28



90

06:10:23,168 06:10:23,395 06:10:23,396 06:10:23,690 06:10:23,691 06:10:23,691 06:10:23,691 06:10:23,749 06:10:24,259 06:10:25,214 06:10:25,215 06:10:25,216 06:10:25,217 06:10:25,964 06:10:25,966 06:10:25,968 06:10:25,970 06:10:27,681 06:10:27,682 06:10:27,683 06:10:27,684 06:10:27,686 06:10:28,237 06:10:28,239 06:10:29,955 06:10:29,957 06:10:29,959 06:10:29,961 06:10:29,964 06:10:29,966 06:10:31,986 06:10:31,989 06:10:31,992 06:10:31,994 06:10:31,999 06:10:32,003 06:10:32,088 06:10:32,090 06:10:32,092 06:10:32,887 06:10:32,888 06:10:32,889 06:10:32,891 06:10:32,892 06:10:34,364 06:10:34,365 06:10:34,367 06:10:34,369 06:10:34,371 06:10:35,354 06:10:35,355 06:10:35,356 06:10:36,121 06:10:36,122 06:10:36,123 06:10:36,125 06:10:36,127

15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900

2002:1::9 2002:7::9 2002:6::9 2002:3::9 2002:6::9 2002:2::9 2002:4::9 2002:7::9 2002:1::9 2002:2::9 2002:5::9 2002:7::9 2002:4::9 2002:6::9 2002:1::9 2002:5::9 2002:3::9 2002:5::9 2002:6::9 2002:2::9 2002:6::9 2002:7::9 2002:1::9 2002:3::9 2002:2::9 2002:3::9 2002:1::9 2002:6::9 2002:5::9 2002:4::9 2002:1::9 2002:4::9 2002:5::9 2002:6::9 2002:3::9 2002:3::9 2002:4::9 2002:7::9 2002:5::9 2002:2::9 2002:7::9 2002:3::9 2002:6::9 2002:4::9 2002:5::9 2002:6::9 2002:5::9 2002:3::9 2002:2::9 2002:6::9 2002:4::9 2002:5::9 2002:7::9 2002:4::9 2002:6::9 2002:2::9 2002:5::9

1356329423 1356329423 1356329423 1356329424 1356329424 1356329424 1356329424 1356329424 1356329424 1356329425 1356329425 1356329425 1356329425 1356329426 1356329426 1356329426 1356329426 1356329428 1356329428 1356329428 1356329428 1356329428 1356329428 1356329428 1356329430 1356329430 1356329430 1356329430 1356329430 1356329430 1356329432 1356329432 1356329432 1356329432 1356329432 1356329432 1356329432 1356329432 1356329432 1356329433 1356329433 1356329433 1356329433 1356329433 1356329434 1356329434 1356329434 1356329434 1356329434 1356329435 1356329435 1356329435 1356329436 1356329436 1356329436 1356329436 1356329436

0.626628 0.855476 0.856706 0.146214 0.147093 0.146378 0.107844 0.20756 0.707377 0.660341 0.589117 0.672604 0.633171 0.405855 0.406152 0.338661 0.410267 1.050354 1.115303 1.117665 0.104468 0.101075 0.668604 0.670461 1.376427 1.379683 1.381731 1.375881 1.316313 1.337602 1.402395 1.353828 1.332546 1.406244 1.40603 0.409405 0.443207 0.486137 0.426894 0.277796 0.279177 0.292055 0.295117 0.242212 1.69555 0.763332 0.690778 0.761892 0.753198 0.748037 0.691306 0.674958 0.490506 0.455487 0.515996 0.494575 0.43587

28 28 28 29 29 29 29 29 29 30 30 30 30 31 31 31 31 32 32 32 33 33 33 33 34 34 34 34 34 34 36 36 36 36 36 37 37 37 37 38 38 38 38 38 38 39 39 39 39 40 40 40 41 41 41 41 41



91

06:10:36,649 06:10:37,183 06:10:37,994 06:10:37,995 06:10:37,995 06:10:37,996 06:10:37,996 06:10:38,313 06:10:38,776 06:10:38,778 06:10:38,781 06:10:38,782 06:10:39,038 06:10:39,944 06:10:39,946 06:10:40,247 06:10:40,730 06:10:40,732 06:10:40,733 06:10:41,192 06:10:42,567 06:10:42,568 06:10:42,569 06:10:42,570 06:10:42,820 06:10:42,822 06:10:42,854 06:10:42,882 06:10:43,188 06:10:44,316 06:10:44,318 06:10:44,320 06:10:44,322 06:10:44,324 06:10:45,214 06:10:45,216 06:10:45,217 06:10:45,219 06:10:45,265

15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900 15900

2002:1::9 2002:2::9 2002:3::9 2002:2::9 2002:7::9 2002:6::9 2002:1::9 2002:3::9 2002:7::9 2002:6::9 2002:2::9 2002:3::9 2002:5::9 2002:6::9 2002:1::9 2002:4::9 2002:6::9 2002:7::9 2002:3::9 2002:4::9 2002:3::9 2002:1::9 2002:2::9 2002:4::9 2002:7::9 2002:7::9 2002:5::9 2002:2::9 2002:4::9 2002:1::9 2002:7::9 2002:3::9 2002:5::9 2002:4::9 2002:3::9 2002:2::9 2002:1::9 2002:4::9 2002:7::9

1356329437 1356329437 1356329438 1356329438 1356329438 1356329438 1356329438 1356329438 1356329439 1356329439 1356329439 1356329439 1356329439 1356329440 1356329440 1356329440 1356329441 1356329441 1356329441 1356329441 1356329443 1356329443 1356329443 1356329443 1356329443 1356329443 1356329443 1356329443 1356329443 1356329444 1356329444 1356329444 1356329444 1356329444 1356329445 1356329445 1356329445 1356329445 1356329445

1.030112 0.542026 0.368929 0.345886 0.354213 0.38265 0.366561 2.69453 0.131428 0.161039 0.125935 0.153488 0.335375 0.322879 0.293023 0.563005 0.104971 0.076207 0.095016 0.501702 0.922599 0.900197 0.881017 0.870921 1.151837 0.152783 1.135868 0.183184 0.47921 0.641935 0.642832 0.663869 0.599011 0.608792 0.556626 0.50051 0.541377 0.50172 0.589119

41 42 43 43 43 43 43 41 44 44 44 44 44 45 45 45 46 46 46 46 47 47 47 47 47 48 47 48 48 49 49 49 49 49 50 50 50 50 50



92

HASIL ALGORITMA AM PADA BSR DEBUG 2012-12-24 23:23:38,190 AM_algorithm ##### C-RP IP 2001:1::1 ###### DEBUG 2012-12-24 23:23:38,201 AM_algorithm UPLINK DUPLICATE DISTANCE FOR 2001:1::1 IS 0 DEBUG 2012-12-24 23:23:38,201 AM_algorithm SOURCES DUPLICATE DISTANCE FOR 2001:1::1 IS 1 DEBUG 2012-12-24 23:23:38,201 AM_algorithm MAXIMAL HOPS FROM SOURCES TO UPLINK IS 3 DEBUG 2012-12-24 23:23:38,202 AM_algorithm PATH FROM DR TO RP NUMBER IS 17 DEBUG 2012-12-24 23:23:38,202 AM_algorithm SOURCES NUMBER IS 7 DEBUG 2012-12-24 23:23:38,202 AM_algorithm THIS C-RP 2001:1::1 VALUE IS 14.00 DEBUG 2012-12-24 23:23:38,202 AM_algorithm INSERT COST TO RP_Set DEBUG 2012-12-24 23:23:38,203 AM_algorithm ########################################### DEBUG 2012-12-24 23:23:38,203 AM_algorithm ##### C-RP IP 2001:2::2 ###### DEBUG 2012-12-24 23:23:38,203 AM_algorithm UPLINK DUPLICATE DISTANCE FOR 2001:2::2 IS 0 DEBUG 2012-12-24 23:23:38,204 AM_algorithm SOURCES DUPLICATE DISTANCE FOR 2001:2::2 IS 1 DEBUG 2012-12-24 23:23:38,204 AM_algorithm MAXIMAL HOPS FROM SOURCES TO UPLINK IS 4 DEBUG 2012-12-24 23:23:38,204 AM_algorithm PATH FROM DR TO RP NUMBER IS 18 DEBUG 2012-12-24 23:23:38,204 AM_algorithm SOURCES NUMBER IS 7 DEBUG 2012-12-24 23:23:38,205 AM_algorithm THIS C-RP 2001:2::2 VALUE IS 15.00 DEBUG 2012-12-24 23:23:38,205 AM_algorithm INSERT COST TO RP_Set DEBUG 2012-12-24 23:23:38,205 AM_algorithm ########################################### DEBUG 2012-12-24 23:23:38,205 AM_algorithm ##### C-RP IP 2001:3::3 ###### DEBUG 2012-12-24 23:23:38,205 AM_algorithm UPLINK DUPLICATE DISTANCE FOR 2001:3::3 IS 0 DEBUG 2012-12-24 23:23:38,205 AM_algorithm SOURCES DUPLICATE DISTANCE FOR 2001:3::3 IS 1 DEBUG 2012-12-24 23:23:38,206 AM_algorithm MAXIMAL HOPS FROM SOURCES TO UPLINK IS 4 DEBUG 2012-12-24 23:23:38,206 AM_algorithm PATH FROM DR TO RP NUMBER IS 18 DEBUG 2012-12-24 23:23:38,206 AM_algorithm SOURCES NUMBER IS 7 DEBUG 2012-12-24 23:23:38,206 AM_algorithm THIS C-RP 2001:3::3 VALUE IS 15.00 DEBUG 2012-12-24 23:23:38,206 AM_algorithm INSERT COST TO RP_Set DEBUG 2012-12-24 23:23:38,212 AM_algorithm ########################################### DEBUG 2012-12-24 23:23:38,212 AM_algorithm ##### C-RP IP 2001:4::4 ###### DEBUG 2012-12-24 23:23:38,213 AM_algorithm UPLINK DUPLICATE DISTANCE FOR 2001:4::4 IS 1 DEBUG 2012-12-24 23:23:38,214 AM_algorithm SOURCES DUPLICATE DISTANCE FOR 2001:4::4 IS 2 DEBUG 2012-12-24 23:23:38,214 AM_algorithm MAXIMAL HOPS FROM SOURCES TO UPLINK IS 5 DEBUG 2012-12-24 23:23:38,214 AM_algorithm PATH FROM DR TO RP NUMBER IS 23 DEBUG 2012-12-24 23:23:38,215 AM_algorithm SOURCES NUMBER IS 7 DEBUG 2012-12-24 23:23:38,215 AM_algorithm THIS C-RP 2001:4::4 VALUE IS 19.00 DEBUG 2012-12-24 23:23:38,216 AM_algorithm INSERT COST TO RP_Set



93

DEBUG 2012-12-24 23:23:38,216 AM_algorithm ########################################### DEBUG 2012-12-24 23:23:38,217 AM_algorithm ##### C-RP IP 2001:5::5 ###### DEBUG 2012-12-24 23:23:38,217 AM_algorithm UPLINK DUPLICATE DISTANCE FOR 2001:5::5 IS 1 DEBUG 2012-12-24 23:23:38,218 AM_algorithm SOURCES DUPLICATE DISTANCE FOR 2001:5::5 IS 2 DEBUG 2012-12-24 23:23:38,218 AM_algorithm MAXIMAL HOPS FROM SOURCES TO UPLINK IS 5 DEBUG 2012-12-24 23:23:38,219 AM_algorithm PATH FROM DR TO RP NUMBER IS 23 DEBUG 2012-12-24 23:23:38,219 AM_algorithm SOURCES NUMBER IS 7 DEBUG 2012-12-24 23:23:38,220 AM_algorithm THIS C-RP 2001:5::5 VALUE IS 19.00 DEBUG 2012-12-24 23:23:38,220 AM_algorithm INSERT COST TO RP_Set DEBUG 2012-12-24 23:23:38,221 AM_algorithm ########################################### DEBUG 2012-12-24 23:23:38,221 AM_algorithm ##### C-RP IP 2001:7::7 ###### DEBUG 2012-12-24 23:23:38,222 AM_algorithm UPLINK DUPLICATE DISTANCE FOR 2001:7::7 IS 1 DEBUG 2012-12-24 23:23:38,223 AM_algorithm SOURCES DUPLICATE DISTANCE FOR 2001:7::7 IS 2 DEBUG 2012-12-24 23:23:38,223 AM_algorithm MAXIMAL HOPS FROM SOURCES TO UPLINK IS 5 DEBUG 2012-12-24 23:23:38,223 AM_algorithm PATH FROM DR TO RP NUMBER IS 23 DEBUG 2012-12-24 23:23:38,224 AM_algorithm SOURCES NUMBER IS 7 DEBUG 2012-12-24 23:23:38,224 AM_algorithm THIS C-RP 2001:7::7 VALUE IS 19.00 DEBUG 2012-12-24 23:23:38,225 AM_algorithm INSERT COST TO RP_Set DEBUG 2012-12-24 23:23:38,225 AM_algorithm ########################################### DEBUG 2012-12-24 23:23:38,226 AM_algorithm ##### C-RP IP 2001:6::6 ###### DEBUG 2012-12-24 23:23:38,226 AM_algorithm UPLINK DUPLICATE DISTANCE FOR 2001:6::6 IS 1 DEBUG 2012-12-24 23:23:38,227 AM_algorithm SOURCES DUPLICATE DISTANCE FOR 2001:6::6 IS 2 DEBUG 2012-12-24 23:23:38,228 AM_algorithm MAXIMAL HOPS FROM SOURCES TO UPLINK IS 5 DEBUG 2012-12-24 23:23:38,228 AM_algorithm PATH FROM DR TO RP NUMBER IS 23 DEBUG 2012-12-24 23:23:38,228 AM_algorithm SOURCES NUMBER IS 7 DEBUG 2012-12-24 23:23:38,229 AM_algorithm THIS C-RP 2001:6::6 VALUE IS 19.00 DEBUG 2012-12-24 23:23:38,229 AM_algorithm INSERT COST TO RP_Set DEBUG 2012-12-24 23:23:38,230 AM_algorithm ########################################### DEBUG 2012-12-24 23:23:38,230 __exit__ 41.45ms



UNIVERSITAS INDONESIA

Recommend Documents