MAKALAH komunikasi data

Resource reservation protocol (RSVP)

ZAKIY UBAID
D41107105

JURUSAN ELEKTRO FAKULTAS TEKNIK

UNIVERSITAS HASANUDDIN

2010

Resource reservation protocol (RSVP)

Reservasi sumber daya protokol (RSVP) didefinisikan oleh RFC 2205 adalah kontrol signaling
protokol
yang memungkinkan dua host berkomunikasi untuk mengatur dengan jaringan untuk reservasi
dari band-lebar dan sumber daya lainnya (misalnya, buffering dan sumber daya forwarding)
yang diperlukan untuk memastikan minimum kualitas pelayanan (QoS) untuk data diangkut
antara host.

Dalam pengertian ini, RSVP merupakan protokol yang digunakan untuk menjamin kualitas tinggi
transportasi data, dan khususnya untuk pengangkutan data flow atau aliran (misalnya, suara
real-time, video atau multimedia sinyal). Namun tidak seperti protokol transportasi lainnya,
RSVP tidak sendiri digunakan untuk membawa data pengguna yang sebenarnya. Data pengguna
biasanya akan dilakukan oleh TCP (protokol kontrol transmisi), MPLS (multiprotocol label
switching) atau bahkan kombinasi keduanya.

Sumber Daya Reservation Protocol (RSVP) adalah protokol Transport Layer dirancang untuk
cadangan sumber daya di jaringan untuk sebuah layanan internet terintegrasi. RSVP beroperasi
melalui IPv4 atau IPv6 Internet Layer dan menyediakan receiver-setup dimulai dari pemesanan
sumber daya untuk aliran multicast atau unicast data dengan skala dan ketahanan. RSVP bukan
merupakan transportasi data aplikasi tetapi mirip dengan protokol kontrol, seperti ICMP, IGMP.
RSVP dapat dijelaskan dalam RFC 2205.

RSVP dapat digunakan oleh salah satu host atau router untuk meminta atau memberikan
tingkat tertentu kualitas layanan (QoS) untuk aplikasi data stream atau arus. RSVP
mendefinisikan bagaimana menempatkan aplikasi pemesanan dan bagaimana mereka dapat
melepaskan sumber daya reserved apabila kebutuhan untuk mereka telah berakhir. RSVP
operasi umumnya akan menghasilkan sumber daya yang disediakan di setiap node di sepanjang
jalan.

RSVP itu sendiri bukanlah sebuah protokol routing dan dirancang agar dapat beroperasi dengan
protokol routing saat ini dan masa depan.

Sejarah dan standar terkait

RSVP digambarkan dalam serangkaian dokumen RFC dari IETF:

    * RFC 2205: Versi 1 spesifikasi fungsional telah dijelaskan di RFC 2205 (September 1997) oleh
IETF. Versi 1 menjelaskan antarmuka untuk masuk (lalu lintas) kontrol yang didasarkan "hanya"
pada ketersediaan sumber daya. Kemudian RFC2750 memperpanjang dukungan admission
control.
    * RFC 2210 mendefinisikan penggunaan RSVP dengan terkontrol-beban RFC 2211 dan RFC
2212 dijamin layanan pengendalian QoS. More details di Pelayanan Terpadu. Juga
mendefinisikan format penggunaan dan data dari objek data (yang membawa informasi sumber
daya reservasi) didefinisikan oleh RSVP dalam RFC 2205.
    * RFC 2211 menentukan perilaku elemen jaringan yang diperlukan untuk memberikan
layanan Terkendali-Load.
    * RFC 2212 menentukan perilaku elemen jaringan yang diperlukan untuk memberikan
jaminan layanan QoS.
    * RFC 2750 menjelaskan perpanjangan yang diusulkan untuk mendukung kebijakan
