Oleh : Deni Zakya NIM. :

PENGEMBANGAN APLIKASI DiffServ dengan DISIPLIN ANTRIAN HIERARCHY TOKEN BUCKET dan RANDOM EARLY DETECTION SEBAGAI BANDWIDTH LIMITING

Skripsi Sebagai Salah Satu Syarat untuk Memperoleh Gelar Sarjana Komputer Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta

Oleh : Deni Zakya NIM. : 105091002901

PROGRAM STUDI TEKNIK INFORMATIKA FAKUTAS SAINS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIEF HIDAYATULLAH JAKARTA 2010

PENGEMBANGAN APLIKASI DiffServ dengan DISIPLIN ANTRIAN HIERARCHY TOKEN BUCKET dan RANDOM EARLY DETECTION SEBAGAI BANDWIDTH LIMITING

Oleh : Deni Zakya NIM. : 105091002901

PROGRAM STUDI TEKNIK INFORMATIKA FAKUTAS SAINS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIEF HIDAYATULLAH JAKARTA 2010

KATA PENGANTAR

Segala Puji dan Syukur penulis panjatkan kepada Allah SWT atas segala karunia-Nya karena penulis dapat menyelesaikan penulisan Skripsi ini dengan judul Pengembangan Aplikasi DiffServ dengan Disiplin Antrian Hierarchy Token Bucket dan Random Early Detection Sebagai Bandwidth Limiting dengan baik. Shalawat serta salam penulis haturkan kepada Nabi Muhammad SAW, para sahabat dan keluarga beliau. Setelah

seluruh

penulisan

Skripsi

ini

terlaksana,

penulis

ingin

mengucapkan banyak terimakasih kepada seluruh pihak yang telah membantu baik itu berupa motivasi, bimbingan, moril maupun materil, yang ditujukan kepada: 1. Bapak DR. Syopiansyah Jaya Putra, M.SIS, selaku Dekan Fakultas Sains dan Teknologi, UIN Syarif Hidayatullah Jakarta. 2. Bapak Yusuf Durrachman, M. Sc, MIT, selaku Ketua Program Studi Teknik Informatika, Fakultas Sains dan Teknologi, UIN Syarif Hidayatullah Jakarta 3. Bapak Viktor Amrizal, M.Kom, selaku dosen pembimbing I yang selalu memberikan bimbingan, semangat dan meluangkan waktunya. 4. Ibu Arini, M.T, selaku dosen pembimbing II yang telah memberikan pengarahan dan membantu menyelesaikan penulisan skripsi ini.

vii

Penulis sadar bahwa penyusunan skripsi ini masih jauh dari sempurna, oleh karena itu penyusun mengharapkan kritik dan saran yang bersifat membangun agar penyusunan skripsi ini menjadi lebih baik lagi. Akhir kata, semoga skripsi ini bermanfaat khususnya kepada penulis sendiri dan bagi yang membacanya. Jakarta, 19 April 2010

Deni Zakya 105091002901

viii

ABSTRAK

Deni Zakya, Pengembangan Aplikasi DiffServ dengan Disiplin Antrian Hierarchy Token Bucket dan Random Early Detection Sebagai Bandwidth Limiting. Di bawah bimbingan Victor Amrizal, M.Kom dan Arini, M.T.

Pertumbuhan internet memunculkan warnet yang menggunakan koneksi internet sebagai komponen dasar bisnis tersebut. Pengelola warnet akan menggunakan minimal satu koneksi internet dan membaginya dengan semua node yang terkoneksi dengan internet. Banyaknya

node yang terkoneksi ke router akan menyebabkan kondisi jaringan mengalami kongesti/kepadatan. Sehingga terlihat ada satu atau lebih node yang mendominasi penggunaan bandwidth jaringan. Untuk itu diperlukan konsep Quality of Service (QoS), salah satu cara mengaplikasikan QoS pada jaringan IP adalah dengan Differentiated Service(DiffServ). Penulis menggunakan penjadwalan paket Hierarchy Token Bucket dan Random Early Detection pada penelitian ini. Klasifikasi akan didasarkan pada node yang terhubung, protocol tcp atau udp dan jaringan IIX(lokal) dan internasional. Klasifikasi IIX dan Internasional diambil karena adanya perbedaan kecepatan yang signifikan dari kedua jaringan tersebut. Analisis kualitas layanan pada jaringan dilakukan dengan mengukur parameter throughput, delay, jitter dan packet loss. Pada akhirnya Implementasi DiffServ menggunakan TrafficControl dengan disiplin antrian HTB dan RED dapat berperan untuk mengatur penggunaan bandwidth tiap node pada jaringan. Aplikasi dapat membedakan asal paket dari jaringan IIX(lokal) atau internasional. Dan memberikan batasan kecepatan yang sesuai untuk tiap koneksi. Penggunaan antrian HTB dan RED memberikan kualitas layanan yang baik tanpa mengorbankan parameter pengujian throughput, delay, jitter dan packet loss yang besar. Penulis menggunakan Extreme Programming sebagai Metodologi pengembangan perangkat lunak. Terlihat dari hasil pengujian yang memberikan nilai pengujian dari parameter tersebut relatif kecil dibandingkan dengan penggunaan best effort atau hanya dengan disiplin antrian FIFO. Kata Kunci : Bandwidth Limiting, TrafficControl, Hierarchy Token Bucket, Random Early Detection.

vi

BAB I PENDAHULUAN

1.1

Latar Belakang Pertumbuhan internet memunculkan warnet yang menggunakan koneksi internet sebagai komponen dasar bisnis tersebut. Pengelola warnet akan menggunakan minimal satu koneksi internet dan membaginya dengan semua node yang terkoneksi dengan internet. Penggunaan router pada jaringan komputer warnet dapat menghubungkan koneksi lokal warnet dengan internet. Banyaknya node yang terkoneksi ke router akan menyebabkan kondisi jaringan mengalami kongesti/kepadatan. Hal tersebut akan menyebabkan beberapa paket yang diterima atau dikirim oleh router hilang sebagian. Dampaknya akan ada beberapa node yang kehilangan paket data yang seharusnya diterima. Sehingga terlihat seolah-olah ada satu atau lebih node yang mendominasi penggunaan bandwidth jaringan(Welzl, 2005). Hal tersebut terjadi karena pada router secara default menerapkan disiplin antrian First In First Out (FIFO). Selain itu pula penggunaan jaringan IP yang menerapkan best effort service(Li, 1999), jaringan yang memberikan throughput dan waktu pengiriman bervariasi tergantung kepada beban trafik saat pengiriman terjadi, memberikan dampak turunnya performa jaringan dan menurunnya Quality of Service (QoS) pada jaringan tersebut. Layanan internet seperti streaming audio ataupun video akan mendapatkan penurunan performa, karena kurangnya throughput pada layanan ini.

Untuk itu diperlukan konsep Quality of Service (QoS) yang dapat memberikan performa yang baik untuk semua layanan. Jaringan yang mengaplikasikan QoS dengan baik, harus mampu membedakan trafik atau tipe layanan dan memperlakukan trafik tersebut secara berbeda untuk memberikan jaminan sumber daya tiap trafik. Salah satu cara mengaplikasikan QoS pada jaringan IP adalah dengan Differentiated Service(DiffServ)(Blake, 1998). DiffServ bekerja dengan cara mengklasifikasikan trafik dan memberikan perlakuan yang sesuai untuk tiap trafik. QoS memiliki beberapa modul untuk menjalankan tugasnya, antara lain pengklasifikasi trafik, penanda trafik, traffic policing, manajemen antrian aktif, penjadwalan paket dan traffic shaping. Penulis menggunakan penjadwalan paket HTB dan RED pada penelitian ini. Untuk menerapkan DiffServ, penulis akan menggunakan kernel linux, TrafficControl dan Iptables. Klasifikasi akan didasarkan pada node yang terhubung, protocol tcp atau udp dan jaringan IIX(lokal) dan internasional. Klasifikasi IIX dan Internasional diambil karena adanya perbedaan kecepatan yang signifikan dari kedua jaringan tersebut.

Judul yang penulis angkat adalah “Pengembangan Aplikasi DiffServ dengan disiplin antrian Hierarchy Token Bucket dan Random Early Detection sebagai bandwidth limiting”. Linux digunakan sebagai sistem operasi yang digunakan pada penelitian ini. Penulis akan membangun aplikasi dengan GUI yang memudahkan pengguna untuk mengatur penggunaan bandwidth. Penulis menjembatani penggunaan modul kernel, TrafficControl dan Iptables yang relatif sulit, dengan aplikasi ini. Penelitian ini akan menguji tingkat kualitas jaringan yang telah mengimplementasikan DiffServ. Beberapa parameter yang digunakan untuk mengukur kualitas jaringan, antara lain throughput, delay, jitter dan packet loss.

1.2

Rumusan Masalah Masalah yang dapat dirumuskan dalam tugas akhir ini sebagai berikut : 1. Efisiensi penggunaan bandwidth tiap node pada jaringan dengan memberikan alokasi bandwidth sesuai kebutuhan. 2. Pemisahan alokasi bandwidth tiap node. Klasifikasi didasarkan pada asal dari paket yang datang, IIX untuk jaringan lokal(indonesia) dan International untuk jaringan Internet. Klasifikasi lainnya berdasarkan protocol, TCP atau UDP. 3. Membangun aplikasi berbasis DiffServ dengan router linux. 4. Menguji Quality of Service tiap-tiap node pada jaringan.

1.3

Batasan Masalah Agar pembahasan mengenai topik ini tidak terlalu meluas maka diperlukan batasan masalah. Adapun batasan masalah untuk skripsi ini antara lain: 1. Aplikasi yang penulis buat akan menjembatani pengguna untuk melakukan konfigurasi tidak langsung DiffServ pada kernel linux dengan Traffic Control, Iptables dan Python. 2. Merumuskan konfigurasi yang digunakan aplikasi untuk pemisahan bandwidth IIX & Internasional serta paket tcp dan udp untuk tiap node yang terhubung ke jaringan internet.

3. Pengujian dan analisis QoS dengan parameter nilai bandwidth, jitter dan packet loss.

1.4

Tujuan dan Manfaat Penelitian Penelitian yang penulis lakukan bertujuan untuk: 1. Tujuan Umum 1. Mengembangkan aplikasi bandwidth management yang bersifat open source dan user friendly. 2. Tujuan Khusus 1. Memadukan iptables dan TC(traffic control) sebagai fondasi awal aplikasi. 2. Memberikan pengelolaan bandwidth yang sesuai pada jaringan. 3. Memberikan antar muka grafis yang sederhana dan mudah digunakan. Manfaat yang di dapatkan dalam penelitian ini adalah : 1. Memberikan aplikasi yang mampu mengatur penggunaan bandwidth sesuai kebutuhan. 2. Memberikan aplikasi yang murah dan mudah diterapkan. 3. Menghasilkan aplikasi open source yang bebas digunakan/dikembangkan siapa saja.

1.5

Metodologi Penelitian Metode Penelitian yang penulis gunakan adalah sebagai berikut : 1. Studi Pustaka.

Studi pustaka yang penulis lakukan adalah dengan mempelajari literatur tentang traffic control pada linux dan queueing discipline. 2. Metode Pengembangan Perangkat Lunak(Software Development Method). Metode pengembangan perangkat lunak yang penulis gunakan adalah Agile Software Development dengan Extreme Programming. Tahapannya adalah sebagai berikut : 1.

Planning, perencanaan dari aplikasi yang akan dibuat dengan menjelaskan fitur dan kegunaan dari aplikasi.

2.

Design, proses desain dari hasil perencanaan sebelumnya.

3.

Coding, proses pembuatan unit test untuk kemudian digunakan sebagai penguji pada code yang akan diimplementasikan.

4.

Testing, proses pengujian terhadap code yang diimplementasikan dengan unit test yang sebelumnya telah dibuat.

5.

Release, tahap akhir aplikasi siap diimplementasikan/digunakan oleh pengguna, setelah sebelumnya dipastikan sudah melewati tahapan testing.

1.6

Sistematika Penelitian Penelitian ini terdiri dari lima bab, dengan penjelasan tiap-tiap bab sebagai berikut :

BAB I : PENDAHULUAN Pada bab ini berisi tentang Latar Belakang, Rumusan Masalah, Batasan Masalah, Tujuan dan Manfaat Penelitian, Metodologi Penelitian serta Sistematika Penulisan Penelitian.

BAB II: LANDASAN TEORI Pada bab ini menjelaskan tentang teori perangkat keras dan perangkat lunak, definisi sistem, analisa sistem, definisi perancangan sistem dan jenis program yang digunakan.

BAB III: Metodologi Penelitian Pada bab ini akan menguraikan dan memberikan penjelasan mengenai perancangan perangkat keras, perancangan sistem sehingga dapat diketahui rencana yang akan dikerjakan.

BAB IV: Pembahasan dan Implementasi Pada bab ini akan menjelaskan mengenai pembuatan sistem dan pengujian sistem.

BAB V: Penutup Bab ini berisi kesimpulan dari pembahasan masalah dan saran-saran berkenaan dengan Penelitian ini.

BAB II LANDASAN TEORI

2.1.

Pengantar Quality of Service

Pertama kali jaringan IP diterapkan hanya membawa satu tipe informasi yaitu data non-real time, sehingga jaringan bisa didesain untuk berjalan secara best-effort yang memperlakukan semua paket sama. Tujuan utama dari jaringan IP adalah memastikan perangkat terminal mempunyai protokol dan kecerdasan yang sesuai untuk menjamin transmisi data yang bisa diandalkan sehingga jaringan bisa berjalan

sesederhana

mungkin. Pada pertengahan tahun 90-an, tipe jaringan data dan suara mulai disatukan. Ide utama adalah konvergensi lalu lintas suara dan data, dan menciptakan sebuah jaringan yang mampu membawa suara dan data. Dengan konvergensi tersebut, terdapat tantangan baru. Dalam jaringan baru tersebut, operasi best effort yang dilakukan jaringan IP tidak lagi mampu memenuhi kebutuhan berbagai macam lalu lintas data yang dibawa oleh jaringan. Untuk menjawab masalah tersebut, muncul konsep Quality of Service(QoS) (Welzl, 2005). QoS dapat didefinisikan dari dua sudut pandang: QoS dari sudut pandang pengguna dan QoS dari sudut pandang jaringan. Dari sudut pandang pengguna, QoS merupakan pandangan pengguna terhadap kualitas layanan yang diterima dari penyedia

jaringan, seperti suara, video, maupun data. Dari sudut pandang jaringan, istilah QoS mengacu kepada kemampuan jaringan menyediakan QoS yang diharapkan oleh pengguna. Kemampuan yang dibutuhkan oleh jaringan dalam menyediakan QoS di jaringan paket dapat dibagi menjadi dua. Pertama, untuk menyediakan QoS, sebuah jaringan paket harus mampu membedakan kelas-kelas lalu lintas data sehingga pengguna dapat memperlakukan satu atau lebih kelas lalu lintas data berbeda dengan kelas lalu lintas data lainnya. Kedua, setelah jaringan mampu membedakan kelas-kelas lalu lintas data, jaringan harus mampu memperlakukan kelas-kelas tersebut secara terpisah dengan menyediakan jaminan sumber daya dan perbedaan layanan dalam jaringan. Persepsi pengguna terhadap kualitas layanan dilakukan dengan melakukan tes secara subjektif, sebagai fungsi dari keterbatasan pada jaringan seperti, waktu tunda, jitter, dan paket hilang. Jumlah keterbatasan pada jaringan akan bergantung dari mekanisme QoS yang diimplementasikan pada jaringan. Pada sebuah jaringan yang membawa berbagai tipe lalu lintas data, keterbatasan yang menjadi elemen penting pada suatu tipe lalu lintas data bisa saja menjadi tidak penting untuk tipe lalu lintas data lainnya, dan sebaliknya.

Mekanisme QoS yang

diimplementasikan pada jaringan harus mampu mengoptimalkan hal tersebut.

2.1.1.

Fungsi Dasar QoS

Tanpa mekanisme QoS, sebuah jaringan IP menyediakan layanan yang sifatnya best effort. Pada layanan best effort, semua paket tidak dapat dibedakan dan diberikan perlakuan forwarding yang sama. Sebuah mekanisme QoS pada jaringan IP meyediakan kemampuan untuk membedakan paket dan memberikan perlakuan yang

berbeda. Dua mekanisme QoS utama yang tersedia untuk jaringan IP adalah Integrated Service (IntServ) dan Differentiated Service (DiffServ) (Welzl, 2005). Istilah traffic flow menunjukkan aliran trafik dan tiap alirannya mewakili sumber trafik yang berbeda-beda. Pada layanan best effort, semua paket digabungkan kedalam sebuah aliran massal tanpa mempedulikan asal trafik. Pada IntServ, tiap-tiap aliran dibedakan dari awal sampai akhir. Pada DiffServ, tiap-tiap aliran trafik tidak dibedakan per aliran, melainkan dikumpulkan terlebih dahulu menjadi kelas-kelas kecil. Kelas-kelas trafik tersebut diberikan perlakuan yang berbeda-beda tiap hopnya (Li,1999). Pembahasan akan ditekankan pada metoda QoS DiffServ, dan akan dijelaskan lebih lanjut pada sub bab berikutnya. Untuk menyediakan QoS dalam jaringan IP jaringan harus mampu menjalankan tugas dasar, yaitu membedakan trafik atau tipe layanan menjadi beberapa kelas dan memperlakukan kelas-kelas trafik secara berbeda dengan menyediakan jaminan resource dan pembedaan layanan pada jaringan.

2.1.2.

Traffic Policing

Traffic Policing digunakan untuk mengecek apakah trafik yang masuk pada port masukan sesuai dengan laju trafik yang telah disetujui antara pengguna dan penyedia jasa jaringan IP. Traffic policing terdiri dari pengukuran trafik berdasarkan laju trafik yang telah disetujui dan menandai atau menandai ulang paket berdasarkan keluaran hasil pengukuran tersebut. Sebuah paket kemungkinan dapat dijatuhkan

berdasarkan proses traffic policing ini. Traffic policing terdiri atas dua submodul, yaitu traffic meter dan packet marker/re-marker. Biasanya, traffic policing menyesuaikan laju trafik yang datang dengan acuan laju tertentu, dengan acuan yang digunakan dapat berupa satu acuan laju yaitu Committed Information Rate (CIR) atau dua acuan laju, CIR dan Peak Information Rate (PIR). Untuk mendapatkan laju yang sesuai dengan CIR dan PIR, traffic policing menggunakan tiga parameter yaitu Peak Burst Size (PBS), Committed Burst Size (CBS) dan Excess Burst Size (EBS) (Blake, 1998).

a. Peak Information Rate. Peak Information Rate (PIR) merupakan laju maksimum pengiriman bit seorang pengguna yang disetujui bersama antara pengguna dan penyedia layanan oleh sebuah Service Level Agreement (SLA). Bagi seorang pengguna, laju pengiriman maksimum secara fisik dibatasi oleh laju jalur dari pelanggan tersebut. PIR dari seorang pelanggan tidak akan lebih besar dari laju jalur pelanggan tersebut. Bila PIR dinyatakan sebagai λ max , maka secara teori invers dari PIR adalah laju kedatangan paket minimum yang dinyatakan sebagai 1/ λ max . PIR dinyatakan dalam ukuran bytes per sekon. PIR menyatakan laju pengiriman paket IP dan karenanya, dalam menghitung jumlah byte pada sebuah paket IP, seluruh paket termasuk header IP diperhitungkan; header yang berada pada layer yang lebih bawah, misalnya layer 2 dan overhead dari jalur fisik tertentu, tidak diperhitungkan.

b. Committed Information Rate. Commited Information Rate (CIR) merupakan laju trafik rata-rata jangka panjang yang disediakan oleh penyedia jasa layanan yang dijamin kepada pelanggan sesuai persetujuan. CIR dinyatakan dalam satuan byte per sekon. Dalam menghitung jumlah byte pada sebuah paket IP untuk CIR, seluruh paket termasuk header IP diperhitungkan. Akan tetapi, seperti PIR, hanya layer IP yang diperhitungkan untuk menghitung CIR dan header dari layer yang lebih bawah, misalnya layer dua dan overhead lainnya tidak ikut diperhitungkan. Biasanya, pengiriman paket merupakan sederetan luapan tiba-tiba paket (burst) yang diselingi oleh jeda waktu tanpa pengiriman paket sama sekali. Saat paket datang dalam luapan mendadak tersebut, paket-paket dikirimkan pada laju maksimum, yaitu PIR. Karena hal ini tidak berlangsung secara kontinyu, maka laku rata-rata pada jangka panjang akan lebih kecil dari PIR. Karenanya, CIR biasanya akan lebih kecil dari PIR.

