1. Pendahuluan. 2. Tinjauan Pustaka

1 1. Pendahuluan

Dalam kajian Teknologi Virtualisasi Tingkat Sistem Operasi, mesin virtual (guest OS) yang disediakan harus sama dengan induk mesin (host OS) dimana Teknologi Virtualisasi Tingkat Sistem Operasi tersebut berada [1]. Dengan keterbatasan fungsi dari teknologi virtualisasi tersebut, kemudian dilakukan penelitian untuk mengatasi masalah tersebut yaitu dengan menggunakan teknologi virtulisasi cloud computing. Salah satu software

cloud computing yang dapat digunakan untuk membangun layanan cloud computing Infrastructure as a Service (IaaS) adalah OpenStack. OpenStack

memiliki beberapa service, dan salah satu service yang digunakan untuk membuat sebuah virtual server serta melakukan manajemen terhadap

instance atau mesin virtual adalah compute yang mempunyai project name

Nova. Compute mengatur tentang pengalokasian processor, memory dan

resource yang lain. Dalam penelitian ini akan dibahas mengenai cara kerja

salah satu service yang ada di OpenStack yaitu compute dan akan dilakukan analisis mengenai keelastisitasan dari OpenStack. Analisis dilakukan dengan menggunakan bantuan Devstack.

2. Tinjauan Pustaka

Penelitian yang telah dilakukan oleh Omar Sefraoui, Mohammed Aissaoui, dan Mohsine Eleuldj dengan judul “OpenStack : Toward an

Open-Source Solution for Cloud Computing ” melakukan studi perbandingan antara

beberapa software cloud yaitu, Eucalyptus, OpenNebula, dan OpenStack. Dari hasil perbandingan ketiga software cloud tersebut didapat OpenStack merupakan solusi cloud terbaik dikarenakan OpenStack merupakan software

cloud open source dan support terhadap standard baru. [2]

Penelitian tentang cloud computing dengan deployment model

infrastructure as a service juga dilakukan oleh Luchi Sulistyowati. Penelitian

dilakukan dengan menggunakan UEC ( Ubuntu Enterprise Cloud), UEC digunakan untuk melakukan implementasi cloud computing untuk penyediaan

web server. Berdasarkan dari penelitan yang telah dilakukan cloud computing

dengan layanan Infrastructure as a Service dapat digunakan dan menopang kinerja penyediaan web server. [3]

Dengan melihat beberapa penelitian yang sudah dilakukah sebelumnya, akhirnya dilakukan penelitian untuk melakukan analisis terhadap cara kerja dan elastibilitas dari layanan cloud computing infrastructure as a

service yang menggunakan software cloud OpenStack. Penelitian akan

dikhususkan terhadap komponen OpenStack yaitu komponen compute, untuk melihat seberapa elastis komponen tersebut.

Cloud computing adalah sebuah bentuk layanan yang memungkinkan

untuk dapat hadir dimanapun, memberikan kenyamanan, akses jaringan sesuai permintaan (on-demand) ke lokasi sumber daya komputasi terkonfigurasi (misalnya, jaringan, server, storage, aplikasi, dan layanan) yang dapat dengan cepat dijalankan dan diluncurkan, dengan upaya pengelolaan minimal atau

2

dengan menggunakan penyedia layanan jasa. Berdasarkan service model yang ada, cloud computing dibagi menjadi 3 hal yaitu, infrastructure as a service,

platform as a service dan software as a service. Sedangkan berdasarkan deployment model, cloud computing dibagi menjadi 4 hal yaitu, private cloud, community cloud, public cloud dan hybrid cloud. [4]

Infrastructure as a service (IaaS) merupakan salah satu komponen

dari cloud computing jika dilihat dari service models yang diberikan. Server, sistem pemberkasan, switch, router dan sistem lain digabungkan dalam sebuah pool dan dibuat agar dapat diakses untuk mengurusi beban kerja yang terjadi dalam komponen aplikasi sampai pada aplikasi berkomputasi level tinggi. [5]

Openstack merupakan salah satu software cloud yang digunakan untuk membangun infrastructure as a service, openstack sendiri bersifat open

source. Terdapat 7 service inti dari OpenStack yaitu : Compute, Object Storage, Identity, Dashboard, Block Storage, Network dan image service. Compute dengan project name Nova adalah service yang digunakan untuk

