SEMINARSKI RAD IZ INFORMATIKE

Racunalne mreže su stvorene s ciljem spajanja racunala na razlicitim lokacijama, tako da ona mogu razmjenjivati i dijeliti podatke (komunicirati). U pocetcima je vecina podataka koji su se prenosili takvim mrežama bila u tekstualnom obliku. Danas, s naglim porastom multimedijskih i mrežnih tehnologija, multimedija je postala nezaobilazna pojava na Internetu. Na tržištu su se pojavili multimedijski mrežni proizvodi kao Internet telefonija, Internet televizija, video konferencije i dr. U buducnosti, ljudi ce sve više htjeti koristiti usluge kao što su ucenje na daljinu (Distance Learning), razne distribuirane simulacije i radne grupe koje nece tražiti da clanovi jednog tima budu u istoj zgradi, pa cak ni u istoj državi. Ekonomske prednosti takvog rada su ocigledne.

Multimedijske mrežne usluge moraju izgraditi hardversku i softversku infrastrukturu i razne alate koji ce podržavati prijenos multimedijskih usluga racunalnim mrežama i omoguciti korisnicima kvalitetnu komunikaciju. Multimedijske mrežne usluge ce uvelike unaprijediti uporabu racunala kao komunikacijskog alata. Vjeruje se da ce jednog dana multimedijske mreže zamijeniti telefone, televizore i druge izume koji su jednom davno drasticno promijenili naše živote.

2. Ciljevi i izazovi multimedijskih mrežnih usluga

2.1. Stvarno-vremenski izazov

Slanje multimedijskih podataka i usluga racunalnim mrežama nije nimalo lak zadatak. Za pocetak postoje barem tri poteškoce.

Prvo, u usporedbi s tradicionalnim tekstualnim aplikacijama, multimedijske aplikacije obicno zahtjevaju puno vecu širinu pojasa. Tipican QuickTime filmski isjecak u trajanju od 25 sekundi i formata 320x240 elemenata slike zauzima i do 2,3 MB što je otprilike ekvivalent 1000 ekrana tekstualnih podataka. To je bilo nezamislivo u vrijeme dok su se mrežama prenosili samo tekstualni podaci.

Drugo, vecina multimedijskih aplikacija zahtjeva prijenos podataka u realnom vremenu. Audio i video podaci moraju se reproducirati kontinuirano, tocno onom brzinom kojom su bili uzorkovani. Ako podaci ne stignu na vrijeme, reprodukcija ce stati i ljudsko uho ili oko ce primijetiti pogrešku. U Internet telefoniji, ljudsko uho nece osjetiti kašnjenja manja od 250 ms. Ako kašnjenje prijede 250 ms glas ce zvucati kao da je prespojen preko udaljenog satelita i korisnik ce se žaliti na kvalitetu ostvarenog poziva. Osim kašnjenja, mrežna zagušenja imaju još veci ucinak na prijenos podataka u stvarnom vremenu. Kod prijenosa podataka koji ne moraju stizati u stvarnom vremenu na odredište, zagušenje mreže ce imati za posljedicu jedino to da ce podacima trebati više vremena da stignu na odredište ali korisnik nece primijetiti nikakve pogreške prilikom reprodukcije. S druge strane, podaci koji moraju stici u stvarnom vremenu biti ce izbaceni ako ne stignu na vrijeme a njihova eventualna retransmisija ce samo još više pogoršati situaciju i napraviti zastoj u mreži.

Trece, prijenos multimedijskih podataka je najcešce usnopljen. Kod vecine multimedijskih aplikacija prijamna strana ima ograni cenu veli cinu spremnika (buffer). Ako se ništa ne poduzme da se "izgladi" usnopljenost podataka može se desiti ili preljev (overflow) ili da stigne premalo podataka (underflow) u prijamni spremnik. Racunalo koje prima takve podatke nece ih znati prikladno obraditi. Kada podaci stižu prebrzo spremnik ce se "preliti" i neki paketi ce biti izgubljeni što ce u konacnici rezultirati lošijom kvalitetom reproduciranog materijala. Kada podaci stižu presporo, racunalo nece imati dovoljno podataka za obradu u spremniku, što takoder ruši kvalitetu.

U svakodnevnom životu, usnopljeni prijenos i stvarno-vremenski prijenos multimedijskih sadržaja istovremeno dijele tisuce ili milijuni korisnika koji imaju ogranicenu širinu frekvencijskog pojasa, nepredvidivo kašnjenje i dostupnost. Kako riješiti ove probleme danas je glavni izazov s kojim se multimedijski mrežni promet mora suociti.

Mogucnost rješenja ovih problema dolazi iz postojece softverske mrežne arhitekture i brzonapredujucih hardverskih rješenja. Osnovni dijelovi Interneta, TCP/IP (Transmission Control Protocol / Internet Protocol) i UDP/IP (User Datagram Protocol / Internet Protocol), osiguravaju mnoštvo mogucnosti koje multimedijske aplikacije mogu iskoristiti.
Dakle, projektiranje stvarno-vremenskih mrežnih protokola za multimedijske usluge postaje glavna zadaca inženjera i strucnjaka diljem svijeta, prije no što zapocne pravo multimedijsko doba.

2.2. Multimedija preko Interneta

Postoje i drugi nacini prijenosa multimedijskih podataka kao što su rezervirani linkovi, kabeli i ATM. Medutim, unatoc tome prijenos preko Interneta je izuzetno privlacno rješenje. Rezervirani linkovi i kabeli nisu prakticni jer zahtjevaju posebne instalacije i adekvatnu novu programsku podršku. Bez postojecih tehnologija kao što su lokalne mreže (LAN, Local Area Network) i WAN (Wide Area Network) razvoj nove programske podrške postaje jako skup. ATM se smatrao najboljim rješenjem za multimediju jer podržava vrlo širok frekvencijski pojas, konekcijski je orijentiran i podržava razlicite razine kvalitete usluge (Quality Of Service - QoS) za razne primjene. Ali trenutno vrlo malo korisnika ima ATM mrežu u svojim ustanovama, a još manje ih ima ATM do svojeg racunala u tim ustanovama.

S druge strane, Internet se eksponencijalno širi. Dobro razvijene LAN i WAN tehnologije temeljene na IP protokolu povezuju sve vece i vece mreže po cijelom svijetu i ukljucuju ih u Internet. U stvari, Internet je postao platforma za vecinu mrežnih aktivnosti. Ovo je osnovni razlog za daljnje razvijanje multimedijskih internetskih protokola. Druga prednost prijenosa multimedije preko IP-a je da korisnici mogu imati integrirane podatkovne i multimedijske usluge u jednoj mreži bez dodatnih ulaganja u novu mrežu i sucelja izmedu razlicitih mreža.