c. Burst Sizes Ada tiga parameter pendukung ukuran burst yang digunakan dalam traffic policing : Committed Burst Size, Excess Burst Size (EBS), dan Peak Burst Size (PBS). CBS merupakan ukuran burst maksimum yang bisa dijamin oleh jaringan dan merupakan jumlah maksimum paket dalam ukuran byte yang dapat dikirimkan pada PIR dengan memperhatikan CIR yang telah disetujui. EBS merupakan batasan lain dari ukuran burst yang melebihi CBS, dan CBS < EBS. Paket yang melebihi EBS

akan ditandai merah. CBS dan EBS digunakan secara berkesinambungan dengan CIR. PBS merupakan parameter ukuran burst yang mirip dengan CBS, yang didefinisikan secara berkesinambungan dengan PIR. 2.1.3.

Traffic Metering

Ada dua macam traffic metering dan mekanisme pewarnaan paket, yaitu : 1. Single Rate Three Color Marker (srTCM) 2. Two Rate Three Color Marker (trTCM)

2.1.4.

Manajemen Antrian Aktif

Tanpa adanya Manajemen Antrian Aktif atau Active Queue Management (AQM) pada router, router menggunakan mekanisme yang disebut sebagai metode tail drop. Metode ini merupakan teknik manajemen antrian yang bersifat pasif, yaitu paket yang melimpah dibuang secara otomatis saat antrian benar-benar penuh. Keuntungan utama dari metode ini adalah kesederhanaannya. Akan tetapi metode tail drop dapat berujung pada fenomena yang disebut sebagai sinkronisasi global TCP (Braithwaite, 2006). Sinkronisasi global TCP terjadi dalam proses sebagai berikut. Ketika host pengirim TCP menerima sebuah acknowledgement negative (NAK) yang berarti ada paket TCP yang hilang saat melewati jaringan, host tersebut berasumsi bahwa hilangnya paket disebabkan terjadinya kongesti pada jaringan. Untuk membantu mengurangi aliran trafik yang masuk ke dalam jaringan, TCP secara otomatis mengurangi laju pengiriman paket. Pada metode tail drop, saat buffer penuh, semua paket yang datang menuju buffer seluruhnya dijatuhkan. Bila paket ini merupakan paket TCP, semua aliran

TCP yang mengalami kehilangan paket akan memelankan laju pengiriman secara simultan dan kembali mengulangi transmisi pada waktu yang hampir bersamaan. Karena semua aliran TCP yang terpengaruh dengan keadaan tersebut bereaksi dalam perilaku yang sinkron, maka kondisi kongesti pada jaringan akan berosilasi antara kondisi kongesti penuh (saat semua aliran TCP mengirim paket dengan laju penuh) dan tanpa kongesti (semua aliran TCP memelankan laju pengiriman paket). Fenomena ini disebut sebagai sinkronisasi global TCP dan menyebabkan utilisasi resource jaringan yang tidak efisien. Manajemen antrian aktif adalah mekanisme pengendalian kongesti yang bertugas untuk mencegah terjadinya sinkronisasi TCP. Ide utama dari AQM adalah untuk mengantisipasi terjadinya kongesti dan mengambil tindakan untuk mencegah atau mengurangi efek dari kongesti. Metode AQM yang biasa dan penulis gunakan adalah Random Early Detection (RED).

2.1.5.

Penjadwalan Paket

Penjadwalan paket (packet scheduling) digunakan untuk menjadwalkan paket pada antrian sehingga kapasitas jaringan pada port keluaran dapat terdistribusi merata pada semua kelas trafik yang memasuki jaringan (Welzl, 2005). Penjadwalan paket dapat dikatakan sebagai inti dari mekanisme QoS. 1. First-In-First-Out First-In-First-Out (FIFO) merupakan disiplin antrian default yang digunakan bila tidak ada algoritma penjadwalan paket lain yang digunakan. Pada FIFO, paket diantrikan pada sebuah jalur antrian dan dilayani sesuai

urutan memasuki antrian tersebut. Karena paket yang datang pertama kali adalah juga paket yang dilayani pertama kali, maka antrian FIFO juga sering disebut sebagai antrian First-Come-First-Served (FCFS). Keuntungan utama dari dari mekanisme FIFO ini adalah kesederhanaannya. FIFO hanya membutuhkan sebuah buffer, yang dapat menyimpan paket yang datang dan mengirimkannya sesuai urutan kedatangannya. Pada router berbasis perangkat lunak, hal ini akan meringankan beban kerja router. FIFO memperlakukan semua paket sederajat sehingga cocok digunakan untuk jaringan best effort. Masalah utama yang dihadapi FIFO adalah FIFO tidak dapat membedakan (atau hanya memiliki kemampuan yang sangat terbatas untuk membedakan) kelas trafik. Karena ketiadaan perbedaan kelas ini, semua aliran trafik akan mengalami perlakuan yang sama. Akan tetapi pada saat terjadi kongesti, FIFO memiliki kecenderungan yang berbeda terhadap paket TCP dan UDP. FIFO cenderung mendahulukan trafik UDP karena protokol TCP akan menurunkan transmisinya saat terjadi kongesti.

2. Priority Queuing FIFO menempatkan setiap paket pada sebuah antrian tanpa memperhatikan perbedaan antar kelas trafik. Cara yang sederhana untuk menciptakan perbedaan kelas trafik adalah dengan menggunakan Priority Queuing (PQ). Pada PQ, antrian dibagi sebanyak N antrian, dengan urutan prioritas 1 sampai dengan N. Urutan pelayanan paket bergantung dari urutan prioritas dan keberadaan paket pada antrian dengan prioritas lebih tinggi.

Misal terdapat sejumlah antrian dari antrian 1 sampai antrian j. Bila pada saat paket yang berada di antrian j mendapat giliran dilayani, datang paket pada antrian dengan prioritas lebih tinggi, misalnya antrian (j-3), maka paket yang berada pada antrian (j-3) akan dilayani terlebih dahulu. Seperti FIFO, keuntungan utama dari PQ adalah kesederhanaan: PQ menyediakan jalan mudah untuk menciptakan perbedaan kelas trafik. Masalah utama dari PQ adalah bila tidak dikonfigurasi secara benar, PQ dapat menyebabkan berhentinya layanan pada antrian prioritas bawah. Bila pada antrian prioritas atas laju layanan lebih kecil dari laju kedatangan paket, maka paket pada antrian tidak akan berhenti dilayani. Akibatnya, paket pada antrian prioritas di bawahnya tidak akan mendapat kesempatan untuk dilayani. Karena kemungkinan terjadinya hal tersebut, maka penggunaan PQ perlu dilakukan secara hati- hati. PQ lebih cocok digunakan saat trafik prioritas tinggi merupakan sebagian kecil dari keseluruhan trafik di jaringan. Misal terdapat sebagian kecil trafik yang sangat penting dan harus diproses secepat mungkin. Cara paling sederhana untuk menangani trafik tersebut adalah membuat prioritas tertinggi untuk trafik tersebut. Karena trafik tersebut hanya sebagian kecil dari keseluruhan trafik, efeknya terhadap trafik lainnya akan minimal.PQ merupakan antrian yang paling tepat diterapkan untuk trafik real time, seperti video dan VoIP. Trafik tersebut biasanya menggunakan trafik UDP. Cara lain menangani keterbatasan kapasitas jaringan pada antrian prioritas rendah adalah membatasi laju layanan pada prioritas tinggi. Misal pada

prioritas pertama laju layanan dibatasi 10% dari kapasitas jaringan. Artinya prioritas antrian tertinggi hanya akan dilayani secara PQ bila konsumsi kapasitas jaringan pada antrian tersebut berada di bawah batas 10 %. 3. Fair Queuing. Cara lain memberikan pembedaan kelas trafik adalah Fair Queuing (FQ). Pada FQ, paket datang diklasifikasikan kedalam N antrian, Setiap antrian diberikan alokasi kapasitas jaringan sebesar 1/N total kapasitas jaringan. Setiap antrian dilayani secara berurutan (round robin) dengan melewati antrian yang kosong. Pada setiap gilirannya, satu paket dikeluarkan dari antrian. FQ sangat sederhana, dan tidak membutuhkan mekanisme alokasi kapasitas jaringan secara khusus. Bila ditambahkan sebuah kelas antrian baru ke dalam N buah antrian, kapasitas jaringan tiap antrian otomatis diubah menjadi sebesar 1/(N+1) untuk tiap antrian. FQ memiliki dua buah persoalan utama. Pertama, karena kapasitas jaringan keluaran dibagi secara merata ke dalam N antrian, bila tiap kelas memiliki kebutuhan kapasitas jaringan yang berbeda FQ tidak akan mendistribusikan kebutuhan kapasitas jaringan sesuai kebutuhannya. Kedua, karena pada setiap giliran layanan paket yang dikeluarkan adalah satu buah, tanpa bergantung pada ukuran paket, maka distribusi kapasitas jaringan antar antrian yang sesungguhnya tidak akan sama besar. Antrian yang memiliki paket dengan ukuran lebih besar akan mendapat bagian kapasitas jaringan yang lebih besar dari 1/N total kapasitas jaringan.

4. Class-Based WFQ Class Based (CB)-WFQ mirip dengan WRR yang telah dijelaskan sebelumnya. Pada CB-WFQ, aliran trafik dibagi ke dalam kelas-kelas, tetapi dengan pembagian kapasitas jaringan yang bergantung dari kebutuhan masing-masing kelas, dengan total kapasitas jaringan seluruh kelas adalah 100% kapasitas jaringan keluaran. Perbedaannya adalah, pada WRR, aliran trafik pada masing- masing kelasnya dibagi berdasarkan FQ, sedangkan pada CB-WFQ aliran trafik pada masing-masing kelas dibagi berdasarkan WFQ.

5. Hierarchy Token Bucket Hierarchy Token Bucket (HTB) merupakan cara untuk mengaplikasikan CB-WFQ pada router berbasis linux menggunakan traffic controller. HTB menjamin jumlah layanan yang diterima sebuah kelas trafik paling kecil sesuai dengan jumlah yang dibutuhkan dan diberikan kepadanya. Apabila sebuah kelas menggunakan kapasitas jaringan lebih kecil dari yang diberikan kepadanya, sisa kapasitas jaringan yang tidak digunakan didistribusikan ke kelas lainnya. Trafik VoIP diberikan bagian sebesar 100 kbps. Akan tetapi bila trafik VoIp yang masuk besarnya lebih kecil dari 100 kbps, sisa kapasitas jaringan akan diberikan kepada trafik lainnya, sehingga total trafik yang memakai link utama akan tetap 128 kbps.

2.1.6.

Traffic Shaping

Traffic shaping digunakan untuk mengatur laju aliran trafik yang datang untuk membentuk laju trafik sedemikian rupa agar laju trafik keluaran bersifat lebih mulus. Bila laju trafik yang datang bersifat sangat acak (bursty) maka perlu ditempatkan dulu pada sebuah buffer sehingga laju keluaran lebih konstan(Li, 1999). Dengan cara ini, traffic shaping membuat aliran trafik lebih sesuai dengan profil trafik yang didefinisikan sebelumnya, misalnya SLA. Analogi dari traffic shaping ini adalah, misalnya, pada pintu masuk jalan tol. Pengemudi diminta berhenti sejenak pada gerbang masuk jalan tol. Pengemudi kemudian dipersilahkan memasuki jalan tol dengan kecepatan tertentu, misalnya 60 km/jam. Dengan cara ini mobil akan memasuki jalan tol pada kecepatan yang cenderung sama yaitu 60 km/jam walaupun memasuki jalan tol pada kecepatan yang bervariasi. Akan tetapi pemberhentian trafik sementara akan menyebabkan terjadinya delay tambahan pada paket selama di buffer. Ada dua tipe traffic shaper, yaitu traffic shaper murni dan token bucket traffic shaper. Token bucket traffic shaper sering juga disebut sebagai leaky bucket traffic shaper. 1. Traffic Shaper Murni Pada traffic shaper murni, paket yang datang ditempatkan pada sebuah buffer, atau tempat penampungan sementara, dengan kedalaman d dan dikeluarkan

dalam

laju

konstan

r.

Traffic

shaper

murni

tidak

memperkenankan terjadinya lonjakan laju pada aliran keluaran. Biasanya, laju keluaran traffic shaper, r, akan lebih kecil dari laju jalur yang sebenarnya, C.

Dengan traffic shaper murni, laju keluaran r akan menentukan batas atas dari laju trafik keluaran karena lonjakan laju trafik (burst) tidak diperbolehkan. Bila ukuran burst melebihi kedalaman d, maka paket yang meluap berlebih akan dibuang.

2. Token Bucket Traffic Shaper Token bucket traffic shaper menggunakan sistem keranjang, yang hamper serupa dengan keranjang C yang digunakan pada srTCM dan trTCM. Token diletakkan pada keranjang token dengan laju token konstan sebesar r. Laju token r ini mirip dengan CIR. Keranjang token memiliki kedalaman d yang mirip dengan kedalaman keranjang C, yaitu CBS. Bila keranjang token telah penuh, tidak ada lagi token yang ditambahkan ke dalam keranjang. Setiap token membolehkan buffer mengeluarkan satu byte paket. Bila tidak ada paket yang tersisa pada buffer, keranjang token akan tertutup dan tidak ada token yang dikeluarkan. Saat ada paket yang memasuki buffer, token dikeluarkan dalam laju jalur C, dan paket dikeluarkan dalam “lonjakanâ€

laju. Akan tetapi bila keranjang berada dalam keadaan

kosong, paket yang berada dalam buffer harus menunggu sampai ada token yang memasuki keranjang. Hasil operasi ini adalah paket diperbolehkan keluar dalam lonjakan laju C. Ukuran lonjakan atau burst dibatasi hanya sampai kedalaman keranjang, yaitu d. Karena token diletakkan pada keranjang dengan laju r, maka laju rata-rata dalam dari paket yang keluar buffer dalam jangka panjang akan sama dengan

r. Karenanya, token bucket traffic shaper memiliki cara kerja yang sama dengan keranjang C pada srTCM dan trTCM kecuali keranjang token diaplikasikan pada port keluaran sementara keranjang C pada port masukan.

2.2.

Differentiated Services Salah satu solusi untuk mengaplikasikan QoS adalah menerapkan arsitektur

Differentiated Service (DiffServ) pada jaringan. DiffServ bekerja dengan prinsip pengklasifikasian trafik. Edge Router akan mengklasifikasikan paket datang berdasarkan peraturan tertentu, dan memberikan tanda yang menandai paket dengan code point yang menentukan level layanan yang akan diterima paket tersebut. Core Router akan memberikan perlakuan berbeda terhad ap paket yang datang berdasarkan code point dan isi dari tabel Per-Hop Behaviour (PHB) (Li, 1999).

2.2.1.

Arsitektur DiffServ Arsitektur DiffServ berdasarkan sebuah model sederhana dimana trafik

yang memasuki sebuah jaringan diklasifikasikan dan dapat dikondisikan pada tepi jaringan dan ditempatkan pada beberapa Behavior Aggregate (BA) yang berbeda. Setiap BA diidentifikasikan oleh sebuah Differentiated Service Code Point (DSCP), sehingga BA dapat didefinisikan sebagai kumpulan paket dengan DSCP yang sama yang melewati sebuah link pada arah tertentu. Pada inti jaringan, paket diteruskan bergantung kepada PHB yang ditentukan oleh DSCP (Blake, 1998). Sebuah domain DiffServ terdiri atas DiffServ boundary nodes dan DiffServ interior nodes. DiffServ boundary nodes menghubungkan sebuah domain

DiffServ ke domain lainnya, baik domain DiffServ maupun domain non-DiffServ, sementara DiffServ interior nodes hanya menghubungkan node-node yang berada pada sebuah domain DiffServ yang sama. Baik DiffServ boundary nodes maupun DiffServ interior nodes harus mampu menjalankan PHB yang tepat kepada sebuah paket berdasarkan DSCP yang dimilikinya. Sebagai tambahan, DiffServ boundary nodes mungkin diperlukan untuk melakukan fungsi pengondisian trafik yang didefinisikan oleh SLA antara domain DiffServ tersebut dan domain lain yang berpasangan dengan domain tersebut. SLA mungkin mengandung parameter-parameter seperti paket hilang maksimum, waktu tunda paket maksimum, dll. SLA menjelaskan aturan-aturan dan kondisi-kondisi dari layanan yang ditawarkan. DiffServ interior nodes mungkin dibutuhkan untuk menjalankan fungsi pengondisian trafik yang terbatas seperti penulisan ulang DSCP. Interior nodes hanya perlu mengetahui bagaimana menangani beberapa kelas-kelas trafik daripada menyimpan pengetahuan tentang ratusan dari aliran trafik individual. Di sini, informasi per aliran dibuang di dalam domain. Mereka tidak mengimplementasikan fungsi pengondisian trafik. Secara umum, interior nodes melakukan tugas yang lebih sederhana dari boundary nodes. Interior node yang mengimplementasikan klasifikasi dan fungsi pengondisian trafik yang lebih kompleks akan memiliki karakterisitik yang sama dengan DiffServ boundary nodes. Diffserv boundary nodes bertindak sebagai DiffServ ingress node dan DiffServ egress node untuk arah trafik yang berbeda. Trafik memasuki sebuah domain DiffServ melalui DiffServ ingress node dan keluar melalui DiffServ egress

node. Sebuah DiffServ ingress node bertanggung jawab dalam memastikan trafik yang memasuki domain DiffServ memenuhi SLA antara domain tersebut dan domain lain yang terhubung dengan ingress node. Diffserv egress node dapat melakukan fungsi pengondisian trafik pada trafik yang diteruskan ke domain yang terhubung secara langsung, bergantung pada SLA antara kedua domain. Router yang bekerja sebagai DiffServ boundary nodes umumnya disebut sebagai edge router, sedangkan router yang bekerja sebagai interior nodes biasanya disebut sebagai core router.

2.2.2.

Traffic Conditioner Sebuah traffic conditioner terdiri atas elemen-elemen berikut: meter,

marker, shaper, dan dropper. Aliran trafik akan diseleksi oleh classifier, yang akan meneruskannya ke bagian traffic conditioner. Meter digunakan (apabila diperlukan) untuk membandingkan aliran trafik terhadap suatu profil trafik. Hasil keluaran sebuah meter dapat mempengaruhi proses marking, dropping, atau shaping terhadap paket tersebut (Blake, 1998). Sebuah traffic conditioner tidak perlu selalu terdiri atas empat elemen yang disebutkan sebelumnya. Contohnya, pada kasus dimana tidak ada profil trafik yang mempengaruhi, paket cukup melewati classifier dan marker saja. Traffic conditioner biasanya terletak di DiffServ ingress dan egress node, tetapi dapat juga diletakkan pada interior node di dalam sebuah domain DiffServ, ataupun di dalam domain non-DiffServ. 1. Meter

Traffic meter membandingkan properti sementara dari aliran trafik yang diseleksi oleh classifier terhadap suatu profil trafik yang diberikan TCA. Suatu meter meneruskan informasi ke fungsi pengondisian lainnya untuk menjalankan proses yang sesuai, baik untuk paket yang memenuhi profil maupun tidak memenuhi profil.

2. Marker Packet marker mengisi field DSCP pada paket dengan nilai tertentu, untuk menggabungkan paket tersebut ke BA yang sesuai. Marker dapat diatur untuk menandai setiap paket yang memasukinya ke dalam satu codepoint tertentu, atau diatur untuk menandai paket dengan suatu set codepoint yang mewakili PHB tertentu, bergantung kepada kondisi meter. Marker juga dapat melakukan proses remarking, yaitu mengubah nilai codepoint dari suatu paket.

3. Shaper Shaper menahan sebagian atau seluruh trafik pada suatu aliran trafik untuk membentuk aliran trafik yang sesuai dengan profil trafik. Proses yang dilakukan oleh shaper disebut shaping. Shaper biasanya memiliki buffer yang berukuran terbatas, sehingga paket dapat dibuang bila tidak tersedia buffer yang cukup untuk menampung trafik yang akan ditahan.

4. Dropper

Dropper bekerja untuk membuang sebagian atau seluruh paket pada suatu aliran trafik untuk membentuk aliran trafik yang sesuai dengan profil trafik yang telah ditentukan. Proses tersebut disebut policing. Dropper dapat diibaratkan sebagai sebuah shaper yang memiliki ukuran buffer nol atau sangat kecil.

2.3.

Linux Traffic Control