pengendalian masuk generik yang berbasis di RSVP. Ekstensi termasuk spesifikasi obyek
kebijakan dan deskripsi pada penanganan peristiwa kebijakan. (Januari 2000).
    * RFC 3209, "RSVP-TE: Extensions untuk RSVP untuk Terowongan LSP" (Desember 2001).
    * RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource
Reservasi Rekayasa Protokol-Traffic (RSVP-TE) Extensions" (Januari 2003).
    * RFC 3936, menjelaskan "Prosedur untuk Memodifikasi reservasi resource Protocol (RSVP)"
(Oktober 2004), praktik terbaik saat ini dan menetapkan prosedur untuk memodifikasi RSVP.
    * RFC 4495, meluas "A Resource Reservation Protocol (RSVP) Extension untuk Pengurangan
Bandwidth dari Flow Reservasi" (Mei 2006), RSVP untuk memungkinkan bandwidth dari
pemesanan yang sudah ada harus dikurangi, bukan meruntuhkan reservasi.
    * RFC 4558, "Simpul-ID Resource Reservasi Berbasis Protokol (RSVP) Hello: Sebuah
Pernyataan Klarifikasi" (Juni 2006).

Para RSVP saat ini didefinisikan gaya reservasi adalah:

   1. Tetap filter - cadangan sumber daya untuk sebuah aliran tertentu.
   2. Shared eksplisit - cadangan sumber daya untuk beberapa arus dan berbagi semua sumber
daya
   3. Wildcard filter - cadangan sumber daya untuk jenis umum mengalir tanpa menyebutkan
aliran, semua berbagi arus sumber daya

Permintaan reservasi RSVP terdiri dari flowspec dan filterspec dan pasangan disebut
flowdescriptor sebuah. Efek pada masing-masing node spec adalah bahwa sementara flowspec
set parameter dari penjadwal paket pada sebuah node, filterspec set parameter di classifier
paket.
[Sunting] Pesan
Ada dua jenis utama pesan:
    * Pesan Path (jalur)
    Pesan path dikirim dari host pengirim sepanjang jalur data dan menyimpan status jalan di
setiap node di sepanjang jalan.
    Kondisi jalan mencakup alamat IP dari node sebelumnya, dan beberapa objek data:

           1. template pengirim untuk menggambarkan format data pengirim

           2. pengirim tspec untuk menggambarkan karakteristik arus lalu lintas arus data
           3. adspec yang membawa data iklan (lihat RFC 2210 untuk lebih jelasnya).

    * Reservasi pesan (resv)

    Pesan resv dikirim dari receiver ke host pengirim sepanjang jalur data sebaliknya. Pada setiap
node tujuan alamat IP dari pesan resv akan berubah ke alamat dari simpul berikutnya pada
reverse path dan sumber alamat IP ke alamat alamat node sebelumnya pada reverse path.
    Pesan resv meliputi objek data flowspec yang mengidentifikasi sumber daya yang mengalir
kebutuhan.

Data objek pada pesan RSVP dapat ditransmisikan dalam urutan apapun. Untuk daftar lengkap
pesan RSVP dan objek tanggal lihat RFC 2205.
[Sunting] Operasi

Sebuah host RSVP yang perlu untuk mengirimkan aliran data dengan QoS yang spesifik akan
mengirimkan pesan RSVP jalan setiap 30 detik yang akan melakukan perjalanan sepanjang rute
unicast atau multicast yang ditetapkan sebelumnya oleh protokol routing kerja. Jika pesan path
sampai pada sebuah router yang tidak mengerti RSVP, router yang meneruskan pesan tanpa
menafsirkan isi pesan dan tidak akan cadangan sumber daya untuk aliran.

Mereka yang ingin mendengarkan mereka mengirim resv yang sesuai (singkatan dari
"Cadangan") pesan yang kemudian menelusuri jalan belakang untuk pengirim. Pesan resv berisi
spesifikasi aliran. Ketika router menerima pesan RSVP resv akan:

   1. Melakukan pemesanan berdasarkan parameter permintaan. Untuk proses kontrol

