Implementasi Teknologi MPLS/DiffServ dengan Kondisi High Traffic pada Jaringan IPv4 dan IPv6

Transkripsi

1 Implementasi Teknologi MPLS/DiffServ dengan Kondisi High Traffic pada Jaringan IPv4 dan IPv6 Romi Darmawan, Dodi Sudiana Departemen Teknik Elektro, Universitas Indonesia, Depok, Jawa Barat, 16424, Indonesia Abstrak Aplikasi berbasis jaringan internernet real-time seperti VoIP dan Video Conferencing sangat sensitif terhadap gangguan berupa ketersediaan bandwidth, terjadinya delay, packet loss, dan jitter. Untuk jaringan data dengan trafik bervariasi (seperti voice, video, data), dibutuhkan perlakuan khusus terhadap trafik data tertentu. Implementasi teknologi Quality of Service untuk menguji kinerja umum dilakukan dan teknik yang paling populer adalah Differentiated of Service (DiffServ). Namun dengan meningkatnya penetrasi trafik data pada jaringan komunikasi, masalah skalabilitas dan efisiensi menjadi penting. Multi- Protocol Label Switching (MPLS) memberikan kecepatan, skalabilitas serta efisiensi terhadap unjuk kerja jaringan. Dengan mengintegrasikan kedua teknologi tersebut, diharapkan unjuk kerja jaringan semakin baik bagi aplikasi atau layanan yang memerlukan garansi Quality of Service (QoS). Dalam penelitian ini implementasi teknologi MPLS DiffServ-Aware tidak hanya dilakukan pada jaringan IPv4 namun juga pada jaringan IPv6. Simulasi menunjukkan aplikasi yang sensitif terhadap QoS seperti VoIP, implementasi MPLS/DiffServ mampu memberikan garansi QoS dengan delay mencapai 87 ms, packet loss sebesar 0% dan jitter yang sangat kecil. Untuk aplikasi video conferencing, unjuk kerja juga lebih baik jika dibandingkan dengan hanya menggunakan teknologi IP Best- Effort, DiffServ, maupun MPLS secara independen. Untuk jaringan IPv6, unjuk kerja throughput lebih baik dari IPv4, namun secara keseluruhan unjuk kerja jaringan IPv4 masih lebih baik dibandingkan jaringan IPv6. Kata Kunci: real-time application, IPv4, IPv6, QoS, DiffServ, MPLS, unjuk kerja Implementation of MPLS/DiffServ QoS Technology in High Traffic Condition for IPv4 and IPv6 Networks Abstract Real-time network based applications such as VoIP and Video Conferencing are critical when it deals with bandwidth, delay, packet loss, and jitter. In a service integrated network (such as voice,video, and data services), it is needed to treat a service accordingly. The implementation of Quality of Service are common in today's networks : one of those technologies is Differentiated of Service (DiffServ). Nevertheless, with higher penetration of data traffics from time to time, the issues of scalability and eficiency appear significantly. Multi-Protocol Label Switching (MPLS) offers a good solution for improving the network performance. By integrating those two technologies, it is expected to improve the

2 overall network performance, especially for service or application that needs QoS-guaranteed. This research not only focus on the implementation of MPLS DiffServ-Aware in IPv4 networks environment but also in IPv6 as well. Simulation results, showed that MPLS/DiffServ technology provides best performance for real-time or QoS-sensitive applications. For VoIP application, the delay is recorded as 87 ms, packet loss 0% and a very low jitter. For video conferencing service, those QoS parameters are also better if compared to those technologies if are implemented separately. Althought IPv6 showed a higher throughput performance, still IPv4 showed a better performance generally. Keywords: real-time application, IPv4, IPv6, QoS, DiffServ, MPLS, performance 1. Pendahuluan Kehadiran IPv6 mengindikasikan bahwa penetrasi pengguna jaringan dan juga lalu lintas data (layanan aplikasi) mengalami peningkatan. Sementara dari sisi type of service sendiri berdasarkan data yang diperoleh oleh Internet Telecommunication Union (ITU), aplikasi real-time seperti VoIP dan Video Conferencing juga mengalami pertumbuhan pengguna yang pesat dan hal ini akan terus berlanjut [1]. Aplikasi real-time merupakan jenis layanan yang sensitif terhadap delay dan juga packet loss, sehingga dalam implementasinya jaringan yang dilalui oleh layanan tersebut sebaiknya mendukung QoS. Berbagai metode scheduling, queuing dan drop behavior dapat diterapkan pada edge router untuk mendukung pengalokasian kapasitas dan juga prioritas data pada congested networks. Dengan metode DiffServ (Differentiated of Service), aplikasi dapat diklasifikasikan berdasarkan jenis layanannya (Class 0f Service) untuk menentukan prioritas dari paket-paket tersebut. Namun DiffServ memiliki keterbatasan dalam menangani masalah skalabilitas dan fleksibilitas pada jaringan. Ketika lalu lintas data membesar maka congestion pada jaringan tidak dapat dihindari, begitu juga ketika terjadi link/node failure pada jaringan maka degradasi unjuk kerja jaringan tidak dapat dihindari. Untuk itu diperlukan teknologi lain yang mampu memberikan guaranteed QoS yang lebih baik. MPLS (Multi Protocol Label Switching) saat ini menjadi salah satu solusi terbaik yang dapat ditawarkan. Banyak ISP telah menanamkan teknologi ini pada jaringan backbone mereka untuk memberikan pengalaman yang lebih baik bagi user saat menggunakan aplikasi layanan jaringan. Berbeda dengan jaringan IP tradisional, MPLS menggunakan Label Switch Path (LSP) untuk mengalirkan paket data, di mana link yang