Implementasi DIffServ pada linux menggunakan traffic control yang berfungsi untuk pengalokasian dari suatu bandwidth untuk mendukung kebutuhan atau keperluan aplikasi atau suatu layanan jaringan. Traffic control adalah kumpulan aturan dan mekanisme yang mengizinkan sebuah jaringan untuk memenuhi kualitas layanan secara efisien. Beberapa mekanisme yang digunakan seperti shaping, scheduling, monitoring, policing, signaling, pricing, admission control, congestion control dan flow control dan lainnya. Selain itu traffic control dapat diartikan sebagai kumpulan fungsi dari sebuah jaringan untuk mencegah kondisi padat, yang membentuk mengatur aliran data pada titik tertentu dalam system (Brown, 2006). Traffic control adalah sekumpulan sistem dan mekanisme antrian terhadap paket data yang diterima maupun dikirim pada sebuah router. Termasuk untuk memutuskan untuk menerima paket data pada kecepatan tertentu pada sebuah interface dan memutuskan untuk mengirim paket data dengan urutan maupun kecepatan tertentu pada output dari interface (Hubert, 2004).

Pada umumnya traffic control terdiri atas antrian tunggal yang mengumpulkan paket data yang masuk dan mendequeue seketika paket data yang diterima. Metode antrian ini biasa disebut dengan FIFO.

2.3.1.

Metode Traffic Control pada Kernel Linux Terdapat beberapa metode yang digunakan oleh traffic control pada

interface (Hubert , 2004), yaitu : 1. Shaping Shapers menahan paket untuk mencapai kecepatan yang diinginkan. shaping adalah mekanisme untuk menahan paket data sebelum transimisi pada output queue untuk mencapai outpu kecepatan yang diinginkan. Metode ini adalah yang biasa digunakan user untuk solusi pengendalian bandiwdth. Penundaan paket sebagai bagian dari solusi traffic control membuat tiap mekanisme shaping kedalam bentuk mekanisme untuk menjaga paket tidak hilang. Shaper mencoba untuk membatasi atau membentuk traffic untuk mencapai tanpa melampaui kecepatan yang dikonfigurasi (biasanya diukur dalam paket per detik atau bits/bytes per detik). Shaper dapat melancarkan bursty traffic.Salah satu keuntungan dari shaping bandwidth adalah kemampuan untuk mengendalikan latency dari paket data. Mekanisme dasar untuk shaping ke kecepatan yang diinginkan biasanya mekanisme token dan bucket. 2. Scheduling

Scheduler mengatur paket untuk output. scheduling adalah mekanisme untuk pengaturan paket di antara input dan output dari sebagian besar antrian. scheduler yang biasanya digunakan adalah FIFO scheduler. Jika melihat dari sudut pandang yang lebih umum, mekanisme traffic control apapun yang berada pada output queue dapat diartikan sebagai scheduler, karena paket diurutkan untuk output. Mekanisme scheduling umum lainnya mencoba untuk beradaptasi dengan kondisi jaringan. Fair queuing algorithm mencoba untuk mencegah suatu client atau aliran data yang mendominasi penggunaan jaringan. Algoritma Round Robin memberikan tiap aliran data ataupun client gilirannya untuk dequeue paket. 3. Classifying Classifier mengurutkan atau memisahkan traffic ke dalam beberapa queue. Classifying adalah mekanisme untuk menentukan paket mana yang dipisah untuk diperlakukan berbeda, dan dimungkinkan dengan output queue yang berbeda. Selama proses penerimaan, routing dan transmisi paket data, peralatan jaringan dapat mengklasifikasikan paket data tersebut dengan berbagai cara. Klasifikasi termasuk di dalamnya marking packet yang biasanya terjadi pada ruang lingkup dari jaringan yang berada pada kendali administrasi tunggal atau dapat terjadi pada tiap-tiap hop. Linux model mengizinkan paket data untuk melewati beberapa macam classifier dan untuk diteruskan ke policer. 4. Policing

Policing menghitung dan membatasi traffic dalam queue tertentu. Policing sebagai bagian dari elemen traffic control adalah mekanisme sederhana yang menentukan paket apa saja yang dibatasi. Policing biasanya digunakan pada perbatasan jaringan untuk memastikan bahwa peer tidak mengkonsumsi lebih dari bandwidth yang sebelumnya dialokasikan. Policer akan menerima traffic pada kecepatan tertentu dan melakukan sebuah aksi pada traffic yang melewati kecepatan ini. Solusi yang lebih kasar adalah dengan membuang paket, meskipun paket data dapat diklasifikasikan ulang daripada dibuang.

Policer akan mencek traffic

terhadap kecepatan yang akan masuk ke dalam queue. Jika paket akan masuk ke dalam queue dengan nilai kecepatan dibawah dari semestinya, lakukan satu hal( izinkan enqueuing). Jika suatu paket melebihi kecepatan yang seharusnya, lakukan hal lain. Meskipun policer menggunakan mekanisme token bucket, policer tidak mampu menunda paket data seperti halnya mekanisme shaping. 5. Dropping Dropping membuang keseluruhan paket data, aliran data atau klasifikasi. Dropping sebuah paket data adalah mekanisme untuk menentukan paket apa yang dibuang. 6. Marking Marking adalah mekanisme untuk menandai paket data. Digunakan untuk memilih paket yang nantinya akan diproses oleh qdisc.

2.3.2.

Queuing Discipline Antrian menentukan cara mengirimkan data. Penting untuk diingat bahwa

kita hanya bisa menentukan data yang kita kirim (Hubert, 2004). Cara kerja dari internet membuat kita tidak memiliki kemampuan untuk mengendalikan apa yang orang lain kirimkan. Setiap output interface membutuhkan scheduler dan secara default adalah FIFO. Secara sederhana qdisc adalah scheduler. Qdisc lain yang tersedia pada Linux akan mengatur kembali paket data yang memasuki antrian tergantung pada aturan scheduler tersebut. Qdisc adalah bagian penting dari Linux traffic control dan biasa disebut queueing discipline. Terdapat banyak qeueuing discipline pada kernel linux, namun pada pembahasan kali ini hanya 2 yang kita gunakan. Random Early Detection, untuk menanggulangi congestion. Hierarchical Token Bucket, untuk membagi bandwidth sesuai dengan kebutuhan, misal berdasarkan ip ataupun port yang diinginkan. 1. Random Early Detection Bagian ini menjelaskan algoritma RED. RED menghitung average queue size menggunakan low-pass filter dengan exponential weighted moving average. Average queue size dibandingkan dengan 2 thresholds, minimum threshold dan maximum threshold. Ketika average queue size kurang dari minimum threshold tak ada paket yang di mark. Ketika average queue size lebih besar dari maximum threshold, setiap paket yang datang di mark. Jika paket yang dimark dibuang atau jika semua node sumber bekerja sama dapat dipastikan bahwa average queue size tidak secara signifikan melampaui maximum threshold (Hubert, 2004).

Ketika average queue size berada di antara minimum dan maximum threshold, tiap paket yang datang di mark dengan probabilitas pa, di mana pa adalah fungsi dari average queue size avg. Tiap kali paket ditandai, probabilitas dari paket yang di mark dari suatu koneksi adalah berbanding lurus terhadap pembagian koneksi dari bandwidth pada gateway. Algoritma RED adalah sebagai berikut :

for each packet arrival calculate the average queue size avg if minth <= avg < maxth calculate probability pa with probability pa: mark the arriving packet else if maxth <= avg mark the arriving packet

Berbeda dengan tail-drop algorithm yang membuang paket ketika buffer penuh, RED algorithm membuang paket yang datang dengan metode probabilitas. Probabilitas

terhadap

pembuangan

paket

akan

meningkat

seiring

dengan

perkembangan dari pergitungan average queue size. Sebagai catatan RED merespon terhadap panjang queue per rata-rata waktu bukan pada saat itu. Untuk itu jika queue telah kosong pada waktu sebelumnya. RED tidak akan berusaha untuk membuang paket(kecuali melampaui queue tentunya). Di lain pihak, jika queue sebelumnya penuh, paket yang baru datang akan memiliki kemungkinan besar untuk dibuang.

RED algorithm terdiri atas 2 bagian utama, yaitu : menghitung average queue size dan memutuskan untuk membuang atau tidak paket yang datang.

A. Penghitungan

Average

Queue

Size

RED menghitung average queue size menggunakan low-pass filter. Untuk itu ukuran queue yang berasal dari traffic yang melonjak atau dari kepadatan tetap tidak akan ditentukan oleh hal tersebut. Low-pass filter yang digunakan adalah exponential weighted moving average(EWMA) dengan formula berikut :

avg = (1−wq)avg+wq.q keterangan : avg = ukuran rata-rata paket yang masuk. wq = bobot antrian. q = ukuran antrian actual.

B. Keputusan pembuangan paket Pada tahapan ini, RED menentukan untuk membuang atau tidak paket yang datang.

Terdapat

2

parameter

RED,

minth(minimum

threshold)

dan

maxth(maximum threshold). Ukuran paket rata-rata yang berada di bawah nilai minth tidak akan dibuang, sedangkan ketika berada di atas nilai maxth paket akan langsung dibuang. Ketika berada di antara kedua nilai tersebut, paket akan dibuang dengan probabilitas yang beragam dari 0 sampai nilai maksimum

probabilitasnya(maxp). Berikut formula penghitungan probabilitas untuk ukuran paket rata-rata yang berada di antara kedua nilai tersebut :

pb = maxp(avg - minth)/(maxth - minth) pa = pb/(1−count . pb)

keterangan : pa = nilai kemungkinan suatu paket. maxp = nilai maksimum probabilitas. avg = nilai ukuran rata-rata paket. maxth = nilai maksimal rata-rata paket. minth = nilai minimum rata-rata paket. count = jumlah paket data yang masuk.

2. Hierarchical Token Bucket HTB adalah salah satu queueing discipline berbasis class(classful). HTB berbasis atas class hierarkis yang terdiri atas tiga tipe, yaitu : root, inner dan leaf. Root adalah induk dari semua class dan semua lalu lintas data akan melewatinya. Inner class memiliki induk class, dapat berupa root ataupun inner class lain, dan memiliki class turunan. Leaf adalah kelas akhir atau class yang hanya memiliki class induk tanpa class turunan (Devera, 2002). Leaf adalah class yang menampung paket data yang ada di queue.

HTB memastikan bahwa jumlah layanan yang disediakan untuk tiap class kurang atau sama dengan jumlah yang telah ditetapkan. Ketika sebuah class memiliki permintaan yang kurang dari jumlah yang ditetapkan, sisa bandwidth akan didistribusikan ke class yang lain. HTB scheduler Terdapat pohon class pada HTB scheduler. Terdapat pula list global yang disebut self feed, yang terdapat pada sebelah kanan. Self feed terdiri atas self slot. Terdapat satu slot per priority per level. Tiap self slot memiliki beberapa class. Semua class pada slot memiliki level dan prioritas seperti slot. Tiap inner(non-leaf) class memiliki inner feed slots. Terdapat satu inner feed slot per priority dan per inner class. Terdapat Self slot yang memiliki beberapa class dengan prioritas yang sama seperti slot dan class pasti pemilik dari slot children. Feed mengindikasikan prioritas dari class. Dapat dilihat pada bagan di bawah.

Gambar 2.1 Prioritas pengiriman paket (Devera, 2002)

Ketika leaf class ingin mengirimkan paket, HTB akan mencek prioritasnya. Paket data akan mulai dikirim dengan urutan prioritas paling tinggi dan level paling rendah. Semua akan dikirim sampai ke prioritas paling rendah dan level paling tinggi.

Gambar 2.2 Prioritas Paket (Devera, 2002) Jika dilihat pada bagan di atas, leaf2 akan dikirim terlebih dahulu disbanding leaf1. Karena leaf2 berada pada level yang lebih rendah, meskipun memiliki prioritas yang lebih rendah. Contoh Kasus Pada gambar 2.3, tidak ada paket yang datang. Maka tiap leaf tidak melakukan apa-apa.

Gambar 2.3 Diagram HTB(Devera, 2002) Pada gambar 2, terdapat paket yang datang pada class C dan D dan berada di bawah min-rate. Sehingga leaf berwarna hijau. Tiap leaf diberikan prioritasnya masing-masing(biru = rendah, merah = tinggi). Karena D memiliki prioritas yang lebih tinggi, maka D akan mengirimkan paket data. Kemudian diikuti oleh kelas C yang memiliki prioritas lebih rendah.

Gambar 2.4 Diagram HTB paket datang(Devera, 2002)

Kali ini paket data pada D melebihi min-rate yang seharusnya, sehingga D menjadi warna kuning. Untuk itu D harus meminjam ke class di atasnya, yaitu B. D akan melepaskan diri dari self feed dan masuk ke inner feed B dan otomatis B akan masuk ke self feed yang sesuai. Keadaan ini akan mengakibatkan class C akan didequeue paketnya terlebih dahulu dibanding B, karena memiliki level terendah.

Gambar 2.5 Diagram HTB node D overload. (Devera, 2002) Kondisi sekarang C melampaui ceil dan tidak bisa pinjam ke A. D melampaui rate dan meminjam ke B. Di B melampaui rate dan meminjam ke A. di A tidak melampui rate dan berstatus hijau. D dapat mengirimkan paket data. Tapi C harus menunggu sampai C normal.

Gambar 2.6 Diagram HTB node C overload(Devera, 2002) Sekarang C berada pada status kuning yang artinya melampaui rate dari C. C harus meminjam dari A dan sekarang berada di level 2. Sama halnya dengan D dan E, harus meminjam ke B. Pada B melampaui rate, dan harus meminjam ke A. A tidak melampaui rate. Karena semua berada pada level 2 di posisi class A. Paket data yang akan dikirim adalah yang memiliki prioritas paling tinggi. Dan yang memiliki prioritas paling tinggi akan menggunakan algoritma round robin untuk dequeuenya.

Gambar 2.7 Diagram HTB paket A mengirim(Devera, 2002)

2.4.

TC tools Pada paket iproute2, tc adalah satu-satunya yang dapat digunakan untuk traffic

control. Karena tc secara langsung berinteraksi dengan kernel untuk pembuatan, penghapusan dan modifikasi terhadap struktur traffic control. TC tool menampilkan semua konfigurasi terhadap struktur kernel untuk mendukung traffic control. Utilitas ini menggunakan argument awal salah satu dari tiga komponen linux traffic control yaitu : qdisc, class dan filter (Hubert, 2004). Syntax dasar penggunaan TC :

Penggunaan : tc [ OPTIONS ] OBJECT { COMMAND | help } where OBJECT := { qdisc | class | filter } OPTIONS := { −s[tatistics] | −d[etails] | −r[aw] }

2.4.1. tc qdisc

Gambar 2.8 tc qdisc (Hubert, 2004) Keterangan : 1. Menambahkan queueing discipline. Dapat dirubah menjadi del untuk menghapus qdisc. 2. Device yang akan ditambahkan qdisc. 3. Berarti egress atau output pada interface. Kata root wajib digunakan, meskipun pada qdisc lain yang memiliki fungsi terbatas dapat menambahkan qdisc pada ingress di device yang sama. 4. Handle angka spesifik dari user dengan bentuk major:minor. Angka minor untuk yang memiliki qdisc akan selalu nol(0). Biasa disingkat dengan syntax “1:”, angka minor akan otomatis nol(0). 5. Queueing yang dipakai, pada contoh ini adalah HTB. Setelah ini adalah parameter khusus dari qdisc yang dipakai. Contoh ini tidak menyertakan itu.

2.4.2. tc class

Gambar 2.9 tc class (Hubert, 2004) Keterangan : 1. Menambahkan class. Bisa diubah menjadi del untuk menghapus class. 2. Device yang ingin ditambahkan class baru. 3. Spesifikasi dari handle induk(biasanya qdisc) yang ingin kita tambahkan class baru. 4. Ini adalah handle unik dengan pola major:minor untuk identifikasi class. Angka minor harus tidak boleh nol(0). 5. qdisc yang akan digunakan pada class ini. 6. nilai rate yang nantinya dapat di pinjam oleh class/qdisc turunan. 7. nilai ceil(tepi) yang dipakai sebagai batasan rate yang dapat dipinjam.

2.4.3. tc filter

Gambar 2.10 tc filter (Hubert, 2004) Keterangan : 1. Menambahkan filter, dapat juga diganti dengan del untuk membuang filter. 2. device yang ingin ditambahkan filter. 3. parent handle yang ingin kita tambahkan filter. 4. filter berdasarkan protocol tertentu. Contoh ini dalah ip. 5. parameter prio untuk filter didahulukan dibanding yang lain. 6. classifier yang digunakan TC untuk filter. 7. parameter untuk classifier. Pada kasus ini paket dengan port 22 akan dipilih. 8. sama dengan baris 7, mencocokan dengan protocol tertentu. 9. paket data yang terpilih nantinya akan dikirim ke class pada parameter ini. 10. policer dan opsional untuk tc. 11. policer akan melakukan satu aksi ketika melampaui kecepatan ini dan parameter aksi berada pada baris setelah ini. 12. sama seperti konsep burst pada HTB.

13. minimum policed unit. Untul menghitung semua paket yang masuk gunakan mpu 0. 14. Aksi yang dilakukan oleh policer.

2.4.4. TC untuk penggunaan RED Asumsikan kondisi jaringan dengan bandwidth 128kbps dan latency 500msec. Berikut perhitungannya : Bandwidth = 128kbps = 16000 Byte / sec Latency = 500msec = 0.5 sec Max = Bandwidth * Latency = 16000 * 0.5 = 8000 Min = Max / 2 = 4000 Limit = 8 * max = 8 * 8000 = 64000 Burst = (2 * min + max) / (3 * avpkt) = (2 * 4000 + 8000) / (3 * 1000) = 5.33

#tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5.33 avpkt 1000 probability 0.02 bandwidth 128

2.4.5. TC untuk penggunaan HTB Misal kita ingin membatasi penggunaan bandwidth klien. Asumsikan kita memiliki bandwidth 2Mbit dan klien A dengan 128Kbit dan klien B dengan 512Kbit. Dan untuk klasifikasi port SSH = 64Kbit, TELNET = 4Kbit, POP3 = 32Kbit, SMTP = 32Kbit.

Gambar 2.11 contoh HTB tree (Hubert, 2004)

#tc qdisc add dev eth0 root handle 1:0 htb #tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2Mbit ceil 2Mbit #tc class add dev eth0 parent 1:1 classid 1:2 htb rate 128Kbit ceil 128Kbit #tc class add dev eth0 parent 1:1 classid 1:3 htb rate 512Kbit ceil 512Kbit #tc class add dev eth0 parent 1:2 classid 1:21 htb rate 64Kbit ceil 64Kbit #tc class add dev eth0 parent 1:2 classid 1:22 htb rate 4Kbit ceil 128Kbit #tc class add dev eth0 parent 1:3 classid 1:31 htb rate 32Kbit ceil 32Kbit #tc class add dev eth0 parent 1:3 classid 1:32 htb rate 32Kbit ceil 32Kbit

#tc qdisc add dev eth0 parent 1:21 handle 210: pfifo limit 10 #tc qdisc add dev eth0 parent 1:22 handle 220: pfifo limit 10 #tc qdisc add dev eth0 parent 1:31 handle 310: pfifo limit 10 #tc qdisc add dev eth0 parent 1:32 handle 320: pfifo limit 10 #tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.1/24 match ip sport 22 0xff flowid 1:21 #tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.1/24 match ip sport 23 0xff flowid 1:22 #tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.2/24 match ip sport 25 0xff flowid 1:31 #tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.2/24 match ip sport 110 0xff flowid 1:32

2.5.

Python Python adalah salah satu bahasa pemrograman script. Karena script sehingga

