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.
Download
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 bandwith 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
Ver Type Unused Checksum
Group address
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.
Penggabungan IP Multicast dan RSVP request dapat dilihat pada ilustrasi berikut ini
Dari illustrasi diatas dapat dilihat bahwa permintaan RSVP receiver 5 digabungkan pada router multicast 3 (MR 2) dengan sebelumnya permintaan RSVP dibuat oleh receiver 2. permintaan ini tidak melalui MR 1.