admission control dan kebijakan parameter permintaan dan bisa menginstruksikan penggolong
paket dengan benar menangani subset yang dipilih dari paket data atau bernegosiasi dengan
lapisan atas bagaimana penanganan paket harus dilakukan. Jika mereka tidak dapat
mendukung reservasi yang diminta, mereka mengirim pesan menolak untuk membiarkan
pendengar tahu tentang hal itu.
   2. Teruskan permintaan hulu (dalam arah pengirim). Pada setiap node flowspec pesan resv
dapat dimodifikasi oleh sebuah forwarding node (misalnya dalam kasus aliran multicast
pemesanan reservasi permintaan dapat digabungkan).
   3. Router kemudian menyimpan sifat aliran, dan juga polisi itu. Ini semua dilakukan dalam
keadaan lunak, jadi jika tidak ada yang mendengar untuk jangka waktu tertentu, maka pembaca
akan time out dan pemesanan akan dibatalkan. Memecahkan masalah ini jika salah satu
pengirim atau penerima crash atau menutup salah tanpa terlebih dahulu membatalkan
reservasi. Router individu dapat, atas pilihannya, polisi lalu lintas untuk memeriksa bahwa itu
sesuai dengan spesifikasi mengalir.

Pesan resv juga memiliki objek FilterSpec, ia mendefinisikan paket yang akan menerima QoS
diminta didefinisikan dalam flowspec tersebut. Sebuah spec filter sederhana bisa saja alamat IP
pengirim dan opsional yang UDP atau port TCP.
[Sunting] Fitur-fitur lainnya

    * Integritas - RSVP pesan yang ditambahkan dengan message digest diciptakan dengan
menggabungkan isi pesan dan kunci bersama dengan menggunakan message digest algoritma
(biasanya MD5). Kuncinya dapat didistribusikan dan dikonfirmasikan menggunakan jenis pesan
2: integritas tantangan permintaan dan respon integritas tantangan.
    * Pelaporan Error - ketika sebuah node mendeteksi kesalahan, pesan kesalahan dibuat
dengan kode kesalahan dan disebarkan hulu di jalan balik ke pengirim.
    * Informasi tentang aliran RSVP - dua jenis pesan diagnostik memungkinkan operator jaringan
untuk meminta informasi negara RSVP pada aliran tertentu.
    * Fasilitas Diagnostik - Sebuah ekstensi untuk standar yang memungkinkan pengguna untuk
mengumpulkan informasi mengenai kondisi RSVP di sepanjang jalan. RFC2745 - RSVP Diagnostik
Pesan

Proses dasar reservasi resource menggunakan RSVP

Setelah membuat sebuah koneksi dengan cara normal (yaitu, dengan TCP dan IP), RSVP
digunakan dalam 'tahap kedua' dari koneksi set-up untuk cadangan bandwidth yang diperlukan
untuk memenuhi kualitas pelayanan (QOS) seperti yang didefinisikan oleh spesifikasi aliran
(flowspec). Reservasi bandwidth ( atau sumber daya lain) dengan RSVP dilakukan untuk setiap
arah komunikasi secara terpisah.

Sejauh RSVP yang bersangkutan ada host mengirimkan (pada akhir hulu satu-arah
koneksi) dan host penerima (pada akhir hilir sambungan). Dan jika pemesanan
kapasitas untuk kedua arah komunikasi yang diperlukan, maka RSVP harus digunakan
dua kali - kedua ujung yang didirikan sebagai kedua ujung hulu dan hilir dari dua yang terpisah
satu arah koneksi.