Internet svojom arhitekturom nije narocito pogodan za prijenos stvarno-vremenskih multimedijskih podataka. Budu ci da multimediju karakteriziraju velika kolicina podataka i vrlo gust promet kroz mrežu, hardver mora osigurati dovoljnu širinu frekvencijskog pojasa. Multimedijske usluge su obicno predvidene za višeodredišno slanje (multicast), tj. za slanje istog multimedijskog sadržaja grupi primatelja u isto vrijeme, pa protokoli dizajnirani za multimedijske usluge moraju to uzeti u obzir zbog smanjenja prometa. Takoder je potrebno obaviti rezervaciju resursa da bi se stvorio dovoljno širok kanal za stvarnovremensku aplikaciju. Treba paziti i na to da je Internet paketska mreža i da paketi nezavisno putuju do odredišta. Buduci da paketi moraju doci na odredište u tocno odredenom vremenskom slijedu, potrebni su novi prijenosni protokoli koji ce i o tome brinuti, kako bi se audio i video podaci nesmetano reproducirali i bili prikladno sinkronizirani.

Rješenje za prijenos multimedije preko IP-a je u tome da se klasificira sav promet, da se odrede prioriteti za razlicite aplikacije te da se onda rezerviraju resursi. Radna grupa za integrirane usluge IETF (Internet Engineering Task Force) razvila je poboljšani internetski model koji su nazvali Integrated Services za stvarno-vremenske aplikacije (pogledati RFC 1633). Resource ReSerVation Protokol (RSVP), zajedno sa Real-time Transport Protokolom (RTP), Real-time Control Protokolom (RTCP) i Real-time Streaming Protokolom (RTSP) osiguravaju temelje za stvarno-vremenske usluge. Oni omogucavaju aplikacijama da konfiguriraju i upravljaju istom infrastrukturom za multimedijske i tradicionalne usluge i da si same odrede vrstu i kvalitetu usluge koja im je potrebna.

3. QoS

Postoji mnogo definicija kvalitete usluge (QoS, Quality of Service). Npr. ITU-T E.800 definira kvalitetu usluge kao "ukupni ucinak djelovanja usluga koje odreduju razinu zadovoljstva korisnika usluga'.

Visoka kvaliteta usluge je kategorija koja bitno ovisi o ocekivanjima korisnika. Npr. u fiksnoj telefoniji korisnik ocekuje stalnu raspoloživost sustava. Nadalje, kad se poziv jednom prihvati, korisnik ocekuje da nece biti neocekivano prekinut i da ce kvaliteta biti stalna. U mobilnoj se telefonskoj mreži korisnici lakše mire s cinjenicom da ne mogu uvijek ostvariti poziv, da se on nekada prekine i da kvaliteta veze varira.

U Internetu je standardni model usluge tzv. "best-effort" model: mreža ce pokušati zadovoljiti korisnikove zahtjeve, ali bez ikakvih garancija da ce tražena kvaliteta zaista biti pružena. U vecini primjera zastupa se elastican pristup kvaliteti usluge, tj. prilagodavanje promjenama u propusnosti i kašnjenju, dok se niti u slucaju mrežnog zagušenja usluga ne odbija, vec svi korisnici osjecaju pogoršanje kvalitete.

Iako su korisnici Interneta navikli na cekanje i prolazne probleme s kašnjenjem i propusnošcu, kod npr. pregledavanja web stranica, za multimedijske primjene (prijenos govora ili videa), kao i stvarnovremenske primjene, takav model nije prihvatljiv.

Kvaliteta na razini aplikacije. Korisnik je covjek. Odnosi se uglavnom na kvalitativne parametre kao što su percepcijska kvaliteta pojedinog medija, odnos medu pojedinim medijima, kvaliteta medusobne uskladenosti.

Kvaliteta na razini sustava. Korisnik je aplikacija. To su kvantitativni parametri (propusnost, vrijeme odziva, sustav posluživanja i rasporedivanja).

Kvaliteta na razini mreže. Korisnik je sustav. Izražava se preko mjerljivih, kvantitativnih i kvalitativnih parametara kvalitete usluge. To su propusnost, kašnjenje, kolebanje kašnjenja, gubici, raspoloživost i blokiranje.

Uloga kvalitete usluge je rezervacija i dodjela resursa od izvora do odredišta za vrijeme multimedijske sjednice, održavanje resursa prema specifikaciji zatražene kvalitete usluge i prilagodba promjenama koje nastaju tijekom poziva.

4. Internet

4.1. Osnovni pojmovi

Internet je najopcenitije govoreci mreža dviju ili više mreža. Kao globalni informacijski sustav logicki je povezan jedinstvenim adresnim prostorom temeljenim na IP-u (Internet Protocol). Komunikacija se temelji na TCP/IP obitelji protokola i IP-kompatibilnim protokolima, te njihovim proširenjima i sljedbenicima. Usluge viših slojeva temelje se na infrastrukturi i komunikaciji navedenih sustava. Internet je datagramska mreža, odnosno radi na principu komutacije paketa.

Mreža je skup racunala (PC, radne stanice), uredaja, komunikacijskih medija i mrežnog softvera koji implementiraju neki komunikacijski protokol. Mreže mogu biti povezane komutacijskim uredajima - obnavljacima (repeater), mostovima (bridge), usmjeriteljima (router) i spojnim pristupima (gateway).

Protokol je skup pravila koja propisuju nacin na koji se podaci prenose preko komunikacijskog medija. Npr. protokol može odrediti redoslijed razmjene podataka izmedu dviju strana. U stvari, razmjena podataka izmedu dvije strane može se jedino obaviti ako oba racunala koriste isti protokol.

Svojstvo Interneta da posjeduje veliki broj razlicitih protokola, od kojih svaki obavlja neku drugu funkciju, omogucava mu modularnost, fleksibilnost, jednostavnost i proširivost. Mrežni poslužitelji koji pružaju neku odredenu uslugu trebaju samo implementirati taj konkretni protokol ne brinuci se da njihova usluga nece raditi. Nadalje, odredene komponente protokola mogu se koristiti u drugim aplikacijama, pa se ne mora ponovno izmišljati neke specificne funkcije.
Svaki sloj u protokolnom složaju izgraduje se na sloju koji je direktno ispod njega. Svaki sloj protokolnog složaja dodaje paketu koji se prenosi zaglavlje karakteristicno za taj sloj. Npr. na mrežnom sloju se upisuju izvorišna i odredišna adresa i dr.

4.2. TCP/IP složaj

