Penggabungan IP Multicast dan PSVP
Internet telah digunakan
sebagai meida yang cukup handal untuk transmisi data dengan batasan delay yang
hampir atau bahkan tidak ada. Protokol TCP/IP telah didesain untuk trafik jenis
ini dan dapat bekerja dengan baik Meskipun demikian, trafik multimedia yang
telah dikompromikan dengan potensial penggunaan trafik multicast, mempunyai karakteristik yang berbeda dan
pertimtaan yang lebih baik sehingga diperlukan penggunaan protocol yang berbeda
untuk mendukung pelayanannya. Misalnya : jika penerima harus menunggu untuk
transmisi ulang TCP, maka dimungkinkan akan ada waktu jeda yang tidak dapat
diterima, misalnya pada real-time data seperti audio, video atau data-data lain
yang sensitive terhadap delay.
Mekanisme kontrol TCP ,
“Slow start”, dapat menginterferensi data audio dan video pada palyout rate.
Ketika tidak ada diagram path yang tetap untuk aliran melalui internet, maka
tidak ada mekanisme yang dapat menjamin tersedianya bandwith yang diperlukan
untuk data multimedia antara pengirim dan penerima, jadi kualitas dari layanan
tidak dapat dijamin. Sebagai tambahan lagi TCP tidak dapat mendukung timing
informasi yang merupakan keperluan yang kritis utnuk mendukung multimedia.
Aplikasi-aplikasi
multimedia dapat menjadi awal dari kompleksitas TCP dan digunakan didalam
transport framework yang sederhana. Kebanyakan algoritma playback tidak dapat
mentolelir adanya kehilangan data yang lebih banyak dari lengthy delay yang
disebabkan oleh transmisi ulang dan juga tidak dapat sebagai jaminan dalam
pengantaran data secara sequensial. Beberapa macam protocol telah dikembangkan
untuk memperbaiki arsitekture internet dan menigkatkan dukungan untuk aplikasi
multimedia, seperti audio, video, dan konfrensi interaktif multimedia.
Protokol-rotokol yang dikembangkan tersebut misalnya RTP, RTCP, RSVP dan RTSP.
Protocol berorientasi real-time didesain untuk dapat digunakan secara multicast
atau unicast pada pelayanan jaringan. Sejak beberapa aplikasi real-time dapat
memelihara jaringan dan resource server dengan menggunakan IP Multicast, Maka
keperluan dan karakteristik khusus harus dipertimbangkan dalam perancangan
protocol. Seperti : scalability, multicast routing, dan akomodasi pada penerima
dengan jumlah banyak dan heterogen.
Dengan mengikuti
diskusi-diskusi tentang beberapa protocol yang digunakan untuk aplikasi
multimedia secara real-time, dapat
dilihat bahwa keandalan IP Multicast sangat dipertimbangkan. Keandalan
pengantaran data diperlukan oleh beberapa aplikasi real-time maupun aplikasi
non-real-time. Pada pelayanan unicast IP, deteksi dan koreksi kesalahan dalam
layer TCP sangat mendukung keandalannya. Untuk keandalan multicast, pendekatan
baru dalam tracking acknowledgment dan deteksi dan koreksi kesalahan telah
diterapkan, ketika sebuat IP multicast terkirim pada beribu-ribu penerima.
Resource Reservation Protocol (RSVP)
Resource Reservation
Protocol (RSVP ) adalah sebuah resource reservation setup protocol yang
didesain untuk diintegrasikan pada pelayanan internetworking. Sebuah aplikasi
memerlukan RVSP untuk meminta end-to-end QoS yang spesifik untuk streaming
data. RVSP bertujuan untuk secara
efisien men-setup jaminan resouce reservation QoS yang dapat mendukung routing
protocol unicast dam multicast dan dapat ditempatkan pada pengantara dalam
group multicast yang besar. RSVP telah didefinikan pada IETF.
Format header RSVP dapat dilihat pada ilustrasi berikut
4
|
8
|
16
|
32 bits
|
Ver
|
Flags
|
Message type
|
RSVP checksum
|
Send TTL
|
(Reserved)
|
RSVP length
|
|
RSVP header structure
Message type Possible values are:
1
|
Path.
|
2
|
Resv.
|
3
|
PathErr.
|
4
|
ResvErr.
|
5
|
PathTear.
|
6
|
ResvTear.
|
7
|
ResvConf.
|
Sebuah host penerima mengunakan RSVP untuk meminta sebuah QoS yang
spesifik dari jaringan untuk melakukan pengiriman straming bagian data dari
sumber data. Dasar dari RSVP reservation meminta spesifikasi untuk end-to-end
Qos yang dibutuhkan. (misalnya peak/average bandwitg dan delay bounds) dan
definisi dari set data paket untuk menerima Qos. RSVP berguna untk lingkunngan
dimana Qos reservation data didukung oleh kelokasi resource daripada
apenambahan resource. Untuk multicast, sebuah host mengirimkan pesan IGMP untuk
bergabung dalam sebuah group host dan kemudian megirimkan pesan RSVP untuk
mencadangkan resource selama mengirimkan data pada group tersebut.
IGMP (Internet Group Management Protocol) digunakan oleh IP host untuk
melaporkan anggota group host-nya kepada beberapa mulcast router tetangga secara
cepat. IGMP merupakan bagian dari IP. IGMP harus diimplementasikan oleh semua
host yang besesuaian dengan spesifikasi level 2 dari IP multicast. Pesan-pesan
IGMP tercakup dalam datagram IP, dengan IP protokol nomer 2 (Compliant with IETF
RFC1112, Aug 1989.)
Format dari Paket IGMP dapat ditunjukanan pada ilustrasi berikut ini
IGMP packet structure
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 mendacangkan 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 QoS Reservation. Pendekatan untuk penanganan reservasi
bandwith dan pembayaran melalui beberapa carrier network masih perlu
didefinikan lebih lanjut.
Kontrol RSVP QoS
memerlukan pesan-pesan yang dikirmkan untuk mencadangkan resource sepanjang
semua node (router dan host) selama pencadangan pengantaran pada penerima.
Perlu diperhatikan bahwa RSVP merupakan inisiatif dari penerima, RSVP meminta
resource hanya dalam satu arah. Untuk multicast, permintaan reservasi
memerulakan hanya pada perjalan pada sebuah point dimana permintaan ini
digabungkan dengan reservasi yang lain untuk straming sebuah sumber data.
Perancangan pada sisi penerima diorientasikan pada akomodasi group multicast
yang banyak dan anggota group yang dinamik.
Tidak ada komentar:
Posting Komentar