BAB 4 HASIL DAN PEMBAHASAN. sebelumnya pada bab 3 yang akan dianalisis dan dibahas sehingga diharapkan

Transkripsi

1 BAB 4 HASIL DAN PEMBAHASAN Pada bab ini akan dijelaskan mengenai hasil dari skenario yang telah ditentukan sebelumnya pada bab 3 yang akan dianalisis dan dibahas sehingga diharapkan menghasilkan suatu jawaban atas masalah yang ada pada bab sebelumnya dan dapat digunakan sebagai acuan dalam menentukan kesimpulan dan rencana kedepannya. 4.1 Pengujian Simulasi Pada bagian ini, penulis akan menampilkan dan menjelaskan mengenai hasi dari penelitian yang dijalankan menggunakan network simulator NS-3. Pada simulasi berdasarkan skenario yang sudah dijelaskan sebelumnya, penulis akan melakukan beberapa simulasi yaitu sebagai berikut: Analisa dan Hasil Skenario I Pada saat menjalankan simulasi ini ada beberapa parameter yang ada dalam program yang harus diperhatikan, antara lain: PDR (Packet Delivery Ratio) Delay Throughput Packet loss Ratio Berikut adalah hasil output dari simulasi skenario dengan jalur Tunnel1 yang menjadi Best-Path pada infrastruktur jaringan MPLS. 53

2 54 Node 6 dengan IP Source pada pengguna1 : dan pengguna2 : Node 11 dengan IP Destination pada server1 : dan server2 : Node 12 dengan IP Source pada pengguna1 : dan pengguna2 : Node 11 dengan IP Destination pada server1: dan server2: Digunakannya dua server pada Node 11, ketika terjadi down pada server utama yaitu server1 yang disebabkan oleh congestion/bottleneck, server2 akan secara otomatis membackup sehingga proses pengirman data tetap berjalan lancar. Hasil Output: Gambar 4.1 Node 6 ke Node 7 (Server1) Node 6 mengklasifikasikan paket yang diterima dari source pada pengguna1 dan pengguna2 menuju destination pada server1 dengan panjang paket 228. Node 6 menemukan entry dan mencari ftn (fec-to-nhlfe) dan nhlfe (next hop label first entry) yang sesuai. ftn digunakan untuk pemetaan dari FEC dari setiap paket yang masuk ke nhlfe yang sesuai. nhlfe digunakan untuk mencari label dan nexthop yang sesuai. Default policy pada nhlfe memilih label 100 dengan nexthop melalui interface2 untuk forwading paket ke Node 7. Default policy digunakan sebagai prioritas pemilihan label

3 55 dan nexthop. Proses pemilihannya adalah label dan nexthop yang diklarifikasi pertama yang akan menjadi prioritas. Gambar 4.2 Node 6 ke Node 7 (Server2) Node 6 mengklasifikasikan paket yang diterima dari source pada pengguna1 dan pengguna2 menuju destination pada server2 dengan panjang paket 228. Node 6 menemukan entry dan mencari ftn dan nhlfe yang sesuai. Default policy pada nhlfe memilih label 100 dengan nexthop melalui interface2 untuk forwarding paket ke Node 7. Gambar 4.3 Node 12 ke Node 7 (Server1) Node 12 mengklasifikasikan paket yang diterima dari source pada pengguna3 dan pengguna4 menuju destination pada server1 dengan panjang paket 228. Node 12 menemukan entry dan mencari ftn dan nhlfe yang sesuai. Default policy pada nhlfe

4 56 memilih label 900 dengan nexthop melalui interface2 untuk forwarding paket ke Node 7. Gambar 4.4 Node 12 ke Node 7 (Server2) Node 12 mengklasifikasikan paket yang diterima dari source pada pengguna3 dan pengguna4 menuju destination pada server2 dengan panjang paket 228. Node 12 menemukan entry dan mencari ftn dan nhlfe yang sesuai. Default policy pada nhlfe memilih label 900 dengan nexthop melalui interface2 untuk forwarding paket ke Node 7. Gambar 4.5 Node 7 ke Node 8 Node 7 menerima paket dari Node 6 yang memiliki stack top label 100 dengan ttl 63 melalui interface0 dan menerima paket dari Node 12 yang memiliki stack top label 900