Slika 2. opisuje dio TCP/IP složaja koji koriste svi sustavi spojeni na Internet:

Na dnu su podatkovni linkovi i fizicki slojevi. Fizicki sloj radi s naponima, a sloj podatkovih veza pruža razne korisne usluge kao uokvirivanje, otkrivanje pogrešaka, ispravljanje pogrešaka i kontrolu toka podataka. Zajedno, oni su odgovorni za prijenos sirovih bitova preko fizickog linka. Važno svojstvo internetskog složaja je da nema nikakvih ogranicenja glede fizickog medija kojim se prenose podaci.

TCP/IP aplikacije koriste 4 sloja:
-aplikacijaski protokol (kao npr. mail);
- protokol (kao što je npr. TCP) koji pruža usluge mnogim aplikacijama;
- IP koji isporucuje datagrame na njihovo odredište;
-protokole koji su potrebni za upravljanje fizickim medijem (Ethernet, PPP - Point to Point Protocol).

TCP (Transmission Control Protokol) razbija poruke u datagrame, ponovno ih spaja na prijamnom kraju, vraca sve što se izgubi i sve ih ponovno slaže ispravnim redoslijedom. TCP je konekcijski orijentiran protokol i osigurava pouzdan prijenos podataka s kraja na kraj. Koristi dvosmjerni tok podataka. Pouzdan prijenos znaci da niti jedan paket nece biti izgubljen. To znaci da klijent mora poslati potvrdu primitka svakog paketa i mora cekati eventualno izgubljene pakete. Ako TCP ne dobije potvrdu primitka, dolazi do retransmisije. TCP stavlja svoje zaglavlje na pocetak svakog datagrama. To zaglavlje sadrži barem 20 bajta (bajt - 8 bitni dio informacije) od kojih su najvažniji broj porta (port - adresa transportnog sloja) i numeracija paketa. Osim njih u zaglavlje se još dodaje i zaštitna suma i drugi podaci. TCP je standardiziran u RFC 793.

IP (Internet protokol) omogucava prijenos podataka i to je datagramska usluga. Datagram je skup podataka koji se šalju u jednoj poruci. IP je odgovoran za usmjeravanje individualnih datagrama. TCP isporucuje IP-u datagrame. Naravno mora mu reci Internet adresu odredišnog racunala i taj podatak je sve što zanima IP. Zadatak IP-a je samo da nade rutu do odredišta i isporuci datagram. Da bi se omogucilo spojnim pristupima i ostalim sustavima da proslijeduju datagram, IP dodaje svoje zaglavlje.

U zaglavlje zapisuje izvorišnu i odredišnu adresu, broj protokola i zaštitnu sumu. Izvorišna adresa je adresa Vašeg racunala, a odredišna je adresa nekog drugog racunala. Broj protokola govori IP-u na prijamnoj strani da proslijedi datagram TCP-u (a ne nekom drugom protokolu kao što je npr. UDP). Zaštitna suma omogucava IP-u na prijamnoj strani da utvrdi da li se zaglavlje oštetilo u prijenosu (ova zaštitna suma razlikuje se od one koju dodaje TCP).

IP, dakle, pruža bezkonekcijsku i nepouzdanu uslugu isporuke. Osim toga u zaglavlju IP-a postoji još jedna informacija koja je jako važna. Time to Live je broj koji se smanjuje svaki put kada datagram prode kroz neki sustav i kad on postane jednak nuli datagram se odbacuje. To se koristi ako se u mreži dogodi neka petlja, da ne bi došlo do zagušenja. IP je standardiziran u RFC 791.

4.3. UDP

Potreba stvaranja UDP-a (User Datagram Protocol) isprva je nastala zbog toga što je bilo neprakticno koristiti TCP za neke vrlo kratke poruke koje stanu u jedan datagram. Za takve poruke je TCP prekompleksan. Takve poruke su npr. upiti koje šalje korisnik kada se pokušava spojiti na neki drugi sustav. Korisnik upisuje ime drugog sustava i šalje upit nekom sustavu koji ima bazu podataka imena i pretvara to ime u Internet adresu (broj) koju onda vraca korisniku. Obje te poruke su jako kratke i korisniku nije bitna sigurnost isporuke jer ako odgovor ne dode kroz par sekundi korisnik može ponovno poslati upit.

UDP je dizajniran za aplikacije kod kojih se ne mora spajati nizove datagrama. Uvodi se u sustav slicno kao TCP. Postoji UDP zaglavlje, mreža stavlja UDP zaglavlje ispred podataka, baš kao što to radi i TCP. Onda UDP šalje podatke IP-u koji dodaje svoje zaglavlje u koje upisuje UDP-ov broj protokola umjesto TCP-ovog.

Ipak, UDP ne obalja tako puno kao TCP. Ne dijeli podatke u datagrame i ne prati što je sve poslao da bi eventualno mogao nešto ponovno poslati ako je potrebno. UDP daje samo brojeve portova tako da ga može koristiti nekoliko programa odjednom. UDP zaglavlje je znatno krace od TCP-ovog, ne sadržava broj niza i zaštitna suma nije obvezatna. Ako se paket odbaci ne javlja se poruka o greški. O pouzdanosti prijenosa brine se sama aplikacija.

5. RSVP

5.1. Uvod

RSVP (Resource ReSerVation Protocol) je mrežni protokol koji omogucava prijamnoj strani da zatraži odredenu kvalitetu usluge s kraja na kraj za njegov tok podataka. Stvarno-vremenske aplikacije koriste RSVP za rezervaciju neophodnih resursa kod mrežnih usmjeritelja duž prijenosne rute tako da bi tražena širina frekvencijskog pojasa bila stvarno raspoloživa jednom kad prijenos krene. RSVP je glavna komponenta buduceg Interneta sa integriranim uslugama.

5.2. Razvoj

RSVP su razvili Xerox Corp.'s Palo Alto Research Center (PARC), MIT i Information Sciences Institute of University of California (ISI). RSVP specifikacija je predana Internet Engineering Steering Group (IESG) na razmatranje 1994.g., a 1997.g. RSVP Version 1 Functional Specification i mnogi drugi prijedlozi bili su odobreni kao standardi:
-RFC 2205, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
-RFC 2206, RSVP Management Information Base using SMIv2 (RFC 2206)
- RFC 2207, RSVP Extensions for IPSEC Data Flows
- RFC 2208, RSVP Version 1 Applicability Statement Some Guidelines on Deployment
-RFC 2209, RSVP Version 1 Message Processing Rules

5.3. Nacin rada RSVP-a