bersifat interpreted tapi python memungkinkan untuk dicompile. Memiliki pendekatan Berorientasi Objek dan yang terpenting adalah terstruktur secara sintaks kodenya. Struktur sintaks akan diatur dengan indentasi tiap baris kodenya. Prinsip dasar dari python adalah kesederhanaan (http://docs.python.org/).

2.5.1. Hello World Setiap contoh yang ada dapat dicoba di linux, untuk mencoba di system operasi lain sesuaikan bagian shebang(#!). Buat file hello.py dan masukkan baris kode berikut :

#!/usr/bin/env python print “Hello World!”

Jalankan file tadi dengan menambahkan atribut execute dengan perintah :

$ chmod u+x hello.py

Jalankan file hello.py dengan perintah berikut :

$ ./hello.py Hello World!

Setelah dieksekusi akan tampil teks Hello World!. Karena bersifat interpreted, tidak perlu ada proses kompilasi sebelumnya.

2.5.2. Dasar Python 1. Literal

Literal adalah bilangan seperti 5, 5,2, 4e12, string seperti ‘ini adalah string’ atau “ini string juga.”. Literal dapat digunakan dan ditampung pada variable nantinya. 2. Bilangan Terdapat 4 tipe bilangan pada python, diantaranya : 1) Integer, 2, 4, 10, 1000, dll. 2) Long Integer, nilainya lebih besar dari integer. 3) Floating Point, 2,3, 1,0, dll. 4) Complex, (-5+4j) dan (2.3 - 4.6j). 3. String String pada python dapat ditandai dengan tanda petik satu, dua maupun tiga. ‘string dengan satu petik’ “string dengan dua petik” ‘’’ string dengan tiga petik dapat dibuat multi baris‘’’ 4. Variabel Untuk penamaan variable wajib didahului oleh huruf atau underscore ‘_’. Berikut contoh penamaan yang benar. nama _nama Nama Variabel akan langsung bisa digunakan ketika kita memberikan nilai ke dalamnya. Berikut contohnya :

nama = “deni” usia = 22

5. Indentasi Indentasi sangat penting pada python, karena python membaca indentasi dari kode program untuk menentukan alur dan blok dari tiap bagian kode. Kode berikut akan error bila dijalankan : x=5 y=3 z=4 print x

di bagian lain akan dipelajari tentang control program dan fungsi. Pada bagian itu indentasi akan sering digunakan. 2.5.3. Operator dan Ekspresi 1. Operator Berikut operator yang ada pada python : +

-

*

**

/

//

<<

>>

&

|

^

~

<

>

<=

>=

==

!=

%

<>

2. Ekspresi Penggunaan ekspresi pada python cukup sederhana, berikut contohnya :

length = 5 breadth = 2 area = length * breadth 3. Alur Kendali Terdapat beberapa pernyataan pada python untuk mengatur alur kendali program, diantaranya adalah if, while dan for..in. 1) If Pernyataaan if akan menguji kebenaran dari ekspresi, kemudian akan menjalankan blok yang diinginkan. Berikut contoh penggunaannya : x=0 if x < 1: print x elif x > 0: print “x lebih besar dari 0” else: print “error” 2) While Pernyataan ini akan mengulang blok yang sudah ditentukan selama ekspresi dalam while masih bernilai benar. Berikut contohnya: ulang = True while ulang: print “baris yang akan dijalankan selama masih bernilai true”

else: print “baris yang dijalankan ketika bernilai false” 3) For .. in Pada pernyataan ini, perulangan akan terjadi sebanyak N sesuai dengan jumlah sequence object yang digunakan. for i in range(1,5) print i

2.5.4. Fungsi Untuk membuat fungsi cukup menggunakan keyword def. Kemudian diikuti nama fungsi dan parameternya. Berikut contohnya : def Tambah(): print x + 1

Jika mengikuti konvensi dari python, minimal sebuah fungsi akan memiliki parameter self. Sehingga didapat fungsi berikut : def Tambah(self): print x Jika ingin menambah parameter lain, cukup dengan memisahkan dengan tanda koma(,). Sebagai contoh : def Tambah(self, x, y): print x + y

Sebuah fungsi dapat memiliki nilai kembalian / return value. Cukup dengan menggunakan keyword return. def Tambah(self, x, y): return x + y

2.5.5. Pemrograman Berorientasi Objek 1) Class Penggunaan class pada python hanya menggunakan keyword class. Berikut contohnya : class Manusia: def Bicara(self): print “berbicara” Untuk menginstansiasi objek dari class yang kita buat. Cukup dengan kode berikut : objManusia = Manusia() objManusia.Bicara()

2) Method Penggunaan dan pembuatan method pada class, sama dengan fungsi biasa. Perbedaan hanya terlihat pada cara memanggil method. Berikut contohnya : class Mobil: def Nama(self, nama):

self.nama = nama print self.nama objMobil = Mobil() objMobil.Nama(“Sedan”) Contoh di atas akan menghasilkan kata sedan. Terlihat pada definisi fungsi terdapat 2 parameter yaitu: self dan nama. Tapi untuk memanggil fungsi cukup melewatkan untuk variable setelah self. Karena self tidak dianggap sebagai parameter.

3) __init__

method

Pada python terdapat constructor method pada class. Disebut dengan __init__ method. Method ini akan dipanggil terlebih dahulu ketika objek dibuat dari kelas

tersebut.

Berikut

contoh

penggunaannya:

class Mobil: def __init__(self): print “mobil dibuat” t = Mobil() 4) Inheritance Untuk membuat turunan kelas pada python sangat mudah. Hanya menggunakan

tanda

(kelas

induk).

class Induk: def __init__(self): print “kelas induk”

Berikut

contohnya

:

class Turunan(Induk): def __init__(self): print “kelas turunan”

2.5.6. PyGTK PyGTK 2.0 adalah sekumpulan modul Python yang menyediakan antarmuka untuk GTK Python 2.x. Seluruh PyGTK dokumen mengacu pada versi 2.x PyGTK dan GTK, GTK merujuk pada versi 2.x GTK. Situs web utama untuk PyGTK adalah www.pygtk.org. Penulis utama PyGTK adalah James Henstridge, [email protected]. Python adalah sebuah bahasa pemrograman yang extensible, berorientasi obyek yang disediakan dengan kumpulan modul yang menyediakan akses ke sebagian besar operating system services, internet services (seperti HTML, XML, FTP, dll), grafis (termasuk OpenGL, TK, dll), fungsi penanganan string, layanan mail (IMAP, SMTP, POP3, dll), multimedia (audio, JPEG) dan layanan kriptografi. Selain itu ada banyak modul lain yang tersedia dari pihak ketiga yang menyediakan banyak layanan lainnya. GTK pada dasarnya adalah sebuah application programmers interface (API) berorientasi objek. Walaupun sepenuhnya ditulis dalam C, diimplementasikan dengan menggunakan gagasan kelas dan callback functions (pointer ke fungsi). Dengan menggunakan pygtk, pengguna python dapat dengan mudah menggunakan GTK sebagai GUI untuk program mereka. Hanya dengan menggunakan python yang memanggil GTK widgets yang diperlukan untuk program mereka.

2.5.7. Matplotlib Matplotlib adalah pustaka 2D plotting python yang menghasilkan diagram dalam berbagai format hardcopy dan lingkungan interaktif lintas platform. Matplotlib dapat digunakan dalam python scripts, python dan ipython shell (ala matlab atau mathematica), web application servers, dan 6 graphical user interface toolkits. Matplotlib mencoba untuk membuat hal yang mudah menjadi mudah dan yang sulit menjadi mungkin. Anda bisa generate plots, histograms, power spectra, bar charts, errorcharts, scatterplots, dan lain-lain, hanya dengan beberapa baris kode.

Gambar 2.12 contoh plot dengan matplotlib Sebagai contoh, untuk generate 10.000 gaussian angka acak dan membuat histogram berisi data dalam 100 bins, cukup dengan mengetikkan: >>> from pylab import randn, hist >>> x = randn(10000) >>> hist(x, 100)

Untuk power user, anda memiliki kendali penuh atas model garis, font properties, axes properties, dan lainnya, lewat object oriented interface atau sekumpulan fungsi yang mirip bagi pengguna Matlab®. Pylab mode menyediakan

semua fungsi pyplot plotting dan juga fungsi non-plotting functions dari numpy dan matplotlib.mlab.

2.6.

Extreme Programming

Extreme Programming (XP) adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. Sasaran XP adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Menurut Pressman(2005), Extreme Programming adalah proses yang paling banyak digunakan pada agile process. Perencanaan kegiatan diatur sebagai kerangka empat

–

perencanaan(planning),

desain(design),

pengkodean(coding)

dan

pengujian(testing) - XP menunjukkan sejumlah teknik yang inovatif dan kuat yang memungkinkan tim tangkas untuk membuat perangkat lunak rilis sering memberikan fitur dan fungsi yang telah dijelaskan dan kemudian diprioritaskan oleh pelanggan. Menurut Schach(2005), Extreme Programming adalah salah satu dari sejumlah paradigma baru yang secara kolektif disebut sebagai proses tangkas oleh Beck. Mereka ditandai dengan penekanan lebih sedikit pada analisis dan desain dari di hampir semua model siklus-hidup yang lain dan dengan pelaksanaan dimulai jauh lebih awal dalam siklus hidup, karena perangkat lunak bekerja dianggap lebih penting daripada dokumentasi rinci. Responsif terhadap perubahan lain tujuan utama proses tangkas, begitu pula pentingnya bekerja sama dengan klien. Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan

berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak(Beck, 2004). Penulis menggunakan model proses Extereme Programming dari Pressman dengan

perencanaan

kegiatan

berupa

perencanaan(planning),

desain(design),

pengkodean(coding) dan pengujian(testing) serta diakhiri release dari aplikasi. 2.6.1. Nilai-nilai Dasar XP Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses pengembangan perangkat lunak(Beck, 2004):

1.

Communication XP

memfokuskan pada komunikasi yang baik antar anggota tim. Para

anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang biasanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programer lain dalam menuliskan kode program. 2.

Courage Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim

harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya. 3.

Simplicity Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.

4.

Feedback Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.

5.

Quality Work Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.

2.6.2. Aspek Dasar XP Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project(Beck, 2004). Teknik-teknik tersebut dapat diamati pada gambar berikut ini:

Gambar 2.13 XP practices(Beck, 2004)

1.

The Planning Game Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan

terminologi

“game”

karena

Beck

menyarankan

untuk

menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut. 2.

Small Releases Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka

hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem. 3.

Metaphor Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.

4.

Simple Design Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak

perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil. 5.

Refactoring Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak

mengherankan

bahwa

cara

berpikir

mereka

terhadap

proses

pengembangan perangkat lunak sangat mirip satu dengan lainnya. 6.

Testing XP

menganut

paradigma berbeda dalam

hal

tes

dengan

model

pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih

dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis
test
code
design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP. 7.

Pair Programming Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.

8.

Collective Ownership Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program

dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya. 9.

Coding Standards Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.

10. Continous Integration Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan

penerapan

sistem

ini oleh

Microsoft

dan

telah

sering

dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi. 11. 40-hours Week

Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan. 12. On-Site Customer Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya. 2.6.3. Extreme Programming Software Development Process.

Design planning

coding testing

release

Gambar 2.14 XP Software Development Process(Pressman, 2005) XP mencakup beberapa aturan dan praktek yang terdiri atas planning, design, coding dan test(Pressman, 2005). Berikut penjelasan dari masing-masing tahapan yang akan dilakukan pada pembuatan aplikasi ini, 1. Planning.

Pada tahap ini perencanaan terhadap software yang diinginkan mengacu pada user stories. User stories menggambarkan fitur dan fungsi yang dibutuhkan terhadap software tersebut. Ketika semua user stories telah ditentukan, developer akan menentukan lama pengerjaan untuk tiap-tiap user stories. 2. Desain. Proses desain pada XP mengikuti prinsip KIS(Keep It Simple). Desain akan berisikan semua implementasi dari stories tanpa ada pengurangan maupun penambahan. Desain yang memiliki fungsi tambahan tidak disarankan. XP menggunakan CRC(Class-Responsibility-Collaborator) cards untuk mengidentifikasi dan mengorganisasikan kelas berorientasi objek yang berkaitan dengan proses pengembangan software. Jika terdapat kesulitan untuk melakukan desain terhadap stories, XP menyarankan untuk membuat prototype dari desain tersebut. Hal tersebut disebut sebagai spike solution, prototype nantinya akan diimplementasikan dan dievaluasi. XP menyarankan refactoring, sebuah teknik pengembangan yang juga teknik desain. Fowler mendeskripsikan refactoring sebagai berikut: “Refactoring adalah proses perubahan sebuah system software dengan satu cara yang tidak merubah behaviour eksternal dari kode yang meningkatkan struktur internal. Hal ini adalah cara untuk membersihkan kode dan memodifikasi ataupun menyederhanakan desain internal yang meminimalisasi peluang munculnya bug. Pada dasarnya, ketika melakukan refactor kita meningkatkan desain dari kode setelah tertulis.”

Perubahan

desain

dapat

terjadi

walaupun

sudah

memasuki

tahap

coding/implementasi. Hal tersebut dilakukan untuk mendapat desain yang baik dan kode yang bersih. 3. Coding. Pada tahap ini, proses pengembangan tidak langsung melakukan implementasi terhadap desain yang telah dibuat. Pembuatan unit test untuk tiap-tiap stories yang nantinya akan diimplementasikan. Saat unit test selesai dibuat, pengembang lebih baik fokus terhadap apa yang akan diimplementasikan untuk melewati unit test. Tahap ini akan mengacu pada desain sebelumnya. Karena pembuatan unit test dilakukan terlebih dahulu. Maka implementasi desain sebaiknya dibuat untuk melewati unit test yang dibuat. 4. Testing. Tahap ini akan menggunakan unit test yang sebelumnya telah dibuat. Karena pembuatan dari unit test adalah pendekatan utama dari XP. Unit test yang dibuat sebaiknya diimplementasikan dengan penggunaan framework untuk otomatisasi. Testing akan dilakukan dengan unit test yang sebelumnya telah dibuat. PyUnit akan digunakan sebagai framework untuk melakukan testing terhadap aplikasi. 5. Release. Tahap akhir setelah melewati semua test dan dinyatakan bebas dari bug dan dapat diimplementasikan/digunakan oleh pengguna.

2.7.

Studi Sejenis Penelitian oleh Pramudita(2008) yang dilaksanakan di gedung

Labtek VIII

Institut Teknologi Bandung (ITB) dan lab di gedung Pusat Antar Universitas (PAU)

ITB. Tujuan dari tugas akhir ini adalah memberikan Quality of Service (QoS) dengan mengimplementasikan Differentiated Service (DiffServ) pada jaringan testbed, mengukur dan menganalisis parameter-parameter kualitas layanan jaringan berbasis DiffServ, serta mencari disiplin antrian yang mampu memberikan layanan paling sesuai

dengan

kebutuhan

kelas

trafik

Expedited Forwarding (EF) dan Assured

Forwarding (AF). Hasil pengujian memperlihatkan bahwa DiffServ mampu mengklasifikasikan trafik ke dalam kelas-kelas yang sesuai dan memberikan pelayanan yang berbeda di antara kelas-kelas trafik tersebut. Implementasi masih menggunakan script dan bersifat statis, dan disarankan pengklasifikasian dilakukan secara dinamis. Penelitian lain oleh Marieska(2008) pada Wimax. IEEE Standard 802.16 tidak mendefinisikan algoritma penjadwalan. Algoritma penjadwalan bukan bagian dari standar sehingga perancang sistem Wimax dapat memilih algoritma yang paling cocok untuk diterapkan di jaringannya. Gabungan beberapa jenis algoritma mungkin menghasilkan nilai metrik yang lebih baik daripada satu jenis algoritma. Dan penerapan bersifat statis dan terbatas pada simulator. Penelitian tersebut melakukan penerapan pada jaringan lab sehingga masih menggunakan klasifikasi statis dan harus dilakukan konfigurasi ulang jika ingin diterapkan pada jaringan yang sebenarnya. Penulis akan menggunakan disiplin antrian dan menerapkan secara dinamis pada jaringan. Sehingga konfigurasi untuk jaringan dapat bersifat dinamis. 2.7.1.

Perbandingan aplikasi berbasis tc

Penggunaan tc secara langsung menggunakan baris perintah dinilai sangat menyulitkan

bagi

sebagian

pengguna.

Terdapat

beberapa

aplikasi

yang

mengimplementasikan tc dengan lebih mudah diantaranya, 1. Traffik http://sourceforge.net/projects/traffik/ “A Linux Traffic Control Management Interface: build tc-style rules for control network flows. Have support to set queue disciplines to interface (root) or inside a class (leaf), create classes and classifiers.” Antarmuka manajemen linux traffic control: membuat tc-style rules untuk kendali aliran jaringan. Memiliki dukungan untuk menset queue disciplines untuk interface(root) atau didalam class (leaf), classes dan classifiers.

Gambar 2.15 Traffik Sudah mengimplementasikan beberapa qdisc, tapi masih belum memberikan log untuk memonitor seberapa besar bandwidth yang dikonsumsi tiap-tiap node. 2. Banjar http://sourceforge.net/projects/banjar/

“Web-based bandwidth management tools based on tc and iptables for internet cafe or small to medium network administrators.” Bandwidth management tools berbasis web pada tc dan iptables untuk warung internet atau administrator jaringan skala kecil sampai sedang.

Gambar 2.16 Banjar Memiliki pemisahan bandwidth IIX dan International, tapi belum memiliki log untuk penggunaan bandwidth tiap-tiap node. 3. YABMAS http://sourceforge.net/projects/yabmas/ “Yet Another Bandwidth Management and Authentication System is a small bash script which allows automated management of client bandwidth allocation, and client authentication by MAC address through the use of iptables and htb/tc scheduling.” Yet Another Bandwidth Management and Authentication System adalah bash script kecil yang mengizinkan manajemen otomatis dari alokasi bandwidth klien dan otentikasi dengan MAC address melalui penggunaan iptables dan htb/tc scheduling.

Sebuah skrip yang memudahkan penggunaan tc dengan htb qdisc. Masih belum menerapkan penggunaan log yang memudahkan pengguna melihat konsumsi bandwidth tiap node.

BAB III METODOLOGI PENELITIAN

3.1.

Alat dan Bahan

Bahan yang digunakan adalah paket data yang diterima. Untuk kemudian dialirkan ke jaringan yang dibangun untuk tujuan penelitian ini. Adapun peralatan yang digunakan dibagi dua, yaitu : 1. Perangkat Keras •

PC server(1 unit) dengan spesifikasi : 1. Operating System : Fedora Core 10. 2. 2 kartu interface .

•

PC client(3 unit) dengan spesifikasi : 1. Operating System : Windows XP. 2. 1 kartu interface.

•

Switch

2. Perangkat Lunak •

IPTABLES.

•

TC.

•

Linux Kernel 2.6.x.

3.2.

•

GTK.

•

Python.

Metode Penelitian

3.2.1. Metode Pengumpulan Data 1. Studi Pustaka Studi pustaka dilakukan untuk mendapatkan bahan dan data yang diperlukan dalam melakukan penelitian ini. Sumber yang diambil berupa buku, jurnal, paper, tesis dan disertasi yang banyak terdapat di internet. Pencarian penelitian sebelumnya juga dilakukan untuk membandingkan dan mempelajari sehingga dapat diterapkan pula pada penelitian ini. 3.2.2. Metode Pengembangan Perangkat Lunak 1. Extreme Programming Extreme Programming(Pressman, 2005) adalah suatu pendekatan baru terhadap model pengembangan perangkat lunak yang kontroversial berdasar pada model iterative dan incremental. Langkah awal adalah tim pengembang menetapkan beberapa fitur(stories) yang diinginkan klien untuk diimplementasikan pada produk. Untuk tiap fitur tim memberitahukan kepada klien tentang lama pengerjaan dan biayanya. Langkah ini berada pada bagian planning untuk analisis kebutuhan perangkat lunak tersebut.

design planning

coding testing

release

Gambar 3.1 Extreme Programming process(Pressman, 2005)

XP mencakup beberapa aturan dan praktek yang terdiri atas planning, design, coding dan test(Pressman, 2005). Berikut penjelasan dari masing-masing tahapan yang akan dilakukan pada pembuatan aplikasi ini,

1. Planning. Pada tahap ini perencanaan terhadap software yang diinginkan mengacu pada user stories. User stories menggambarkan fitur dan fungsi yang dibutuhkan terhadap software tersebut. Ketika semua user stories telah ditentukan, developer akan menentukan lama pengerjaan untuk tiap-tiap user stories. Adapun beberapa fungsi dan kebutuhan dari aplikasi adalah sebagai berikut: 1. Aplikasi mampu generate parameter TC dan iptables yang dibutuhkan. 2. Aplikasi mampu generate parameter untuk TC dan iptables yang akan dibutuhkan oleh aplikasi. 3. Aplikasi membuat laporan realtime untuk mengukur pemakaian bandwidth.