menyediakan sebuah virtual server. Object Store dengan project name Swift, merupakan service yang digunakan untuk menyimpan data dalam skala yang besar. Identity dengan project name Keystone menyediakan autentikasi dan autorisasi bagi semua layanan OpenStack. Dashboard dengan project name

Horizon merupakan sebuah modul web-based yang dapat digunakan untuk

melakukan management OpenStack. Block Storage dengan project name

Cinder menyediakan infrastruktur untuk melakukan management terhadap volume yang ada di OpenStack. Network dengan project name Neutron ada

untuk melayani keperluan jaringan di OpenStack. Image Service dengan

project name Glance adalah komponen yang digunakan untuk membuat

sebuah virtual disk images. [6] Konseptual arsitektur pada OpenStack dapat digambarkan seperti pada Gambar 1

3

Gambar 1 Conceptual Architecture [7]

Pada Gambar 1 merupakan service yang ada di OpenStack. Dijelaskan juga hubungan masing-masing service yang ada di OpenStack. Setiap service yang ada tidak berdiri sendiri, tapi saling bergantung. Compute merupakan

service dari OpenStack yang dibahas dipenelitian ini. Compute memiliki

beberapa komponen inti, seperti nova-api, nova-compute, nova-scheduler, dan nova-conductor.

3. Metode Penelitian

Metode yang digunakan dalam penelitian ini adalah metode Network

Development Life Cycle (NDLC). Dalam metode ini, terdapat 6 tahapan yang

digunakan, setiap tahapan akan menghasilkan sebuah output tertentu. Output yang dihasilkan dari setiap tahapan akan menjadi dasar dari tahapan selanjutnya. Gambar 2 menjelaskan alur dari NDLC.

4

Gambar 2 Network Development Life Cycle [8]

Analysis, Tahapan analysis dimulai dengan membuat check list

terhadap kebutuhan hardware dan software yang akan digunakan dalam penelitian. Kebutuhan hardware dan software ini disesuaikan dengan kasus atau permasalahan yang dihadapi yaitu tentang analisis salah satu komponen yang ada di Openstack, nova, dan proof of concept dari sebuah fungsi cloud yaitu elastisitas. Sistem operasi yang digunakan dalam penelitian ini adalah Ubuntu Server 12.04 64 bit, pada penelitian ini, installasi openstack tidak menggunakan script dari openstack melainkan menggunakan shell script dari devstack, untuk versi Openstack yang digunakan adalah Openstack dengan

codename Havana. Sedangkan untuk kebutuhan hardware, hanya

membutuhkan dua buah komputer, yang pertama yang berfungsi sebagai

controller node dan compute node, sedangkan komputer kedua digunakan

untuk melakukan konfigurasi. Selain itu, juga dibutuhkan hardware lain seperti switch dan kabel unshielded twisted pair (UTP) yang digunakan untuk menunjang komunikasi data.

Design, Pada tahapan ini dibangun sebuah arsitektur jaringan baru

dan topologi logikanya yang didasarkan dari hasil analisis. Arsitektur jaringan yang baru digambarkan seperti pada gambar 3.

5

Gambar 3Rancangan Topologi Jaringan Cloud

Pada Gambar 3, modem digunakan untuk mengakses internet, akses internet diperlukan ketika pertama kali melakukan penginstalan Devstack.

Cloud server merupakan server utama yang digunakan, pada server ini

terdapat semua komponen dari Openstack yang sudah terinstall. Client sendiri digunakan untuk dapat mengakses cloud server melalui dashboard atau melalui SSH.

Adapun spesifikasi perangkat keras yang digunakan dalam penelitian ini adalah sebagai berikut :

Tabel 1Spesifikasi Perangkat

Perangkat Spesifikasi Fungsi

Server - Prosesor Intel® core™ 2

quad CPU Q9300 @ 2.50 GHz (4 CPUs)

- RAM 3 GiB - 500 GiB HDD - Ubuntu Server 12.04

Controller node dan Compute node, tempat

masing-masing service dari OpenStack

berjalan. Laptop - Prosesor Intel® core™ i3

CPU m 330 @2.13 GHz (4 CPUs)

- RAM 2 GiB - 320 GiB HDD

Client dan konfigurasi

OpenStack.

Switch Switch untuk jaringan

192.168.1.1 / 24