5 57 dengan ttl 63 melalui interface1. stack top label didapat dari pengiriman paket yang berasal dari Node 6 yang memiliki label 100 dan Node 12 yang memiliki label 900. Node 7 menemukan entry dan mencari ilm (incoming label map) dan nhlfe yang sesuai. ilm digunakan untuk pemetaan label yang masuk ke nhlfe. Secara default policy, Node 7 memiliki dua pertimbangan untuk memilih label dan nexthop yang tepat yaitu (swap, 200 nexthop ) dan (swap, 300 nexthop ). label dan nexthop yang diklarifikasi pertama yang akan menjadi prioritas. Sehingga Node 7 memilih label 200 dengan nexthop melalui interface2 untuk forwarding paket ke Node 8. (swap, 300 nexthop ) akan digunakan untuk jalur cadangan jika terjadi kegagalan link pada nexthop sehingga dapat secara cepat membackup (FastReroute). Gambar 4.6 Node 8 ke Node 10 Node 8 menerima paket dari Node 7 yang memiliki stack top label 200 dengan ttl 62 melalui interface0. Stack top label didapat dari pengiriman paket yang berasal dari Node 7 yang memiliki label 200. Node 8 menemukan entry dan mencari ilm dan nhlfe yang sesuai. Secara default policy, Node 8 memiliki dua pertimbangan untuk memilih label dan nexthop yang tepat yaitu (swap, 500 nexthop ) dan (swap, 400 nexthop ). label dan nexthop yang diklarifikasi pertama yang akan menjadi prioritas.

6 58 Sehingga Node 8 memilih label 500 dengan nexthop melalui interface2 untuk forwarding paket ke Node 10. (swap, 400 nexthop ) akan digunakan untuk jalur cadangan jika terjadi kegagalan link pada nexthop sehingga dapat secara cepat membackup (FastReroute). Gambar 4.7 Node 10 ke Node 11 Node 10 menerima paket dari Node 8 yang memiliki stack top label 500 dengan ttl 61 melalui interface0. stack top label didapat dari pengiriman paket yang berasal dari Node 8 yang memiliki label 500. Node 10 menemukan entry dan mencari ilm dan nhlfe yang sesuai. Secara default policy, Node 10 memilih label 700 dengan nexthop melalui interface2 untuk forwarding paket ke Node 11. Gambar 4.8 Node 11 ke IP destionation (server1 dan server2)

7 59 Node 11 menerima paket dari Node 10 yang memiliki stack top label 700 dengan ttl 60 melalui intarface2. stack top label didapat dari pengiriman paket yang berasal dari Node 10 yang memiliki label 700. Node 11 menemukan entry dan mencari ilm dan nhlfe yang sesuai. Secara default policy, Node 11 memilih label dengan nexthop akan tetapi default policy melakukan pop label karena paket sudah mencapai IP destination Uji Monitoring Performance: Uji monitoring performance digunakan untuk mengukur seberapa baik dan buruknya konektivitas pada jaringan, sehingga dapat diukur seberapa besar nilai parameter paremeter yang diuji. Untuk uji monitoring performance pada Tunnel1, parameter-parameter yang digunakan untuk mengukur kualitas layanan IPTV berupa PDR, Delay, Throughput dan Packet Loss Ratio. Pada pengujian kali ini, penulis menggunakan pengguna1 untuk uji konektivitas ke server1 dan server2. Uji konektivitas ini dilakukan pada pengguna agar pengguna dapat men-trace suatu nilai parameter jaringan pada server. Uji Performance ke server1: Monitoring Performance dilakukan selama 1.2 seconds Monitoring Performance dilakukan selama 1.5 seconds. Gambar 4.9 Monitoring Performance dilakukan selama 1.2 seconds.

8 60 Gambar 4.10 Monitoring Performance dilakukan selama 1.5 seconds Pengujian untuk server2 dilakukan, bila terjadi masalah di server1 seperti bottleneck yang dapat menyebabkan server down, maka server2 dapat membackup, sehingga pengiriman paket tetap terjamin. Uji Performance ke server2 : Gambar 4.11 Monitoring Performance dilakukan selama 1.2 seconds. Gambar 4.11 Monitoring Performance dilakukan selama 1.2 seconds

9 61 Gambar 4.12 Monitoring Performance dilakukan selama 1.5 seconds Uji Monitoring Performance dengan Grafik Pengujian dilakukan selama 1.2, 1.5, 1.8, 2.1, 2.4, 2.7, 3.0, 3.3, 3.6, 3.9 seconds untuk setiap nilai PDR, Throughput, Delay dan Packet Loss Ratio. 1. Uji monitoring PDR Gambar 4.13 Monitoring performance terhadap server1