Kada aplikacija koja prima tok podataka zatraži specificnu kvalitetu usluge (QoS) za svoj tok podataka, ona svoj zahtjev dostavlja usmjeriteljima, preko kojih ce ici podaci, pomocu RSVP-a. RSVP je odgovoran za "pregovaranje" oko parametara veze s tim usmjeriteljima. Jednom kada je rezervacija ostvarena, RSVP nadgleda usmjeritelje i prijamno racunalo i održava kvalitetu veze koje je zatražena.

Svaki cvor koji ima mogucnost rezervacije resursa ima nekoliko lokalnih procedura za podešavanje i nametanje rezervacije. Policy control odreduje ima li korisnik administrativnu dozvolu za ostvarivanje rezervacije. U buducnosti ce se tu implementirati i provjera dozvole pristupa i naplata rezervacije. Admission control prati resurse sustava i odreduje ima li cvor uvjete za ostvarivanje tražene kvalitete usluge (QoS).
RSVP daemon suraduje s obje gore navedene procedure. Ako bilo koji od zahtjeva nije ostvaren, RSVP javlja pogrešku aplikaciji koja je zatražila vezu. Ako su oba zahtjeva zadovoljena RSVP daemon podešava packet scheduler i packet classifier kako bi se ostvarila tražena kvaliteta usluge. Packet classifier odreduje klasu kvalitete usluge za svaki paket, a packet scheduler slaže prijenos paketa kako bi se ostvarila dogovorena kvaliteta usluge za svaki tok podataka. RSVP daemon takoder komunicira s usmjeriteljem kako bi odredio put kojim ce poslati daljnje zahtjeve za rezervaciju. Ovaj rezervacijski postupak se ponavlja u smjeru suprotnom od onog kojim ce teci podaci sve dok se rezervacija ne sjedini s nekom drugom rezervacijom za isti izvor toka podataka.

Rezervacije se implementiraju preko dva tipa RSVP poruka: PATH i RESV. PATH poruke se periodicki šalju od pošiljatelja na jednu (unicast) ili više (multicast) adresa. PATH poruka sadrži flow spec koji opisuje obrazac izvorišta (format u kojem su podaci, izvorišnu adresu i izvorišni port) i karakteristike mrežnog prometa. Te informacije koristi primatelj da bi odredio povratni put do pošiljatelja i odlucio koje resurse treba rezervirati. Primatelji se moraju ukljuciti u multicast grupu da bi mogli primiti PATH poruke.

RESV poruke generira prijamna strana i one sadrže rezervacijske parametre ukljucujuci i flow spec i filter spec. Flow spec odreduje kakve pakete ce koristiti packet classifier, a koristi ga i packet scheduler i njegov sadržaj ovisi o traženoj usluzi. RESV poruke idu istim putem kao i PATH poruke, ali suprotnim smjerom, usput podešavajuci rezervacije za jednog ili više pošiljatelja na svakom cvoru.
Rezervacijska stanja koja RSVP stvara na routerima su tzv. mekana stanja. Da bi se ta stanja održala ili obnavljala RSVP deamon mora periodicki slati poruke za osvježavanje. Odsustvo tih poruka za osvježavanje ce nakon nekog vremena uništiti rezervacijska stanja. Uporabom tih mekih stanja RSVP može vrlo lako mijenjati rute i ukljucivati i iskljucivati korisnike.

Zahtjevi za rezervacijom potjecu od primatelja. Oni ne moraju ici do samog izvorišta podataka nego putuju prema njemu sve dok se ne susretnu sa nekim drugim zahtjevom za istim podacima i stope se sa njima.

Ovo spajanje zahtjeva za rezervacijom glavna je prednost RSVP-a. Na taj se nacin može veliki broj korisnika ukljuciti u multicast grupu bez znacajnog povecanja mrežnog prometa (scalability).

Rezervacijski proces ne odašilje podatke i ne pruža traženu kvalitetu usluge, ali osigurava raspoloživost mrežnih resursa jednom kada do prijenosa stvarno dode.

Iako je RSVP po hijerarhiji iznad IP protokola, on je više kontrolni nego usmjeriteljski protokol. On se u stvari oslanja na druge usmjeriteljske protokole da bi doznao gdje treba isporuciti zahtjev za rezervacijom. RSVP takoder suraduje s unicast i multicast usmjeriteljskim protokolima. Kada tok podataka upravljan RSVP-om promijeni svoju putanju, usmjeriteljski modul obavještava RSVP modul o promjenama i RSVP se brzo prilagodava novoj putanji, te podešava rezervacijske parametre.

Isporuka rezervacijskih parametara nije isto što i njihovo odredivanje. QoS kontrolni uredaji odreduju kako podesiti parametre veze da bi se postigla tražena kvaliteta usluge, a RSVP samo pruža mogucnost distribucije tih parametara. Buduci da razne aplikacije mogu imati razne QoS kontrolne uredaje RSVP je dizajniran tako da te QoS parametre tretira kao nevidljive podatke koji se moraju isporuciti kontrolnim modulima u routerima koji ih onda interpretiraju po potrebi. Ovo logicko odvajanje QoS kontrolnih uredaja i distribucijskih sredstava pojednostavljuje RSVP i cini ga prilagodljivijim novim mrežnim tehnologijama i primjenama.

5.4. Svojstva RSVP-a

RSVP razlikuje pošiljatelja i primatelja. Iako u mnogim slucajevima jedno racunalo može biti i primatelj i pošiljatelj, jedna RSVP rezervacija rezervira resurse za tok podataka u samo jednom smjeru.

RSVP podržava i pojedinacni (unicast) i višeodredišni (multicast) nacin rada i prilagodava se promjeni korisnika i ruta.

RSVP je predviden i za unicast i za multicast. Buduci da rezervacije stvaraju primatelji i da su rezervacijska stanja mekana, RSVP može lako mijenjati rute i korisnike. Mogu se slati IGMP (Internet Group Management Protocol) poruke i zahtijevati ukljucenje u multicast grupu. Spajanje rezervacija omogucava RSVP-u da se prilagodi velikim multicast grupama bez stvaranja prevelikog opterecenja na odašiljackoj strani.

Unutar heterogenih višeodredišnih (multicast) grupa primatelji imaju razlicite kapacitete na raspolaganju i razlicite zahtjeve na kvalitetu usluge. Pojedini primatelj bira razinu kvalitete usluge i tako stvara rezervaciju i održava ju na toj razini koliko god dugo želi. Pošiljatelji rasporeduju promet u nekoliko razlicitih RSVP tokova s razlicitim razinama kvalitete usluge. Svaki RSVP tok podataka je homogen i primatelji mogu birati jedan ili više tih tokova. Ovakav pristup omogucava heterogenim primateljima da zatraže razlicite kvalitete usluga prilagodene njihovim karakteristicnim mogucnostima i potrebama.