192.168.1.20 / 24

Host IP 192.168.1.10 / 24 Fixed IP 10.11.12.0 / 24 Floating IP 192.168.1.224 / 27

6

Perangkat lunak dan perangkat keras diatas sudah memenuhi kebutuhan untuk melakukan penelitian tentang analisis fungsi compute pada openstack yang dikarenakan pada tahap pembuatan instance hanya menggunakan flavor m1.low. Pada tahap design, juga dilakukan pembuatan

flowchart mengenai alur pembuatan cloud instance dan tahapan yang terjadi

didalamnya.

Gambar 4 Flowchart Pembuatan Cloud Instance

Pada Gambar 4 merupakan flowchart pembuatan cloud instance, dimulai dari proses pemilihan image sistem operasi, pemilihan jenis flavors sampai kepada hasil yang berupa sebuah cloud instance.

7

Gambar 5 Detail flowchart proses pembuatan instance

Dalam pembuatan cloud instance, terdapat beberapa tahapan yang terjadi seperti yang ditunjukan pada Gambar 5, dimulai dari tahap scheduling,

building, networking, block device mapping, dan yang terakhir tahap spawning. Pada tahap design juga dilakukan pengalokasian alamat IP seperti

yang tertera pada tabel 2.

Tabel 2Pengalokasian Alamat IP

Mesin Alamat IP Fungsi

Server 192.168.1.10 / 24 10.11.12.0/24 192.168.1.224/27 Host IP Fixed IP Floating IP

8

Simulation prototyping, Pada tahapan ini dilakukan simulasi terhadap prototype dari desain yang sudah dirancang dengan menggunakan bantuan

aplikasi GNS3. Hasil dari simulasi tersebut ditunjukan oleh gambar 7.

Gambar 6 Simulation Prototyping dengan GNS3

Pada Gambar 6, server adalah tempat dimana OpenStack diinstall dengan menggunakan shell script Devstack. Didalam server tersebut, terdapat dua node yang diinstall dalam satu server yang sama, yaitu compute node dan controller node.

Implementation, Pada bagian ini dibahas mengenai pembangunan

proyek secara fisik yang mencakup instalasi mesin, konfigurasi jaringan fisik dan pengaturan alamat IP. Implementasi dilakukan dengan menggunakan

script dari devstack.

Monitoring, Tahapan monitoring dilakukan untuk mengetahui sistem

berjalan dengan baik secara keseluruhan. Terutama untuk mengetahui penggunaan resource yang terpakai. Pengamatan terhadap resource yang dipakai diperlukan untuk mengambil hasil analisis yang dibutuhkan. Aspek yang akan diamati yaitu mengenai penggunaan RAM serta lama downtime ketika melakukan proses resize image.

Management, dalam tahapan management dilakukan pengalokasian flavor atau computing resources seperti processor, RAM dan disk storage

yang dapat dipilih oleh tenant atau penyewa. Dalam proses management dilakukan penambahan flavor yang mempunyai nama m1.low.

Gambar 7 flavors m1.low

Host IP 192.168.1.10 / 24 Fixed IP 10.11.12.0 / 24 Floating IP 192.168.1.224 / 27

192.168.1.20 / 24 192.168.1.1 / 24

9

Flavors m1.low mempunyai RAM sebesar 1024 MB dan mempunyai 1 buah

VCPU, 0 MB swap dan 0 GB ephemeral disk seperti yang terlihat pada Gambar 7.

4. Hasil dan Pembahasan

Pada tahapan ini dijelaskan mengenai hasil dari analisis fungsi

compute. Dalam Openstack sudah disediakan tipe-tipe flavors yang dapat

digunakan dalam pembuatan instance.

Gambar 8tipe-tipe flavors

Gambar 8 menjelaskan mengenai tipe-tipe flavors yang ada didalam Openstack, dari m1.nano sampai m1.xlarge, flavors juga dapat dikonfigurasi sesuai dengan keinginan. Dalam analisis ini dilakukan uji coba pembuatan

instance menggunakan image linux mint dengan tipe flavors m1.tiny dan

kemudian akan dilakukan resize instance dari m1.tiny ke m1.low dalam kondisi instance sedang running untuk membuktikan sifat elastis dari OpenStack.

Pada saat client menjalankan sebuah instance, API akan menjalankan fungsi run_instance() dan mengirimkan request untuk membuat sebuah