2. Desain. Proses desain pada XP mengikuti prinsip KIS(Keep It Simple). Desain akan berisikan semua implementasi dari stories tanpa ada pengurangan maupun penambahan. Desain yang memiliki fungsi tambahan tidak disarankan. XP menggunakan CRC(Class-Responsibility-Collaborator) cards untuk mengidentifikasi dan mengorganisasikan kelas berorientasi objek yang berkaitan dengan proses pengembangan software. Jika terdapat kesulitan untuk melakukan desain terhadap stories, XP menyarankan untuk membuat prototype dari desain tersebut. Hal tersebut disebut sebagai spike solution, prototype nantinya akan diimplementasikan dan dievaluasi. XP menyarankan refactoring, sebuah teknik pengembangan yang juga teknik desain. Fowler mendeskripsikan refactoring sebagai berikut: “Refactoring adalah proses perubahan sebuah system software dengan satu cara yang tidak merubah behaviour eksternal dari kode yang meningkatkan struktur internal. Hal ini adalah cara untuk membersihkan kode dan memodifikasi ataupun menyederhanakan desain internal yang meminimalisasi peluang munculnya bug. Pada dasarnya, ketika melakukan refactor kita meningkatkan desain dari kode setelah tertulis.” Perubahan

desain

dapat

terjadi

walaupun

sudah

memasuki

tahap

coding/implementasi. Hal tersebut dilakukan untuk mendapat desain yang baik dan kode yang bersih.

Pada desain, perancangan aplikasi akan terdiri dari beberapa bagian diantaranya sebagai berikut : 1. Perancangan desain GUI dengan pembuatan prototype dengan menggunakan GTK. 2. Desain input yang diperlukan. 3. Desain ouput yang diperlukan. 4. Perancangan class yang dibutuhkan dengan CRC. 5. Perancangan tampilan laporan penggunaan bandwidth.

3. Coding. Pada tahap ini, proses pengembangan tidak langsung melakukan implementasi terhadap desain yang telah dibuat. Pembuatan unit test untuk tiap-tiap stories yang nantinya akan diimplementasikan. Saat unit test selesai dibuat, pengembang lebih baik fokus terhadap apa yang akan diimplementasikan untuk melewati unit test. Tahap ini akan mengacu pada desain sebelumnya. Karena pembuatan unit test dilakukan terlebih dahulu. Maka implementasi desain sebaiknya dibuat untuk melewati unit test yang dibuat. Aplikasi akan dibuat menggunakan python dan GTK sebagai GUI. 4. Testing. Tahap ini akan menggunakan unit test yang sebelumnya telah dibuat. Karena pembuatan dari unit test adalah pendekatan utama dari XP. Unit test yang dibuat sebaiknya diimplementasikan dengan penggunaan framework untuk otomatisasi.

Testing akan dilakukan dengan unit test yang sebelumnya telah dibuat. PyUnit akan digunakan sebagai framework untuk melakukan testing terhadap aplikasi. 5. Release. Tahap ini setelah semua test dilakukan dan dinyatakan bebas bug dan siap diimplementasikan/digunakan oleh pengguna.

Pemilihan judul penelitian

Perumusan Masalah

Analisis Kebutuhan

Studi Pustaka

METODE EXTREME PROGRAMMING Aplikasi mampu generate parameter TC dan iptables yang dibutuhkan. Planning

Aplikasi mampu generate parameter untuk TC dan iptables. Aplikasi membuat laporan realtime untuk mengukur pemakaian bandwidth.

Desain

Perancangan desain GUI dengan pembuatan prototype dengan menggunakan GTK. Desain Input Desain Output Perancangan class yang dibutuhkan dengan CRC.

Perancangan tampilan laporan penggunaan bandwidth.

Coding

Pembuatan Unit Test. Tahap Pemograman

Testing

Pengujian

BlackBox Testing Unit Testing Pengujian QoS

Release

Penarikan Kesimpulan dari sistem

Gambar 3.2 Ilustrasi Metodologi Penelitian Perancangan Aplikasi Bandwidth Management dengan TC.

BAB IV PEMBAHASAN

4.1.

Planning Tahap ini penulis melakukan analisis terhadap user stories(kebutuhan) terhadap

aplikasi yang akan dibuat. Karena framework yang dapat berkomunikasi dengan traffic control di modul kernel linux adalah tc. Maka penulis akan menggunakan tc sebagai jembatan penghubung antar aplikasi bantu yang penulis buat dengan queueing discipline yang digunakan. TC bukan sebuah API yang dapat diakses langsung dengan memanggil dari kode program. Untuk itu diperlukan pemanggilan langsung terhadap tool tersebut dan melakukan parsing terhadap outputnya. TC dapat langsung digunakan sebagai tools untuk mengatur lalu lintas jaringan. Pengaturan untuk tiap-tiap queueing discipline memiliki syntax yang berbeda. 4.1.1. Analisis penggunaan bandwidth. Protokol ip yang digunakan router menggunakan disiplin antrian First In First Out (FIFO) yang bersifat best effort service. Router akan melewatkan paket data dengan waktu yang bervariasi sesuai dengan beban trafik yang ada. Hal tersebut dapat memberikan kongesti pada jaringan dan tidak adanya pembedaan tiap paket data yang

lewat. Sehingga tiap node tidak mendapatkan QoS yang sesuai. Berikut hasil pengujian menggunakan disiplin antrian FIFO, Tabel 4.1 Pengukuran kecepatan tanpa bandwidth management Percobaan ke-

Node 1

Node 2

Upload

Download

Upload

Download

1

85 kbps

255 kbps

34 kbps

127 kbps

2

80 kbps

244 kbps

39 kbps

185 kbps

Koneksi internet pada tiap isp memiliki jalur masing-masing, sehingga langsung menuju jaringan global. Hal ini berdampak pada kecepatan yang sama ketika kita mengakses konten lokal, karena untuk mengaksesnya kita harus berputar ke jaringan luar negeri dulu. APJII membentuk IIX untuk mengatasi masalah tersebut. IIX adalah jaringan interkoneksi nasional dengan menggabungkan semua ISP yang ada di Indonesia. Dengan begitu jumlah hop antar router akan berkurang dan memberikan throughput yang lebih baik. Berikut pengujian dengan server yang berada pada jaringan IIX, Tabel 4.2 Pengukuran kecepatan untuk jaringan IIX Percobaan ke-

Node 1

Node 2

Upload

Download

Upload

Download

1

88 kbps

768 kbps

66 kbps

721 kbps

2

87 kbps

754 kbps

64 kbps

701 kbps

Dari hasil pengujian di atas terlihat belum adanya klasifikasi tiap paket, sehingga terdapat ketimpangan throughput antar node. Terlihat satu node mengkonsumsi bandwidth jaringan lebih banyak dari node yang lain. Untuk itu diperlukan klasifikasi

berdasarkan node yang terhubung dengan jaringan serta berdasarkan paket tcp ataupun udp. Pembedaan kecepatan juga dilakukan untuk paket data yang dikirim ke atau dari jaringan IIX ataupun internasional. 4.1.2. Aplikasi mampu generate parameter TC dan iptables yang dibutuhkan. 1. HTB HTB yang bersifat classful qdisc, memiliki pengaturan tc yang lebih banyak dibanding classless. Pada HTB tidak hanya mengatur qdisc tapi juga bisa dibuat child dari qdisc yang ada, dengan begitu kita dapat melakukan pengaturan yang lebih luas lagi. Terdapat beberapa pengaturan yang wajib pada classful qdisc pada kasus ini HTB. 1. pengaturan qdisc #tc qdisc add dev eth1 root handle 1: htb default 9999 #tc qdisc add dev eth1 parent 1:2 handle 21: pfifo limit 10

pada pengaturan qdisc dapat dilihat syntax baku sebagai berikut, #tc qdisc [add|del] dev device_name [root|parent CLASSID|handle QHANDLE] [QDISC_KIND]

Berikut penjelasan dari tiap pengaturan yang diperlukan : 2. opsi add adalah untuk menambahkan qdisc pada device network tertentu dan del untuk menghapusnya. 3. opsi device_name untuk pengaturan network device yang akan diatur. 4. opsi root untuk pengaturan qdisc induk. 5. opsi parent adalah classid dari parent qdisc. 6. opsi handle adalah qdiscid untuk qdisc tersebut. 7. opsi QDISC_KIND adalah jenis qdisc yang ingin digunakan.

2. pengaturan class #tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1Mbit ceil 2Mbit #tc class add dev eth1 parent 1:1 classid 1:2 htb rate 64Kbit ceil 256Kbit

pada pengaturan class dapat dilihat syntax baku sebagai berikut, #tc class [add|del] dev device_name [root|parent CLASSID] [classid CLASSID] QDISCKIND rate n ceil n

Berikut penjelasan dari pengaturan yang diperlukan : a) Opsi add adalah untuk menambahkan class dan del untuk menghapusnya. b) Opsi device_name adalah network device yang akan diberikan class. c) Opsi root untuk pengaturan class induk. d) Opsi parent adalah classid induk dari class tersebut. e) Opsi CLASSID adalah classid yang digunakan sebagai id class tersebut. f) Opsi QDISCKIND adalah qdisc yang digunakan pada class tersebut. g) Opsi rate adalah kecepatan normal class tersebut. h) Opsi ceil adalah kecepatan maksimum class tersebut.

3. pengaturan filter #tc filter add dev eth1 parent 1:0 protocol ip u32 match ip dst 192.168.0.12/32 flowid 1:2

untuk pengaturan filter berikut syntax baku : #tc filter [add|del] dev device_name [parent CLASSID] protocol

proto [u32 match selector|fw classid CLASSID]

[root|handle handleid|flowid FLOWID]

penjelasan dari pengaturan yang diperlukan : a) opsi add digunakan untuk menambah filter dan del untuk menghapus filter. b) Opsi device_name adalah network device yang ditambah filter. c) Opsi parent adalah parent yang memiliki qdisc root dari device_name. d) Opsi protocol untuk menentukan filter pada protocol yang diinginkan. e) Opsi u32 ataupun fw adalah untuk mencocokan paket data yang ingin difilter. f) Opsi handle maupun flowid untuk mencocokkan classid yang akan difilter.

Dari

beberapa

pengaturan

digambarkan sebagai berikut :

sebelumnya

akan

didapat

konfigurasi

yang

Level

Class main link Classid 1:1

Class IIX Classid 1:2

Class Internasional Classid 1:3

Class Intl Node Classid 1:n3

3

2

Class IIX node Classid 1:n2

1

Class tcp node Classid 1:n2*2

0

Qdisc Leaf RED Qdisc Handleid n2*2:

Class udp Classid 1:n2*2+1

Qdisc Leaf RED Qdisc Handleid n2*2+1:

Gambar 4.3 HTB tree bandwidth management

Untuk penambahan tiap node yang akan ditambahkan pada tree tersebut. Cukup ditambahkan pada level 0 dan level 1 saja, dengan penambahan id yang sesuai dengan ketentuan. Node sebelah di kiri digunakan untuk klasifikasi paket data dari dan ke jaringan IIX dan sebelah kanan untuk jaringan internasional. Tiap-tiap node nantinya

akan diklasifikasikan lagi paket data pada transport layer yaitu apakah paket tersebut TCP atau UDP. Classid 1:1 digunakan untuk menghandle maksimum bandwidth yang ada. Classid 1:2 digunakan untuk menghandle maksimum bandwidth untuk koneksi IIX. Classid 1:3 digunakan untuk menghandle maksimum bandwidth untuk koneksi internasional. Dan child dari node IIX dan Internasional akan digunakan untuk menghandle tiap node dalam jaringan. Classid child akan berupa 1:n2 untuk paket data IIX dan 1:n3 untuk paket data Internasional, dimana n adalah bilangan bulat. Tiap node akan memiliki leaf class yang membedakan paket TCP dan UDP. Tiap-tiap node class yang menghandle tiap node pada jaringan akan bertambah secara dinamis sesuai kebutuhan user, dan child classnya akan mengikuti. Berikut potongan kode untuk generate class seperti gambar 4.3 di atas, # tc qdisc add dev DEVICE root htb default 8888 # tc class add dev DEVICE parent 1:0 classid 1:1 htb rate RATE ceil MAXRATE # tc class add dev DEVICE parent 1:1 classid 1:2 htb rate RATE ceil MAXRATE # tc filter add dev DEVICE parent 1:0 handle 6666 fw classid 1:2 # tc class add dev DEVICE parent 1:1 classid 1:3 htb rate RATE ceil MAXRATE # tc filter add dev DEVICE parent 1:0 handle 9999 fw classid 1:3 # bagian ini akan digenerate oleh aplikasi secara dinamis sesuai kebutuhan pengguna. # tc class add dev DEVICE parent 1:2 classid 1:N2 htb rate RATE ceil MAXRATE

# tc filter add dev DEVICE parent 1:0 protocol ip u32 match ip dst IP flowid 1:N2 # tc class add dev DEVICE parent 1:3 classid 1:N3 htb rate RATE ceil MAXRATE # tc filter add dev DEVICE parent 1:0 protocol ip u32 match ip dst IP flowid 1:N3 # tc class add dev DEVICE parent 1:N2 classid 1:N2*2 htb rate RATE ceil MAXRATE # tc filter add dev DEVICE parent 1:N2 u32 match ip protocol 6 0xff flowid 1:N2*2 # tc class add dev DEVICE parent 1:N2 classid 1:N2*2+1 htb rate RATE ceil MAXRATE # tc filter add dev DEVICE parent 1:N2 u32 match ip protocol 17 0xff flowid 1:N2*2+1 # tc class add dev DEVICE parent 1:N3 classid 1:N3*2 htb rate RATE ceil MAXRATE # tc filter add dev DEVICE parent 1:N3 u32 match ip protocol 6 0xff flowid 1:N3*2 # tc class add dev DEVICE parent 1:N3 classid 1:N3*2+1 htb rate RATE ceil MAXRATE # tc filter add dev DEVICE parent 1:N3 u32 match ip protocol 17 0xff flowid 1:N3*2+1

2. RED Pengaturan RED lebih singkat dibanding pengaturan HTB. Hal ini dikarenakan RED yang bersifat classless. Pengaturan RED hanya memerlukan beberapa parameter,

diantaranya

:

a) limit rate, batasan kecepatan yang diizinkan. b) min rate, batasan minimum kecepatan yang diizinkan. c) max rate, batasan maksimum kecepatan yang diizinkan. Ketika melewati paket akan didrop. d) burst rate e) probability, kemungkinan paket yang akan didrop. Direkomendasikan 20% - 30%. f) Avpkt, average packet yang direkomendasikan diset 1000.

Adapun bentuk syntax dari RED yang diset dari TC adalah sebagai berikut: #tc qdisc add dev DEV root red limit LIMIT min MIN max MAX burst BURST avpkt 1000 probability PROP

Nilai yang diset pada RED haruslah dalam satuan Byte bukan bit. Maka sebelumnya harus dikonversi ke dalam Byte. Berikut rumus untuk mendapatkan beberapa parameter di atas. Bandwidth : 64kbps = 8000KB/s Latency : 0.5 s. Max : Bandwidth * Latency = 8000 * 0.5 = 4000 Min : Max / 2 = 2000 Limit : 8 * Max = 8 * 4000 = 32000 Burst : (2 * min + max) / (3 * avpkt) = (2 * 2000 + 4000) / (3 * 1000) = 2.667 Jika kita gunakan parameter di atas, maka akan kita gunakan pada tc sebagai berikut,

#tc qdisc add dev eth0 parent ID red limit 32000 min 2000 max 4000 burst 2.667 avpkt 1000 probability 0.02

Aplikasi nantinya akan meminta input berupa bandwidth dan latency yang dimiliki. Dan akan langsung mengenerate parameter lain, untuk kemudian menjalankan tc dengan parameter ada. 3. Iptables Aplikasi ini dibutuhkan untuk melakukan filtering terhadap tiap paket data yang datang maupun dikirim dari router. Filter akan lebih spesifik untuk mencari dan menandai paket data mana yang datang maupun dikirim ke jaringan IIX ataupun Internasional. Karna nantinya kedua paket data tersebut akan diperlakukan berbeda. Berikut potongan kode untuk melakukan filtering terhadap paket data yang datang dari IIX dan untuk dari Internasional akan ditandai bila tidak termasuk paket tersebut, # clear iptables #$IPTABLES = perintah iptables #$DEV_UPLINK = device yang menghadap jaringan internet #$DEV_DOWNLINK = device yang menghadap jaringan lokal $IPTABLES -t mangle -F $IPTABLES -t filter -F $IPTABLES -t nat –F $IPTABLES -t mangle -X $IPTABLES -t mangle -N IIX # bagian ini akan diulang dan ditambahkan ip dari server yang terhubung dengan IIX

$IPTABLES -t mangle -A IIX -i $DEV_UPLINK -p ! icmp -s 167.205.0.0/16 -j CONNMARK --set-mark 103 $IPTABLES -t mangle -A IIX -i $DEV_UPLINK -p ! icmp -s 167.205.0.0/16 -j RETURN $IPTABLES -t mangle -A IIX -i $DEV_DOWNLINK -p ! icmp -d 167.205.0.0/16 -j CONNMARK --set-mark 103 $IPTABLES -t mangle -A IIX -i $DEV_DOWNLINK -p ! icmp -d 167.205.0.0/16 -j RETURN #bagian ini akan menangani sisa paket data yang tidak cocok pada rules sebelumnya dan ditentukan sebagai paket data dari jaringan internasional $IPTABLES -t mangle -N INTL $IPTABLES -t mangle -A INTL -i $DEV_UPLINK -p ! icmp -s 0.0.0.0/0 -j CONNMARK --set-mark 104 $IPTABLES -t mangle -A INTL -i $DEV_UPLINK -p ! icmp -s 0.0.0.0/0 -j RETURN $IPTABLES -t mangle -A INTL -i $DEV_DOWNLINK -p ! icmp -d 0.0.0.0/0 -j CONNMARK --set-mark 104 $IPTABLES -t mangle -A INTL -i $DEV_DOWNLINK -p ! icmp -d 0.0.0.0/0 -j RETURN $IPTABLES -t mangle -A PREROUTING -j IIX $IPTABLES -t mangle -A PREROUTING -j INTL

4.1.3. Aplikasi mampu generate parameter untuk TC dan Iptables. Terlihat dari analisis kebutuhan parameter TC sebelumnya. Terdapat beberapa parameter untuk TC yang dibutuhkan. Beberapa di antaranya adalah : a) Network device yang akan digunakan.

b) Kecepatan maksimum untuk tiap network device yang digunakan. c) Beberapa parameter untuk HTB 1) classid untuk tiap node. Node qdisc root dengan handle 1:0, node parent class dengan classid 1:1. Node IIX dengan 1:2, node internasional dengan classid 1:3. child class IIX akan menggunakan classid 1:n2 dan internasional dengan classid 1:n3, untuk n adalah bilangan bulat. Untuk qdisc child class tersebut akan mengikuti classid dengan handle n2: untuk IIX dan n3 untuk Internasional, untuk n adalah bilangan bulat 2) Maksimum rate untuk parent class. 3) Rate untuk tiap class node yang tidak melebihi parent class. d) Bandwidth dan latency yang dimiliki oleh network device yang menggunakan RED. e) Ip yang digunakan oleh tiap network interface yang digunakan untuk routing oleh iptables f) Daftar ip host yang terhubung jaringan IIX untuk penanda paket data yang dikirim ataupun diterima.

4.1.4. Konfigurasi yang dibutuhkan sebagai gateway server. Konfigurasi yang dibutuhkan hanya melakukan setting terhadap iptables. Iptables nantinya akan membuat setiap paket data yang masuk ke dalam server untuk diteruskan ke internet. Proses yang dapat dilakukan berupa SNAT maupun Masquerade.

Aplikasi nantinya akan mengenerate syntax iptables sesuai keinginan dan langsung mengeksekusinya. Berikut adalah contoh syntax yang dibutuhkan untuk SNAT dan masquerade. SNAT $IPTABLES -t nat -A POSTROUTING -o DEV -j SNAT –to-source IPPUBLIC

Masquerade $IPTABLES -t nat -A POSTROUTING -o DEV -j MASQUERADE

Untuk penggunaan SNAT diperlukan input berupa ip public nantinya digunakan untuk merubah ip private yang digunakan dalam LAN. Sedangkan penggunaan Masquerade tidak memerlukan input, karena akan langsung merubah ke ip public yang ada.

4.1.5. Aplikasi membuat laporan realtime untuk pengukur pemakaian bandwidth. Pada TC terdapat opsi untuk melihat rate yang terjadi untuk setiap class. Tapi terdapat kekurangan pada penggunaanya. Tidak adanya log ataupun laporan yang bersifat realtime. Untuk mendapatkan kecepatan yang diberikan untuk tiap class, cukup dengan perintah berikut : #tc -s -d class show dev DEV

Perintah tersebut akan memberikan output berupa laporan untuk semua class yang ada, berikut salah satu contoh laporan yang akan muncul:

class htb 1:10 parent 1:1 leaf 101: prio 0 quantum 1000 rate 64000bit ceil 64000bit burst 1599b/8 mpu 0b overhead 0b cburst 1599b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 195312 ctokens: 195312