3 dibangun dipastikan memiliki resources dan bandwidth yang dibutuhkan. Dengan mengkombinasikan teknologi DiffServ dengan MPLS, maka paket-paket data tidak hanya dapat diklasifikasikan namun juga dapat dikontrol sedemikian rupa sehingga kekurangan pada teknologi DiffServ dapat ditutupi. Dengan pertimbangan tersebut, teknologi MPLS DiffServ-Aware (MPLS DS-Traffic Engineering) kini mulai banyak diadopsi oleh para network administator, terutama pada jaringan yang menggunakan layanan aplikasi real-time serta pada jaringan backbone ISP. Di dalam laporan skripsi ini akan dievaluasi dan dianalisis beberapa implementasi teknologi MPLS, DiffServ, dan integrasi antara keduanya (MPLS/DiffServ) baik pada jaringan IPv4 maupun IPv6. Unjuk kerja dari aplikasi akan diamati dan dianalisa berdasarkan parameter QoS yang dihasilkan dari simulasi. Penelitian berkaitan dengan Differentiated of Service pada jaringan MPLS sendiri telah banyak dilakukan, namun kebanyakan masih pada protokol jaringan IPv4. Almofary et.al [2] melakukan perbandingan unjuk kerja MPLS/DiffServ pada jaringan IPv4, Czerny et.al [3] menggunakan test bed untuk menganalisan unjuk kerja QoS dari implementasi MPLS DS-TE pada jaringan IPv4. Sementara Aziz et.al [4] membandingkan unjuk kerja DiffServ dengan MPLS/DiffServ untuk aplikasi real-time pada jaringan IPv4 dan IPv6. Dalam penelitian ini dilakukan perbandingan antara teknologi IP Best-Effort, MPLS, DiffServ dan MPLS DS-TE baik pada jaringan berlingkungan IPv4 dan IPv6. Analisis terhadap unjuk kerja aplikasi real-time dan non real-time seperti VoIP, Video Conferencing dan FTP dilakukan pada kedua lingkungan protokol tersebut. 2. Tinjauan Teoritis 2.1. Multi-Protocol Label Switching (MPLS) Multi-Protocol Label Swtiching (MPLS) mampu bekerja pada berbagai protokol jaringan, seperti Internet Protocol (IP), Asynchronous Transport Mode (ATM), dan juga Frame Relay. Selain itu MPLS juga dilengkapi dengan fitur Traffic Engineering (TE) yang mampu memaksimalkan kinerja jaringan. Berbeda dengan proses forwarding paket pada IP, Multi-Protocol Label Switching (MPLS) menggunakan label (20-bit) yang dienkapsulasi pada paket sebagai identifier pada penentuan jalur forwarding paket tersebut. Tiap-tiap paket sebelum diteruskan oleh router akan

4 diberikan label, sehingga tidak diperlukan proses routing look-up pada setiap node yang disinggahi paket-paket tersebut. Artinya proses penerusan paket tidak berdasarkan dari alamat tujuan pada packet header melainkan berdasarkan label, ini menyebabkan proses pengiriman paket lebih cepat dan fleksibel dibandingkan dengan menggunakan teknologi penerusan paket seperti pada IP konvensional. Masalah skalabilitas, kecepatan, QoS, serta rekayasa trafik memotivasi dikembangkannya teknologi Multi- Protocol Label Switching (MPLS). Header pada MPLS (4-bytes) terdiri dari empat bagian (field) di mana bagian yang paling penting adalah label field yang berisi index. Bagian QoS mengindikasikan class of service, bagian S berkaitan dengan penggunaan multiple labels, dan TtL mengindikasikan banyaknya proses forwarding yang harus dilalui paket [6]. Header paket dari MPLS yang sering dideskripsikan sebagai protokol layer 2.5 ditunjukkan pada gambar 2.1. Gambar 2.1. Header Paket MPLS [6] Bagian terpenting dari teknologi MPLS adalah penggunaan label. Pada jaringan MPLS, proses pemberian label pada paket dilakukan saat paket sampai pada ujung atau batas dari jaringan MPLS (edge network). Label Edge Router (LER) adalah router yang berada pada daerah ujung jaringan (Ingress) MPLS, dan proses enkapsulasi MPLS header dilakukan oleh router tersebut. LER memetakan label berdasarkan destination address paket tersebut untuk menentukan jalur atau interface yang akan dilewati paket. Jalur yang dilwati oleh paket-paket MPLS disebut sebagai Label Switch Path (LSP). Sementara pada core router atau Label Switch Router (LSR), dilakukan proses label swapping berdasarkan informasi pada label forwarding table. Pada ujung lainnya dari