10 62 Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai PDR sebesar 96.8 % pada 1.2 seconds sampai pada 3.9 seconds. Nilai ratio PDR akan terus meningkat seiring dengan bertambahnya waktu yang dapat mempengaruhi besarnya packet yang dikirim dan paket yang diterima. 2. Uji monitoring Throughput Gambar 4.14 Monitoring performance terhadap Server1. Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai Throughput sebesar Mbps pada 1.2 seconds sampai Mbps pada 3.9 seconds. Nilai ini dipengaruhi oleh ratio PDR yang akan terus meningkat seiring dengan bertambahnya waktu yang dapat mempengaruhi

11 63 besarnya packet yang dikirim dan paket yang diterima. PDR dalam hal ini mempengaruhi nilai Throughput. 3. Uji monitoring Delay Gambar 4.15 Monitoring performance terhadap Server1. Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai Delay sebesar seconds pada 1.2 seconds sampai pada 3.9 seconds. Nilai ini dipengaruhi oleh bertambahnya waktu yang dapat mempengaruhi besarnya paket yang dikirim dan jumlah hop count ke destination.

12 64 4. Uji monitoring Packet Loss Ratio Gambar 4.16 Monitoring performance terhadap Server1. Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai Packet Loss Ratio sebesar 3.2% pada 1.2 seconds sampai pada 3.9 seconds. Nilai ini dipengaruhi oleh selisih nilai ratio PDR Output Paket Capture (Pcap) Tools wireshark untuk paket capture dari source menuju destination, beserta label ke label setiap hop. Port dari pengguna berupa Dynamic Port sedangkan pada Server berupa protocol UDP port 1234 VLC (Searchagent).

13 65 Gambar 4.17 Customer Edge VPN1_A ke Provider Edge PE_1 Gambar 4.18 Customer Edge VPN1_C ke Provider Edge PE_1

14 66 Gambar 4.19 Provider Edge PE_1 ke Core P1 Gambar 4.20 Core P1 ke Provider Edge PE_2

15 67 Gambar 4.21 Provider Edge PE_2 ke Customer Edge VPN1_B Analisa dan Hasil Skenario II Dalam suatu jaringan terkadang semuanya tidak berjalan dengan lancar dan trafik selalu dalam keadaan baik. Kepadatan dan congestion yang terjadi dapat membuat trafik menjadi lambat bahkan menjadi down. Berikut adalah hasil output dari simulasi skenario dengan jalur Tunnel1 yang menjadi Best-Path pada infrastruktur jaringan MPLS tetapi mengalami kegagalan link pada P1 menuju PE_2 beserta parameter parameter yang harus diperhatikkan. IP Source dan IP Destination yang digunakan tetap sama seperti jalur Tunnel1 dan untuk proses jalannya alur beserta output pada node 6, node 12 dan node 7 sama seperti pada proses jalannya alur Tunnel1. Yang membedakkan Redundant Tunnel1 dengan Tunnel1 adalah ketika proses jalannya alur dimulai pada Node 8.

16 68 Hasil Output : Gambar 4.22 Node 8 ke Node 9 Node 8 menerima paket dari Node 7 yang memiliki stack top label 200 dengan ttl 62 melalui interface0. stack top label didapat dari pengiriman paket yang berasal dari Node 7 yang memiliki label 200. Node 8 menemukan entry dan mencari ilm dan nhlfe yang sesuai. Secara default policy, Node 8 memiliki dua pertimbangan untuk memilih label dan nexthop yang tepat yaitu (swap,500 nexthop ) dan (swap,400 nexthop ). label dan nexthop yang diklarifikasi pertama yang akan menjadi prioritas. Akan tetapi path yang menghubungkan P1 dengan PE_2 sebagai jalur utama megalami down, sehingga nexthop dengan label 400 akan digunakan. Gambar 4.23 Node 9 ke Node 10 Node 9 menerima paket dari Node 8 yang memiliki stack top label 400 dengan ttl 61 melalui interface1. stack top label didapat dari pengiriman paket yang berasal dari Node