instance baru kepada nova-api. Nova-api kemudian menerima permintaan

tersebut dan mengirimkan permintaan untuk melakukan validasi auth-token dan access permission ke pada keystone.

Gambar 9tahap scheduling

Keystone kemudian melakukan validasi terhadap token yang diterima

10

kemudian berinteraksi dengan nova-database, dan dilakukan pembuatan

database entry terhadap instance baru. Setelah itu nova-api akan meminta

kepada nova-scheduler untuk melakukan proses filtering dan weighting guna memperoleh host ID yang valid. Nova-scheduler kemudian berinteraksi dengan nova-database untuk menentukan host yang tepat yang dapat digunakan oleh instance. Setelah melalui proses filtering dan weighting, nova-scheduler akan meminta kepada nova-compute untuk menjalankan

instance di host yang sudah ditentukan. Setelah nova-compute menerima

permintaan tersebut dari nova-scheduler, nova-compute kemudian melakukan interaksi dengan nova-conductor untuk meminta informasi tentang instance yang berupa host ID dan flavor yang digunakan (Ram, CPU, Disk).

Nova-conductor kemudian berinteraksi dengan nova-database untuk meminta

informasi tersebut, nova-database kemudian memberikan informasi instance kepada conductor dan kemudian mengirimkannya kepada

nova-compute. Setelah itu nova-compute akan melakukan penguploadan image dari image storage dengan cara mengirimkan auth-token kepada glance untuk

mendapatkan image URL, glance kemudian melakukan verifikasi kepada

keystone dan sesudah itu nova-compute akan memperoleh image metadata.

Setelah tahap ini selesei, berakhir sudah tahapan scheduling seperti yang terlihat pada Gambar 9. Setelah melalui tahapan scheduling, tahapan selanjutnya adalah tahapan networking. Pada tahapan ini nova-compute akan meminta kepada neutron-server untuk melakukan pengalokasian dan konfigurasi jaringan supaya instance dapat memperoleh IP address.

.

Gambar 10tahap Block Device Mapping

Tahap selanjutnya adalah tahap block device mapping seperti yang terlihat pada Gambar 10. Tahapan ini dilakukan untuk memperoleh volume atau disk yang akan digunakan oleh instance. Pada tahap ini, nova-compute melakukan interaksi kepada volume API untuk memasangkan volumes kepada

instance. Cinder-api kemudian melakukan validasi kepada keystone. Setelah

proses tersebut selesei nova-compute akan memperoleh informasi tentang

block-storage.

11

Tahap terakhir adalah tahap spawning, seperti yang terlihat pada Gambar 11, pada tahap ini nova-compute menghasilkan data untuk driver

hypervisor. Sesudah semua tahapan dari scheduling sampai dengan spawning

diselesaikan, instance akan berada pada power state running, seperti yang terlihat pada gambar 12, jika sudah berada pada kondisi running maka

instance sudah berhasil dibuat dan dapat dijalankan.

Gambar 12 running instance

Untuk pengaksesan instance dapat dilakukan dengan dengan mengakses VNC console yang terdapat pada dashboard.

Gambar 13 akses instance melalui VNC console

Pada Gambar 13 merupakan hasil akhir dari pembuatan instance yang diakses melalui VNC console. Setelah dilakukan analisis mengenai cara kerja saat OpenStack melakukan pembuatan instance, kemudian dilakukan juga analisis tentang elastisitas dari OpenStack yaitu dengan melakukan uji coba resize

12

Gambar 14 state diagram fungsi nova.compute.api.resize

Pertama kali akan dilakukan pengecekan apakah terjadi perubahan flavor_id atau tidak, jika tidak terdapat perubahan maka proses yang dilakukan adalah migrasi instance ke host tanpa melakukan penggantian flavor. Kemudian dilakukan juga reservasi kuota untuk instance type yang baru. Setelah itu task state instance akan diperbaharui menjadi RESIZE_PREP dan nova-scheduler akan dipanggil untuk menjalankan fungsi prep_resize().

Gambar 15 state diagram fungsi nova.scheduler.manager.prep_resize

Pada saat fungsi tersebut berjalan dilakukan proses filtering host, proses yang dilakukan untuk memperoleh valid host. Apabila tidak ditemukan host yang valid maka instance state akan dirubah kembali menjadi active dan akan terjadi rollback quota reservation. Jika terdapat host yang valid nova-compute.manager dipanggil untuk menjalankan fungsi prep_resize().