Proses reservasi dimulai dengan pesan path RSVP yang diterbitkan oleh host pengirim.
Pesan Jalur menggambarkan sifat data atau aliran data yang akan dikirim dalam bentuk
informasi jalur negara. Secara khusus, pesan Jalur RSVP termasuk template pengirim
dan tspec pengirim. Template pengirim memberikan informasi dengan mana paket dari
aliran data yang relevan (yang kapasitas yang akan dicadangkan) dapat jelas dibedakan
dari data lain yang mungkin bisa berbagi jalan yang sama. The tspec pengirim menjelaskan lalu
lintas
spesifikasi data yang akan dikirim (bit rate, kualitas layanan yang diperlukan, dll).

Pesan Path harus mengikuti jalan yang sebenarnya bahwa data selanjutnya akan diangkut
bersama. RSVP mengumpulkan informasi tentang jalur dalam daftar hop RSVP alamat IP dan di
(spesifikasi iklan) adspec. Akhirnya, pesan Jalur tiba di hilir host (atau dalam kasus pesan
multicast, di sejumlah host hilir). Setiap host hilir yang membutuhkan reservasi bandwidth
harus berasal permintaan pemesanan sendiri berdasarkan informasi jalur received.6 Hal ini
dilakukan dengan cara suatu Resv RSVP (permintaan reservasi) pesan.

Pesan Resv dikirim hulu dari host menerima (menggunakan daftar hop RSVP untuk
Pedoman itu). Pesan Resv membuat permintaan pemesanan dengan mendefinisikan kebutuhan
dalam hal gaya, spec flowspec dan menyaring. Gaya menggambarkan sifat yang diperlukan
pemesanan.
flowspec menggambarkan kualitas layanan (QoS) yang diminta dan filter spec menyediakan
sarana yang paket data akan dapat diidentifikasi tegas (itu termasuk bukan hanya informasi
yang diambil dari template pengirim tetapi juga informasi tentang penerima).
Permintaan reservasi pesan (Resv) dikenakan oleh setiap router ke admission control
prosedur. Dalam hal inilah yang menentukan apakah reservasi yang diminta secara
administratif diijinkan, dan juga apakah sumber daya memadai saat ini tersedia untuk dapat
memenuhi permintaan tersebut.

Admis-kontrol sion juga mencoba untuk memastikan bandwidth yang tidak terlalu dilindungi
dan selanjutnya tidak digunakan. Jika reservasi berhasil, paket yang membentuk aliran data
yang akan dikenakan mengalir admission control (FAC) selama periode utama transfer data. Hal
ini memastikan bahwa pengirim tidak melebihi reservasi nya. Penerimaan kontrol, kontrol
aliran masuk (FAC) dan
penegakan kebijakan sangat penting untuk fungsi yang baik dari jaringan menawarkan RSVP.
Sebuah
bagian penting dari kebijakan perlu penciptaan sebuah 'tekanan balik' pada pengguna untuk
menghalangi mereka dari reservasi yang berlebihan. Pengisian untuk reservasi mungkin metode
terbaik
mencapai hal ini.

6 Pemesanan RSVP permintaan (Resv) juga dapat dilakukan bahkan jika pesan Path tidak
diterima.

Dalam hal ini, rincian jalan harus sudah diketahui penerima.

 Jika diminta pada saat permintaan reservasi (Resv), konfirmasi reservasi (ResvConf) akan
dihasilkan oleh tuan rumah pengiriman (sekali pesan Resv berhasil mencapai itu) dan hilir
dikirim ke penerima.
Jika ada pesan atau kesalahan prosedur selama proses isyarat RSVP (atau penolakan
pemesanan), maka PathErr (jalur pesan kesalahan) atau ResvErr (reservasi permintaan pesan
kesalahan) akan dibuat sesuai. Akhirnya, pemesanan akan diruntuhkan setelah komunikasi
selesai. Pemesanan mungkin dihancurkan baik oleh pengirim (dengan mengeluarkan pesan
PathTear hilir), oleh penerima (dengan mengeluarkan pesan ResvTear hulu), atau dengan salah
satu router RSVP menengah (yang harus mengirim pesan PathTear baik hilir dan ResvTear
pesan hulu).