5 jaringan MPLS (Egress), terdapat LER yang akan meneruskan paket ke jaringan lainnya seperti yang ditunjukkan gambar 2.2. LER Egress menghapus label atau MPLS header dari paket Quality of Service Pada dasarnya berbagai arsitektur atau implementasi QoS telah dikembangkan, mulai dari mekanisme queuing, scheduling, traffic shaping, signaling, hingga policing dan management [14]. Dalam aplikasinya teknologi dasar yang dipakai antara lain Best- Effort (BE), Integrated Service (IntServ), dan Differentited Service (DiffServ), namun dalam perkembangannya hadir teknologi baru berupa protokol seperti Resource Reservation Protocol (RSVP), dan Multi- Protocol Label Switching (MPLS). Sebelum model DiffServ dikenalkan, terdapat model Integrated Service (IntServ) yang memungkinkan berbagai kebutuhan QoS seperti bandwidth dan delay didedikasikan oleh jaringan kepada aplikasi sebelum proses pengiriman trafik data. Secara umum DiffServ juga memiliki kemampuan yang sama dengan IntServ yang merupakan multiple service model. Namun dibandingkan IntServ, DiffServ mampu menangani QoS dengan skalabilitas jaringan yang lebih besar. Masalah skalabilitas yang dimiliki Integrated Service, dapat diatasi oleh Differentiated Service (DiffServ). Hal ini karena DiffServ merespon terhadap sekumpulan flows (Class of Service) daripada tiap individual flow. Model DiffServ bekerja secara sederhana, di mana paket yang melintasi jaringan diklasifikasikan ke dalam kelas-kelas pada edge router yang kemudian memiliki Behaviour Aggregates (BA) yang berbeda. Tiap-tiap BA didefinisikan oleh sebuah Differentiated Service Code Point (DSCP) [16]. Kemudian paket- paket tersebut akan diteruskan pada domain DiffServ berdasarkan Per-Hop Behavior (PHB) tergantung pada mekanisme scheduling dan manajemen congestion yang diterapkan. Terdapat tiga jenis PHB yang distandarisasikan oleh IETF, Default PHB (Best-Effort) Expedited Forwarding (EF) dan Assured Forwarding (AF). Tiap-tiap PHB tersebut dideskripsikan dari resources yang dimiliki (buffer dan bandwidth) atau dari karakteristik yang secara eksternal dapat diamati, seperti delay, loss, dan jitter. Penerapan teknologi MPLS (Multi-Protocol Label Switching) dan juga DiffServ (Differentiated of Service) sama-sama memberikan kompleksitas fungsional pada bagian

6 ujung jaringan (edge network). Pada MPLS penentuan jalur yang akan dilalui paket serta konfigurasi Forwarding Equivalance Class (FEC) dilakukan pada edge router. Sementara pada DiffServ, proses pengklasifikasian serta traffic policy juga dilakukan oleh edge router. Karakteristik dari kedua teknologi tersebut membuat MPLS maupun DiffServ mendukung skalabilitas jaringan dan cocok untuk diimplementasikan pada jaringan backbone. Label pada DiffServ dan juga DSCP dibawa dalam bagian Type of Service dalam IP header. Sementara itu, MPLS label dapat dibawa oleh MPLS shim header atau dienkapsulasi di dalam layer 2 header. Dan oleh karena MPLS LSR tidak memeriksa IP header dalam proses penerusan paket, maka diperlukan suatu mekanisme untuk menetukan PHB dari MPLS label. Dengan mengintegrasikan fungsi MPLS dan DiffServ dalam suatu domain jaringan, ingress router bertanggung jawab dalam membangun LSP (Label Switch Path) untuk suatu aliran data dan juga memberikan garansi QoS pada aliran data tersebut. EXP field pada MPLS shim header digunakan untuk mendefinisikan kelas DiffServ dari paket yang melalui ingress router (inbound). Gambar 2.2 menunjukkan proses penerusan paket IP pada jaringan MPLS. Gambar 2.2 Penerusan paket IP pada jaringan MPLS [6] 3. Metode Peneitian

7 Metode penelitian yang dilakukan pada skripsi ini adalah dengan melakukan studi literatur dan simulasi jaringan. Studi literatur dilakukan untuk mendapatkan referensi terkait penelitian yang akan dilakukan, dan menggunakan referensi tersebut sebagai sumber informasi dalam menyelesaikan permasalahan yang terdapat pada skripsi ini. Selanjutnya sistem yang dirancang akan diuji menggunakan perangkat lunak simulator jaringan OPNET Modeler 14.5 untuk dianalisa. Sistem jaringan yang akan dibangun pada perangkat simulator OPNET menggunakan komponen seperti router, switch, workstation, dan server. Sementara untuk media komunikasi atau link yang digunakan adalah ppp_adv (2.3 Mbps) pada komunikasi serial dan untuk komunikasi ethernet menggunakan 100BaseT (100 Mbps). Logical link atau tunneling juga dibangun pada pengujian sistem jaringan yang menggunakan teknologi MPLS, komponen MPLS_E-LSP_Static digunakan untuk mendukung fitur tersebut. Untuk router yang digunakan berupa ethernet2_slip8_ler untuk edge router dan ethernet2_slip8_lsr untuk switched router. Router tersebut mampu mendukung implementasi teknologi MPLS dan DiffServ pada sistem jaringan berbasis IP. Sementara untuk client dan server digunakan komponen ethernet_wkstn_adv dan server_wkstn_adv. Komponen yang digunakan sebagai switch berupa ethernet16_switch yang memiliki 16 ethernet interface pada perangkatnya. Komponen Application_Config dan Profile_Config digunakan untuk mendefinisikan layanan aplikasi yang digunakan dan yang berjalan pada sistem jaringan yang diuji. Layanan aplikasi yang digunakan kemudian dispesifikasikan pada workstation ataupun server. Untuk implementasi fitur Quality of Service seperti scheduling, traffic policy, dan traffic shaping digunakan komponen QoS_Config. Konfigurasi QoS dapat dilakukan secara global melalui komponen tersebut maupun secara local pada router individual. Sementara untuk komponen MPLS_Config digunakan pada model sistem jaringan Multi- Protocol Label Switching (MPLS). Gambar 3.1 menunjukkan model jaringan yang akan diuji pada jaringan IPv6 (OSPFv3). Topologi jaringan uji untuk seluruh skenario sama seperti pada gambar, dengan implementasi teknologi yang berbeda.