17 69 8 yang memiliki label 400. Node 9 menemukan entry dan mencari ilm dan nhlfe yang sesuai. Secara default policy, Node 9 memilih label 600 dengan nexthop melalui interface2 untuk forwarding paket ke Node 10. Gambar 4.24 Node 10 ke Node 11 Node 10 menerima paket dari Node 9 yang memiliki stack top label 600 dengan ttl 60 melalui interface0. stack top label didapat dari pengiriman paket yang berasal dari Node 9 yang memiliki label 600. Node 10 menemukan entry dan mencari ilm dan nhlfe yang sesuai. Secara default policy, Node 10 memilih label 700 dengan nexthop melalui interface1 untuk forwarding paket ke Node 11. Gambar 4.25 Node 11 ke IP destionation (server1 dan server2) Node 11 menerima paket dari Node 10 yang memiliki stack top label 700 dengan ttl 59 melalui intarface2. stack top label didapat dari pengiriman paket yang berasal dari Node

18 70 10 yang memiliki label 700. Node 11 menemukan entry dan mencari ilm dan nhlfe yang sesuai. Secara default policy, Node 11 memilih label dengan nexthop akan tetapi default policy melakukan pop label karena paket sudah mencapai IP destination Uji Monitoring Performance Uji monitoring performance memiliki skenario yang sama seperti pada jalur Tunnel1, yaitu dengan memperhatikan parameter-parameter yang digunakan untuk mengukur kualitas layanan IPTV berupa PDR, Delay,Throughput dan Packet Loss Ratio. Uji Performance ke server1: Gambar 4.26 Monitoring Performance dilakukan selama 1.2 seconds.

19 71 Gambar 4.27 Monitoring Performance dilakukan selama 1.5 seconds. Pengujian untuk server2 dilakukan, bila terjadi masalah di server1 seperti bottleneck yang dapat menyebabkan server down, maka server2 dapat membackup, sehingga pengiriman paket tetap terjamin. Uji Performance ke server2 : Gambar 4.28 Monitoring Performance dilakukan selama 1.2 seconds.

20 72 Gambar 4.29 Monitoring Performance dilakukan selama 1.5 seconds Uji Monitoring Performance dengan Grafik Pengujian dilakukan selama 1.2, 1.5, 1.8, 2.1, 2.4, 2.7, 3.0, 3.3, 3.6, 3.9 seconds untuk setiap nilai PDR, Throughput, Delay dan Packet Loss Ratio. 1. Uji monitoring PDR Gambar 4.30 monitoring performance terhadap Server1.

21 73 Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai PDR sebesar 96.8% pada 1.2 seconds sampai % pada 3.9 seconds. Nilai ratio PDR akan terus meningkat seiring dengan bertambahnya waktu yang dapat mempengaruhi besarnya packet yang dikirim dan paket yang diterima. 2. Uji monitoring Throughput Gambar 4.31 monitoring performance terhadap Server1. Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai Throughput sebesar Mbps pada 1.2 seconds sampai Mbps pada 3.9 seconds. Nilai ini dipengaruhi oleh nilai ratio PDR yang akan terus meningkat seiring dengan bertambahnya waktu yang dapat mempengaruhi besarnya packet

22 74 yang dikirim dan paket yang diterima. PDR dalam hal ini mempengaruhi Throughput. 3. Uji monitoring Delay Gambar 4.32 monitoring performance terhadap Server1 Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai Delay sebesar seconds pada 1.2 seconds sampai pada 3.9 seconds. Nilai ini dipengaruhi oleh bertambahnya waktu yang dapat mempengaruhi besarnya paket yang dikirm dan jumlah hop count ke destination.

23 75 4. Uji monitoring Packet Loss Ratio Gambar 4.33 monitoring performance terhadap Server1 Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai Packet Loss Ratio sebesar 3.2% pada 1.2 seconds sampai pada 3.9 seconds. Nilai ini dipengaruhi oleh selisih nilai ratio PDR Output Paket Capture (Pcap) Tools wireshark untuk paket capture dari source menuju destination, beserta label ke label setiap hop. port dari pengguna berupa Dynamic Port sedangkanpada Server berupa protocol UDP port 1234 VLC (Search agent). Untuk paket capture dari Customer Edge VPN1_A ke Provider Edge PE_1, VPN1_C ke Provider Edge PE_1, Provider Edge PE_1 ke Core P1 sama seperti pada jalur Tunnel1.

24 76 Gambar 4.34 Core P1 ke Core P2 Gambar 4.35 Core P2 ke Provider Edge PE_2