13

Fungsi prep_resize() akan mengirimkan notifikasi mengenai instance usage kepada nova-conductor dan memanggil fungsi _prep_resize() yang berguna untuk melakukan validasi apakah resize ke host yang sama diperbolehkan atau tidak, sesuai dengan konfigurasi yang sudah dibuat. Kemudian informasi instance yang sudah diperbaharui dikirim ke nova-conductor dan fungsi resize_instance() dijalankan.

Gambar 17 state diagram fungsi nova.compute.manager.resize_instance

Fungsi resize_instance() akan meminta informasi mengenai network dan informasi mengenai instance kepada nova-conductor. Kemudian task state instance akan diperbaharui menjadi RESIZE_MIGRATING. Setelah itu akan meminta informasi mengenai block device dan kemudian meminta compute driver untuk melakukan migrasi disk dan power off instance. Kemudian sesudah itu menghubungi volume service untuk memutuskan hubungan volume yang terhubung dengan instance. Setelah itu, network service akan dipanggil untuk melakukan migrasi network. Task state instance kemudian akan diperbaharui menjadi RESIZE_MIGRATED. Fungsi yang akan berjalan selanjutnya adalah fungsi finish_resize().

14

Pada fungsi ini jika terjadi perubahan flavor maka dilakukan update flavor instance dari flavor type yang lama ke flavor type yang baru. Kemudian dilakukan pengaturan network instance ke host tujuan dengan memanggil network service. Instance task state akan diperbaharui lagi menjadi RESIZE_FINISHED, setelah itu nova-compute akan mengambil informasi mengenai block device dari volume service dan task state instance akan dirubah menjadi RESIZED.

Gambar 19 state diagram fungsi nova.compute.api.confirm_resize

Tahapan terakhir yang dijalankan adalah confirm resize, fungsi yang berjalan pada tahap ini adalah fungsi nova.compute.api.confirm_resize. Dilakukan reservasi quota kemudian pengkonfirmasian pergantian resource. Sesudah itu instance state akan berubah menjadi ACTIVE, dan dilakukan commit quota reservation. Instance sudah berhasil dilakukan pergantian flavor.

Gambar 20 Running instance sesudah proses resize

Pada gambar 20 nampak bahwa flavor instance sudah berganti dari m1.tiny menjadi m1.low yang mempunyai resource RAM sebesar 1 GB.

15

Dapat dilihat juga di gambar 21, melalui system monitor yang terdapat di linux mint bahwa memory yang terpasang sudah berganti menjadi 1001.6 MiB yang semula.

Dilakukan juga pengujian untuk mengetahui bagaimana cara kerja pembagian memori pada OpenStack. Jumlah RAM fisik yang digunakan pada pengujian ini sebesar 3 GB, tetapi pada server OpenStack hanya digunakan 2 GB. Pengujian dilakukan dengan menguji quota, quota merupakan batas limit penggunaan resource, dengan menggunakan parameter RAM. Pertama kali pengujian dilakukan dengan melakukan pengaturan quota RAM sebesar 2 GB.

Gambar 22 status intances

Kemudian dibuat 2 buah instance dengan masing-masing instance memiliki RAM sebesar 1 GB, dan kedua instance tersebut dijalankan, seperti yang terlihat pada Gambar 22. Hasilnya, kedua instance tersebut dapat dijalankan dengan lancar, hal ini dikarenakan masih terdapat alokasi memori yang tersedia untuk kedua instance tersebut.

Gambar 23 instances sebelum dijalankan

Pengujian yang kedua dilakukan dengan cara pengaturan quota melebihi dari batas RAM fisik atau overcommit quota. Hal ini dapat dilakukan karena terdapat management memory, apabila terdapat memory yang idle akan dialokasikan kepada instance yang membutuhkan memory yang lebih. Pada Gambar 23 terdapat 3 instances yang dibuat untuk melakukan pengujian, setiap instance mempunyai RAM sebesar 1 GB. Gambar 23 menunjukkan kondisi ketika setiap instance sudah dapat digunakan tetapi belum dijalankan.

16

Gambar 24 instances sesudah dijalankan