8 Gambar 3.1. Topologi jaringan yang diuji pada proses simulasi Terdapat 8 skenario yang akan disimulasikan untuk melihat pengaruh implementasi teknologi DiffServ dan MPLS terhadap unjuk kerja jaringan, baik untuk protokol jaringan IPv4 maupun IPv6. Tiap skenario memiliki konfigurasi aplikasi dan juga arsitektur jaringan (network resources) yang serupa. Untuk penentuan jalur atau rute lalu lintas data, OSPF sebagai routing protocol yang paling populer akan dipilih. Sistem jaringan uji akan dirancang dengan tiga kondisi beban data (traffic load) yang berbeda. Dengan memberikan kondisi low-load (40%), high-load (100%), dan over-load (200%) akan dianalisa pengaruh dari teknologi yang diimplementasikan berdasarkan parameter tertentu. Kondisi low-load dimulai pada waktu simulasi berjalan detik, kondisi high-load ketika simulasi berjalan detik, dan untuk 720 detik sampai waktu simulasi selesai (1000 detik) sistem uji berada dalam kondisi over-load. Pengujian unjuk kerja dari mekanisme QoS yang telah diimplementasikan dilakukan dengan menjalankan proses simulasi selama 1000 sekon, di mana parameterparameter QoS (global dan local parameter) dari aplikasi VoIP, Video Conferencing, dan File Transfer Protocol (FTP) akan diperoleh untuk kemudian dianalisa. Selain itu parameter QoS pada beberapa node (Object Parameter) juga akan turut dianlisa sehingga menghasilkan hasil perbandingan yang mendalam. Parameter yang akan diuji dan dianalisa adalah throughput, packet loss, End-to-End delay, queuing delay dannjitter. Selanjutnya sistem jaringan akan diberikan beban data yang bervariasi selama proses simulasi. Pada 120 s, aplikasi dijalankan sehingga menghasilkan kondisi low-load

9 (40%) pada jaringan. Pada waktu simulasi 360 s beban data ditingkatkan menjadi 100% (high-load). Sementara kondisi over-load (200%) akan dimulai pada waktu simulasi 720 s. Untuk parameter QoS yang akan diamati, unjuk kerja dari jaringan akan dilihat dari sisi global parameter dan juga object parameter, sehingga pengaruh implementasi teknologi QoS untuk setiap skenario dapat dilihat pengaruhnya baik untuk seluruh domain jaringan maupun untuk sebuah node. 4. Hasil Penelitian dan Pembahasan Ada 8 skenario yang dijalankan untuk menganalisa unjuk kerja tiap-tiap skenario, dengan parameter-parameter yang akan dianalisa berupa throughput, packet loss, delay, jitter, queuing delay, dan traffic dropped Throughput Link rate yang digunakan pada komunikasi WAN (Point-to-Point) sebesar 2.3 Mbps. Link tersebut tidak mengindikasikan data rate dari aliran paket, melainkan untuk menentukan jalur atau path yang dilalui oleh paket (metric cost) menggunakan protokol routing OSPF. Sehingga paket data akan diteruskan melalui jalur LER Ingress LER Egress (LER Ingress-LSR3-LSR7-LER Egress), sementara kedua jalur lainnya tidak digunakan sampai teknologi Multi-Procol Label Switching (MPLS) diimplementasikan. Pada skenario menggunakan teknologi MPLS, maka paket data akan turut diteruskan melalui jalur lain yang tersedia. Pada skenario 1 (IPv4) dan 2 (IPv6) sistem tidak diberikan garansi QoS (Best- Effort), skenario 3 (IPv4) dan 4 (IPv6) sistem diimplementasikan teknik QoS DiffServ, skenario 5 (IPv4) dan 6 (IPv6) sistem dijalankan pada domain jaringan MPLS, sementara pada skenario 7 (IPv4) dan 8 (IPv6) sistem berada pada domain jaringan Multi-Protocol Label Swtiching (MPLS) yang mendukung DiffServ Traffic Engineering. Grafik yang diperoleh dari hasil simulasi untuk skenario 7 dan 8 selama 1000 detik pada gambar 4.1 menunjukkan bahwa throughput data yang diperoleh untuk jaringan IPv4 dan IPv6 sedikit berbeda pada setiap LSP, dimana throughput pada IPv6 lebih besar akibat overhead yang diberikan pada paket data. Congestion baru terjadi ketika sistem diberi beban berlebih (720 s). Terlihat jelas bahwa LSP 0_1dan LSP 2_1 mengalami

