53
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:
4.1.1 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.
Node 6 dengan IP Source pada pengguna1 : 192.168.1.1 dan pengguna2 : 192.168.2.1 → Node 11 dengan IP Destination pada server1 : 192.168.5.2 dan server2 : 192.168.6.2.
Node 12 dengan IP Source pada pengguna1 : 192.168.3.1 dan pengguna2 : 192.168.4.1 → Node 11 dengan IP Destination pada server1: 192.168.5.2 dan server2: 192.168.6.2.
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 10.1.1.2 melalui interface2 untuk forwading paket ke Node 7. Default policy digunakan sebagai prioritas pemilihan label
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 10.1.1.2 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
memilih label 900 dengan nexthop 10.1.8.2 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 10.1.8.2 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
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 10.1.2.2) dan (swap, 300 nexthop 10.1.3.2). label dan nexthop yang diklarifikasi pertama yang akan menjadi prioritas. Sehingga Node 7 memilih label 200 dengan nexthop 10.1.2.2 melalui interface2 untuk forwarding paket ke Node 8. (swap, 300 nexthop 10.1.3.2) akan digunakan untuk jalur cadangan jika terjadi kegagalan link pada nexthop 10.1.2.2 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 10.1.5.2) dan (swap, 400 nexthop 10.1.4.2). label dan nexthop yang diklarifikasi pertama yang akan menjadi prioritas.
Sehingga Node 8 memilih label 500 dengan nexthop 10.1.5.2 melalui interface2 untuk forwarding paket ke Node 10. (swap, 400 nexthop 10.1.4.2) akan digunakan untuk jalur cadangan jika terjadi kegagalan link pada nexthop 10.1.5.2 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 10.1.7.2 melalui interface2 untuk forwarding paket ke Node 11.
Gambar 4.8 Node 11 ke IP destionation (server1 dan server2)
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.
4.1.1.1 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.
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
Gambar 4.12 Monitoring Performance dilakukan selama 1.5 seconds.
4.1.1.2 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
Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai PDR sebesar 96.8 % pada 1.2 seconds sampai 99.7931 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 0.0631439 Mbps pada 1.2 seconds sampai 0.943767 Mbps pada 3.9 seconds.
Nilai ini dipengaruhi oleh ratio PDR yang akan terus meningkat seiring dengan bertambahnya waktu yang dapat mempengaruhi
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 0.00613975 seconds pada 1.2 seconds sampai 0.006144235 pada 3.9 seconds. Nilai ini dipengaruhi oleh bertambahnya waktu yang dapat mempengaruhi besarnya paket yang dikirim dan jumlah hop count ke destination.
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 0.2069 pada 3.9 seconds. Nilai ini dipengaruhi oleh selisih nilai ratio PDR.
4.1.1.3 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 (Search- agent).
Gambar 4.17 Customer Edge VPN1_A ke Provider Edge PE_1
Gambar 4.18 Customer Edge VPN1_C ke Provider Edge PE_1
Gambar 4.19 Provider Edge PE_1 ke Core P1
Gambar 4.20 Core P1 ke Provider Edge PE_2
Gambar 4.21 Provider Edge PE_2 ke Customer Edge VPN1_B
4.1.2 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.
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 10.1.5.2) dan (swap,400 nexthop 10.1.4.2). 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 10.1.4.2 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
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 10.1.6.2 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 10.1.7.2 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
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.
4.1.2.1 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.
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.
Gambar 4.29 Monitoring Performance dilakukan selama 1.5 seconds.
4.1.2.2 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.
Pada saat awal, semua pengguna membangun konektivitas dengan server1 yang mempunyai nilai PDR sebesar 96.8% pada 1.2 seconds sampai 99.6873% 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 0.0631439 Mbps pada 1.2 seconds sampai 0.943767 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
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 0.00715847 seconds pada 1.2 seconds sampai 0.007163517 pada 3.9 seconds. Nilai ini dipengaruhi oleh bertambahnya waktu yang dapat mempengaruhi besarnya paket yang dikirm dan jumlah hop count ke destination.
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 0.2391 pada 3.9 seconds. Nilai ini dipengaruhi oleh selisih nilai ratio PDR.
4.1.2.3 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.
Gambar 4.34 Core P1 ke Core P2
Gambar 4.35 Core P2 ke Provider Edge PE_2
Gambar 4.36 Provider Edge PE_2 ke Customer Edge VPN1_B
4.1.3 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
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 99.7931% pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang Redundant Tunnel1 yang memiliki nilai sebesar 96.2667% pada 1.2 seconds sampai 99.7609% 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
dari perbandingan nilai Throughput ketika memiliki nilai 0.0631439 Mbps pada 1.2 seconds sampai 0.943767 Mbps pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang Redundant Tunnel1 yang memiliki nilai sebesar 0.062796 Mbps pada 1.2 seconds sampai 0.943506 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 0.00613975 seconds pada 1.2 seconds sampai 0.006144235 seconds pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang
Redundant Tunnel1 yang memiliki nilai sebesar 0.00715847 seconds pada 1.2 seconds sampai 0.007163517 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 0.2069% pada 3.9 seconds untuk Tunnel1 lebih baik ketimbang Redundant Tunnel1 yang memiliki nilai sebesar 3.7333% pada 1.2 seconds sampai 0.2391% pada 3.9 seconds.
4.2 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 0.00613975 seconds hingga 0.007237277 seconds, nilai throughput yang besar dimulai dari range 0.061439 Mbps hingga 0.942642 Mbps dan nilai packet loss ratio yang kecil dimulai dari range 3.733% hingga 0.2069%, 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.