Ketiga instances tersebut kemudian dijalankan secara bergantian dimulai dari linux mint kemudian linux mint 2 dan terakhir linux mint 3. Setiap instance akan diberi beban untuk memaksimalkan penggunaan RAM. Pada Gambar 24 terdapat 2 instance yang berjalan dengan lancar yaitu, linux mint dan linux mint 2. Tetapi pada instance linux mint 3 tidak dapat berjalan. Hal ini dikarenakan memori yang dimiliki oleh server sudah dialokasikan terlebih daulu untuk kedua instance yang pertama kali dijalankan.

Tabel 3 Status instance

Instance Memory total Memory used Status

Linux mint 1025648k 868176k Running

Linux mint 2 1025648k 894762k Running

Linux mint 3 1025648k - Shutdown

Pada Tabel 3, merupakan hasil dari monitoring RAM setiap instance yang menggunakan command linux top. Pada saat instance linux mint dan linux mint 2 sudah hampir mencapai batas maksimal penggunaan RAM, instance linux mint 3 statusnya berubah menjadi shutdown dan tidak dapat dijalankan.

Sesudah tahapan pengujian selesei, kemudian dilakukan tahap monitoring. Dalam proses monitoring juga terdapat perubahan kondisi RAM, monitoring ini dilakukan ketika dalam proses pembuatan instance sampai

instance tersebut berhasil dijalankan. Monitoring dilakukan dengan

menggunakan command dari linux yaitu top.

Gambar 25 Monitoring awal sebelum pembuatan instance

Pada gambar 25 terlihat bahwa kondisi awal free RAM adalah 681492k, kondisi ini merupakan kondisi RAM sebelum dilakukan pembuatan instance.

17

Gambar 26 Monitoring sesudah instance running

Setelah dilakukan pembuatan instance, terjadi perubahan pada kondisi RAM yang terpakai yaitu menjadi 3889292k. Hal ini terjadi karena instance sedang dalam posisi running yang ditunjukan dengan berjalannya hypervisor kvm.

Gambar 26 Monitoring downtime

Gambar 27 Monitoring downtime

Dilakukan juga proses monitoring untuk mengetahui lama downtime ketika melakukan proses resize instance ke flavor yang baru. Proses

monitoring ini menggunakan aplikasi PRTG, dengan menggunakan sensor

ping. Pada Gambar 26 dan 27 merupakan hasil dari proses monitoring

downtime, dapat dilihat dari kedua gambar tersebut terjadi downtime selama

30 detik. 5. Kesimpulan

Dari penelitian yang telah dilakukan tentang analisis cara kerja dan analisis elastisitas teknologi cloud computing Infrastructure as a Service yang dalam hal ini menggunakan OpenStack. Dapat disimpulkan bahwa ketika terjadi proses penggantian flavor, terjadi downtime selama 30 detik yang mengakibatkan instance tidak dapat diakses. Dari hasil uji coba yang sudah dilakukan dapat disimpulkan bahwa di OpenStack dapat dilakukan

18

overcommit quota, tetapi mempunyai batasan apabila RAM yang tersedia

sudah terpakai penuh maka apabila terdapat instance lain yang ingin berjalan harus menunggu sampai resource RAM kembali tersedia.

6. Daftar Pustaka

[1] Bayu, TI, dkk, 2010, Penerapan Teknologi Virtualisasi Tingkat Sistem Operasi pada Server Linux Ubuntu 8.04 Menggunakan OpenVZ, Aiti Vol. 7 No. 1.

[2] Sefraoui. O., Aissaoui, M., Eleuldj, M., 2012, OpenStack: Toward

an Open-Source Solution for Cloud Computing, IJCA, (55)03 :

38-42.

[3] Sulistyowati, Luchi, 2012, Implementasi Cloud Computing sebagai Infrastructure as a Service untuk Penyediaan Web Server.

[4] Mell, P., Grance, T., 2011, The NIST Definition of Cloud

Computing.

[5] Carolan, J dan Gaede, S, 2009, Introduction to Cloud Computing Architechture White Paper-1st Edition.

[6] OpenStack, 2013, OpenStack Compute Administration Guide. [7] OpenStack, 2014, OpenStack Cloud Administrator Guide.

[8] Goldman, J.E., & Rawles, P.T., 2001, Applied Data

Communications, A Business-Oriented Approach, Hoboken : John