5.5. RSVP sucelje

RSVP komunicira i s krajnjim korisnikom i s mrežnim elementima unutar samih usmjeritelja. Za programere najvažniji dio je programsko sucelje na korisnickoj strani. Ovo su osnovne funkcije koje se nalaze u RSVP biblioteci RAPI (RSVP Application Programming Interface):
-rapi_session () stvara i inicira API sjednicu
- rapi_sender () traži od pošiljatelja da specificira parametre svog toka podataka. RSVP daemon primatelja koristi taj flow spec da bi stvorio PATH poruku za doticni tok podataka.
- rapi_reserve () stvara, podešava ili briše rezervaciju.
- rapi_release () traži od RSVP daemona da poništi rezervaciju.

6. RTP

6.1. Uvod

RTP (Real-time Transport Protocol) je protokol temeljen na IP-u i osigurava podršku za prijenos stvarno-vremenskih podataka (audio i video). Usluge koje pruža RTP su vremenska rekonstrukcija, otkrivanje izgubljenih paketa, sigurnost i identifikacija sadržaja. RTP je primarno stvoren za višeodredišni (multicast) prijenos stvarno-vremenskih podataka, ali može se koristiti i za pojedinacni (unicast) prijenos. Može se koristiti i za jednosmjerni prijenos, kao što je Video-on-Demand (VoD), i za interaktivne usluge kao što je Internet telefonija.

RTP se nadopunjuje s RTCP kontrolnim protokolom kako bi dobio podatke o kvaliteti prijenosa i o sudionicima u prijenosu.

6.2. Razvoj

Pokušaji prijenosa glasa mrežama poceli su još ranih sedamdesetih, a 1991. završen je niz eksperimenata na DARTnet-u koju su stvorili Network Research Group of Lawrence Berkeley Laboratory. Protokol koji se tamo koristio kasnije se nazvao RTP version 0.

1992.g. Henning Schulzrinne, GMD Berlin, objavio je RTP version 1, koji je, nakon nekih promjena, odobren 1995.g. od strane ESG-a i nazvan RTP version 2 i kao takav objavljen u slijedecim dokumentima:
- RFC 1889, RTP: A Transport Protocol for Real-Time Applications
- RFC 1890, RTP Profile for Audio and Video Conferences with Minimal Control

U sijecnju 1996.g. Netscape je najavio "Netscape LiveMedia" zasnovan na RTP-u i drugim standardima. Microsoft tvrdi da njihov NetMeeting Conferencing Software podržava RTP. Nakon toga je Industry Alliance around Netscape Inc. pocela koristiti RTP kao podlogu za RTSP (Real Time Streaming Protocol)

6.3. Nacin rada RTP-a

Paketi poslani Internetom imaju nepredvidivo kašnjenje i kolebanje zbog nesinkroniziranosti odašiljacke i prijamne strane. Stvarno-vremenske aplikacije zahtijevaju prikladno vremenski sinkronizirano slanje i reprodukciju podataka. RTP omogucava vremensko oznacavanje, numeraciju paketa unutar niza i razne druge mehanizme koji se brinu o pravovremenom dolasku paketa na odredište.

Vremensko oznacivanje (timestamping) je najvažniji podatak za stvarno-vremenske aplikacije. Pošiljatelj u to polje upisuje trenutak uzorkovanja prvog uzorka (npr. prvog audio uzorka ili slike). Vremenske oznake rastu s kolicinom vremena koju pokriva paket. Nakon prijama paketa, prijamnik koristi vremenske oznake kako bi pravilno rekonstruirao podatke. Vremenske oznake služe i za medusobnu sinkronizaciju razlicitih medija kao što su audio i video u MPEG-u (npr. za sinkronizaciju usana i zvuka). Medutim, RTP sam po sebi nije zadužen za sinkronizaciju. To treba obaviti na aplikacijskom sloju.

UDP ne isporucuje pakete vremenskim slijedom kojim su odaslani pa se koristi numeracija paketa (sequence numbers) kako bi se pristigli paketi pravilno posložili. Pomocu numeracije paketa takoder se može otkriti i gubitak paketa. Treba primijetiti da u nekim video formatima, kada se video okvir podijeli u nekoliko RTP paketa, svi imaju istu vremensku oznaku pa ona nije dovoljna za pravilno svrstavanje paketa.

Identifikacija vrste tereta (payload type identifier) odreduje format tereta i koji su postupci kompresije i kodiranja korišteni. Iz tog polja aplikacija na prijamnoj strani zna kako interpretirati i pravilno reproducirati podatke. Osnovni tipovi tereta su definirani u RFC 1890 (npr. PCM, MPEG1/MPEG2 audio i video, JPEG video, Sun CellB video, H.261 video itd.). U jednom trenutku prijenosa pošiljatelj RTP paketa može slati samo jednu vrstu tereta iako se tijekom prijenosa ta vrsta može promijeniti (npr. zbog zagušenja mreže).

Još jedna funkcija RTP-a je identifikacija izvora (source identification). To omogucava prijamnoj aplikaciji da zna odakle dolaze podaci (velika primjena u audio konferencijama).

Svi gore navedeni mehanizmi su implementirani u RTP zaglavlje, Slika 4. pokazuje RTP paket unutar UDP/IP paketa.

RTP radi preko UDP-a kako bi iskoristio njegovo multipleksiranje i funkciju zaštitne sume (checksum). TCP i UDP su dva najcešce korištena prijenosna protokola na Internetu. TCP je konekcijski orijentiran protokol koji osigurava direktnu vezu i pouzdan tok podataka izmedu dvije tocke, dok je UDP bezkonekcijski orijentiran i nepouzdan datagramski protokol za prijenos. UDP je izabran kao odredišni protokol za RTP iz dva razloga. Prvo, RTP je dizajniran primarno za višeodredišno slanje pa mu samim tim direktna TCP veza ne odgovara. Drugo, za stvarno-vremenske aplikacije pouzdanost isporuke nije jednako važna kao pravovremenost dolaska podataka. Cak štoviše, pouzdana veza kao što je TCP nije poželjna. Npr. prilikom zagušenja mreže neki paketi ce biti izgubljeni i aplikacija ce moci reproducirati sadržaj, ali s puno nižom kvalitetom. Ako protokol inzistira na pouzdanom prijenosu i traži da se izgubljeni paketi ponovno pošalju, to ce povecati kašnjenje, zagušiti mrežu i na kraju aplikacija vjerojatno više nece imati dovoljno podataka za obradu.
RTP i RTCP paketi se zato obicno šalju koristeci UDP/IP usluge. Pokušava se postici i to da se mogu slati i pomocu CLNP (ConnectionLess Network Protocol), IPX (Internetwork Packet Exchange), AAL5/ATM i drugim protokolima.