10 peningkatan throughput mencapai maksimum data rate 2.3 Mbps. Data throughput untuk seluruh skenario yang dijalankan diberikan pada tabel 4.1. Tabel 4.1. Throughput hasil simulasi (bit/sec) Scenario Throughput (bps) LER (Ingress) - LSR 1 LER (Ingress) - LSR 3 LER (Ingress) - LSR 4 1 Average 60,359 1,658, Std Dev 316, , Average 28,998 1,688, Std Dev 234, , Average 70 1,687, Std Dev , Average 57,617 1,668, Std Dev 311, , Average 1,133, ,689 1,123,134 Std Dev 808, , ,330 6 Average 1,152, ,420 1,143,913 Std Dev 804, , ,678 7 Average 1,109, ,690 1,108,005 Std Dev 799, , ,825 8 Average 1,128, ,425 1,127,740 Std Dev 809, , ,504 Dari hasil analisis data yang didapat pada hasil simulasi, diperoleh nilai throughput yang lebih tinggi pada jaringan IPv6 untuk setiap teknologi yang bersesuaian. Untuk teknologi no-qos (Best-Effort), didapatkan nilai throughput pada sistem jaringan IPv6 ( bps) lebih besar 0.7% dibandingkan pada jaringan IPv4 ( bps). Untuk skenario 3 (IPv4) dan 4 (IPv6) yang menggunakan teknologi DiffServ didapatkan perbedaan throughput sebesar 3.5% dengan rata rata throughput selama simulasi (1000 s) pada skenario 3 sebesar bps dan rata rata throughput pada skenario 4

11 sebesar bps. Pada skenario 5 dan 6 yang menggunakan teknologi MPLS tanpa DiffServ, untuk jalur LSP 0_1 didapatkan unjuk kerja throughput pada jaringan IPv6 (skenario 6) lebih besar sebesar 3.7%, pada LSP 2_1 sebesar 3%, dan pada jalur LSP 1_1 mencapai 15%. Pada skenario 7 dan 8 untuk jalur yang dilewati oleh VoIP tidak berbeda jauh dengan skenario 5 dan 6, begitu juga dengan jalur LSP 0_1 dan LSP 2_1 yang memiliki nilai throughput lebih besar sekitar 2% - 3% untuk sistem jaringan berbasis IPv Packet Loss Packet loss merupakan parameter QoS yang sifatnya sensitif pada aplikasi realtime (voice, video). Untuk mendapatkan persentase packet loss pada sebuah komununikasi end-to-end, dilakukan pengambillan data traffic sent dan traffic received pada sisi client dan server. Perhitungan packet loss secara matematis diperoleh dari perbandingan antara jumlah paket yang hilang dengan jumlah paket yang dikirimkan oleh source node. Dalam penelitian, analisis unjuk kerja aplikasi terhadap nilai packet loss yang terjadi akan difokuskan pada aplikasi VoiP. Nilai yang didapat pada hasil simulasi ditunjukkan pada tabel 4.2. Tabel 4.2. Packet loss aplikasi voice (VoIP) Scenario Traffic Sent (Bytes) Traffic Received (Bytes) Packet Loss (%) ,4 1,5 0,03 0,07 0,03 0,0 Packet loss terajadi pada seluruh traffic flows pada skenario 1 (BE_IPv4) dan skenario 2 (BE_IPv6), yang disebabkan karena teknik scheduling yang digunakan adalah First-In First-Out (FIFO). Pada skenario 3 (DiffServ IPv4) dan skenario 4 (DiffServ) aplikasi VoIP diberikan prioritas utama dengan bandwidth size sebesar 20% dengan teknik scheduling CBWFQ. VoIP merupakan jenis layanan yang sangat sensitif terhadap packet loss, sehingga untuk jaringan yang terdapat congestion (over-load) fitur DiffServ sangat membantu. Pada skenario 3 dan 4 besar packet loss turun drastis menjadi sebesar 0.5% dibandingkan pada skenario Best-Effort yang mencapai 25%. Sementara untuk

12 integrasi teknologi DiffServ dengan MPLS pada skenario 7 dan 8 diberikan kontrol terhadap lalu lintas data yang melalui setiap LSP. Dari hasil konfigurasi traffic policy pada outbound interface, didapatkan nilai packet loss untuk aplikasi video conferencing lebih besar dibandingkan scenario 5 dan 6 (MPLS) namun lebih kecil dibandingkan skenario 3 dan 4 (DiffServ). Pada skenario MPLS/DiffServ trafik data dari aplikasi FTP diberikan prioritas terendah, hal tersebut tampak dari nilai packet loss pada FTP paling besar pada skenario 7 dan 8 mencapai 62.5% End to End Delay Pada OPNET modeler 14.5 statistik dari parameter QoS End-to-End delay (latency) merepresentasikan nilai dari beberapa delay yang terjadi pada sistem (network delay + encoding delay + decoding_delay + compression delay + decompression delay). Statistik yang diperoleh berdasarkan one-way delay, sehingga pengambilan data akan dilakukan pada node source/server (Voice_Src, VC_Src1, VC_Src2, VC_Src3). Voice atau VoIP merupakan aplikasi/layanan yang sangat sensitif terhadap delay (latency). Sistem jaringan yang menggunakan paket data VoIP sebagai layanan aplikasinya harus mampu memberikan garansi QoS yang mendukung low-latency. Sesuai standarisasi ITU-T, network delay (End-to-End Delay) untuk komunikasi voice data yang baik adalah sebesar ms. Gambar 4.1 menunjukkan unjuk kerja one-way delay pada pengiriman paket data VoIP (G.711) pada sistem jaringan IPv4. Pada skenario Best-Effort dan DiffServ, trafik data akan diteruskan melalui jalur LER Ingress LSR 3 (LSP 1_1) bersamaan dengan paket data dari aplikasi lainnya. Sementara pada skenario MPLS dan MPLS/DiffServ trafik data voice akan diberikan dedicated path (LSP 1_1), sementara paket data dari aplikasi video dan FTP akan melewati jalur lain (LSP 0_1 dan LSP 2_1) yang telah dipetakan dalam konfigurasi. Dengan memberikan jalur khusus bagi trafik data voice, maka seluruh bandwidth yang tersedia pada link diberikan untuk komunikasi VoIP. Dengan melakukan traffic binding, maka kondisi congestion dapat dihindari. Hal ini terlihat dari nilai delay yang terlihat pada grafik 4.1 yang konsisten, sebesar 87 ms pada skenario 5 (MPLS) dan skenario 7 (MPLS/DiffServ). Untuk grafik delay aplikasi VoIP pada jaringan IPv6 diberikan pada grafik 4.2. Pada grafik 4.1 dan 4.2 terlihat bahwa delay yang didapatkan pada implementasi sistem jaringan Best-Effort adalah yang paling besar, yaitu mencapai 3 s. Tingginya delay pada skenario 1 (BE IPv4) dan skenario 2 (BE IPv6) diakibatkan karena tidak adanya prioritas antrian yang diberikan untuk paket