Output yang muncul terdiri dari banyak parameter, beberapa di antaranya adalah kecepatan minimum dan maksimum. Nilai 1:10 adalah classid yang dimaksud dan parent adalah parent class dari class tersebut. Untuk melihat kecepatan yang sedang berjalan, parameter rate akan memberikan nilai berupa kecepatan aktual pada saat perintah ini dieksekusi. Kekurangan inilah yang nantinya akan dibuat log berupa diagram garis yang akan update tiap detik dan memberikan fungsi pelaporan terhadap user mengenai kecepatan aktual yang dimiliki suatu class saat itu. Aplikasi nantinya akan mencocokan classid yang ada dengan hasil output perintah sebelumnya. Setelah itu langsung ditampilkan dan nilai kecepatan sebelumnya akan disimpan dan dari sini akan terlihat fungsi log untuk kecepatan tiap waktu. 4.1.6. User Stories Dari hasil analisis user stories sebelumnya dapat disimpulkan bahwa terdapat beberapa user stories yang dapat dibagi, di antaranya : 1. Konfigurasi qdisc HTB dan RED dengan TC 2. Aplikasi mampu konfigurasi Iptables untuk marking dan routing.

3. Penggunaan TC untuk mengambil data kecepatan tiap node. 4. Penggunaan TC untuk setting qdisc sebelumnya.

4.2.

Design 4.2.1

Class Design

Proses desain akan dilakukan menggunakan Class Responsibilities, and Collaboration (CRC) Card. Penggunaan CRC card untuk mengarahkan berpikir secara

objek

dibanding

secara

prosedural.

Tiap-tiap

CRC

card

akan

merepresentasikan tiap objek yang dibutuhkan. Proses desain di sini akan lebih fokus pada bagaimana tiap objek saling berinteraksi bukan bagaimana membuat objek tersebut. Dari user stories pada tahap planning, penulis membuat beberapa class yaitu : 1. HTB, digunakan untuk mengenerate TC statement. 2. RED, digunakan untuk mengenerate TC statement. 3. TC, digunakan untuk mengeksekusi TC statement yang sebelumnya dibuat oleh class lain. 4. BWGUI, digunakan untuk menangani GUI dari aplikasi. 5. Client, digunakan untuk menangani informasi tiap klien. 6. BandwidthConsumption, digunakan untuk menangani penggunaan bandwidth tiap client.

HTB Generate tc statement untuk root qdisc. Generate tc statement untuk tambah/edit/hapus client.

Client

Gambar 4.4 Class HTB

RED Generate tc statement sesuai dengan algoritma RED yang sudah ditetapkan. Generate tc statement untuk edit dan hapus RED qdisc.

Gambar 4.5 Class RED TC Eksekusi statement untuk TC. Parsing output untuk kecepatan aktual tiap-tiap class.

Client

Gambar 4.6 Class TC BWGUI Menangani GUI untuk aplikasi. Setting TC dengan tampilan grafis. Memberikan laporan penggunaan bandwidth tiap client dengan plot.

TC HTB RED Client BandwidthConsumtpion

Gambar 4.7 Class BWGUI

Client Menangani informasi tiap client, di antaranya: - IP address - Rate Gambar 4.8 Class Client

BandwidthConsumption

Parsing kecepatan aktual tiap kelas dari TC. Menyimpan kecepatan tiap class untuk ditampilkan pada plot.

TC Client

Gambar 4.9 Class BandwidthConsumption

BWGUI HTB

Client

RED

TC

BandwidthConsumption

Gambar 4.10 Desain Class Class BWGUI akan menggunakan class HTB, RED dan TC. Karena class BWGUI yang nantinya akan menangani input dan output dari pengguna. Karena

input berupa nilai bandwidth rate dan informasi client. Maka class BWGUI memerlukan class tersebut. Class HTB menggunakan class client untuk menampung informasi client berupa IP, bandwidth rate dan lainnya. Class TC hanya berkomunikasi

dengan

BWGUI

dan

BandwidthConsumption.

Karena

BandwidthConsumption memerlukan class TC untuk mengambil bandwidth rate dari tiap class dan melakukan parsing terhadap outputnya.

4.2.2

GUI design

Gambar 4.11 Layout BWTC tab Gateway

Layout untuk GUI memiliki beberapa widget, di antaranya menu, plot, tab, dan beberapa textbox dan button. Untuk tampilan awal dari aplikasi, terlihat dari gambar 4.11 Terdapat tab gateway yang aktif, di dalamnya memiliki 2 group frame.

Sebelah kiri adalah NAT settings yang berguna untuk mengeset PC sebagai gateway atau hanya melewatkan paket. Dan terdapat 2 textbox untuk setting network interface yang digunakan untuk terhubung ke internet dan jaringan local. Sebelah kanan adalah Max Upload & Download Rate yang digunakan untuk mengatur kecepatan maksimum upload dan download yang dimiliki. Terdapat 2 Textbox, satu untuk mengatur upload dan untuk mengatur download. Satuan yang digunakan dalam textbox tersebut adalah kbps.

Gambar 4.12 Layout BWTC tab Download Rate

Pada tab selanjutnya atau tab Download Rate, terdapat beberapa tombol dan table. Tombol Add Client berfungsi menambah informasi klien dan mengatur kecepatan klien tersebut. Tombol Edit Client berfungsi mengubah informasi klien yang sudah

masuk. Tombol Delete Client berfungsi menghapus klien dari table dan melepas pengaturan kecepatan. Fungsi dari table di bawahnya adalah untuk menampilkan klien yang telah ditambah. Informasi klien ditampilkan pada table tersebut. Dan ketika dipilih akan menampilkan log berupa plot di bagian atas.

Gambar 4.12 Layout BWTC tab Upload Rate Pada Tab ini terdapat sebuah group frame Upload Settings yang berisi textbox untuk upload limit, probability dan latency. Tidak seperti download rate, pada tab upload rate tidak bergantung pada berapa klien karena menggunakan RED yang tidak memiliki fungsi classifier. Proses nantinya akan mengenerate RED ke dalam network interface yang sebelumnya disetting sebagai inet interface.

Gambar 4.13 Layout BWTC dialogbox Client.

Pada tab Download Rate, terdapat button Add Client dan Edit Client. Aksi dari kedua button tersebut akan memunculkan dialogbox seperti di atas. Dialogbox akan muncul untuk meminta informasi terkait klien yang ingin diatur kecepatan downloadnya.

Gambar 4.14 Layout BWTC menu File.

Menu file digunakan untuk membuat setting baru ataupun mengambil setting yang sudah ada dan menyimpannya ketika ada perubahan.

Gambar 4.15 Layout BWTC menu Help Menu help hanya memberikan dialogbox about dan penggunaan dari aplikasi ini.

Gambar 4.16 Layout BWTC plot log rate.

Plot akan muncul ketika pengguna memilih salah satu klien yang ada dalam table. Ketika terpilih plot akan memunculkan diagram garis untuk menunjukkan penggunaan bandwidth dari klien tersebut. Plot akan terupdate tiap 1 detik dan memberikan log realtime kepada pengguna.

4.3.

Coding Setelah desain selesai, masuk ke tahap coding. Tahap ini tidak langsung membuat

code dari tiap objek dari hasil desain sebelumnya. Pembuatan Unit Test untuk menguji tiap class didahulukan. Contoh Unit Test yang akan dibuat adalah sebagai berikut :

import unittest from modules.RED import RED

def test_qdisc(self): red = RED() self.assertEqual(red.qdisc, 'root red') def test_red(self): red = RED() self.assertEqual(red.setRed(128000),'/sbin/tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000 probability 0.02 bandwidth 128')

if __name__ == '__main__': unittest.main()

Terlihat pengujian terhadap class RED dilakukan untuk menguji attribute qdisc dan fungsi setRed. Penggunaan fungsi assert equal digunakan untuk membandingkan antara hasil output dan nilai seharusnya yang keluar. Pengujian dilakukan untuk semua class yang ada. Setelah beberapa unit test dibuat, implementasi dari desain bisa dilakukan. Tahap penulisan kode dimaksimalkan untuk lolos dari unit test. Hal ini berguna untuk mencegah dari adanya bug pada kode yang ditulis. Berikut contoh kode untuk RED :

class RED(): def __init__(self, dev = 'eth0', bandwidth=384000): self.bandwidth = bandwidth # bps self.maxupload = bandwidth / 8 # Byte self.limit = 0 self.min = 0

self.max = 0 self.burst = 0 self.latency = 0.5 # detik self.avpkt = 1000 # 1000 nilai default dari red self.probability = 0.02 # probabilitas untuk mark dan drop 20%

self.tc = '/sbin/tc' self.command = 'qdisc add' self.dev = dev self.qdisc = 'root red'

self.space = ' '

def setRed(self, bandwidth, probability=0.02, latency=0.5): try: self.latency = latency self.probability = probability self.bandwidth = bandwidth

self.maxupload = bandwidth / 8 self.max = self.maxupload * self.latency self.min = self.max / 2 self.limit = self.max * 8 self.burst = (2 * self.min + self.max) / (3 * self.avpkt) self.burst = self.burst val = self.addQdisc() return val

except: print 'bad value'

def getRED(self): return self.setRed(self.bandwidth)

def addQdisc(self): perintah = self.tc + self.space perintah += self.command + self.space perintah += 'dev ' + self.dev + self.space perintah += self.qdisc + self.space perintah += 'limit' + self.space + str(int(self.limit)) + self.space perintah += 'min' + self.space + str(int(self.min)) + self.space perintah += 'max' + self.space + str(int(self.max)) + self.space perintah += 'burst' + self.space + str(self.burst) + self.space perintah += 'avpkt' + self.space + str(self.avpkt) + self.space perintah += 'probability' + self.space + str(self.probability) + self.space perintah += 'bandwidth' + self.space + str(self.bandwidth/1000)

return perintah

def delRED(self):

return '/sbin/tc qdisc del dev ' + self.dev + ' root'

Setelah kode ditulis, langsung dilakukan pengetesan dengan test case yang sebelumnya dibuat. Berikut hasil dari eksekusi unit test tersebut :

..F. ================================================================= ===== FAIL: test_red (__main__.TestRED) --------------------------------------------------------------------Traceback (most recent call last): File "test.py", line 28, in test_red self.assertEqual(red.setRed(128000),'/sbin/tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000 probability 0.02 bandwidth 128') AssertionError: '/sbin/tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5.33333333333 avpkt 1000 probability 0.02 bandwidth 128' != '/sbin/tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5.33 avpkt 1000 probability 0.02 bandwidth 128'

--------------------------------------------------------------------Ran 4 tests in 0.000s

FAILED (failures=1)

Terlihat ada gagal pada unit test tersebut. Hal ini karena terdapat perbedaan antara hasil output dan nilai yang seharusnya keluar. Terdapat perbedaan pada statement burst yang seharusnya bernilai 5 tapi output dari fungsi yang diuji adalah 5.33333333333. Untuk itu perlu diperbaiki fungsi tersebut. Nilai burst yang seharusnya bilangan bulat bukannya pecahan. Sehingga kode berikut self.burst dirubah

self.burst =

menjadi self.burst = int(math.ceil(self.burst)).

Eksekusi kembali unit test sebelumnya dan didapat hasil berikut : .... --------------------------------------------------------------------Ran 4 tests in 0.000s

OK

Proses perubahan kode secara terus menerus sampai didapat kode yang sederhana dinamakan refactoring. Refactoring merupakan aspek penting pada metode Extreme Programming. Karena detil kode untuk tiap class tidak dijelaskan, maka pada tahap inilah penulisan kode akan melebihi desain dan terus mengembangkan desain tersebut. Lakukan terus perubahan dan pecahkan fungsi yang memiliki terlalu banyak baris kode menjadi beberapa fungsi. Dengan begitu fungsi akan mudah dimengerti cara kerjanya. Secara tidak langsung mengembangkan desain sederhana yang sebelumnya dibuat tanpa merubah cara program berjalan.

4.4.

Testing Untuk menguji bug pada kode yang ditulis sebelumnya, unit test yang sebelumnya

telah dibuat dieksekusi. Lakukan refactoring terus menerus sampai bug hilang. Untuk menguji fungsionalitas dari aplikasi digunakan BlackBox Testing.

4.4.1

Unit Testing

Setelah semua kode ditulis, lakukan eksekusi terhadap unit test yang telah dibuat. Sebaiknya tambahkan lebih banyak test case untuk tiap unit case. Hal ini diperlukan untuk mendeteksi bug yang kemungkinan muncul akibat proses refactoring sebelumnya. Setelah beberapa iterasi dihasilkan test case untuk beberapa fungsi. Berikut adalah potongan test case yang akan diuji,

class TestRED(unittest.TestCase): "RED tests"

def test_red(self): red = RED('eth0', 128000) self.assertEqual(red.getRED(),'/sbin/tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000 probability 0.02 bandwidth 128')

def test_DelRED(self):

red = RED() self.assertEqual(red.delRED(), '/sbin/tc qdisc del dev eth0 root')

class TestHTB(unittest.TestCase): "HTB tests"

def test_class(self): classifier = Classifier('eth0', '1:1', '1:2', '64Kbit', '1Mbit') self.assertEqual(classifier.getClass(), '/sbin/tc class add dev eth0 parent 1:1 classid 1:2 htb rate 64Kbit ceil 1Mbit')

class TestClient(unittest.TestCase): "Client tests"

def test_client(self): self.client

=

Client('Client 1','192.168.1.10', 64000,

64000, 512000, 128000,'00:FF:00:10:AF:89')

self.assertEqual(self.client.get_name(), 'Client 1') self.assertEqual(self.client.get_ip(), '192.168.1.10') self.assertEqual(self.client.get_dload(), 64000) self.assertEqual(self.client.get_uload(), 64000) self.assertEqual(self.client.get_dmax(), 512000) self.assertEqual(self.client.get_umax(), 128000) self.assertEqual(self.client.get_mac(), '00:FF:00:10:AF:89')

class TestBandwidthConsumption(unittest.TestCase): "BandwidthConsumption tests"

def test_BConsumption(self): bc = BandwidthConsumption()

class TestTC(unittest.TestCase): "TC tests"

def test_TC(self): tc = TC()

Dan hasil yang didapat setelah mengeksekusi test case di atas adalah sebagai berikut,

.... --------------------------------------------------------------------Ran 6 tests in 0.000s

OK

4.4.2

BlackBox Testing

Pada blackbox testing penulis mencoba melakukan tes terhadap semua fungsionalitas dari aplikasi ini. Berikut beberapa hasil tes yang penulis lakukan terhadap aplikasi dan hasilnya,

1. Pengujian Set firewall untuk fungsi SNAT atau Masquerade.

Gambar 4.17 pengujian firewall feature Pengguna mengisi ip public yang digunakan yang nantinya akan digunakan sebagai source NAT. Interface yang berhubungan dengan internet dan jaringan lokal diatur di sini.

Gambar 4.18 cek firewall Pengecekan apakah SNAT di iptables berhasil dieksekusi atau tidak. Hasilnya menunjukkan berhasil memberikan satu rule untuk SNAT.

Gambar 4.19 pengujian masquerade Berbeda dengan yang tadi, di sini dilakukan pengetesan untuk masquerade. Perubahan SNAT secara dinamis dan pengaturan interface. Cara yang dilakukan hampir sama dengan sebelumnya.

Gambar 4.20 cek masquerade Terlihat pengaturan sebelumnya berhasil memberikan satu rule ke iptables untuk melakukan masquerade. 2. Pengujian Set Max Download dan Max Upload rate.

Gambar 4.21 pengujian max download dan upload Di sebelah kanan terdapat pengaturan untuk maksimum dan minimum upload yang diijinkan. Pengaturan ini bergantung pada koneksi internet yang kita miliki.

Gambar 4.22 cek tc max rate Pengaturan untuk download berhasil dan menambah rule pada TC dengan HTB qdisc.

Gambar 4.23 cek tc max rate Pengaturan upload dengan RED qdisc juga berhasil dilakukan di sini. 3. Pengujian Tambah, Ubah dan Hapus Client.

Gambar 4.24 pengujian tambah node Di sini dilakukan pengujian untuk menambah client yang ingin diatur alokasi bandwidthnya.

Gambar 4.25 penambahan node

Gambar 4.26 cek tc leaf Terlihat bertambah satu rule untuk client yang ditambah sebelumnya.

Gambar 4.27 pengubahan node Client yang sebelumnya telah ditambah, dapat diubah parameternya. Pengujian perubahan parameter dilakukan di sini.

Gambar 4.28 cek perubahan pada leaf Perubahan parameter berhasil merubah rule pada tc yang ada.

Gambar 4.29 penghapusan node Perintah hapus dilakukan di sini. Pengujian untuk menghapus rule client dari table dan rule TC.

Gambar 4.30 cek penghapusan pada tc Terlihat sudah terhapus rule dari client yang dihapus tersebut.

4. Pengujian Tampilkan plot untuk bandwidth rate tiap client.

Gambar 4.33 pengujian tampilan plot Tabel 4.4 Pengujian black box Fungsi

Status

Set firewall untuk fungsi SNAT atau Masquerade

OK

Set Max Download dan Max Upload rate

OK

Tambah, Ubah dan Hapus Client

OK

Set Upload Rate

OK

Tampilkan plot untuk bandwidth rate tiap client

OK

4.5.

Release Tahap ini aplikasi sudah dapat diimplementasikan, dan penulis melakukan

pengujian implementasi untuk membuktikan apakah aplikasi dapat memenuhi fungsinya sebagai bandwidth limiting. 4.5.1

Implementation Test

Penulis akan melakukan implementation tes dengan beberapa node yang berhubungan langsung dengan gateway. Berikut topologi jaringan yang digunakan :

Gambar 4.34 Topologi jaringan pengujian Pengujian akan dilakukan dengan beberapa parameter, di antaranya: 1. Rate : 64kbps, max rate : 64kbps 2. Rate : 64kbps, max rate : 128kbps 3. Rate : 128kbps, max rate : 128kbps 4. Rate : 128kbps, max rate : 256kbps Berikut hasil dari pengujian alokasi bandwidth untuk tiap node yang melewati gateway:

1. Pengujian rate : 64kbps, max rate 64kbps

Gambar 4.35 Pengujian node download dan upload 64kbps 2. Pengujian rate : 64kbps, max rate 128kbps

Gambar 4.36 pengujian

node kecepatan 64kbps, kecepatan maksimum 128kbps. 3. Pengujian rate : 128kbps, max rate 128kbps

Gambar 4.37

Pengujian node kecepatan 128kbps, maksimum 128kbps.

4. Pengujian rate : 128kbps, max rate 256kbps

Gambar 4.38 Pengujian node kecepatan 128kbps, maksimum kecepatan 256kbps. 4.5.2

QoS Testing

Setelah pengujian aplikasi berjalan dengan baik dan sesuai dengan desain sebelumnya. Pengujian lanjutan untuk menguji pengaturan QoS berjalan dengan baik atau tidak. Pengujian akan dilakukan dengan 2 situs pengujian, yaitu speedtest.net untuk menguji throughput dan pingtest.net untuk menguji delay, jitter dan packet loss. Pengujian pertama akan dilakukan dengan menggunakan disiplin antrian HTB saja. Terdapat 3 node yang terhubung dengan gateway dan scenario pengujian menggunakan server lokal dan internasional, 1. Tiap node diberi kecepatan download 128kbps, maksimum 128 kbps dan upload 32 kbps maksimum 32kbps.

Tabel 4.5 Qos Testing 1, hasil Speedtest.net.

Koneksi

Node 1

Node 2

Node 3

Upload

Download

Upload

Download

Upload

Download

IIX

30 kbps

126 kbps

34 kbps

127 kbps

24 kbps

118 kbps

Internasional

28 kbps

131 kbps

39 kbps

125 kbps

29 kbps

117 kbps

Tabel 4.6 QoS Testing 1, hasil Pingtest.net

Node 1 delay

jitter

Node 2 Packet

delay

jitter

loss

Node 3 Packet

delay

jitter

loss

2. Packet

iap

loss

node

1

56 ms

10 ms

0%

51 ms

9 ms

0%

54 ms

11 ms

0%

diberi

2

76 ms

15 ms

0%

32ms

11 ms

0%

66 ms

12 ms

0%

kecep

atan download 128kbps, maksimum 256kbps dan upload 32kbps maksimum 64kbps. Tabel 4.7 QoS Testing 2, hasil Speedtest.net Koneksi

Node 1

Node 2

Node 3

Upload

Download

Upload

Download

Upload

Download

IIX

56 kbps

255 kbps