U praksi, RTP je obicno implementiran u samu aplikaciju kao i rješenja za povratak izgubljenih paketa i kontrolu zagušenja.

Da bi se podesila RTP sjednica aplikacija definira odredeni par prijenosnih adresa. Prijenosnu adresu cine mrežna adresa (IP adresa) i TPC ili UDP adresa. Dobiva se jedan par adresa za podatke (mrežna adresa, RTP port) i jedan par adresa za kontrolu (mrežna adresa, RTCP port). RTP obicno koristi parni broj porta, a RTCP prvi viši neparni broj porta. U multimedijskoj sjednici svaki medij se prenosi posebnom RTP sjednicom sa svojim posebnim RTCP paketima koji odreduju kvalitetu prijama za tu sjednicu. Npr. audio i video putuju razlicitim RTP sjednicama i tako se omogucava prijamnoj aplikaciji da bira hoce li primati samo jedan ili oba medija.

Gotov scenarij za jednu audio konferenciju predstavljen u RFC 1889 ce možda najbolje ilustrirati uporabu RTP-a. Tamo je definiran profil za uporabu RTP-a i RTCP-a u višekorisnickim audio i video konferencijama s minimalnom kontrolom. Recimo da svaki sudionik konferencije šalje audio podatke u segmentima od 20 ms. Na svaki taj segment se dodaje RTP zaglavlje i takav RTP paket se umece u UDP paket. RTP zaglavlje nosi informaciju o tome kakvo audio kodiranje je uporabljeno (npr. PCM). Korisnici imaju opciju mijenjati nacin kodiranja za trajanja konferencije zbog, npr., zagušenja u mreži ili ako neki novoprikljuceni korisnik nema dovoljnu širinu pojasa za sadašnji nacin kodiranja. Vremenske oznake i numeracija paketa u RTP zaglavlju služe da bi se tocno rekonstruirao podatak sa izvora, tako da se u ovom slucaju audio segmenti reproduciraju na prijamnoj strani svakih 20 ms.

6.4. RTP zaglavlje

Prvih dvanaest bajta pojavljuje se u svakom RTP paketu dok se lista CSRC (contributing source) identifikatora pojavljuje samo ako je doda mikser. Polja imaju slijedece znacenje:
-version (V): 2 bita. Verzija RTP-a. Najnovija je verzija 2.
- pading (P): 1 bit. Ako je jedinica, paket sadrži još jedan ili više bajta na kraju koji nisu dio tereta. Zadnji bajt nosi informaciju koliko ovih okteta se zanemaruje.
-extension (X): 1 bit. Ako je jedinica, onda iza ovog zaglavlja slijedi još tocno jedno dodatno zaglavlje.
- CSCR count (CC): 4 bita. Broj doprinosecih izvora (ako RTP paket sadrži podatke sa više izvora).
-marker (M): 1 bit. Interpretacija ovisi o profilu. Npr. za audio je to pocetak ili kraj perioda tišine, a za video pocetak okvira.
-payload type (PT): 7 bita. Odreduje format RTP tereta i nacin na koji ce ga aplikacija interpretirati.
- sequence number: 16 bita. Raste za 1 za svaki poslani RTP paket i može ga koristiti primatelj da otkrije koji su paketi izgubljeni i da poslaže pakete po redu. Pocetna vrijednost se odabire nasumce.
- timestamp: 32 bita. U polje se upisuje trenutak uzorkovanja prvog uzorka. Koristi se za sinkronizaciju. Pocetna vrijednost se odabire nasumce.
- SSRC: 32 bita. Indikator sinkronizirajceg izvora. Služi za razlikovanje sinkronizirajucih izvora unutar jedne RTP sjednice.
- CSRC list: 0 do 15 stavaka, svaki po 32 bita. Nula za pojedinacni izvor ili neki drugi broj ako podaci izlaze iz RTP miksera.

6.5. Višekorisnicki pristup

Zahvaljujuci odijeljenim RTP sjednicama, svaki korisnik pojedinacno može birati medije koje želi primati. Moguci problemi koji tu nastaju su:
-svi korisnici ne moraju htjeti primati isti format medija;
- mogu postojati razlike u pogledu pristupne mreže;
- mogu postojati razlike u pogledu krajnjeg sustava (terminala);

Za prilagodbu se koriste RTP mikser i RTP translator.
Promatrajmo slucaj kada je glavnina sudionika u mreži velike brzine, a neki sudionici su u dijelu mreže sa sporijom vezom. Loše rješenje bi bilo da svi sudionici koriste audio podatke smanjene pojasne širine, tj. lošije kvalitete. Bolje rješenje je da se prema sporijem dijelu mreže stavi RTP mikser koji rekonstruira struje pojedinih audio izvora, resinkronizira ih i kombinira u jedan tok pogodniji za sporiju vezu. RTP tok iz miksera kodira se kao da je sinkronizirajuci izvor mikser, a u zaglavlju su navedeni doprinoseci tokovi (u RTP zaglavlju popis CSRC ukljucuje pojedina SSRC). RTP mikser je pogodan samo za audio.

Promatrajmo sada slucaj kada su svi sudionici u brzim mrežama ali koriste razlicite formate. Sada nije potrebno kombiniranje pojedinih tokova u jednu jer je propusnost mreže dovoljna. Problem prilagodbe formata se rješava primjenom RTP translatora.
RTP translator obavlja prekodiravanje iz jednog formata u drugi uz netaknutu oznaku sinkronizirajuceg izvora.

6.6. Svojstva RTP-a

• RTP osigurava isporuku s-kraja-na-kraj podataka sa stvarno-vremenskim osobinama, kao što su interaktivni audio i video. On sam po sebi nema nikakav mehanizam koji bi osigurao pravovremensku isporuku vec za to treba pomoc nižih slojeva koji imaju kontrolu nad resursima u usmjeriteljima i svvitcherima. RTP se oslanja na RSVP za rezervaciju resursa i osiguravanje tražene kvalitete usluge (QoS).
• RTP ne mora znati ništa o nižim mrežnim slojevima osim da ce oni obaviti uokvirivanje. RTP se oslanja na UDP (ili neki drugi prijenosni protokol) za multipleksiranje i zaštitnu sumu.
• Za razliku od drugih nacina prijenosa podataka RTP ne garantira nikakvu pouzdanost isporuke ili kontrolu toka podataka ili zagušenja mreže. On daje vremenske oznake i numeraciju paketa, a o implemetiranju svega toga brine se sama aplikacija.
• RTP je protokol koji namjerno nije dovršen da bi bio otvoren za nove vrste tereta i novu multimedijsku programsku podršku. RTP se može jednostavno prilagoditi novim formatima i aplikacijama dodavanjem novog profila i specifikacijom tereta.
• RTP i RTCP pružaju funkcionalnost i kontrolne mehanizme neophodne za prijenos stvarno-vremenskih sadržaja. Medutim, RTP/RTCP ne obavlja zadatke na višim mrežnim slojevima kao što je npr. sinkronizacija. To se mora obaviti na aplikacijskoj razini.
• Algoritme za kontrolu toka i strategiju retransmisije definira aplikacija. To je koncept uokvirivanja na razini aplikacije (Application Level Framing - ALF). RTP se prilagodava aplikaciji pomocu profila i specifikacije formata vrste tereta.