13 data voice (DiffServ), dan juga tidak adanya dedicated path yang bebas congestion seperti pada implementasi teknologi MPLS. Namun jika diperhatikan pada grafik dari implementasi teknologi DiffServ, terlihat pada saat kondisi high-load atau congestion (100%) nilai delay naik mencapai 500 ms (IPv4), bahkan nilai delay naik drastis mencapai 2.4 s pada IPv6. Kemudian turun menjadi 1.9 ketika kondisi over-load (200%). Gambar 4.1. Grafik E2E delay dari aplikasi VoIP pada sistem jaringan IPv4

14 Gambar 4.2. Grafik E2E delay dari aplikasi VoIP pada sistem jaringan IPv Queuing Delay Nilai atau besarnya queuing delay yang didapatkan pada hasil simulasi menunjukkan waktu yang dibutuhkan oleh sebuah paket untuk mentransmisikan bit pertama dari paket tersebut hingga bit terakhir melalui link atau kanal komunikasi. Nilai hasil pengamatan akan ditampilkan berdasarkan teknologi yang digunakan pada proses penjaluran (routing) paket. Skenario 1,2,3, dan 4 menggunakan algoritma shortest path first (OSPF) untuk meneruskan paket pada media transmisi. Jalur yang dipilih adalah jalur yang memiliki cost paling kecil yaitu LER Ingress LSR 3, sementara dua jalur lainnya tidak digunakan. Pada hasil simulasi didapatkan bahwa queuing delay pada jaringan IPv6 (skenario 2 dan 4) lebih besar dibandingkan pada jaringan IPv4 (skenario 1 dan 3). Pada skenario 5 (IPv4) dan 6 (IPv6) digunakan teknologi MPLS pada proses penerusan paket. Dengan menggunakan label dalam proses forwarding, utilisasi network resources menjadi lebih maksimal. Paket akan dikirimkan melalaui jalur LSP 0_1 LSP 1_1, dan LSP 2_1 baik pada skenario 5 maupun skenario 6. Dengan jumah user atau aplikasi yang lebih sedikit

15 untuk setiap link komunikasi, nilai queuing delay yang didapat juga menjadi lebih kecil. Sementara pada skenario 7 (IPv4) dan skenario 8 (IPv6) selain menggunakan teknik MPLS untuk menentukan proses forwarding paket. Pada skenario 7 dan 8 juga digunakan teknologi DiffServ untuk memberikan prioritas paket saat terjadi antrian (queuing). Pada tabel 4.3 diberikan nilai rata-rata queuing delay selama proses simulasi (1000 s) untuk seluruh skenario. Tabel 4.3. Queuing delay yang dialami paket outbound Scenario Queuing Delay LER (Ingress) - LSR 1 (sec) LER (Ingress) - LSR 3 (sec) LER (Ingress) - LSR 4 (sec) 1 Average 0,119 0,243 0,0002 Std Dev 0,542 0,3087 3,42E-05 2 Average 0,048 1,571 0,0003 Std Dev 0,328 1,221 3,01E-05 3 Average 0,0002 0,409 0,0002 Std Dev 2,60E-05 0,709 2,61E-05 4 Average 0,087 0,992 0,0003 Std Dev 0,429 0,951 3,07E-05 5 Average 0,426 0,0064 0,303 Std Dev 0,742 0,0001 0,569 6 Average 0,726 0,0007 0,643 Std Dev 1,166 2,00E-04 1,056 7 Average 0,004 0,0004 0,003 Std Dev 0,001 6,00E-05 0,001 8 Average 0,209 0,0005 0,259 Std Dev 0,4 7,00E-05 0,496 Pada tabel terlihat bahwa tidak hanya nilai queuing delay pada IPv6 saja yang lebih besar dari IPv4, namun juga jika dibandingkan pada tabel 4.13 terlihat bahwa skenario dengan menggunakan DiffServ memiliki nilai delay yang lebih kecil. Ini dikarenakan