61 kbps

127 kbps

62 kbps

198 kbps

Internasional

48 kbps

244 kbps

48 kbps

185 kbps

58 kbps

211 kbps

Tabel 4.8 QoS Testing 2, hasil Pingtest.net Node 1

Node 2

Node 3

delay

jitter

Packet

delay

jitter

Packet

loss

delay

jitter

loss

Packet loss

1

35ms

13ms

0%

33 ms

11 ms

0%

38ms

15ms

0%

2

33ms

12ms

0%

38 ms

13 ms

0%

32ms

16ms

0%

3. Tiap node diberi kecepatan 256kbps, maksimum 256kbps dan upload 64 kbps maksimum 64kbps. Tabel 4.9 QoS Testing 3, hasil Speedtest.net Koneksi

Node 1

Node 2

Node 3

Upload

Download

Upload

Download

Upload

Download

IIX

75 kbps

255 kbps

52 kbps

262 kbps

60 kbps

278 kbps

Internasional

70 kbps

244 kbps

64 kbps

248 kbps

62 kbps

286 kbps

Tabel 4.10 QoS Testing 3, hasil Pingtest.net Node 1 delay

jitter

Node 2 Packet

delay

jitter

loss

Node 3 Packet

delay

jitter

loss

Packet loss

1

25 ms

8ms

0%

28 ms

6ms

0%

27 ms

8ms

0%

2

26 ms

9ms

0%

24 ms

5ms

0%

26 ms

9ms

0%

Pengujian pertama akan dilakukan dengan menggunakan disiplin antrian HTB dan RED untuk leaf class. Terdapat 3 node yang terhubung dengan gateway dan scenario pengujian menggunakan server lokal dan internasional,

1. Tiap node diberi kecepatan download 128kbps, maksimum 128 kbps dan upload 32 kbps maksimum 32kbps Tabel 4.11 QoS Testing 4, hasil Speedtest.net Koneksi

Node 1

Node 2

Node 3

Upload

Download

Upload

Download

Upload

Download

IIX

32 kbps

127 kbps

34 kbps

127 kbps

32 kbps

128 kbps

Internasional

28 kbps

124 kbps

32 kbps

128 kbps

32 kbps

126 kbps

Tabel 4.12 QoS Testing 4, hasil Pingtest.net Node 1 delay

jitter

Node 2 Packet

delay

jitter

loss

Node 3 Packet

delay

jitter

loss

Packet loss

1

52ms

12ms

0%

65ms

16ms

0%

50ms

15ms

0%

2

77ms

14ms

1%

60ms

17ms

0%

49ms

14ms

0%

2. Tiap node diberi kecepatan download 128kbps, maksimum 256kbps dan upload 32kbps maksimum 64kbps. Tabel 4.13 QoS Testing 5, hasil Speedtest.net Koneksi

Node 1

Node 2

Node 3

Upload

Download

Upload

Download

Upload

Download

IIX

65 kbps

226 kbps

64 kbps

228 kbps

62 kbps

232 kbps

Internasional

60 kbps

222 kbps

59 kbps

209 kbps

58 kbps

218 kbps

Tabel 4.14 QoS Testing 5, hasil Pingtest.net Node 1 delay

jitter

Node 2 Packet

delay

jitter

loss

Node 3 Packet

delay

jitter

Packet

loss

loss

1

40ms

14ms

0%

38ms

14ms

0%

35ms

12ms

0%

2

38ms

13ms

0%

35ms

13ms

0%

40ms

15ms

0%

3. Tiap node diberi kecepatan 256kbps, maksimum 256kbps dan upload 64 kbps maksimum 64kbps. Tabel 4.15 QoS Testing 6, hasil Speedtest.net Koneksi

Node 1

Node 2

Node 3

Upload

Download

Upload

Download

Upload

Download

IIX

64 kbps

255 kbps

64 kbps

256 kbps

64 kbps

255 kbps

Internasional

62 kbps

254 kbps

60 kbps

252 kbps

62 kbps

256 kbps

Tabel 4.16 QoS Testing 6, hasil Pingtest.net Node 1 delay

jitter

Node 2 Packet loss

delay

jitter

Node 3 Packet loss

delay

jitter

Packet loss

1

22ms

1ms

0%

21ms

1ms

0%

24ms

3ms

0%

2

23ms

2ms

0%

21ms

1ms

0%

22ms

2ms

0%

4.6.

Analisis pengujian Implementation Test dan QoS Testing memberikan hasil yang sesuai dengan

fungsi dari HTB untuk memberikan jaminan alokasi bandwidth tiap kelas yang ada. Secara default ketika kita tidak memberikan disiplin antrian pada kelas di HTB, disiplin antrian pfifo akan digunakan pada kelas tersebut. Dengan begitu kapasitas jaringan yang ada akan diperebutkan oleh masing-masing sub kelas. RED bertugas untuk menjatuhkan paket data secara acak yang memiliki probabilitas tinggi dan berperan besar dalam memberikan kongesti pada jaringan. Dampak yang diberikan adalah adanya penurunan kecepatan. Hal ini dikarenakan sifat dari TCP yang akan memelankan laju pengiriman datanya ketika terdapat paket data yang jatuh. Terlihat dari percobaan pada situs speedtest.net(subbab 4.6.4), kecepatan yang diperoleh tiap node bervariasi. Tiap node saling berebut jaringan dan memberikan kecepatan yang cukup bervariasi. Sedangkan percobaan berikutnya yang menggunakan disiplin antrian RED memiliki kecepatan yang hampir sama. Karena RED akan menjatuhkan paket data secara aktif dan mencegah kongesti pada jaringan. Dampaknya laju TCP tiap kelas akan menurun dan tidak saling berebut. Terlihat setelah penggunaan RED, laju tiap node relatif stabil dan sama. Hasil uji pingtest.net(subbab 4.6.4), tiap node memiliki nilai delay, jitter dan packet loss yang cukup baik. Hal ini dapat dilihat dari hasil yang cukup untuk digunakan oleh aplikasi seperti voice ataupun streaming.

BAB V KESIMPULAN

5.1.

Kesimpulan

Setelah melakukan pengetesan terhadap aplikasi yang telah dibuat dan menyelesaikan penelitian ini. Dapat ditarik kesimpulan sebagai berikut: 1. Aplikasi DiffServ menggunakan TrafficControl dengan disiplin antrian HTB dan RED dapat berperan untuk mengatur penggunaan bandwidth tiap node pada jaringan. Hasil pengujian dapat dilihat di Implementation Test(subbab 4.5.1) dan QoS testing(subbab 4.5.2). 2. Aplikasi dapat membedakan asal paket dari jaringan IIX(lokal) atau internasional. Dan memberikan batasan kecepatan yang sesuai untuk tiap koneksi. Hasil pengujian dapat dilihat pada QoS testing(subbab 4.5.2). 3. Aplikasi dapat diterapkan pada router linux berbasis DiffServ. Karena bersifat open source dan dapat dimodifikasi dan ditambah fungsionalitasnya. 4. Pengujian QoS dengan parameter uji delay, jitter dan packet loss memberikan hasil yang baik. Terlihat dari hasil pengujian yang memberikan nilai pengujian dari parameter tersebut relatif kecil bila dibandingkan dengan sebelumnya yang menggunakan disiplin antrian FIFO atau default dari router. Hasil pengujian dapat dilihat pada QoS Testing(subbab 4.5.2).

5.2. Saran Berikut ini beberapa saran yang mungkin berguna untuk digunakan sebagai bahan pertimbangan yang ingin melakukan penelitian atau aplikasi yang hampir sama, 1. Dimungkinkan untuk menerapkan semua queueing discipline yang ada. Sehingga pengguna bebas memilih yang ingin digunakan. 2. Memberikan log berupa diagram garis yang lebih luas dan dimungkinkan untuk disimpan dalam database untuk keperluan auditing di lain waktu. 3. Python sebagai scripting language dan menggunakan Extreme Programming sebagai metode yang digunakan dapat mempercepat dan menyederhanakan proses pembuatan aplikasi.

1

DAFTAR PUSTAKA Almesberger, Werner. 2001. Differentiated Services on linux. ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz Beck, Kent. 2004. Extreme Programming Explained: Embrace Change, Second Edition. Massachusetts: Addison Wesley Professional. Blake, et. al. 1998. An Architecture for Differentiated Services. RFC 2475. http://www.ietf.org/rfc/rfc2475 Braden, et. al. 1998. Recommendations on Queue Management and Congestion Avoidance in the Internet. RFC 2309. http://www.ietf.org/rfc/rfc2309.txt Braithwaite, Stephen. 2006. Implementation of AQMs on Linux made Easy. The University of Southern Queensland. http://eprints.usq.edu.au/2075/1/Braithwaite-6800-Queuing.pdf Brown, Martin A. 2006. Traffic Control HOWTO. Version 1.0.2. http://linuxip.net/articles/Traffic-Control-HOWTO/. diakses pada hari ini. C H, Swaroop. A Byte of Python. http://www.byteofpython.info. Devera, Martin. 2002. HTB Linux queuing discipline manual - user guide. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Floyd, Sally dan Van Jacobson. 1993. Random Early Detection Gateways for Congestion Avoidance. Lawrence Berkeley Laboratory University of California. http://www.icir.org/floyd/papers/red/red.html Floyd, et. al. 2001. Adaptive RED: An Algorithm for Increasing the Robustness of RED’s Active Queue Management. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.7450&rep=rep1 &type=pdf Floyd, Sally. Congestion Control Principles. RFC 2914. http://www.ietf.org/rfc/rfc2914 Hubert , Bert. 2004. Linux Advanced Routing & Traffic Control HOWTO. http://lartc.org/lartc.pdf Li, Suqiao. 1999. Network Traffic Control and Bandwidth Management in Internet: A Differentiated Services Case Study. McGill University.

2

http://digitool.library.mcgill.ca/R/?func=dbin-jumpfull&object_id=30688&local_base=GEN01-MCG02 Marieska, Mastura Diana. 2008. Analisis Algoritma Penjadwalan Berbasis Quality of Service pada Wimax. http://digilib.itb.ac.id/ Nagle, John. 1984. Congestion Control in IP/TCP Internetworks. RFC 896. http://tools.ietf.org/html/rfc896 Nichols, et. al. 1998. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474. http://www.ietf.org/rfc/rfc2474.txt Pramudita, Damar Aji. 2008. Differentiated Service(DiffServ) di Jaringan Testbed menggunakan Disiplin Antrian PRIORITY QUEUEING dan HIERARCHY TOKEN BUCKET. http://digilib.itb.ac.id/ Python v2.6.1 Documentation. http://docs.python.org/ Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering, Sixth Edition. New York: McGraw Hill. Pressman, Roger S. 2005. Software Engineering: A Practitioner’s Approach, Sixth Edition. New York: McGraw Hill. Valenzuela, et. al. 2004. Hierarchical Token Bucket Algorithm to Enhance QoS in IEEE 802.11: Proposal, Implementation dan Evaluation. http://ieeexplore.ieee.org/iel5/9623/30413/01400539.pdf?arnumber=1400539 Welzl, Michael. 2005. Network congestion control : managing Internet traffic. England:John Wiley & Sons Ltd.

Pengembangan Aplikasi DiffServ dengan Disiplin Antrian Hierarchy Token Bucket dan Random Early Detection Sebagai Bandwidth Limiting Deni Zakya

Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta Tel : (021) 823026 Fax : (021) 8624025 Email : [email protected]

ABSTRACT Growth of the Internet led to the cafe to use internet connection as a basic component of the business. Cafe manager will use at least one Internet connection and share it with all the nodes are connected to the Internet. Number of nodes that are connected to the router will cause the network conditions experienced congestion / density. So it looks like there are one or more nodes that dominate network bandwidth usage. For that needed the concept of Quality of Service (QoS), one way to apply QoS in IP networks with Differentiated Services (DiffServ). The author uses a packet scheduling Hierarchy Token Bucket and Random Early Detection in this study. Classification will be based on the connected node, protocol tcp or udp and IIX network (local) and international. International Classification of IIX and taken because of the significant difference in speed from the second network. Analysis of quality of service on the network is done by measuring the parameters of throughput, delay, jitter and packet loss. In the end, using the DiffServ Implementation TrafficControl with RED queue discipline HTB and may act to regulate the use of bandwidth for each node in the network. Applications can distinguish the origin of a network packet IIX (local) or international. And provide the appropriate speed limit for each connection. Use of HTB and RED queues provide good quality care without sacrificing throughput testing parameters, delay, jitter and packet loss that big. The author uses Extreme Programming as a methodology of software development. Seen from the test results that provide value testing of these parameters is relatively small compared with the use of best effort or just with FIFO queue discipline. Keywords: Bandwidth Limiting, TrafficControl, Hierarchy Token Bucket, Random Early Detection. 1.

PENDAHULUAN 1.1. Latar Belakang

Penggunaan router pada jaringan komputer warnet dapat menghubungkan koneksi lokal warnet dengan internet. Banyaknya node yang terkoneksi ke router akan menyebabkan kondisi jaringan mengalami kongesti/kepadatan. Sehingga terlihat seolah-olah ada satu atau lebih node yang mendominasi penggunaan bandwidth jaringan(Welzl, 2005).

1.

2.

3. 4.

Efisiensi penggunaan bandwidth tiap node pada jaringan dengan memberikan alokasi bandwidth sesuai kebutuhan. Pemisahan alokasi bandwidth tiap node. Klasifikasi didasarkan pada asal dari paket yang datang, IIX untuk jaringan lokal(indonesia) dan International untuk jaringan Internet. Klasifikasi lainnya berdasarkan protocol, TCP atau UDP. Membangun aplikasi berbasis DiffServ dengan router linux. Menguji Quality of Service tiap-tiap node pada jaringan.

1.2. Rumusan Masalah 1.3. Batasan Masalah Masalah yang dapat dirumuskan dalam tugas akhir ini sebagai berikut :

Agar pembahasan mengenai topik ini tidak terlalu meluas maka diperlukan batasan masalah.

tentang traffic control pada linux dan queueing discipline.

Adapun batasan masalah untuk skripsi ini antara lain: 1.

Aplikasi yang penulis buat akan menjembatani pengguna untuk melakukan konfigurasi tidak langsung DiffServ pada kernel linux dengan Traffic Control, Iptables dan Python. 2. Merumuskan konfigurasi yang digunakan aplikasi untuk pemisahan bandwidth IIX & Internasional serta paket tcp dan udp untuk tiap node yang terhubung ke jaringan internet. 3. Pengujian dan analisis QoS dengan parameter nilai bandwidth, jitter dan packet loss. 1.4. Tujuan dan Manfaat Penelitian Penelitian yang penulis lakukan bertujuan untuk: 1.

Tujuan Umum 1. Mengembangkan aplikasi bandwidth management yang bersifat open source dan user friendly. 2. Tujuan Khusus 1. Memadukan iptables dan TC(traffic control) sebagai fondasi awal aplikasi. 2. Memberikan pengelolaan bandwidth yang sesuai pada jaringan. 3. Memberikan antar muka grafis yang sederhana dan mudah digunakan. Manfaat yang di dapatkan dalam penelitian ini adalah : 1.

2. 3.

Memberikan aplikasi yang mampu mengatur penggunaan bandwidth sesuai kebutuhan. Memberikan aplikasi yang murah dan mudah diterapkan. Menghasilkan aplikasi open source yang bebas digunakan/dikembangkan siapa saja.

1.5. Metodologi Penelitian Metode Penelitian yang penulis gunakan adalah sebagai berikut : 1.

Studi Pustaka. Studi pustaka yang penulis lakukan adalah dengan mempelajari literatur

2.

Metode Pengembangan Perangkat Lunak(Software Development Method). Metode pengembangan perangkat lunak yang penulis gunakan adalah Agile Software Development dengan Extreme Programming. Tahapannya adalah sebagai berikut : 1. Planning, perencanaan dari aplikasi yang akan dibuat dengan menjelaskan fitur dan kegunaan dari aplikasi. 2. Design, proses desain dari hasil perencanaan sebelumnya. 3. Coding, proses pembuatan unit test untuk kemudian digunakan sebagai penguji pada code yang akan diimplementasikan. 4. Testing, proses pengujian terhadap code yang diimplementasikan dengan unit test yang sebelumnya telah dibuat. 5. Release, tahap akhir aplikasi siap diimplementasikan/digunakan oleh pengguna, setelah sebelumnya dipastikan sudah melewati tahapan testing.

1.6. Sistematika Penelitian

Penelitian ini terdiri dari lima bab, dengan penjelasan tiap-tiap bab sebagai berikut : BAB I : PENDAHULUAN Pada bab ini berisi tentang Latar Belakang, Rumusan Masalah, Batasan Masalah, Tujuan dan Manfaat Penelitian, Metodologi Penelitian serta Sistematika Penulisan Penelitian. BAB II: LANDASAN TEORI Pada bab ini menjelaskan tentang teori perangkat keras dan perangkat lunak, definisi sistem, analisa sistem, definisi perancangan sistem dan jenis program yang digunakan. BAB III: Metodologi Penelitian Pada bab ini akan menguraikan dan memberikan penjelasan mengenai perancangan perangkat keras, perancangan sistem sehingga dapat diketahui rencana yang akan dikerjakan. BAB IV: Pembahasan dan Implementasi Pada bab ini akan menjelaskan mengenai pembuatan sistem dan pengujian sistem.

BAB V: Penutup Bab ini berisi kesimpulan dari pembahasan masalah dan saran-saran berkenaan dengan Penelitian ini. 2.

LANDASAN TEORI 2.1. Pengantar Quality of Service Pertama kali jaringan IP diterapkan hanya membawa satu tipe informasi yaitu data non-real time, sehingga jaringan bisa didesain untuk berjalan secara besteffort yang memperlakukan semua paket sama. Tujuan utama dari jaringan IP adalah memastikan perangkat terminal mempunyai protokol dan kecerdasan yang sesuai untuk menjamin transmisi data yang bisa diandalkan sehingga jaringan bisa berjalan sesederhana mungkin. Pada sebuah jaringan yang membawa berbagai tipe lalu lintas data, keterbatasan yang menjadi elemen penting pada suatu tipe lalu lintas data bisa saja menjadi tidak penting untuk tipe lalu lintas data lainnya, dan sebaliknya. Mekanisme QoS yang diimplementasikan pada jaringan harus mampu mengoptimalkan hal tersebut. 2.1.1. Fungsi dasar QoS Dua mekanisme QoS utama yang tersedia untuk jaringan IP adalah Integrated Service (IntServ) dan Differentiated Service (DiffServ) (Welzl, 2005). Istilah traffic flow menunjukkan aliran trafik dan tiap alirannya mewakili sumber trafik yang berbeda-beda. Pada layanan best effort, semua paket digabungkan kedalam sebuah aliran massal tanpa mempedulikan asal trafik. Pada IntServ, tiap-tiap aliran dibedakan dari awal sampai akhir. Pada DiffServ, tiap-tiap aliran trafik tidak dibedakan per aliran, melainkan dikumpulkan terlebih dahulu menjadi kelas-kelas kecil. Kelas-kelas trafik tersebut diberikan perlakuan yang berbedabeda tiap hopnya (Li,1999). Pembahasan akan ditekankan pada metoda QoS DiffServ, dan akan dijelaskan lebih lanjut pada sub bab berikutnya. Untuk menyediakan QoS dalam jaringan IP jaringan harus mampu menjalankan tugas dasar, yaitu membedakan trafik atau tipe layanan menjadi beberapa kelas dan memperlakukan kelas-kelas trafik secara berbeda dengan menyediakan

jaminan resource dan pembedaan layanan pada jaringan. 2.1.2. Traffic Policing Traffic Policing digunakan untuk mengecek apakah trafik yang masuk pada port masukan sesuai dengan laju trafik yang telah disetujui antara pengguna dan penyedia jasa jaringan IP. Traffic policing terdiri dari pengukuran trafik berdasarkan laju trafik yang telah disetujui dan menandai atau menandai ulang paket berdasarkan keluaran hasil pengukuran tersebut. Biasanya, traffic policing menyesuaikan laju trafik yang datang dengan acuan laju tertentu, dengan acuan yang digunakan dapat berupa satu acuan laju yaitu Committed Information Rate (CIR) atau dua acuan laju, CIR dan Peak Information Rate (PIR). Untuk mendapatkan laju yang sesuai dengan CIR dan PIR, traffic policing menggunakan tiga parameter yaitu Peak Burst Size (PBS), Committed Burst Size (CBS) dan Excess Burst Size (EBS) (Blake, 1998). a. Peak Information Rate b. Commited Information Rate c. Burst Size 2.1.3. Traffic Metering Ada dua macam traffic metering dan mekanisme pewarnaan paket, yaitu. 1. Single Rate Three Color Marker (srTCM). 2. Two Rate Three Color Marker (trTCM). 2.1.4. Manajemen Antrian Aktif Tanpa adanya Manajemen Antrian Aktif atau Active Queue Management (AQM) pada router, router menggunakan mekanisme yang disebut sebagai metode tail drop. Akan tetapi metode tail drop dapat berujung pada fenomena yang disebut sebagai sinkronisasi global TCP (Braithwaite, 2006). Pada metode tail drop, saat buffer penuh, semua paket yang datang menuju buffer seluruhnya dijatuhkan. Bila paket ini merupakan paket TCP, semua aliran TCP yang mengalami kehilangan paket akan memelankan laju pengiriman secara