RSVP (sumber protokol pemesanan) memungkinkan untuk reservasi sumber daya jaringan
seperti halnya diperlukan untuk memenuhi, baik kualitas yang terjamin pelayanan (QOS)
spesifikasi (sebagaimana didefinisikan dalam RFC 2212) atau layanan jaringan yang
dikendalikan-unsur beban (CLNES atau CLS) (sebagaimana didefinisikan dalam RFC 2211). QOS
dan CLNES skema 'menjamin' bandwidth sumber daya jaringan lain dengan menciptakan skema
prioritas untuk pengolahan header paket dan penyampaian jaringan lapisan paket. Paket
prioritas yang lebih tinggi bisa menggunakan sumber daya yang pertama. Prinsip-prinsip
tentang bagaimana kualitas layanan (QOS) adalah 'dijamin' kita bahas di bawah layanan
dibedakan (DiffServ) yang dijelaskan dalam Bab 5. Jadi RSVP adalah 'transportasi protokol' yang
memungkinkan untuk reservasi bandwidth untuk memastikan bahwa prioritas paket
menggunakan DiffServ benar-benar akan mencapai kualitas layanan (QOS) spesifikasi yang
dibutuhkan untuk aliran data. Kontrol tambahan sinyal dan sumber daya reservasi
diselenggarakan oleh RSVP dengan menghilangkan kebutuhan untuk hop-by-hop packet
filtering dan re-prioritas paket aliran data yang diperlukan dengan mudah DiffServ (Jasa
dibedakan). Flow admission control (FAC) dan kepolisian hanya perlu berada di bawah dan
diambil sekali (pada router pertama di koneksi). Hal ini membuat untuk penerusan lebih cepat
dengan sedikit usaha.

Sumber Daya pemesanan dapat dilakukan dengan menggunakan RSVP baik untuk pengguna
tertentu (yakni, host menerima), atau untuk layanan spesifik (yaitu, protokol aplikasi tertentu,
pelabuhan atau socket) yang digunakan oleh pengguna (host). Pengguna biasanya akan
menggunakan salah satu dari kombinasi berikut protokol:
• Internet Protocol versi 4 (IPv4) TCP / UDP dan layanan dibedakan (DiffServ). Dalam hal ini
kasus, reservasi didasarkan pada alamat IPv4 dan / atau perilaku DiffServ efisiensi secara
agregat dalam
gerbang;
• Internet Protocol versi 6 (IPv6) TCP / UDP dan layanan dibedakan (DiffServ). Dalam hal ini
kasus, reservasi didasarkan pada alamat IPv6 dan / atau efisiensi secara agregat perilaku
DiffServ-
gerbang;
• sambungan jaringan label-switched (misalnya, sebuah MPLS (multiprotocol label switching)
con-
nection - seperti yang akan kita diskusikan segera). Dalam hal ini reservasi dikaitkan dengan
koneksi label, atau
• IPv6 label-switched koneksi jaringan. Dalam hal ini reservasi dikaitkan dengan
aliran IPv6 label (yang kita lihat dalam bab 5 - Gambar 5.14). (Akibatnya aliran IPv6
label adalah sama sebagai label aliran MPLS, seperti yang akan kita lihat nanti).
Penting untuk dicatat bahwa RSVP mengontrol reservasi sumber daya yang akan
mempengaruhi
lapisan jaringan penyampaian paket yang membentuk aliran data yang diberikan. reservasi ini
diperlukan agar lapisan transport (yaitu, secara langsung antara host yang berkomunikasi)
memenuhi
diperlukan kualitas pelayanan lapisan aplikasi. Dalam pengertian ini, RSVP adalah 'protokol
transport'
(Tetapi tidak satu yang digunakan untuk pengangkutan data pengguna yang sebenarnya).