16 pada skenario 7 dan 8 teknik scheduling CBWFQ digunakan dengan kondisi user atau aplikasi yang lebih sedikit jika dibandingkan pada scenario 3 dan Packet Delay Variation (Jitter) VoIP Packet delay variation atau jitter merupakan komponen yang sangat krusial atau senstif bagi aplikasi voice (VoIP). Untuk aplikasi VoIP, nilai jitter lebih diperhatikan dibandingkan delay dari paket itu sendiri. Pada analisa unjuk kerja variasi delay atau jitter yang dialami oleh aplikasi VoIP ini difokuskan saat kondisi jaringan berada pada keadaan high-load (100%) dan over-load (200%). Gambar 4.16 menujukkan bahwa variasi delay yang sangat besar dan juga tidak konsisten terjadi pada skenario 1 (Best- Effort). Pada skenario 1 paket data menggunakan mekanisme queuing FIFO, sehingga delay yang diperoleh tidak menentu yang mengakibatkan variasi delay atau jitter juga besar. Dari grafik terlihat bahwa jitter pada aplikasi VoIP untuk skenario 1 mencapai 1.3 s. Sementara pada skenario 3 (DiffServ) nilai jitter menurun hingga 0.3 s pada kondisi over-load (200%). Nilai jitter paling rendah terdapat pada hasil simulasi untuk skenario 5 dan 7. Hal ini dikarenakan pada skenario 5 dan 7 digunakan teknologi MPLS yang dapat mengontrol lalu lintas data. Dengan menggunakan teknologi MPLS, maka aplikasi yang sensitif terhadap jitter dapat diberikan perlakuan khusus dengan memberikan dedicated path untuk komunikasinya. Jitter sendiri dapat terjadi karena adanya congestion atau queuing delay pada sistem jaringan. Nilai jitter yang rendah pada skenario 5 dan 7 disebabkan karena trafik data dari aplikasi lain tidak melewati outbound interface yang sama dengan aplikasi VoIP. Nilai jitter yang didapat selama proses simulasi dan yang diberikan pada tabel 4.4 merupakan nilai minimum dan maksimum untuk seluruh kondisi beban.

17 Tabel 4.4. Packet delay variation dari aplikasi VoiP Scenario PDV (s) Low- Load (40 %) High- Load (95%) Over- Load (200%) 1 Minimum 8,00E- 05 8,04E- 05 0,036 Maximum 8,88E- 05 0,04 1,512 2 Minimum 5,16E- 05 5,16E- 05 0,008 Maximum 6,49E- 05 1,28 1,392 3 Minimum 3,05E- 05 3,07E- 05 1,2 Maximum 3,08E- 05 3,5 0,416 4 Minimum 2,45E- 05 2,45E- 05 0,005 Maximum 2,64E- 10 0,98 0,998 5 Minimum 4,04E- 13 4,04E- 13 2,08E- 10 Maximum 1,95E- 10 2,16E- 10 5,60E Minimum 6,18E- 08 1,59E- 10 1,69E- 10 Maximum 1,57E- 06 6,46E- 08 6,58E Minimum 2,41E- 13 2,41E- 13 1,94E- 10 Maximum 1,84E- 10 2,03E- 10 5,82E Minimum 6,19E- 08 1,38E- 10 1,60E- 10 Maximum 1,57E- 06 6,46E- 08 4,11E Traffic Dropped Analisis yang dilakukan terkait jumlah paket yang dijatuhkan (dropped) pada sistem jaringan difokuskan pada implementasi mekanisme congestion avoidance pada sistem simulasi. Analisa akan dilakukan terkait data traffic dropped yang dihasilkan selama proses simulasi (1000 s) pada skenario 3 dan 4 (DiffServ) dan skenario 7 dan 8 (MPLS/DiffServ). Statistik dari paket-paket yang dijatuhkan didapatkan pada outbound interface dari router LER Ingress (IF0, IF1, IF2).

18 Pada skenario 3 (IPv4) dan 4 (IPv6) diimplementasikan teknologi QoS Differentiated Service. Paket-paket data akan dijatuhkan ketika terjadi congestion dengan mekanisme WFQ dan WRED. Ketika beban data melebihi kapasitas kanal yang digunakan (high-load), maka paket-paket pada antrian akan dijatuhkan sesuai traffic policy yang diimplementasikan. Gambar 4.3 menunjukkan nilai traffic dropped yang dialami saat arsitektur QoS DiffServ diimplementasikan. Gambar 4.3. Traffic dropped pada implementasi DiffServ Dari gambar 4.3 ditunjukkan bahwa paket-paket pada domain jaringan IPv6 lebih banyak dijatuhkan dibandingkan pada saat diimplementasikan pada domain jaringan IPv4. Pada saat waktu simulasi 360 sekon, pada jaringan IPv4 paket akan dijatuhkan setiap kali FTP_Client mengunggah berkas ke server (congestion). Sementara pada jaringan IPv6 paket mengalami congestion bahkan ketikan aplikasi FTP tidak mengirimkan data. Besarnya nilai traffic dropped pada jaringan IPv6 menunjukkan bahwa paket-paket data IPv6 lebih besar dibandingkan IPv4. Sementara pada skenario dengan implementasi teknologi routing and switching MPLS (Skenario 7 dan 8), aliran trafik dikontrol dengan melakukan pemetaan transmisi paket pada jalur-jalur yang tersedia. Sehingga pada skenario 7 (IPv4) dan 8 (IPv6) statistik dari traffic dropped akan didapatkan pada interface IF1 (LSP 0_1) dan interface