simultan dan kembali mengulangi transmisi pada waktu yang hampir bersamaan. Karena semua aliran TCP yang terpengaruh dengan keadaan tersebut bereaksi dalam perilaku yang sinkron, maka kondisi kongesti pada jaringan akan berosilasi antara kondisi kongesti penuh (saat semua aliran TCP mengirim paket dengan laju penuh) dan tanpa kongesti (semua aliran TCP memelankan laju pengiriman paket). Manajemen antrian aktif adalah mekanisme pengendalian kongesti yang bertugas untuk mencegah terjadinya sinkronisasi TCP. Ide utama dari AQM adalah untuk mengantisipasi terjadinya kongesti dan mengambil tindakan untuk mencegah atau mengurangi efek dari kongesti. 2.1.5. Penjadwalan Paket Penjadwalan paket (packet scheduling) digunakan untuk menjadwalkan paket pada antrian sehingga kapasitas jaringan pada port keluaran dapat terdistribusi merata pada semua kelas trafik yang memasuki jaringan (Welzl, 2005). 1. First In First Out FIFO memperlakukan semua paket sederajat sehingga cocok digunakan untuk jaringan best effort. Masalah utama yang dihadapi FIFO adalah FIFO tidak dapat membedakan (atau hanya memiliki kemampuan yang sangat terbatas untuk membedakan) kelas trafik. 2. Priority Queuing Pada PQ, antrian dibagi sebanyak N antrian, dengan urutan prioritas 1 sampai dengan N. Urutan pelayanan paket bergantung dari urutan prioritas dan keberadaan paket pada antrian dengan prioritas lebih tinggi. 3. Fair Queuing Pada FQ, paket datang diklasifikasikan kedalam N antrian, Setiap antrian diberikan alokasi kapasitas jaringan sebesar 1/N total kapasitas jaringan. Setiap

antrian dilayani secara berurutan (round robin) dengan melewati antrian yang kosong. 4. Class Based WFQ Pada CB-WFQ, aliran trafik dibagi ke dalam kelas-kelas, tetapi dengan pembagian kapasitas jaringan yang bergantung dari kebutuhan masing-masing kelas, dengan total kapasitas jaringan seluruh kelas adalah 100% kapasitas jaringan keluaran. 5. Hierarchy Token Bucket HTB menjamin jumlah layanan yang diterima sebuah kelas trafik paling kecil sesuai dengan jumlah yang dibutuhkan dan diberikan kepadanya. Apabila sebuah kelas menggunakan kapasitas jaringan lebih kecil dari yang diberikan kepadanya, sisa kapasitas jaringan yang tidak digunakan didistribusikan ke kelas lainnya. 2.1.6. Traffic Shaping Traffic shaping digunakan untuk mengatur laju aliran trafik yang datang untuk membentuk laju trafik sedemikian rupa agar laju trafik keluaran bersifat lebih mulus. Bila laju trafik yang datang bersifat sangat acak (bursty) maka perlu ditempatkan dulu pada sebuah buffer sehingga laju keluaran lebih konstan(Li, 1999). 2.2. Differentiated Services DiffServ bekerja dengan prinsip pengklasifikasian trafik. 2.2.1. Arsitektur DiffServ Arsitektur DiffServ berdasarkan sebuah model sederhana dimana trafik yang memasuki sebuah jaringan diklasifikasikan dan dapat dikondisikan pada tepi jaringan dan ditempatkan pada beberapa Behavior Aggregate (BA) yang berbeda. Setiap BA diidentifikasikan oleh sebuah Differentiated Service Code Point (DSCP), sehingga BA dapat didefinisikan sebagai kumpulan paket dengan DSCP yang sama yang melewati sebuah link pada arah tertentu. Pada inti jaringan, paket

diteruskan bergantung kepada PHB yang ditentukan oleh DSCP (Blake, 1998). 2.2.2. Traffic Conditioner Sebuah traffic conditioner terdiri atas elemen-elemen berikut: meter, marker, shaper, dan dropper. Aliran trafik akan diseleksi oleh classifier, yang akan meneruskannya ke bagian traffic conditioner. Meter digunakan (apabila diperlukan) untuk membandingkan aliran trafik terhadap suatu profil trafik. Hasil keluaran sebuah meter dapat mempengaruhi proses marking, dropping, atau shaping terhadap paket tersebut (Blake, 1998). 2.3. Linux Traffic Control Traffic control adalah kumpulan aturan dan mekanisme yang mengizinkan sebuah jaringan untuk memenuhi kualitas layanan secara efisien. Beberapa mekanisme yang digunakan seperti shaping, scheduling, monitoring, policing, signaling, pricing, admission control, congestion control dan flow control dan lainnya. Selain itu traffic control dapat diartikan sebagai kumpulan fungsi dari sebuah jaringan untuk mencegah kondisi padat, yang membentuk mengatur aliran data pada titik tertentu dalam system (Brown, 2006). 2.3.1. Metode Traffic Control pada Kernel Linux

Terdapat beberapa metode yang digunakan oleh traffic control pada interface (Hubert , 2004), yaitu 1. Shaping Shapers menahan paket untuk mencapai kecepatan yang diinginkan. 2. Scheduling Scheduler mengatur paket untuk output. scheduling adalah mekanisme untuk pengaturan paket di antara input dan output dari sebagian besar antrian. 3. Classifying Classifying adalah mekanisme untuk menentukan paket mana yang dipisah untuk diperlakukan berbeda, dan dimungkinkan dengan output queue yang berbeda. 4. Policing

Policing menghitung dan membatasi traffic dalam queue tertentu. 5. Dropping Dropping membuang keseluruhan paket data, aliran data atau klasifikasi. 6. Marking Marking adalah mekanisme untuk menandai paket data. 2.3.2. Queuing Discipline Antrian menentukan cara mengirimkan data. Penting untuk diingat bahwa kita hanya bisa menentukan data yang kita kirim (Hubert, 2004).

Terdapat banyak qeueuing discipline pada kernel linux, namun pada pembahasan kali ini hanya 2 yang kita gunakan. Random Early Detection, untuk menanggulangi congestion. Hierarchical Token Bucket, untuk membagi bandwidth sesuai dengan kebutuhan, misal berdasarkan ip ataupun port yang diinginkan. 1. Random Early Detection RED menghitung average queue size menggunakan low-pass filter dengan exponential weighted moving average. Average queue size dibandingkan dengan 2 thresholds, minimum threshold dan maximum threshold. Ketika average queue size kurang dari minimum threshold tak ada paket yang di mark. Ketika average queue size lebih besar dari maximum threshold, setiap paket yang datang di mark. Jika paket yang dimark dibuang atau jika semua node sumber bekerja sama dapat dipastikan bahwa average queue size tidak secara signifikan melampaui maximum threshold (Hubert, 2004). 2. Hierarchical Token Bucket HTB berbasis atas class hierarkis yang terdiri atas tiga tipe, yaitu : root, inner dan leaf. Root adalah induk dari semua class dan semua lalu lintas data akan melewatinya. Inner class memiliki induk class, dapat berupa root ataupun inner class lain, dan memiliki class

turunan. Leaf adalah kelas akhir atau class yang hanya memiliki class induk tanpa class turunan (Devera, 2002).

2.4.3. Tc filter

HTB scheduler Terdapat pohon class pada HTB scheduler. Terdapat pula list global yang disebut self feed, yang terdapat pada sebelah kanan. Self feed terdiri atas self slot. Terdapat satu slot per priority per level. Tiap self slot memiliki beberapa class. Semua class pada slot memiliki level dan prioritas seperti slot.

Prioritas pengiriman paket (Devera, 2002) 2.4. TC tools Pada paket iproute2, tc adalah satu-satunya yang dapat digunakan untuk traffic control. Karena tc secara langsung berinteraksi dengan kernel untuk pembuatan, penghapusan dan modifikasi terhadap struktur traffic control. 2.4.1. Tc qdisc

tc qdisc (Hubert, 2004)

tc filter (Hubert, 2004) 2.5. Python Python adalah salah satu bahasa pemrograman script. Karena script sehingga bersifat interpreted tapi python memungkinkan untuk dicompile. Memiliki pendekatan Berorientasi Objek dan yang terpenting adalah terstruktur secara sintaks kodenya. 2.6. Extreme Programming

Extreme Programming (XP) adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. Sasaran XP adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Menurut Pressman(2005), Extreme Programming adalah proses yang paling banyak digunakan pada agile process. Perencanaan kegiatan diatur sebagai kerangka empat – perencanaan(planning), desain(design), pengkodean(coding) dan pengujian(testing) - XP menunjukkan sejumlah teknik yang inovatif dan kuat yang memungkinkan tim tangkas untuk membuat perangkat lunak rilis sering memberikan fitur dan fungsi yang telah dijelaskan dan kemudian diprioritaskan oleh pelanggan.

2.4.2. Tc class

XP Software Development Process(Pressman, 2005) tc class (Hubert, 2004)

XP mencakup beberapa aturan dan praktek yang terdiri atas planning, design, coding dan test(Pressman, 2005). 2.7. Studi Sejenis Penelitian oleh Pramudita(2008) yang dilaksanakan di gedung Labtek VIII Institut Teknologi Bandung (ITB) dan lab di gedung Pusat Antar Universitas (PAU) ITB. Penelitian lain oleh Marieska(2008) pada Wimax. IEEE Standard 802.16 tidak mendefinisikan algoritma penjadwalan. Penulis akan menggunakan disiplin antrian dan menerapkan secara dinamis pada jaringan. Sehingga konfigurasi untuk jaringan dapat bersifat dinamis. 3.

METODOLOGI PENELITIAN 3.1. Alat dan Bahan

Extreme Programming (Pressman, 2005) adalah suatu pendekatan baru terhadap model pengembangan perangkat lunak yang kontroversial berdasar pada model iterative dan incremental. XP mencakup beberapa aturan dan praktek yang terdiri atas planning, design, coding dan test. a. Planning Adapun beberapa fungsi dan kebutuhan dari aplikasi adalah sebagai berikut: 1.

Adapun peralatan yang digunakan dibagi dua, yaitu : 2.

1. Perangkat Keras • PC server(1

•

unit) dengan spesifikasi : 1. Operating System : Fedora Core 10. 2. 2 kartu interface . PC client(3 unit) dengan spesifikasi : 1. Operating System : Windows XP.

2. 1 kartu interface.

• Switch 2. Perangkat Lunak • IPTABLES. • TC. • Linux Kernel 2.6.x. • GTK. • Python. 3.2. Metode Penelitian 3.2.1. Metode Pengumpulan Data 1. Studi Pustaka

Studi pustaka dilakukan untuk mendapatkan bahan dan data yang diperlukan dalam melakukan penelitian ini. 3.2.2. Metode Pengembangan Perangkat Lunak 1. Extreme Programming

3.

Aplikasi mampu generate parameter TC dan iptables yang dibutuhkan. Aplikasi mampu generate parameter untuk TC dan iptables yang akan dibutuhkan oleh aplikasi. Aplikasi membuat laporan realtime untuk mengukur pemakaian bandwidth.

b. Design Pada desain, perancangan aplikasi akan terdiri dari beberapa bagian diantaranya sebagai berikut : 1.

2. 3. 4.

5.

c. Coding

Perancangan desain GUI dengan pembuatan prototype dengan menggunakan GTK. Desain input yang diperlukan. Desain ouput yang diperlukan. Perancangan class yang dibutuhkan dengan CRC. Perancangan tampilan laporan penggunaan bandwidth.

4.

Saat unit test selesai dibuat, pengembang lebih baik fokus terhadap apa yang akan diimplementasikan untuk melewati unit test. d. Test Tahap ini akan menggunakan unit test yang sebelumnya telah dibuat. PEMBAHASAN 4.1. Planning 4.1.1. Analisis penggunaan bandwidth Berikut hasil pengujian menggunakan disiplin antrian FIFO,

Percob aan ke-

1

Node 1 Upload

85 kbps

Node 2

Downloa

Uploa

Downloa

d

d

d

255 kbps

34

127 kbps

untuk IIX dan n3 untuk Internasional, untuk n adalah bilangan bulat b. Maksimum rate untuk parent class. c. Rate untuk tiap class node yang tidak melebihi parent class. d. Bandwidth dan latency yang dimiliki oleh network device yang menggunakan RED. e. Ip yang digunakan oleh tiap network interface yang digunakan untuk routing oleh iptables f. Daftar ip host yang terhubung jaringan IIX untuk penanda paket data yang dikirim ataupun diterima. 4.2. Design 4.2.1. Class Design

kbps 2

80 kbps

244 kbps

39

185 kbps

Dari user stories pada tahap planning, penulis membuat beberapa class yaitu :

kbps

4.1.2. Aplikasi mampu generate parameter untuk TC dan Iptables

a. Network device yang akan digunakan. b. Kecepatan maksimum untuk tiap network device yang digunakan. c. Beberapa parameter untuk HTB a. classid untuk tiap node. Node qdisc root dengan handle 1:0, node parent class dengan classid 1:1. Node IIX dengan 1:2, node internasional dengan classid 1:3. child class IIX akan menggunakan classid 1:n2 dan internasional dengan classid 1:n3, untuk n adalah bilangan bulat. Untuk qdisc child class tersebut akan mengikuti classid dengan handle n2:

1. HTB, digunakan untuk mengenerate TC statement. 2. RED, digunakan untuk mengenerate TC statement. 3. TC, digunakan untuk mengeksekusi TC statement yang sebelumnya dibuat oleh class lain. 4. BWGUI, digunakan untuk menangani GUI dari aplikasi. 5. Client, digunakan untuk menangani informasi tiap klien. 6. BandwidthConsumption, digunakan untuk menangani penggunaan bandwidth tiap client. 4.2.2. GUI Design

4.3. Coding

Tahap ini tidak langsung membuat code dari tiap objek dari hasil desain sebelumnya. Pembuatan Unit Test untuk menguji tiap class didahulukan. Contoh Unit Test yang akan dibuat adalah sebagai berikut : import unittest from modules.RED import RED def test_qdisc(self): red = RED() self.assertEqual(red.qdisc, 'root red') def test_red(self): red = RED() self.assertEqual(red.setRed(128 000),'/sbin/tc qdisc add dev eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000 probability 0.02 bandwidth 128') if __name__ == '__main__': unittest.main() 4.4. Test Untuk menguji bug pada kode yang ditulis sebelumnya, unit test yang sebelumnya telah dibuat dieksekusi. Lakukan refactoring terus menerus sampai bug hilang. 5.

KESIMPULAN 5.1. Kesimpulan

Setelah melakukan pengetesan terhadap aplikasi yang telah dibuat dan menyelesaikan penelitian ini. Dapat ditarik kesimpulan sebagai berikut: 1. Aplikasi DiffServ menggunakan TrafficControl dengan disiplin antrian HTB dan RED dapat berperan untuk mengatur penggunaan bandwidth tiap node pada jaringan. Hasil pengujian dapat dilihat di Implementation Test(subbab 4.5.1) dan QoS testing(subbab 4.5.2). 2. Aplikasi dapat membedakan asal paket dari jaringan IIX(lokal) atau internasional. Dan memberikan batasan kecepatan yang sesuai untuk tiap koneksi. Hasil pengujian dapat dilihat pada QoS testing(subbab 4.5.2). 3. Aplikasi dapat diterapkan pada router linux berbasis DiffServ. Karena bersifat open source dan dapat dimodifikasi dan ditambah fungsionalitasnya. 4. Pengujian QoS dengan parameter uji delay, jitter dan packet loss memberikan hasil yang baik. Terlihat dari hasil pengujian yang memberikan nilai pengujian dari parameter tersebut relatif kecil bila dibandingkan dengan sebelumnya yang menggunakan disiplin antrian FIFO atau default dari router. Hasil pengujian dapat dilihat pada QoS Testing(subbab 4.5.2). 5.2. Saran

Berikut ini beberapa saran yang mungkin berguna untuk digunakan sebagai bahan pertimbangan yang ingin melakukan penelitian atau aplikasi yang hampir sama, 1. Dimungkinkan untuk menerapkan semua queueing discipline yang ada. Sehingga pengguna bebas memilih yang ingin digunakan. 2. Memberikan log berupa diagram garis yang lebih luas dan dimungkinkan untuk disimpan dalam database untuk keperluan auditing di lain waktu.

3. Python sebagai scripting language dan menggunakan Extreme Programming sebagai metode yang digunakan dapat mempercepat dan menyederhanakan proses pembuatan aplikasi. Daftar Pustaka

Almesberger, Werner. 2001. Differentiated Services on linux. ftp://icaftp.epfl.ch/pub/linux/diffser v/misc/dsid-01.ps.gz Beck, Kent. 2004. Extreme Programming Explained: Embrace Change, Second Edition. Massachusetts: Addison Wesley Professional. Blake, et. al. 1998. An Architecture for Differentiated Services. RFC 2475. http://www.ietf.org/rfc/rfc2475

Braden, et. al. 1998. Recommendations on Queue Management and Congestion Avoidance in the Internet. RFC 2309. http://www.ietf.org/rfc/rfc2309.t xt Braithwaite, Stephen. 2006. Implementation of AQMs on Linux made Easy. The University of Southern Queensland. http://eprints.usq.edu.au/2075/1/Bra ithwaite-6800-Queuing.pdf Brown, Martin A. 2006. Traffic Control HOWTO. Version 1.0.2. http://linux-ip.net/articles/TrafficControl-HOWTO/. diakses pada hari ini. C H, Swaroop. A Byte of Python. http://www.byteofpython.info. Devera, Martin. 2002. HTB Linux queuing discipline manual - user guide.

http://luxik.cdi.cz/~devik/qos/htb/m anual/userg.htm Floyd, Sally dan Van Jacobson. 1993. Random Early Detection Gateways for Congestion Avoidance. Lawrence Berkeley Laboratory University of California. http://www.icir.org/floyd/papers/re d/red.html Floyd, et. al. 2001. Adaptive RED: An Algorithm for Increasing the Robustness of RED’s Active Queue Management. http://citeseerx.ist.psu.edu/viewdoc/ download?doi=10.1.1.78.7450&rep =rep1&type=pdf Floyd, Sally. Congestion Control Principles. RFC 2914. http://www.ietf.org/rfc/rfc2914 Hubert , Bert. 2004. Linux Advanced Routing & Traffic Control HOWTO. http://lartc.org/lartc.pdf Li, Suqiao. 1999. Network Traffic Control and Bandwidth Management in Internet: A Differentiated Services Case Study. McGill University. http://digitool.library.mcgill.ca/R/?f unc=dbin-jumpfull&object_id=30688&local_base =GEN01-MCG02 Marieska, Mastura Diana. 2008. Analisis Algoritma Penjadwalan Berbasis Quality of Service pada Wimax. http://digilib.itb.ac.id/ Nagle, John. 1984. Congestion Control in IP/TCP Internetworks. RFC 896. http://tools.ietf.org/html/rfc896 Nichols, et. al. 1998. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474. http://www.ietf.org/rfc/rfc2474.txt

Pramudita, Damar Aji. 2008. Differentiated Service(DiffServ) di Jaringan Testbed menggunakan Disiplin Antrian PRIORITY QUEUEING dan HIERARCHY TOKEN BUCKET. http://digilib.itb.ac.id/ Python v2.6.1 Documentation. http://docs.python.org/ Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering, Sixth Edition. New York: McGraw Hill. Pressman, Roger S. 2005. Software Engineering: A Practitioner’s Approach, Sixth Edition. New York: McGraw Hill. Valenzuela, et. al. 2004. Hierarchical Token Bucket Algorithm to Enhance QoS in IEEE 802.11: Proposal, Implementation dan Evaluation. http://ieeexplore.ieee.org/iel5/9623/ 30413/01400539.pdf?arnumber=14 00539 Welzl, Michael. 2005. Network congestion control : managing Internet traffic. England:John Wiley & Sons Ltd.