Reservasi gaya
Gaya reservasi mencerminkan baik jenis pemesanan (disebut opsi pemesanan) dan
jenis pengirim (disebut pilihan pengirim) yang dibutuhkan. Opsi pemesanan
dapat berupa pemesanan yang berbeda (misalnya, khusus dimaksudkan oleh penerima yang
berlaku bagi pengirim yang berbeda) atau dibagi reservasi (dalam hal sumber daya reserved
dapat digunakan untuk membawa data dari berbagai pengirim yang berbeda). Pemilihan
pengirim baik dengan cara alamat IP eksplisit (mengidentifikasi pengirim tunggal) atau melalui
wildcard (mengidentifikasi semua pengirim dalam rentang subnet alamat IP tertentu). Sebuah
filter tetap (FF) reservasi gaya reservasi yang berbeda yang ditujukan untuk satu point to aliran
data titik.

RSVP merupakan protokol pemesanan resource yang dipakai untukintegrated service. Protokol
RSVP dipakai oleh host untuk meminta QoS dari jaringan untuk dipakai oleh aplikasi tertentu.
RSVP juga dipakai oleh router untuk mengantar permintaan QoS ke semua node sepanjang jalur
aliran data dan dipakai untuk membangun dan memelihara kondisi RSVP didesain untuk
beroperasi dengan protokol peroutingan unicast dan ulticast, sehingga RSVP bukan protokol
perutingan. Proses RSVP memeriksa database perutingan lokal untuk mendapatkan route.
Protokol perutingan menentukan dimana paket akan diteruskan. RSVP hanya fokus dengan QoS
paket tersebut yang diteruskan dengan perutingan.Untuk mendapatkan efisiensi, RSVP
membuat receiver bertanggung jawab dalam permintaan QoS. Permintaan QoS dari aplikasi
host di receiver dilewatkan ke proses RSVP lokal. Kemudian protokol RSVP membawa
permintaan ke semua node (host dan router) sepanjang path data menuju sumber data, tetapi
hanya sejauh lokasi router path data yang dimiliki receiver bergabung dengan diagram distribusi
multicast.

QoS diimplementasikan pada aliran data terpisah melalui mekanisme traffic control.
Mekanisme tersebut terdiri dari packet classifier, admission control, packet scheduler. Selama
pembangunan reservasi, permintaan QoS RSVP dilewatkan melaui dua modul lokal yaitu
admission control dan policy control. Admission control menentukan apakah node memiliki
ketersediaan resource yang cukup untuk menyuplai QoS yang diminta. Policy control
menentukan apakah user memiliki izin administratif untuk melakukan reservasi. Jika kedua
proses berhasil, selanjutnya parameter – parameter di-set dalam packet classifier dan interface
layer link (misal packet scheduler) untuk mendapatkan QoS yang diinginkan. Jika terdapat
proses yang gagal maka program RSVP mengirimkan pemberitahuan kesalahan kepada proses
aplikasi yang meminta.
Mekanisme protokol RSVP menyediakan fasilitas dalam pembuatan dan pemeliharaan reservasi
pada path. RSVP mengirim dan mengontrol parameter QoS dan policy control sebagai data yang
tertutup, kemudian melewatkannya ke modul policy control dan traffic control yang sesuai
untuk penerjemahan. Pada modul RSVP di pengirim secara periodik mengirim pesan path RSVP
yang menggunakan karakteristik aliran data untuk menjelaskan trafik yang dihasilkan oleh
pengirim. Ketika modul RSVP di receiver menerima pesan Path,