19 IF2 (LSP 2_1) dimana pada jalur tersebut congestion akan terjadi, seperti ditunjukkan pada gambar 4.4 Gambar 4.4. Traffic dropped pada implementasi MPLS/DiffServ Pada gambar 4.4 terlihat bahwa paket-paket akan dijatuhkan pada saat diimplementasikan pada jaringan IPv6. Hal ini dikarenakan pada jaringan IPv4, jalur LSP 0_1 maupun LSP 2_1 tidak mengalami congestion selama proses simulasi (1000 s), sementara pada jaringan IPv6, congestion akan terjadi saat diberi beban over-load (720 s). Ini menyimpulkan bahwa saat terjadi congestion, maka paket-paket IP yang akan dijatuhkan lebih banyak pada saat diimplementasi jaringan IPv6 dibandingkan jaringan IPv4. Selain itu, ukuran paket IPv6 yang lebih besar menyebabkan ketika kondisi beban data tinggi atau mendekati kapasitas maksimum kanal, pada sistem jaringan IPv6 terjadi congestion sementara pada jaringan IPv6 tidak terjadi congestion. 5. Kesimpulan

20 Dari hasil pengujian pada perangkat simulasi dan analisis yang telah dilakukan, maka dapat diperoleh bebarapa kesimpulan serta saran sebagai berikut. 1. Integrasi antara teknologi QoS Differentiated of Service (DiffServ) dengan teknologi routing and switching Multi-Protocol Label Switching (MPLS) menghasilkan unjuk kerja jaringan yang lebih baik. Teknologi DiffServ/MPLS memberikan kecepatan, skalabilitas, serta efisiensi sumber daya jaringan. 2. Throughput untuk sistem jaringan berbasis IPv6 lebih besar dibandingkan dengan sistem berbasis IPv4. Dari hasil simulasi diperoleh nilai throughput pada IPv6 lebih besar mencapai 2% - 5% dari throughput pada sistem jaringan IPv4. Salah satu faktor yang menyebabkan nilai throughput IPv6 lebih besar dari IPv4 adalah overhead yang ditimbulkan dari engkapsulasi paket. 3. Dari hasil simulasi didapatkan bahwa pada jaringan IPv6 nilai queuing delay pada jalur transmisi lebih besar dibandingkan dengan jaringan IPv4. Pada skenario 3 ( s) dan 4 ( s) perbandingan mencapai 100%. Secara umum unjuk kerja dari parameter-parameter yang dianalisa menunjukkan bahwa teknologi berbasis IPv4 masih lebih baik dibandingkan saat digunakan pada domain jaringan IPv6. 4. Teknologi DiffServ melakukan kontrol trafik data dengan mendefinisikan PHB suatu aliran data sesuai dengan nilai DSCP yang diberikan. Expedited Forwarding (EF PHB) dan Assured Forwarding (AF PHB) merupakan tipe layanan yang sesuai untuk aplikasi real- time. 5. Perbedaan antara nilai yang didapat pada sistem jaringan IPv4 dan IPv6 sangat besar (queuing delay, packet loss) disebabkan karena Constant Bit Rate (CBR) dari application layer dikonfigurasi mendekati 100% dari channel capacity. Pada sistem yang diujii, paket IPv6 mengalami congestion sementara pada paket IPv4, congestion tidak atau belum terjadi.

21 Daftar Referensi [1] Chapter 46, Quality of Service Networking, Internetworking Technology Overview, June, [2] Almofary, N.H., Moustafa, H.S., Zaki, F.W., Optimizing QoS for Voice and Video Using DiffServ-MPLS, International Journal of Modern Computer Science & Engineering, [3] Czerny, Dillon., MPLS Traffic Engineering DiffServ Aware, College of Technology Masters Theses, Purdue University, 2011 [4] Aziz, Tariq., Saiful, Muhammad., Performance Evaluation of Real-Time Applications over DiffServ/MPLS in IPv4/IPv6 Networks, Blekinge Institute of Techonlogy, Master Thesis, May, [5] Stallings,William. Data and Computer Communications (8th ed), Pearson Education.Inc, [6] Tanenbaum, Andrew S., Wetherall, David. ed, Prentice Hall, [7] Marsic, Ivan. Computer Networks : Performance and Quality of Service, December 2010, Rutgers University. [8] Bonaventure, Olivier. Computer Networking : Principles, Protocols, and Practice, October [9] Aziz, Tariq. Throughput Performance Evaluation of Video/Voice Traffic in IPv4/IPv6 Networks, International Journal of Computer Applications, December, [10] Chapter 13, OSPFv3 Routing : Introduction to OSPFv3 Routing. [11] Solekan, ST, Sistem Telekomunikasi, Politeknik Telkom Bandung, [12] Adhikari, Deepak., Kharel, Jeevan., Performance Evaluation of Voice Traffic over MPLS Network with TE and QoS Implementation, Blekinge Institute of Technology, Master Thesis, May, [13] Sethi, Ardashpal., Hnatyshin, Vasil., The Practical OPNET User Guide for Computer Network Simulation, CRC Press, August, [14] Abidin, Zainol., Fisal, N., IP QoS Enhancement using DiffServ in IPv6 Network, University Teknologi Malaysia, [15] Network Working Group, RFC 2474 : Definition of the Differentiated Service Field in the IPv4 and IPv6 Headers, The Internet Society, December, [16] Al-Zobbi, Mohammed., Comparison Between IPv4 and IPv6 in Adopting Differentiated Services, International Journal of Scientific & Technology Reasearch, Volume 3, Issue 2, February, [17] Ghoreishil, Vahid., Mohammadi, Syahram., Comparing the Performance of Real-Time Applications based on IPv4 and IPv6 Networks, International Journal of Computer Techniques, Volume 1, Issue 2, December, 2014.