7. RTCP

7.1. Uvod

RTCP (Real-Time Control Protocol) je kontrolni protokol predviden za rad zajedno sa RTP-om. Standardiziran je u RFC 1889 i 1890. Sudionici RTP sjednice periodicki šalju RTCP pakete da bi obavijestili izvor o kvaliteti isporuke (dijagnostika) i dostavili svoje podatke (membership).

7.2. Nacin rada

RFC 1889 definira pet RTCP tipova paketa koji nose kontrolne informacije:
• RR: receiver report. Izvješce primatelja. Šalju ga svi primatelji koji nisu aktivni sudionici sjednice. Sadrži povratnu informaciju o kvaliteti prijama RTP paketa za svaki sinkronizirajuci izvor, broj izgubljenih paketa, kašnjenje i vremenske oznake da bi se izracunalo ukupno kašnjenje izmedu primatelja i pošiljatelja.
• SR: sender report. Izvješce pošiljatelja. Šalju ga aktivni sudionici sjednice. Sadrži podatke o pošiljatelju, sinkronizaciji, kumulativne brojace paketa i broj poslanih bajta.
• SDES: source description items. Opis izvora.
• BYE. Odlazak. Oznacuje kraj sudjelovanja.
• APP: application specific functions. Nestandardne funkcije nekih aplikacija (zbog razvoja novih alata i funkcija).

Ovo je primarna uloga RTCP-a. RTCP daje povratnu informaciju aplikaciji o kvaliteti distribucije podataka. Kontrolna informacija je korisna i pošiljatelju i primatelju i nekoj drugoj stranci koja samo gleda sjednicu. Pošiljatelj može podesiti svoje odašiljanje na temelju primljene povratne informacije. Primatelj može utvrditi da li je zagušenje lokalno, regionalno ili globalno. Pomocu te kontrolne informacije mogu se i odrediti performance za višeodredišnu distribuciju.

U RTP paketu izvori su identificirani pomocu nasumce odabranih 32 bitnih identifikatora. Ti identifikatori su neprikladni za ljudsku uporabu pa RTCP SDES (source description) paketi sadrže tekstualnu informaciju (cannonical names) koja je globani jedinstveni identifikator sudionika sjednice. Tu se mogu upisati i korisnikov broj telefona, ime i prezime, e-mail adresa i druge informacije.

RTO izvješce pošiljatelja sadrži podatke o pravom vremenu izvorišnih podataka i vremenskim oznakama paketa. To se može koristiti za sinkronizaciju usana i audio podatka.

RTCP poruke periodicki se šalju medu sudionicima sjednice. Kada se broj sudionika poveca nužno je dobro izbalansirati dobivanje dosadašnjih kontrolnih informacija i ogranicavanje prometa samih kontrolnih informacija. Da bi mogao raditi s velikim multicast grupama RTCP mora sprijeciti zagušenje mreže kontrolnim informacijama.
8. RTSP

8.1. Uvod

Umjesto pohranjivanja velikih multimedijskih sadržaja i njihovog lokalnog reproduciranja, multimedijski podaci se šalju mrežom kao tok podataka. Podaci su razbijeni na manje pakete pogodne za prijenos mrežom i putuju kao tok bitova. Primatelj može reproducirati prvi paket dok dekomprimira drugi a prima treci. Na taj nacin može konzumirati sadržaj bez cekanja da on cijeli stigne na njegovo racunalo.

RTSP (Real-Time Streaming Protocol) je aplikacijski klijent-server protokol za upravljanje dostavom podataka sa stvarno-vremenskim svojstvima preko IP mreže. On omogucava daljinsko upravljanje multimedijskim sadržajem kao kod video rekordera (pauza, premotavanje naprijed i nazad i sl.). Izvor podataka može biti ili prijenos uživo ili vec ranije pohranjeni podaci.

RTSP je aplikacijski protokol dizajniran da suraduje s protokolima s nižeg nivoa (RTP, RSVP). On pruža sredstva za odabir kanala za isporuku (kao što su UDP, multicast UDP, TCP) i mehanizama za isporuku temeljenih na RTP-u. Služi i za pojedinacno i za višeodredišno odašiljanje.

8.2. Razvoj

RTSP su razvili RealNetworks, Netscape Communications i Columbia University. Prva radna verzija predana je lETF-u 1996.g. na razmatranje i od onda su ucinjene mnoge promjene. Standardiziran je u RFC 2326.

8.3. Nacin rada RTSP-a

RTSP uspostavlja i kontrolira stvarno-vremensku vezu izmedu medijskih poslužitelja i klijenata. Medijski poslužitelj pruža usluge reproduciranja ili snimanja multimedijskih podataka dok klijent traži od poslužitelja kontinuiran tok podataka koju ce primati. RTSP je "mrežni daljinski upravljac" izmedu poslužitelja i klijenta. On pruža slijedece usluge:
• Dostavljanje podataka od poslužitelja. Klijent može tražiti opis prezentacije i tražiti od poslužitelja da uspostavi sjednicu i pocne slati tražene podatke.
• Pozivanje nekog medijskog poslužitelja da se ukljuci u konferenciju gdje onda može reproducirati ili snimiti neku prezentaciju.
• Dodavanje nekog medija vec postojecoj prezentaciji. Poslužitelj ili klijent mogu obavijestiti jedan drugog o dostupnosti nekog dodatnog medija.

RTSP pokušava omoguciti iste usluge za tok audio i video podataka kao što ih HTTP pruža za tekst i grafiku. Namjerno je dizajniran da ima slicnu sintaksu i funkcije kao HTTP da mu se mogu dodati neki HTTP-ovi mehanizmi.
U RTSP-u je svaka prezentacija i tok medijskih podataka identificirana RTSP URL-om (Uniform Resource Locator). Ukupni podaci o prezentaciji i svojstva medija upisana su u opisnu datoteku, u koju još mogu biti upisani i nacin kodiranja, jezik, RTSP URL-ovi, odredišne adrese, portovi i drugi parametri. Toj datoteci klijent može pristupiti pomocu HTTP-a, email-a ili na neki drugi nacin.

