Resume
International Journal
OF SOFTWARE DEFINED
NETWORKING
Created by: Pritesh Ranjan, Pankaj Pande, Ramesh Oswal, Zainab Qurani,
Rajneeshkaur Bedi
Software Defined Networking is the most recent
advancement, extending the idea of programmable networks. SDN framework
decouples the network service from underlying implementation providing a novel
approach for application to configure, operate and communicate with the
network. This paper presents a study of programmable networks with emphasis on
the motives and challenges of SDN. Following it we give an overview of SDN
architecture its current applications and future applications.
Software Defined Networking is a result of
such necessities. SDN as an example of “programmable networks” talks of network
evolution. The basic driving idea of SDN is the decoupling of data plane from
control plane. Control Plane is all the logic that decides what is to be done
and instructs the data (or forwarding) plane to implement the decision. Control
plane has the logic of controlling and forwarding behavior like tracking
topology changes, install forwarding rules, computing routes etc. Data plane on
the other hand forwards traffic based on rules as dictated by control plane
logic like forward, filter, buffer, rate-limit and measure packets. SDN
advocate the centralization of control plane and distributed data plane. The
all powerfulcentralized control plane called the controller will control all
the data planes and can be implemented completely in software in software and
installed on commodity hardware.
The immediate benefit
of this separation is the global network view – the controller can see the
status of all routes and switches quickly deciding the best route. It also
helps in selecting the best egress point in an autonomous system for different
flows. Another advantage is the horizontal integration in networking devices
which allows for separate and independent growth of hardware and software. It
also allows rapid innovation of software because many new players can work on
developing controller application as long as they have a well defined API to
communicate with the hardware. This approach promises more flexibility in
choosing the hardware and software by the customer.
SDN
ARCHITECTURE
Today’s network
devices come preinstalled with software from manufacturer and leave a very
little customization option for the customers. This vertical integration in
traditional networks i.e. tight coupling of forwarding plane and control plane,
hinder innovation. The SDN architecture splits the networking devices into data
plane and control plane. Data plane is not intelligent but can perform
forwarding packets very fast and efficiently. It physically carries data
packets from one port to another by following rules that are programmed into
the device hardware. Control plane has the responsibility of adding behavior
into the device; it decides the logic to program the data plane. These two
planes communicate over a secure channel over a standard protocol called
OpenFlow.
OpenFlow provides
an open API between control layer and application layer. This provides an
abstraction for business applications to use facility provided by control layer
without going into the details of their implementation. In the remainder of
this section we will examine the component of the architecture namely: the
infrastructure layer (switch/router), the control layer (controller), southbound
API and northbound API.
Infrastructure
Layer: Switch
When a packet
arrives at the switch the header fields are extracted and matched for the flow
entries installed in the switch, if a match is found, the corresponding action
in flow entry is performed. A default action for packet handling should be
provided -like packet discard, forwarding to another flow table or to the
controller- which will be executed in case of table miss.
The Control
Layer: Controllers
The underlying
infrastructure devices are connected to controller which decides and installs
the rules on switches. To cater scalability and reliability issues two
approaches have been proposed , centralized and distributed. With
a physically as well as logically centralized controller the switches are
heavily dependent on a single controller which can become a single point of
failure or bottleneck. To cater the problem of controller failure OpenFlow
makes a provision for multiple replica controllers which provide backup for the
controller.
In this approach
not all the requests are sent to global controller but only those are forwarded
which require centralized network view. The main purpose of controller is to
add flow rule it can accomplish this task in following way.
Controller
to Switch Message
This type includes
handshake, packet_out message for installing flow entry. It also
handles switch configuration, role configuration, setting asynchronous message
configuration and many others. Controller to switch messages are initiated by
the controller and sent to switch over a TCP connection established between
switch and controller. A message of this type may or may not require a response
from switch.
Following are type
of controller to switch message
1. Features
request/reply message – A features request message is sent by controller
to get the capabilities of switch. A features reply message is sent by
switch which consists of capabilities supported by it. Usually the features
message is sent at the time when connection is established through OpenFlow
channel.
2. Configuration-
The controller can set switch’s configurations through this message. It can
also query switch’s configurations via query message.
3. Modify-State –
Modify state messages are sent by controller to modify state on the switches
.They are used to add/delete and modify flows or group tables on switches .
4. Read-State–
Read state messages are used to get switch statistics.
5. Packet-out– The
controller sends this message to instruct the switch to send a packet out a
particular port or enqueue it or simply drop it by not specifying any action.
6. Barrier –
Controller sends this message to ensure that the message dependencies have been
met. When switch receives this message it has to finish processing all
previously received messages before executing any new message after the Barrier
Request.
Source
: http://www.ijarcsms.com/docs/paper/volume2/issue4/V2I4-0042.pdf
Resume Paper Tugas Akhir Telkom University
PERANCANGAN
DAN ANALISIS SOFTWARE DEFINED NETWORK PADA JARINGAN LAN : PENERAPAN DAN
ANALISIS METODE PENJALURAN PATH CALCULATING MENGGUNAKAN ALGORITMA
DIJKSTRA
Karya
: Brayan Anggita Linuwih, Agus Virgono,
Budhi Irawan
Dalam tugas
akhir ini dilakukan pembuktian penerapan layanan routing menggunakan
metode path calculating algoritma dijkstra sebagai rekayasa kontrol
penjaluran pada jaringan LAN berbasis Software- Defined Network dan
menganalisa perbandingan kinerja metode pemilihan jalur terbaik dalam
lalulintas jaringan pada jaringan LAN berbasis Software-Defined Network dengan
jaringan konvensional yang juga diterapkan algoritma dijkstra dengan arsitektur
yang sama namun tidak memiliki perangkat control plane. Pembuktian dilakukan
dengan melakukan emulasi jaringan sebuah yang terdiri dari 11 buah switch yang
saling terhubung
dengan perangkat control
plane sebagai pengendali sebuah jaringan
Berikut adalah
keunggulan Software-defined networking :
a. Manajemen
terpusat dan kontrol perangkat jaringan dari beberapa vendor.
b. Peningkatan
otomatisasi dan manajemen dengan menggunakan API.
c. Inovasi cepat
melalui kemampuan untuk memberikan kemampuan jaringan baru dan jasa tanpa perlu
mengkonfigurasi perangkat individu atau menunggu penjual rilis.
d. Programmability
oleh operator, perusahaan, vendor perangkat lunak independen, dan pengguna
(bukan hanya produsen peralatan) menggunakan pemrograman umum lingkungan, yang
memberikan semua pihak peluang baru untuk mendorong pendapatan dan
diferensiasi.
e. Peningkatan
kehandalan jaringan dan keamanan sebagai akibat dari pengelolaan jaringan
terpusat dan manajemen otomatis dari perangkat jaringan, penegakan kebijakan
yang seragam, dan meminimalisir kesalahan konfigurasi yang lebih sedikit.
f. Kemampuan
kontrol jaringan akan lebih rinci dengan menerapkan dengan kebijakan di tingkat
sesi, pengguna, perangkat, dan aplikasi secara komprehensif.
g. Penyajian
antarmuka yang lebih baik sebagai aplikasi manajemen jaringan terpus
Secara garis
besar sistem tersebut ditujukan untuk menerapkan aturan penjaluran pada
jaringan berbasisSoftware defined network menggunakan algoritma dijkstra.
Dan selanjutnya membandingkan dua teknologi penjaluran yaitu teknologi
jaringan berbasis router (konvensional) dan teknologi berbasis Software
defined network. Jaringan di simulasikan dalam 2 bentuk sesuai basis
teknologi yang akan diujikan. Perancangan jaringan dimulai dengan menentukan
topologi yang akan digunakan, penerapan topologi pada emulator berbasis
jaringan konvensional dan jaringan Software defined network, pengintegrasian
komponen dalam topologi dan penerapan aturan penjaluran yaitu berbasis
algoritma dijkstra.
Sistematika
pengujian
berikut ini
adalah rincian sistematika pengungujian dari pengujian awal dan pengujian QoS :
·
Pengujian Awal pada Pengujian penjaluran
dilaksanakan dengan melakukan pengiriman paket ICMP sebesar 84 kilobyte dan
tidak di berikan backround traffic. Pengujian ditentukan node sumberke node tujuan
dipilih secara acak. Mewakili setiap router dengan 3 buah skenario. Untuk
pengujian traceroute dilakukan dengan melakukan pengujian pada h1 sebagai node
sumber dan h6 sebagai node sumber. Untuk mengetahui kinerja penjalurkan dilakukan
percobaan menggunakan 3 buah skenario yang telah di tentukan. Dan akan di uji
nilai end to end latency dan pemilihan jalur dari setiap skenario.
· Pengujian QoS dilakukan menggunakan
topologi custom. Dipilih h6 untuk dijadikan node tujuan pengiriman, kemudian h1
sebagai node sumber. Percobaan dilakukan sebanyak 30 kali. Pengambilan data
juga diambil pada jaringan konvensional yang nantinya dijadikan bahan perbandingan
dengan jaringan Software defined Network dari segi QoS.
Dalam pengukuran
ini dibangkitkan trafik [2] UDP dan TCP, yaitu:
a. Trafik
Data dengan inter-departure time (IDT) konstan sebesar 100 pps dengan
ukuruan paket yang terdistribusi poisson μ = 48 bytes, sehingga
membutuhkan bandwidth 38,4 kbps
b. VoIP
dengan G.711 codec tanpa voice activation detection (VAD) sebanyak 100 pps
dengan ukuran paket 80 bytes, sehingga membutuhkan bandwidth 70,4 kbps.
c. Selain
pemberian tiga jenis trafik tersebut secara bersamaan, dibangkitkan pula
background traffic yang bervariasi (25 Mbps, 50 Mbps, 75 Mbps, dan 100 Mbps)
menggunakan Iperf. Percobaan ini dilakukan untuk mengetahui pengaruh kepadatan
trafik terhadap pemilihan jalur dengan melihat kualitas dari pengiriman trafik
data yang sampai di penerima.
Hasil
pengujian performansi penerapan algoritma dijkstra berbasis jaringan SDN
menunjukkan bahwa nilai dari keempat parameter QoS masih berada pada nilai yang
menjadi standar ITU-T G.1010 sertamemiliki nilai delay dan jitter yang
lebih baik dibandingkan penerapan OSPF berbasis jaringan konvensional.
Nilai QoS
untuk UDP pada layanan data, VoIP masing-masing bervariasi dan berada di
kisaran (5.17 – 145.81) ms untuk delay, (0.05 - 0.93) ms untuk jitter,
(13.22 – 73.41) kbps untuk throughput, 8,05 % - 33,81 % untuk packet
loss di semua skenario yang telah dibuat. Adapun nilai QoS untuk TCP pada
layanan data masingmasing bervariasi dan berada di kisaran (10.32 – 20.21) ms
untuk delay, (0.5 - 3.02) ms untuk jitter, (38.12 –38.27) kbps
untuk throughput di semua skenario yang telah dibuat.
Sumber:
https://openlibrary.telkomuniversity.ac.id/pustaka/files/107465/jurnal_eproc/perancangan-dan-analisis-software-defined-network-pada-jaringan-lan-penerapan-dan-analisis-metode-penjaluran-path-calculating-menggunakan-algoritma-dijkstra.pdf

