aplikasi host penerima mengecek karakteristik aliran data yang diminta dan memberi
keputusan apakah resource harus dipesan. Sesekali keputusan dibuat untuk meminta reservasi
resource jaringan, aplikasi host mengirim permintaan ke modul RSVP lokal dalam setup/
penyusunan reservasi. Kemudian penerima modul RSVP membawa permintaan sebagai pesan
Resv ke semua node sepanjang jalur data balik sampai menuju pengirim. RSVP merupakan
protokol pen-setup reservasi resource yang didesain untuk layanan terintegrasi internet. RSVP
dipakai oleh host untuk meminta QoS dari jaringan untuk aliran data aplikasi. Sebuah aplikasi
memerlukan RSVP untuk meminta end-to-end QoS yang spesifik untuk streaming data. RSVP
bertujuan untuk secara efisien men-setup jaminan resouce reservation QoS yang dapat
mendukung routing protocol unicast dan multicast dan dapat ditempatkan pada pengantar
dalam group multicast yang besar.

Dasar dari RSVP adalah meminta spesifikasi untuk end-to-end Qos yang dibutuhkan dan definisi
dari set data paket untuk menerima QoS. RSVP berguna untuk lingkungan dimana QoS
reservation data didukung oleh lokasi resource dari pada penambahan resource. RSVP
mendukung akses pada pelayanan internetworking yang terintegrasi dimana host dan network
bekerja untuk mencapai penjaminan kualitas pengiriman end-to-end. Semua host, router dan
komponen lain dalam infrastruktur elemen jaringan antara pengirim dan penerima harus
mendukung RSVP. Tiap-tiap elemen jaringan ini mencadangkan resource sistem, seperti
bandwith, CPU dan buffer memory, untuk memenuhi permintaan QoS. Hal inilah yang
diharapkan, meskipun demikian, akan memerlukan biaya tambahan pada ISP untuk
mencadangkan resource-nya untuk RSVP pemesanan QoS. Kontrol QoS RSVP memerlukan
pesan-pesan yang dikirimkan untuk mencadangkan resource sepanjang node (router dan host)
selama pencadangan pengantaran pada penerima.
RSVP merupakan inisiatif dari penerima, RSVP meminta resource hanya dalam satu arah. RSVP
merupakan protokol kontrol jaringan yang membolehkan penerima data meminta QoS end-to-
end untuk aliran datanya. Aplikasi real-time menggunakan RSVP untuk meminta resource yang
diperlukan pada router sepanjang jalur transmisi, sehingga bandwidth yang diminta dapat
tersedia ketika transmisi dilakukan. RSVP merupakan komponen utama Integrated Services.
RSVP digunakan untuk melakukan reservasi sumber jaringan. Ketika aplikasi di host (penerima
aliran data) meminta QoS untuk aliran data tersebut, maka digunakan RSVP untuk
menyampaikan permintaan tersebut kepada router sepanjang jalur aliran data. RSVP
bertanggung jawab dalam hal negosiasi parameter – parameter jaringan dengan router
tersebut. Jika reservasi telah ilakukan, RSVP juga bertanggung jawab dalam hal pemeliharaan
kondisi host dan router untuk menyediakan layanan yang diminta.

Aliran data

Setiap node yang mampu melakukan reservasi resource mempunyai beberapa prosedur lokal
pelaksanaan reservasi. Policy control menentukan apakah user memiliki izin administratif untuk
membuat reservasi. Selanjutnya authetication, access control dan accounting untuk reservasi
juga dilakukan oleh policy control. Admission control menjaga jalur resource sistem dan
menentukan apakah node memiliki resource yang cukup untuk mensuplai QoS yang diminta.
RSVP tidak menentukan bagaimana cara jaringan menyediakan pemesanan. RSVP hanya
membolehkan aplikasi untuk melakukan pemesanan. Setiap ada pemesanan router
menentukan penjadwalan dan kebijakan yang diperlukan untuk mendukung pemesanan
tersebut.
Pesan alur (path message) berisi informasi lalu lintas informasi yang menjelaskan QoS pada
suatu arus spesifik. Karena RSVP tidak menangani routing dengan sendirinya, maka digunakan
informasi tabel routing pada setiap router untuk meneruskan pesan RSVP.