Ali, RTSP se razlikuje od HTTP-a u nekoliko stvari. Prvo, dok je HTTP stateless protokol, RTSP cuva stanje (identifikator sjednice) za svaki prikaz u tijeku. Drugo, HTTP je u osnovi asimetrican protokol gdje klijent šalje zahtjev, a poslužitelj odgovara, dok kod RTSP-a i poslužitelj i klijent mogu slati zahtjeve.

RTSP trenutno rabi slijedece metode:

• OPTIONS: Klijent ili poslužitelj govori onom drugom koje opcije on može prihvatiti.
• DESCRIBE: Klijent dobiva opis prezentacije ili medijskog objekta identificiranog pomocu zahtjevanog URL-a od poslužitelja.
• ANNOUNCE: Kada je poslan od strane klijenta prema poslužitelju šalje opis prezentacije ili medijskog objekta identificiranog URL-om. Kad je poslan od strane poslužitelja prema klijentu, obnavlja opis sjednice u stvarnom vremenu.
• SETUP: Klijent traži od poslužitelja da alocira resurse za struju podataka i otvori RTSP sjednicu.
• PLAY: Klijent traži od poslužitelja da zapocne slanje podataka alociranih pomocu SETUP-a.
• PAUSE: Klijent privremeno zaustavlja isporuku struje podataka, ali bez oslobadanja poslužiteljevih resursa.
• TEARDOWN: Klijent traži od poslužitelja da prestane slati podatke i oslobodi svoje resurse.
• GET_PARAMETER: Vraca vrijednost parametra prezentacije ili toka podataka specificirane URL-om.
• SET_PARAMETER: Postavlja vrijednost parametra prezentacije ili toka podataka specificirane URL-om.
• REDIRECT: Poslužitelj izvješcuje klijente da se mora spojiti na neki drugi poslužitelj.
• RECORD: Klijent zapocinje snimanje odredenih podataka u suglasnosti sa opisom prezentacije.

Valja primijetiti da se neke od ovih metoda mogu slati i od klijenta prema poslužitelju i od poslužitelja prema kijentu, dok se neke mogu slati samo u jednom smjeru. Ne moraju sve gore navedene metode postojati u jednom serveru (npr. medijski poslužitelj koji prenosti neki live dogadaj ne mora podržavati PAUSE metodu).

RTSP poruke se obicno šalju neovisnim kanalom, a ne onim kojim putuju podaci. Mogu se odašiljati perzistentnim transportnim vezama, ili se može stvoriti jedna veza po zahtjevu, ili se može raditi u bezkonekcijskom modu.

8.4. Svojstva RTSP-a

• RTSP je aplikacijski protokol, sintaksom i operacijama slican HTTP-u, ali radi s audio i video podacima. Koristi URL-ove isto kao i HTTP.
• RTSP poslužitelj mora obnavljati svoj status pomocu SETUP, TEARDOWN i drugih metoda.
• RTSP poruke se prenose izvan pojasa. Protokol za RTSP može biti drugaciji od onog kojim se prenose podaci.
• Za razliku od HTTP-a, kod RTSP-a zahtjeve mogu izdavati i klijent i poslužitelj.
• RTSP omogucava kompatibilnost izmedu klijenata i poslužitelja razlicitih proizvodaca.

Razvojem mrežnih protokola za mulitmedijske usluge pokušava se prilagoditi Internet, koji u stvari nije pogodan za prijenos stvarno-vremenskih usluga, zahtjevima današnjice. Sve više i više ljudi u svijetu koristi Internet i želi uživati u multimedijskim uslugama sa stvarnovremenskim osobinama. Najpopularnija i najraširenija usluga danas je vjerojatno VoIP (Voice over IP), odnosno Internet telefonija. Kako što bolje prilagoditi jednu takvu paketski orijentiranu mrežu zahtjevima tih korisnika danas je najvažniji zadatak znanstvenika i mrežnih administratora. Današnjih "vjerojatno zadovoljavajucih" 10 do 15 slika u sekundi s vremenom ce sve više rasti i morati ce se stalno obavljati prilagodbe i uvoditi poboljšanja postojecih mrežnih alata. Multimedija se sve više uvodi i u poslovanje, cak i u vidu marketinga, pa je ta prilagodba i ekonomski opravdana.

Medu najvažnijim protokolima za prijenos mutimedijskih sadržaja svakako su RSVP, RTP, RTCP i RTSP. Evo njihovog kratkog pregleda:

RSVP je protokol koji se bavi nižim slojevima (koji imaju direktnu kontrolu nad mrežnim resursima) i on rezervira resurse za stvarnovremenske aplikacije u usmjeriteljima. Zbog te svoje uloge on je kljucan za prijenos multimedijskih sadržaja.

RTP je prijenosni protokol za stvarno-vremenske podatke. On daje vremenske oznake, numerira pakete i osigurava mnoga druga sredstva potrebna za stvarno-vremenki prijenos podataka. RTP se oslanja na RSVP za rezervaciju resursa potrebnih za postizanje tražene kvalitete usluge.

RTCP je kontrolni dio RTP-a koji pomaže oko kvalitete usluge i kontrole pristupa.

RTSP je kontrolni protokol koji inicira i usmjerava isporuku stvarno-vremenskog toka podataka iz mrežnih poslužitelja. On je internetski "daljinski upravljac".

Naravno da ovo nisu svi protokoli koji se danas koriste za prijenos multimedijskih sadržaja. Postoje još mnoge alternative i nadopune gore navedenim protokolima, a koji od njih ce u buducnosti prevladati, tek ce se vidjeti.
K. D.: Mrežni protokoli za multimedijske usluge PREGLED SKRACENICA

SKRACENICA:	ZNACENJE:
ATM	Asyncronous Transfer Mode
HTTP	Hypertext Transfer Protocol
IP	Internet Protocol
LAN	Local Area Network
QoS	Quality of Service
RSVP	Resource Reservation Protocol
RTCP	Real-time Transport Control Protocol
RTP	Real-Time Protocol
RTSP	Real-Time Streaming Protocol
TCP	Transport Control Protocol
UDP	User Datagram Protocol
URL	Uniform Resource Locator
VoD	Video on Demand
VoIP	Voice over IP
WAN	Wide Area Network
K. D.	Mrežni protokoli za multimedijske usluge