1
Analisis Pengiriman Frame Video Terenkripsi secara Unicast, Broadcast, dan Multicast Andarini Kartika D., Ary Mazharuddin S., Baskoro Adi Pratomo Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS) Jl. Arief Rahman Hakim, Surabaya 60111 E-mail:
[email protected],
[email protected],
[email protected]
Abstrak—Sebuah aplikasi video streaming yang menerapkan algoritma enkripsi Rivest Cipher 5 (RC5) telah selesai dibuat. Pustaka yang digunakan adalah Java Media Framework untuk memproses video dan Bouncy Castle sebagai alat kriptografi pada IDE Java Netbeans. Aplikasi ini dimanfaatkan untuk mengetahui performa video streaming apabila diujicobakan pada sebuah jaringan komputer untuk pengiriman data secara unicast, broadcast, dan multicast. Performa yang dimaksud adalah dalam hal kualitas layanan (Quality of Service) pada jaringan yang meliputi delay, jitter, throughput, serta packet loss. Hasil uji coba menunjukkan bahwa ukuran file mempengaruhi delay dan throughput, namun tidak mempengaruhi performa umum dari unicast, broadcast, dan broadcast. Unicast lebih unggul daripada broadcast dan multicast jika jumlah klien hanya dua. Namun jika jumlah klien mencapai 5 buah, maka unicast lebih buruk daripada broadcast dan multicast dalam hal delay, jitter, dan throughput. Di antara broadcast dan multicast, broadcast lebih unggul daripada multicast baik untuk dua klien maupun lima klien. Kata Kunci— streaming, enkripsi, unicast, broadcast, multicast
I. PENDAHULUAN
S
TREAMING merupakan suatu teknologi yang bisa digunakan untuk memainkan data audio atau video secara langsung maupun tidak langsung yang didapat dari sebuah mesin server [1]. Pemanfaatan video streaming dapat berupa video conference, yaitu telekomunikasi dengan menggunakan audio dan video sehingga terjadi pertemuan di tempat letaknya sangat berjauhan. Bagi perusahaan, teknologi ini dinilai sangat efisien karena menghemat biaya perjalanan untuk keperluan rapat atau pertemuan, biaya penginapan, konsumsi, dan lainlain. Sedangkan untuk dosen dan pengajar, video streaming dapat diterapkan dalam bentuk e-learning berbasis video sehingga pengajar bisa memberikan materi belajar tanpa harus berada satu ruangan dengan para mahasiswa atau siswa. Untuk menjaga keamanan pada data video yang dikirimkan melalui jaringan, maka dibutuhkan saluran yang aman dalam melakukan video conference. Salah satu cara yang dapat dilakukan adalah melakukan enkripsi pada data video. Pengiriman data video itu sendiri dapat dilakukan dengan metode unicast, broadcast, dan multicast. Ketiga cara tersebut memiliki kelebihan dan kekurangan masing-masing. Dalam unicast hanya ada satu pengirim dan satu penerima. Metode broadcast dapat mengirimkan paket kepada seluruh komputer
di jaringan lokal namun router akan kebanjiran data. Multicast terlihat lebih efektif karena hanya mengirimkan paket kepada komputer yang tergabung pada satu grup multicast. Berdasarkan permasalahan dan ide di atas, maka dibuatlah sebuah aplikasi video streaming yang menerapkan enkripsi untuk menjaga kerahasiaan data. Algoritma enkripsi yang digunakan adalah Rivest Cipher 5 (RC5). Data video akan dikirimkan dari server menuju klien dengan tiga metode yang berbeda, yaitu unicast, broadcast, dan multicast. II. DASAR TEORI Pada bagian ini akan dijelaskan beberapa hal mengenai teori yang berkaitan dengan perangkat lunak yang diimplementasikan. Hal ini ditujukan untuk memberikan gambaran secara umum terhadap sistem yang akan dibuat. A. Video Streaming Video streaming merupakan proses mengalirkan data video dari suatu pengirim kepada satu atau beberapa penerima [3]. Konsep dasa’r dari video streaming adalah membagi paket video menjadi beberapa bagian, mentransmisikan paket-paket tersebut, lalu pihak penerima melakukan decoding pada potongan video tersebut dan dapat memainkannya tanpa harus menunggu seluruh file terkirim ke mesin penerima. Sistem streaming umumnya tersusun dari kombinasi antara server, perangkat lunak untuk memainkan video, transmisi, serta metode encoding/decoding yang digunakan. Ilustrasi untuk sistem streaming ini dapat digambarkan pada Gambar 1.
2
1 user mengunjungi suatu situs dan menemukan file yang ingin dia mainkan
server streaming mengirimkan file ke komputer user, dengan melewati server web
4 Gambar 1. Sistem Streaming
perangkat lunak klien membaca sandi dan memainkan file
3
server web mengirimkan pesan berupa file spesifik pada server media untuk melakukan strreaming
2 B. RC5 Algoritma RC5 merupakan metode enkripsi yang menggunakan metode enkripsi simetrik dan pengolahan data dalam bentuk block cipher. Operasi-operasi yang digunakan pada algoritma RC-5 merupakan operasi-operasi yang sederhana, antara lain modular addition, XOR, dan cyclic rotation. Parameter-parameter yang diperlukan untuk membangun enkripsi RC5 adalah jumlah putaran (round), jumlah word (w), serta kata kunci. Terdapat tiga proses utama pada algoritma RC5. Yang pertama adalah perluasan kunci, yang kedua adalah proses enkripsi, dan yang terakhir adalah proses dekripsi. Proses perluasan kunci berfungsi untuk memperluas sebuah string yang diberikan oleh pengguna agar mengisi array kunci rahasia. C. Unicast, Broadcast, dan Multicast Pengiriman data pada jaringan komputer berdasarkan tujuan dari paket data terbagi menjadi tiga jenis, yakni unicast, broadcast, multicast. Transmisi unicast merupakan transmisi pesan yang dilakukan dari satu pengirim ke satu host penerima. Istilah broadcast merujuk pada proses dalam jaringan komputer dimana pengiriman datanya bersifat satu arah. Metode multicast adalah sebuah teknik dimana data dikirimkan melalui jaringan kepada komputer-komputer yang tergabung pada grup multicast tertentu. Sebuah grup multicast memiliki sebuah alamat multicast. Alamat multicast pada IPv4 adalah alamat kelas D, sedangkan pada IPv6 alamat multicast sudah otomatis didapatkan dari IPv6. Pada kelas D IPv4, alamat yang direservasikan untuk sebuah grup multicast adalah 224.0.0.0 hingga 239.255.255.255.
Pada aplikasi ini, data video yang akan dikirimkan dari server menuju klien tidak dapat langsung dikirimkan secara mentah, namun harus melalui proses pembuatan sandi (encoding) dan dienkripsi dahulu. Sebaliknya, pada sisi klien, karena data video yang datang merupakan data video terenkripsi dan tersandi, maka klien harus melakukan dekripsi dan pembacaan sandi (decoding) pada data video untuk mendapatkan data video asli yang bisa ditampilkan. Tujuan dari encoding ini adalah untuk mendapatkan format data yang cocok untuk dikirimkan melalui jaringan komputer. Setelah melalui proses encoding, data video kemudian dienkripsi dengan algoritma enkripsi RC5. Ciphertext hasil enkripsi ini kemudian dikirimkan kepada klien yang berkepentingan untuk menerima data video tersebut. Data video yang dikirimkan berupa paket-paket datagram. Proses selanjutnya berjalan pada sisi klien. Paket datagram berisi data video terenkripsi yang datang diterima oleh klien lalu didekripsi. Hasil dekripsi ini adalah data video yang kemudian dibaca sandinya untuk mengkonstruksi sebuah video yang dapat ditampilkan ke layar monitor dengan bantuan sebuah alat pemutar video. Proses Mengirim dan Menerima Video Proses ini diilustrasikan pada Gambar 3(a). Data video ditampung terlebih dahulu pada sebuah DataSource yang kemudian dibuatkan Processor. Processor merupakan interface yang memiliki fungsi untuk memproses dan mengatur data media yang bebasis waktu. Berbeda dengan Player yang melakukan rendering pada data media, Processor mendukung interface yang bisa diprogram dan memungkinkan kontrol pada saat memproses media, serta memungkinkan akses untuk menghasilkan stream data. Pembuatan Processor ini dilakukan oleh kelas Manager yang dimiliki oleh Java Media Framework. Setelah itu dibuat sebuah transmitter yang digunakan untuk mengirimkan data video.
D. Kualitas Layanan Kualitas layanan atau kinerja layanan atau yang lebih dikenal dengan istilah quality of service (QoS) merupakan suatu pengukuran mengenai seberapa baik kinerja dari jaringan. [2]. Parameter yang dapat diukur dalam performa jaringan antara lain delay, jitter, throughput, serta packet loss. III. PERANCANGAN DAN IMPLEMENTASI PERANGKAT LUNAK A. Alur Kerja Sistem Gambar 2 merupakan skema alur kerja sistem secara lengkap dengan melibatkan proses utama yang dilakukan oleh aplikasi ini.
(a) (b) Gambar 3. (a) Proses Mengirim Video, (b) Proses Menerima Video Gambar 2. Alur Kerja Sistem
3 Proses ini diilustrasikan pada Gambar 3(b). Pertama-tama komputer akan memulai tugasnya dengan membentuk suatu sesi terlebih dahulu. Sesi ini digunakan untuk menerima data. Jika ada data yang datang dan data tersebut berhasil didekripsi dan dibentuk ulang menjadi sebuah file video yang dapat dimainkan, maka klien bisa menampilkan video tersebut pada layar monitornya. B. Proses Enkripsi Dekripsi RC5 Proses enkripsi pada aplikasi ini dilakukan dengan bantuan pustaka Bouncy Castle. Aplikasi ini menggunakan algoritma RC5 untuk melakukan enkripsi secara simetrik. Diagram alir proses enkripsi ini ditunjukkan pada Gambar 4(a). Sebelum dapat dimasukkan pada proses enkripsi, plaintext dipecah dahulu menjadi blok-blok dengan ukuran tertentu dalam bit. Blok plaintext ini kemudian dienkripsi dengan algoritma RC5 yang telah diinisialisasi dengan mode "encrypt" dan diberi kunci rahasia yang telah diproses. Luaran dari proses enkripsi ini adalah sebuah blok ciphertext. Karena algoritma RC5 yang digunakan adalah RC5 yang menggunakan padding, maka blok ciphertext akan memiliki padding untuk memenuhi blok ciphertext jika ukuran blok ciphertext tidak memenuhi ukuran standard dari blok untuk RC5.
pada sistem operasi Linux. Perkakas ini menerapkan multicast routing yang bersifat statis. Jadi pengguna harus mendaftarkan seluruh IP yang mungkin akan mengirimkan paket multicast, menggabungkan IP pengirim ke dalam grup multicast, serta pada interface mana paket multicast tersebut akan diteruskan. Perintah pendaftaran ini formatnya adalah: smcroute -a
[]... Gambar 5. Pendaftaran IP Multicast pada Smcroute
IV. UJI COBA DAN ANALISIS A. Skenario Uji Coba Terdapat tiga buah skenario untuk melakukan uji coba performa aplikasi video streaming ini, yang akan dijelaskan sebagai berikut. 1) Skenario Pengujian dengan VariasiUkuran File Router
192.168.1.1
192.168.1.4
192.168.0.1
Switch
Klien
192.168.1.3
192.168.1.3
Server
Server
192.168.0.2
Klien
(a) (b) Gambar 6. Skenario Pengujian dengan Variasi Ukuran File (a) Satu Subnet, (b) Dua Subnet
Gambar 6(a) menerangkan skenario pengujian performa untuk mengetahui pengaruh perbedaan ukuran file terhadap kualitas layanan yang dilakukan pada satu subnet. Dalam pengujian ini digunakan satu server dan satu klien. Server memiliki IP 192.168.1.3, sedangkan IP klien adalah 192.168.1.4. Sedangkan Gambar 6(b) merupakan arsitektur jaringan yang digunakan untuk menguji performa perbedaan ukuran file saat ditransmisikan ke subnet yang berbeda. 2) Skenario Pengujian dengan Variasi Jumlah Klien Klien
Switch
192.168.1.4
192.168.1.4
192.168.1.2 Server
Klien
Klien
192.168.1.2
Klien
Switch 192.168.1.3
(a) (b) Gambar 4. (a) Proses Enkripsi Video, (b) Proses Dekripsi Video
192.168.1.3
Server 192.168.1.5
Klien
Sama dengan proses enkripsi, proses dekripsi juga dilakukan dengan memanfaatkan pustaka Bouncy Castle. Diagram alir untuk proses dekripsi data bisa dilihat pada Gambar 4(b). Pertama-tama Cipher diinisialisasi dulu sehingga berada pada mode "decrypt", serta diberi parameter kunci rahasia. Blok ciphertext yang datang didekripsi sehingga menghasilkan blok plaintext. Jika ada padding pada ciphertext yang datang, maka padding ini akan dihilangkan terlebih dahulu sebelum dilakukan proses dekripsi pada ciphertext. Luaran dari proses dekripsi adalah blok plaintext, yang nantinya diterjemahkan sebagai data video dan dimainkan oleh alat pemutar video. C. Implementasi Multicast Routing Routing multicast bisa diimplementasikan dengan perkakas bernama smcroute yang berjalan sebagai daemon
192.168.1.6
Klien
192.168.1.7
Klien
(a) (b) Gambar 7. Skenario Pengujian dengan Variasi Jumlah Klien (a) Dua Klien, (b) Lima Klien
Arsitektur jaringan untuk pengujian performa dengan 2 buah klien ditunjukkan pada Gambar 7(a). Server merupakan komputer dengan IP 192.168.1.3, sedangkan kedua klien memiliki IP 192.168.2 dan 192.168.1.4. Gambar 7(b) merupakan ilustrasi arsitektur untuk pengujian performa dengan melibatkan lima buah klien. Server memiliki IP 192.168.1.3, sedangkan klien berturut-turut memiliki IP 192.168.1.2, 192.168.1.4, 192.168.1.5, 192.168.1.6, dan 192.168.1.7. B. Hasil Uji Coba Performa dengan Variasi Ukuran File Dari arsitektur yang terdapat pada Gambar 6, dilakukan uji coba performa kualitas layanan yang meliputi delay, jitter, serta
4 throughput. Hasil pengujian dengan lima file yang berbeda diuraikan pada penjelasan di bawah ini. 1) Uji Coba Delay Gambar 8(a)-(e) merupakan grafik hasil pengujian delay untuk lima file dengan ukuran yang berbeda. Dari grafik pada Gambar 8, dapat dilihat bahwa file kedua memiliki delay ratarata yang paling kecil, sedangkan file kelima memiliki delay rata-rata yang paling besar.
(a)
(c)
3) Uji Coba Throughput Gambar 10(a)-(e) merupakan grafik hasil pengujian throughput untuk lima file dengan ukuran yang berbeda. Dari grafik pada Gambar 10, dapat dilihat bahwa file kedua memiliki throughput rata-rata yang paling besar, sedangkan file kelima memiliki throughput rata-rata yang paling kecil.
(a)
(b)
(c)
(d)
(b)
(d)
(e) Gambar 10. Grafik Hasil Uji Coba Throughput untuk (a) File Pertama, (b) File Kedua, (c) File Ketiga, (d) File Keempat, dan (e) File Kelima (e) Gambar 8. Grafik Hasil Uji Coba Delay untuk (a) File Pertama, (b) File Kedua, (c) File Ketiga, (d) File Keempat, dan (e) File Kelima
2) Uji Coba Jitter
(a)
(b)
(c)
(d)
(e) Gambar 9. Grafik Hasil Uji Coba Jitter untuk (a) File Pertama, (b) File Kedua, (c) File Ketiga, (d) File Keempat, dan (e) File Kelima
Gambar 9(a)-(e) merupakan grafik hasil pengujian jitter untuk lima file dengan ukuran yang berbeda. Dari grafik pada Gambar 9, dapat dilihat bahwa jitter yang dialami ketika pengiriman lima file yang berbedaa nilainya relatif sama.
4) Uji Coba Packet Loss Berdasarkan uji coba yang telah dilakukan terhadap 5 file yang berbeda, packet loss yang tercatat sebesar 0% untuk setiap skenario pengujian. 5) Analisis Uji Coba Performa dengan Variasi Ukuran File File pertama yang diujicobakan memiliki ukuran 26,150 KB, frame rate 25,0, dan berdimensi 352 x 288 piksel. File kedua yang diujicobakan memiliki ukuran 1,380 KB, frame rate 24,0, dan ukuran frame 352 x 240 piksel. File ketiga ini memiliki ukuran file sebesar 6,308 KB, frame rate 29,9, serta ukuran frame 320 x 240 piksel. File keempat ini memiliki ukuran file sebesar 817 KB, frame rate 25,0, serta ukuran 384 x 284 piksel. Untuk pengujian file yang terakhir, digunakan file berukuran 22.018 KB, dengan frame rate 30,0, dan dimensi 320 x 240 piksel. Berdasarkan hasil pengujian performa dengan menggunakan lima buah file video yang berbeda untuk lima buah skenario yang berbeda, didapatkan bahwa ukuran file ternyata berpengaruh terhadap delay, jitter, serta throughput pada saat pengiriman video. Namun ukuran file tidak mempengaruhi performa umum dari arsitektur unicast, broadcast, serta multicast. Jika dilihat pada grafik dapat diambil suatu pernyataan bahwa semakin besar ukuran file, maka semakin besar pula delay, jitter, namun semakin kecil throughput yang dialami oleh pengirim dan penerima. Namun tidak hanya ukuran file saja yang mempengaruhi performa ini, namun dimensi file dan frame rate juga ikut diperhitungkan. Meskipun ukuran file kecil, namun jika dimensi atau frame rate lebih besar daripada file lain, file tersebut akan mengalami delay dan jitter yang
5 lebih lama, serta throughput yang lebih kecil daripada file lain dengan ukuran sama namun memiliki frame rate dan dimensi yang lebih kecil. Performa unicast, broadcast, dan multicast tetap sebanding meskipun file yang digunakan untuk pengiriman berbeda-beda ukuran, frame rate, dan dimensinya. Secara umum performa delay dan jitter untuk unicast lebih kecil daripada broadcast dan multicast. throughput untuk unicast, broadcast, dan multicast relatif sama dan sebanding untuk masing-masing file yang dikirimkan. C. Uji Coba Performa dengan Variasi Jumlah Klien Dari arsitektur yang terdapat pada Gambar 7, dilakukan uji coba performa kualitas layanan yang meliputi delay, jitter, serta throughput. Hasil pengujian dengan dua klien dan lima klien yang berbeda diuraikan pada penjelasan di bawah ini. 1) Uji Coba Delay Gambar 11(a)-(f) merupakan grafik hasil pengujian delay untuk dua klien dan lima klien dengan arsitektur yang berbeda. Dari grafik pada Gambar 11, dapat dilihat bahwa delay yang dialami ketika pengiriman file secara unicast untuk lima klien merupakan yang terbesar nilainya di antara yang lain.
(a)
2) Uji Coba Jitter Delay dan jitter merupakan satu satuan yang hampir sama. Delay merupakan keterlambatan dalam waktu transmisi data dari pengirim dan penerima, satuan dari delay adalah sekon (detik) atau milisekon (milidetik). Sedangkan jiter merupakan variasi dari delay atau selisih antara delay pertama dengan delay selanjutnya. Gambar 12(a)-(f) merupakan grafik hasil pengujian jitter untuk dua klien dan lima klien dengan arsitektur yang berbeda. Dari grafik pada Gambar 12, dapat dilihat bahwa jitter yang dialami ketika pengiriman file secara unicast untuk lima klien merupakan yang terbesar nilainya di antara yang lain, serta yang variasinya paling besar.
(a)
(b)
(c)
(d)
(b)
(e) (f) Gambar 12. Grafik Hasil Uji Coba Jitter untuk (a) Unicast Dua Klien, (b) Unicast Lima Klien, (c) Broadcast Dua Klien, (d) Broadcast Lima Klien, (e) Multicast Dua Klien, dan (f) Multicast Lima Klien (c)
(d)
(e) (f) Gambar 11. Grafik Hasil Uji Coba Delay untuk (a) Unicast Dua Klien, (b) Unicast Lima Klien, (c) Broadcast Dua Klien, (d) Broadcast Lima Klien, (e) Multicast Dua Klien, dan (f) Multicast Lima Klien
3) Uji Coba Throughput
(a)
(b)
(c)
(d)
(e)
(f)
Gambar 13. Grafik Hasil Uji Coba Throughput untuk (a) Unicast Dua Klien, (b) Unicast Lima Klien, (c) Broadcast Dua Klien, (d) Broadcast Lima Klien, (e) Multicast Dua Klien, dan (f) Multicast Lima Klien
6 Gambar 13(a)-(f) merupakan grafik hasil pengujian throughput untuk dua klien dan lima klien dengan arsitektur yang berbeda. Dari grafik pada Gambar 11, dapat dilihat bahwa throughput yang dialami ketika pengiriman file secara unicast untuk lima klien merupakan yang terkecil nilainya di antara yang lain, dan juga yang paling bervariasi. 4) Uji Coba Packet Loss Nilai packet loss yang didapatkan dari pengujian untuk lima klien dan dua klien mencapai 0%. Packet loss muncul ketika satu paket data atau lebih yang sedang dikirimkan melalui jaringan mengalami kegagalan untuk dapat sampai kepada tujuan. Packet loss dapat menyebabkan masalah yang cukup berarti terutama pada beberapa aplikasi seperti video streaming atau Voice over IP, karena informasi yang hilang tidak dapat dikembalikan. Jika packet loss bernilai 0%, maka dapat dikatakan bahwa hampir tidak ada paket yang hilang atau terbuang pada proses pengiriman video dari server menuju ke klien. 5) Analisis Uji Coba Performa dengan Variasi Jumlah Klien Dalam pengujian performa dengan variasi jumlah klien yang terlibat, dapat disimpulkan bahwa jumlah klien berpengaruh terhadap performa umum dari arsitektur unicast, broadcast, serta multicast. Pada pengujian ini digunakan dua klien dan lima klien untuk setiap arsitektur yang diuji. Pada pengujian dengan menggunakan dua klien, performa unicast lebihi baik daripada broadcast dan multicast. Hal ini dibuktikan dengan nilai delay dan jitter pada pengiriman secara unicast yang nilainya lebih kecil daripada jika data video dikirimkan secara broadcast dan multicast. Jika digunakan lima klien sekaligus pada pengujian, performa unicast jauh lebih buruk daripada broadcast dan multicast. Delay untuk unicast dapat mencapai 3 detik, sementara broadcast dan multicast mengalami delay kurang dari 1 detik. Throughput pada masing-masing klien untuk pengiriman secara unicast pada lima klien juga sangat bervariasi untuk setiap klien, dan nilai throughput tersebut tergolong kecil jika dibandingkan dengan throughput yang didapat jika menggunakan arsitektur broadcast dan multicast. Secara umum untuk perbandingan antara broadcast dan multicast dalam hal delay dan jitter, baik dengan jumlah klien dua buah maupun lima buah klien, broadcast relatif lebih unggul. Hal ini berdasar pada nilai delay dan jitter yang kecil pada saat pengiriman video secara broadcast daripada multicast. V. KESIMPULAN Dari hasil pengamatan selama perancangan, pengimplementasian, dan proses uji coba sistem didapatkan kesimpulan sebagai berikut. 1. Algoritma enkripsi RC5 dapat diimplementasikan pada pengiriman video dengan tujuan menjaga kerahasiaan data video yang dikirimkan. Pengimplementasian metode enkripsi RC5 pada aplikasi ini dimudahkan dengan bantuan pustaka Bouncy Castle yang telah memiliki berbagai algoritma kriptografi yang telah siap digunakan, termasuk RC5.
2. Data video dapat dikirimkan kepada penerima secara unicast, broadcast maupun multicast. Untuk penerusan paket multicast yang berbeda subnet, dapat digunakan paket smcroute yang berjalan sebagai daemon pada Linux. 3. Berdasarkan hasil uji coba aplikasi dalam hal performa, didapatkan hal-hal di bawah ini: a. Ukuran file yang berbeda tidak mempengaruhi performa umum unicast, broadcast, dan multicast. perbedaan ukuran file ini menyebabkan perbedaan delay, jitter, dan throughput. Semakin besar ukuran file, maka semakin besar delay dan semakin kecil throughput. b. Jumlah klien mempengaruhi performa umum dari unicast, broadcast, dan multicast. Jika klien hanya 2, unicast lebih unggul daripada broadcast dan multicast dalam hal delay, jitter, dan throughput. Namun jika jumlah klien mencapai 5, maka broadcast dan multicast lebih unggul daripada unicast dalam hal delay, jitter, dan throughput. c. Waktu yang diperlukan untuk melakukan enkripsi dan dekripsi adalah sekitar 23 nanodetik untuk waktu enkripsi dan 17 nanodetik untuk proses dekripsi. d. Delay yang terjadi pada aplikasi video streaming masih dapat ditoleransi berdasarkan ketentuan ITUT, karena delay yang terjadi tidak ada yang melebihi 450 ms. e. Jitter juga termasuk baik karena rata-rata kurang dari 225 ms. f. Throughput yang tercatat dapat mencapai 2,5 Mbps. g. Packet loss untuk keseluruhan uji coba pada semua arsitektur mencapai 0%. Hal ini menandakan performa packet loss sangat baik. DAFTAR PUSTAKA [1]
Burton S. Kaliski Jr., Yiqun Lisa Yin, 1998. On The Security of the RC5 Encryption Algorithm. USA: RSA Laboratories. [2] Ze-Nian Li, Mark S. Drew, 2004. Fundamentals of Multimedia. New Jersey: Pearson Education Inc. [3] Yao Wang, Joern Ostermann, Ya-Qin Zhang, 2002. Video Processing and Communication. New Jersey: Prentice Hall. [4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport Protocol for Real-Time Applications, IETF, RFC 1889, Januari 1996 [Online]. Tersedia pada http:/www.rfc-editor.org/rfc/rfc1889.txt. [5] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport Protocol for Real-Time Applications, IETF, RFC 3550, Juli 2003 [Online]. Tersedia pada http:/www.rfc-editor.org/rfc/rfc3550.txt. [6] Ronald L. Rivest, 1997. The RC5 Encryption Algorithm. Massachussets: MIT Laboratory for Computer Science. [7] Ronald L. Rivest, The MD5 Message-Digest Algorithm, IETF, RFC 1321, April 1992 [Online]. Tersedia pada http:/www.rfceditor.org/rfc/rfc1321.txt [8] Anonim.1999. JMF Guide 2.0. USA: Sun Microsystems, Inc. [9] S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer, RTP Payload Format for H.264 Video, IETF, RFC 3984, Februari 2005 [Online]. Tersedia pada http:/www.rfceditor.org/rfc/rfc3984.txt. [10] S.E. Deering, Host extensions for IP multicasting, IETF, RFC 1054, Mei 1988 [Online]. Tersedia pada http:/www.rfc-editor.org/rfc/rfc1054.txt. [11] William Stallings. 1997. Data and Computer Communications. 5th ed. New Jersey: Prentice Hall.
7 [12] Andrew S. Tanembaum. 2003. Computer Networks. 4th ed. New Jersey: Prentice Hall.
[13] William Stallings. 2005.
Cryptography and Network Security Principles and Practices. 4th ed. New Jersey: Prentice Hall.