Jika suatu penerima ingin memesan QoS untuk suatu flow, maka dikirimkan suatu pesan
reservasi (resv). Pesan reservasi berisi permintaan QoS dari receiver untuk suatu arus spesifik
dan diwakili oleh filterspec dan flowspec yang membentuk arus descriptor (flow descriptor).
Receiver mengirimkan pesan resv sampai router akhir pada path dengan alamat yang
diterimanya dari path message. Karena setiap alat RSVP mengetahui alamat dari alat
sebelumnya pada path, path perjalanan pesan reservasi adalah kebalikan ke arah pengirim dan
menetapkan sumber daya reservasi di tiap-tiap router. RSVP tidak menangani keputusan
routing. Algoritma routing unicast dan multicast yang ada yang melakukan keputusan routing.
Ketika route sudah ditentukan RSVP memesan/ menyisihkan resource di link jaringan sepanjang
route tersebut. Jika terjadi perubahan route RSVP memesan ulang resource.
RSVP mendefinisikan session menjadi aliran data dengan tujuan tertentu dan protocol layer
transport. RSVP memperlakukan setiap sesi secara sendirisendiri. Sesi RSVP didefinisikan oleh
DestAddress, ProtocolId, DstPort. Pada DestAddress, alamat tujuan IP paket data dapat berupa
alamat unicast maupun multicast. ProtocolId merupakan ID protokol IP. DstPort merupakan
parameter tambahan yang menggeneralisasi port tujuan.

Model reservasi RSVP

Dasar permintaan reservasi RSVP terdiri dari flowspec dan filter spec, dua hal tersebut disebut
flow descriptor. Flowspec menentukan QoS yang diinginkan. Filter spec bekerja sama dengan
spesifikasi sesi mendefinisikan paket data/ flow untuk menerima QoS yang didefinisikan oleh
flowspec. Flowspec digunakan untuk menyusun parameter-parameter packet scheduler di node
atau mekanisme layer link yang lain saat filter spec dipakai untuk menyusun parameter-
parameter dalam packet classifier. Paket data yang dialamatkan ke sesi tersendiri tetapi tidak
match pada filter spec pada sesi tersebut akan dianggap sebagai trafik best-effort.
Salah satu model reservasi lebih memperhatikan pemeliharaan reservasi/ pemesanan untuk
pengirim yang berbeda dengan sesi yang sama yaitu membangun reservasi distinct untuk setiap
pengirim upstream.

Wildcard-filter (WF)

Mode reservasi Wildcard-Filter menggunakan pilihan membagi pemilihan reservasi dan sender.
Gaya reservasi ini menetapkan reservasi tunggal untuk semua sender di suatu sesi. Reservasi
dari sender yang berbeda digabungkan bersama-sama sepanjang alur dengan demikian hanya
permintaan reservasi yang paling besar yang akan digunakan bersama oleh semua sender.

Fixed-filter (FF)

Model reservasi Fixed-Filter menggunakan reservasi dengan pilihan yang berbeda dan seleksi
sender eksplisit. Artinya bahwa reservasi yang berbeda diciptakan untuk paket data dari sender
tertentu. Paket dari sender yang berbeda dalam sesi yang sama tidak membagi reservasi.

Shared-explicit (SE)

Reservasi model SE membuat reservasi tunggal untuk meng-cover aliran dari suatu subset
sender ditetapkan. Oleh karena itu, suatu daftar sender harus dimasukkan ke dalam permintaan
reservasi dari receiver.
 REFERENSI

 http://en.wikipedia.org/wiki/Resource_reservation_protocol

 http://www.ittelkom.ac.id/library/index.php?
view=article&catid=10%3Ajaringan&id=307%3Aresource-reservation-protocol-
rsvp&option=com_content&Itemid=15

 "Menggelar IP QoS dan MPLS untuk Jaringan MultiService: Teori dan Praktik" oleh John
Evans, Filsfils Clarence (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)