25 77 Gambar 4.36 Provider Edge PE_2 ke Customer Edge VPN1_B Perbandingan Uji Monitoring Performance dengan Grafik Pengujian dilakukan selama 1.2, 1.5, 1.8, 2.1, 2.4, 2.7, 3.0, 3.3, 3.6, 3.9 seconds untuk setiap nilai PDR, Throughput, Delay dan Packet Loss Ratio. 1. Uji monitoring PDR Gambar 4.37 Monitoring performance terhadap Server1

26 78 Berdasarkan uji monitoring yang telah dilakukan pada Tunnel1 dan Redundant Tunnel1, dapat diketahui bahwa nilai ratio PDR Tunnel1 lebih baik ketimbang jalur Redundant Tunnel1, hal ini dapat dilihat dari perbandingan nilai ratio PDR-nya ketika nilai PDR sebesar 96.8% pada 1.2 seconds sampai % pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang Redundant Tunnel1 yang memiliki nilai sebesar % pada 1.2 seconds sampai % pada 3.9 seconds. 2. Uji monitoring Throughput Gambar 4.38 Monitoring performance terhadap Server1 Berdasarkan uji monitoring yang telah dilakukan pada Tunnel1 dan Redundant Tunnel1, dapat diketahui bahwa nilai Throughput Tunnel1 lebih baik ketimbang jalur Redundant Tunnel1, hal ini dapat dilihat

27 79 dari perbandingan nilai Throughput ketika memiliki nilai Mbps pada 1.2 seconds sampai Mbps pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang Redundant Tunnel1 yang memiliki nilai sebesar Mbps pada 1.2 seconds sampai Mbps pada 3.9 seconds. 3. Uji monitoring Delay Gambar 4.39 Monitoring performance terhadap Server1 Berdasarkan uji monitoring yang telah dilakukan pada Tunnel1 dan Redundant Tunnel1, dapat diketahui bahwa nilai Delay Tunnel1 lebih baik ketimbang jalur Redundant Tunnel1, hal ini dapat dilihat dari perbandingan nilai Delay ketika memiliki nilai seconds pada 1.2 seconds sampai seconds pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang

28 80 Redundant Tunnel1 yang memiliki nilai sebesar seconds pada 1.2 seconds sampai seconds pada 3.9 seconds. 4. Uji monitoring Packet Loss Ratio Gambar 4.40 Monitoring performance terhadap Server1 Berdasarkan uji monitoring yang telah dilakukan pada Tunnel1 dan Redundant Tunnel1, dapat diketahui bahwa nilai Packet Loss Ratio Tunnel1 lebih baik ketimbang jalur Redundant Tunnel1, hal ini dapat dilihat dari perbandingan nilai Packet Loss Ratio ketika memiliki nilai 3.2% pada 1.2 seconds sampai % pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang Redundant Tunnel1 yang memiliki nilai sebesar % pada 1.2 seconds sampai % pada 3.9 seconds.

29 Kaitan Analisa Hasil Uji Monitoring dengan QoE Berdasarkan kedua skenario yang telah dilakukan, bahwa uji monitoring penting untuk mengetahui nilai parameter parameter QoS didalamnya yang dapat mempengaruhi QoE dari sisi pengguna. Hasil output uji monitoring dari pengguna dapat menunjukkan bahwa suatu nilai parameter yang di trace ke server memiliki nilai yang baik pada jaringan MPLS dan untuk layanan IPTV. Dengan nilai PDR yang besar yaitu rata rata diatas 90%, nilai delay yang kecil dimulai dari range seconds hingga seconds, nilai throughput yang besar dimulai dari range Mbps hingga Mbps dan nilai packet loss ratio yang kecil dimulai dari range 3.733% hingga %, boleh dikatakan suatu jaringan MPLS yang disimulasikan oleh penulis memiliki performance yang baik dari sisi penyedia layanan akan tetapi semua tergantung pada harapan pengguna yang menerima layanan yang diberikan, karena jika suatu performance jaringan baik belum tentu mempengaruhi pengguna yang puas akan layanan yang diberikan karena pengguna memiliki sisi non-teknikal faktor yang mempengaruhi harapan akan layanan yang diberikan. Sehingga keterkaitan nilai parameter QoS dapat mempengaruhi dan menentukan kepuasan dari pengguna.