Mreni protokoli za multimedijske usluge
Racunalne mree 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 mreama
bila u tekstualnom obliku. Danas, s naglim porastom multimedijskih i mrenih
tehnologija, multimedija je postala nezaobilazna pojava na Internetu.
Na trištu su se pojavili multimedijski mreni 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 traiti da clanovi jednog tima budu u istoj
zgradi, pa cak ni u istoj dravi. Ekonomske prednosti takvog rada
su ocigledne.
Multimedijske mrene usluge moraju izgraditi hardversku i softversku
infrastrukturu i razne alate koji ce podravati prijenos multimedijskih
usluga racunalnim mreama i omoguciti korisnicima kvalitetnu komunikaciju.
Multimedijske mrene usluge ce uvelike unaprijediti uporabu racunala
kao komunikacijskog alata. Vjeruje se da ce jednog dana multimedijske
mree zamijeniti telefone, televizore i druge izume koji su jednom
davno drasticno promijenili naše ivote.
2. Ciljevi i izazovi multimedijskih mrenih usluga
2.1. Stvarno-vremenski izazov
Slanje multimedijskih podataka i usluga racunalnim mreama 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 mreama 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, mrena 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 mree 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 mrei.
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 moe 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 stiu
prebrzo spremnik ce se "preliti" i neki paketi ce biti izgubljeni
što ce u konacnici rezultirati lošijom kvalitetom reproduciranog
materijala. Kada podaci stiu 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 sadraja 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 mreni promet mora suociti.
Mogucnost rješenja ovih problema dolazi iz postojece softverske
mrene 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 mrenih protokola za multimedijske
usluge postaje glavna zadaca inenjera 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 mree
(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 podrava vrlo širok frekvencijski pojas,
konekcijski je orijentiran i podrava razlicite razine kvalitete
usluge (Quality Of Service - QoS) za razne primjene. Ali trenutno vrlo
malo korisnika ima ATM mreu 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
mree po cijelom svijetu i ukljucuju ih u Internet. U stvari, Internet
je postao platforma za vecinu mrenih 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 mrei bez dodatnih ulaganja
u novu mreu i sucelja izmedu razlicitih mrea.
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 mreu, hardver mora osigurati
dovoljnu širinu frekvencijskog pojasa. Multimedijske usluge su obicno
predvidene za višeodredišno slanje (multicast), tj. za slanje
istog multimedijskog sadraja 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 mrea 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 raspoloivost
sustava. Nadalje, kad se poziv jednom prihvati, korisnik ocekuje da nece
biti neocekivano prekinut i da ce kvaliteta biti stalna. U mobilnoj se
telefonskoj mrei 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:
mrea ce pokušati zadovoljiti korisnikove zahtjeve, ali bez
ikakvih garancija da ce traena kvaliteta zaista biti pruena.
U vecini primjera zastupa se elastican pristup kvaliteti usluge, tj. prilagodavanje
promjenama u propusnosti i kašnjenju, dok se niti u slucaju mrenog
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.
QoS se moe promatrati na tri razine:
Aplikacija
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.
Sustav
Kvaliteta na razini sustava. Korisnik je aplikacija. To su kvantitativni
parametri (propusnost, vrijeme odziva, sustav posluivanja i rasporedivanja).
Mrea
Kvaliteta na razini mree. Korisnik je sustav. Izraava se
preko mjerljivih, kvantitativnih i kvalitativnih parametara kvalitete
usluge. To su propusnost, kašnjenje, kolebanje kašnjenja, gubici,
raspoloivost i blokiranje.
Uloga kvalitete usluge je rezervacija i dodjela resursa od izvora do odredišta
za vrijeme multimedijske sjednice, odravanje resursa prema specifikaciji
zatraene kvalitete usluge i prilagodba promjenama koje nastaju tijekom
poziva.
4. Internet
4.1. Osnovni pojmovi
Internet
je najopcenitije govoreci mrea dviju ili više mrea. 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
mrea, odnosno radi na principu komutacije paketa.
Mrea je skup racunala (PC, radne stanice), uredaja,
komunikacijskih medija i mrenog softvera koji implementiraju neki
komunikacijski protokol. Mree 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 moe
odrediti redoslijed razmjene podataka izmedu dviju strana. U stvari, razmjena
podataka izmedu dvije strane moe se jedino obaviti ako oba racunala
koriste isti protokol.
Slika 1. Internetski protokolni sloaj
Svojstvo Interneta da posjeduje veliki broj razlicitih protokola, od kojih
svaki obavlja neku drugu funkciju, omogucava mu modularnost, fleksibilnost,
jednostavnost i proširivost. Mreni posluitelji koji pruaju
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 sloaju izgraduje se na sloju koji je direktno
ispod njega. Svaki sloj protokolnog sloaja dodaje paketu koji se
prenosi zaglavlje karakteristicno za taj sloj. Npr. na mrenom sloju
se upisuju izvorišna i odredišna adresa i dr.
4.2. TCP/IP sloaj
Slika 2. opisuje dio TCP/IP sloaja koji koriste svi
sustavi spojeni na Internet:
Slika 2. Tok podataka kroz TCP/IP sloaj
Na dnu su podatkovni linkovi i fizicki slojevi. Fizicki sloj radi s naponima,
a sloj podatkovih veza prua 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. Vano svojstvo internetskog sloaja 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 prua 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 slae 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 sadri barem
20 bajta (bajt - 8 bitni dio informacije) od kojih su najvaniji
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.
Slika 3. TCP zaglavlje
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.
Slika 4. IP 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, prua bezkonekcijsku i nepouzdanu uslugu isporuke. Osim
toga u zaglavlju IP-a postoji još jedna informacija koja je jako
vana. 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 mrei 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 moe 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, mrea 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.
Slika 5. UDP zaglavlje
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 moe
koristiti nekoliko programa odjednom. UDP zaglavlje je znatno krace od
TCP-ovog, ne sadrava 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 mreni protokol koji omogucava
prijamnoj strani da zatrai odredenu kvalitetu usluge s kraja na
kraj za njegov tok podataka. Stvarno-vremenske aplikacije koriste RSVP
za rezervaciju neophodnih resursa kod mrenih usmjeritelja du
prijenosne rute tako da bi traena širina frekvencijskog pojasa
bila stvarno raspoloiva 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
RSVP radna grupa IETF-a danas razvija i druge protokole za uporabu s
RSVP-om.
5.3. Nacin rada RSVP-a
Kada aplikacija koja prima tok podataka zatrai 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 odrava kvalitetu
veze koje je zatraena.
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 traene 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 zatraila
vezu. Ako su oba zahtjeva zadovoljena RSVP daemon podešava packet
scheduler i packet classifier kako bi se ostvarila traena kvaliteta
usluge. Packet classifier odreduje klasu kvalitete usluge za svaki paket,
a packet scheduler slae 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.
Slika 6. Rezervacija na cvoru
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 sadri flow spec koji
opisuje obrazac izvorišta (format u kojem su podaci, izvorišnu
adresu i izvorišni port) i karakteristike mrenog 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 sadre 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 sadraj ovisi o traenoj 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 odrala ili obnavljala RSVP deamon mora periodicki
slati poruke za osvjeavanje. Odsustvo tih poruka za osvjeavanje
ce nakon nekog vremena uništiti rezervacijska stanja. Uporabom tih
mekih stanja RSVP moe 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.
Slika 7. Spajanje rezervacija
Ovo spajanje zahtjeva za rezervacijom glavna je prednost RSVP-a. Na taj
se nacin moe veliki broj korisnika ukljuciti u multicast grupu bez
znacajnog povecanja mrenog prometa (scalability).
Rezervacijski proces ne odašilje podatke i ne prua traenu
kvalitetu usluge, ali osigurava raspoloivost mrenih 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
traena kvaliteta usluge, a RSVP samo prua 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 mrenim tehnologijama i primjenama.
5.4. Svojstva RSVP-a
RSVP tokovi podataka su u simplex modu.
RSVP razlikuje pošiljatelja i primatelja. Iako u mnogim slucajevima
jedno racunalo moe biti i primatelj i pošiljatelj, jedna RSVP
rezervacija rezervira resurse za tok podataka u samo jednom smjeru.
RSVP podrava 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 moe
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.
RSVP je prilagoden primatelju i obraduje heterogene primatelje.
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 odrava 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 zatrae razlicite kvalitete
usluga prilagodene njihovim karakteristicnim mogucnostima i potrebama.
RSVP je kompatibilan s drugim protokolima.
RSVP radi i s IPv4 i s IPv6.
5.5. RSVP sucelje
RSVP komunicira i s krajnjim korisnikom i s mrenim elementima unutar
samih usmjeritelja. Za programere najvaniji 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 () trai 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 () trai 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 prua RTP su vremenska rekonstrukcija, otkrivanje izgubljenih
paketa, sigurnost i identifikacija sadraja. RTP je primarno stvoren
za višeodredišni (multicast) prijenos stvarno-vremenskih podataka,
ali moe se koristiti i za pojedinacni (unicast) prijenos. Moe
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 mreama 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 podrava 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 najvaniji 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 slue
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 zaduen 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 posloili. Pomocu numeracije paketa takoder se moe
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 moe
slati samo jednu vrstu tereta iako se tijekom prijenosa ta vrsta moe
promijeniti (npr. zbog zagušenja mree).
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.
Slika 8. RTP podatak u IP paketu
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 vana kao pravovremenost
dolaska podataka. Cak štoviše, pouzdana veza kao što je
TCP nije poeljna. Npr. prilikom zagušenja mree neki paketi
ce biti izgubljeni i aplikacija ce moci reproducirati sadraj, ali
s puno niom kvalitetom. Ako protokol inzistira na pouzdanom prijenosu
i trai da se izgubljeni paketi ponovno pošalju, to ce povecati
kašnjenje, zagušiti mreu 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 mrena adresa (IP adresa) i TPC ili
UDP adresa. Dobiva se jedan par adresa za podatke (mrena adresa,
RTP port) i jedan par adresa za kontrolu (mrena 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
moda 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 mrei ili ako neki novoprikljuceni korisnik nema
dovoljnu širinu pojasa za sadašnji nacin kodiranja. Vremenske
oznake i numeracija paketa u RTP zaglavlju slue 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
RTP zaglavlje izgleda ovako:
Slika 9. 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 sadri 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 sadri
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 moe
ga koristiti primatelj da otkrije koji su paketi izgubljeni i da poslae
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. Slui 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 moe
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 mree;
- mogu postojati razlike u pogledu krajnjeg sustava (terminala);
Za prilagodbu se koriste RTP mikser i RTP translator.
Promatrajmo slucaj kada je glavnina sudionika u mrei velike brzine,
a neki sudionici su u dijelu mree 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 mree 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 mreama ali
koriste razlicite formate. Sada nije potrebno kombiniranje pojedinih tokova
u jednu jer je propusnost mree 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 niih slojeva koji imaju kontrolu nad resursima u
usmjeriteljima i svvitcherima. RTP se oslanja na RSVP za rezervaciju resursa
i osiguravanje traene kvalitete usluge (QoS).
• RTP ne mora znati ništa o niim mrenim 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
mree. 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 moe jednostavno prilagoditi novim formatima i aplikacijama dodavanjem
novog profila i specifikacijom tereta.
• RTP i RTCP pruaju funkcionalnost i kontrolne mehanizme neophodne
za prijenos stvarno-vremenskih sadraja. Medutim, RTP/RTCP ne obavlja
zadatke na višim mrenim 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. Sadri 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. Sadri 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).
Kroz ove kontrolne informacijske pakete RTCP prua slijedece usluge:
• Nadgledanje kvalitete usluge i kontrola zagušenja.
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 moe podesiti svoje odašiljanje na
temelju primljene povratne informacije. Primatelj moe utvrditi da
li je zagušenje lokalno, regionalno ili globalno. Pomocu te kontrolne
informacije mogu se i odrediti performance za višeodredišnu
distribuciju.
• Identifikaciju izvora.
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 sadre 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.
Sinkronizacija razlicitih medija.
RTO izvješce pošiljatelja sadri podatke o pravom vremenu
izvorišnih podataka i vremenskim oznakama paketa. To se moe
koristiti za sinkronizaciju usana i audio podatka.
Skaliranje kontrolnih informacija.
RTCP poruke periodicki se šalju medu sudionicima sjednice. Kada
se broj sudionika poveca nuno 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
mree kontrolnim informacijama.
8. RTSP
8.1. Uvod
Umjesto pohranjivanja velikih multimedijskih sadraja i njihovog
lokalnog reproduciranja, multimedijski podaci se šalju mreom
kao tok podataka. Podaci su razbijeni na manje pakete pogodne za prijenos
mreom i putuju kao tok bitova. Primatelj moe reproducirati
prvi paket dok dekomprimira drugi a prima treci. Na taj nacin moe
konzumirati sadraj 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 mree. On omogucava daljinsko upravljanje multimedijskim sadrajem
kao kod video rekordera (pauza, premotavanje naprijed i nazad i sl.).
Izvor podataka moe biti ili prijenos uivo ili vec ranije pohranjeni
podaci.
RTSP je aplikacijski protokol dizajniran da suraduje s protokolima s
nieg nivoa (RTP, RSVP). On prua sredstva za odabir kanala
za isporuku (kao što su UDP, multicast UDP, TCP) i mehanizama za
isporuku temeljenih na RTP-u. Slui 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
posluitelja i klijenata. Medijski posluitelj prua usluge
reproduciranja ili snimanja multimedijskih podataka dok klijent trai
od posluitelja kontinuiran tok podataka koju ce primati. RTSP je
"mreni daljinski upravljac" izmedu posluitelja i
klijenta. On prua slijedece usluge:
• Dostavljanje podataka od posluitelja. Klijent moe
traiti opis prezentacije i traiti od posluitelja da
uspostavi sjednicu i pocne slati traene podatke.
• Pozivanje nekog medijskog posluitelja da se ukljuci u konferenciju
gdje onda moe reproducirati ili snimiti neku prezentaciju.
• Dodavanje nekog medija vec postojecoj prezentaciji. Posluitelj
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 prua 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 moe 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 posluitelj odgovara, dok kod RTSP-a i posluitelj
i klijent mogu slati zahtjeve.
RTSP trenutno rabi slijedece metode:
• OPTIONS: Klijent ili posluitelj govori onom drugom koje
opcije on moe prihvatiti.
• DESCRIBE: Klijent dobiva opis prezentacije ili medijskog objekta
identificiranog pomocu zahtjevanog URL-a od posluitelja.
• ANNOUNCE: Kada je poslan od strane klijenta prema posluitelju
šalje opis prezentacije ili medijskog objekta identificiranog URL-om.
Kad je poslan od strane posluitelja prema klijentu, obnavlja opis
sjednice u stvarnom vremenu.
• SETUP: Klijent trai od posluitelja da alocira resurse
za struju podataka i otvori RTSP sjednicu.
• PLAY: Klijent trai od posluitelja da zapocne slanje
podataka alociranih pomocu SETUP-a.
• PAUSE: Klijent privremeno zaustavlja isporuku struje podataka,
ali bez oslobadanja posluiteljevih resursa.
• TEARDOWN: Klijent trai od posluitelja 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: Posluitelj izvješcuje klijente da se mora
spojiti na neki drugi posluitelj.
• 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
posluitelju i od posluitelja prema kijentu, dok se neke mogu
slati samo u jednom smjeru. Ne moraju sve gore navedene metode postojati
u jednom serveru (npr. medijski posluitelj koji prenosti neki live
dogadaj ne mora podravati PAUSE metodu).
RTSP poruke se obicno šalju neovisnim kanalom, a ne onim kojim putuju
podaci. Mogu se odašiljati perzistentnim transportnim vezama, ili
se moe stvoriti jedna veza po zahtjevu, ili se moe 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 posluitelj mora obnavljati svoj status pomocu SETUP,
TEARDOWN i drugih metoda.
• RTSP poruke se prenose izvan pojasa. Protokol za RTSP moe
biti drugaciji od onog kojim se prenose podaci.
• Za razliku od HTTP-a, kod RTSP-a zahtjeve mogu izdavati i klijent
i posluitelj.
• RTSP omogucava kompatibilnost izmedu klijenata i posluitelja
razlicitih proizvodaca.
ZAKLJUCAK
Razvojem mrenih 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 uivati 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 mreu
zahtjevima tih korisnika danas je najvaniji zadatak znanstvenika
i mrenih 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 mrenih
alata. Multimedija se sve više uvodi i u poslovanje, cak i u vidu
marketinga, pa je ta prilagodba i ekonomski opravdana.
Medu najvanijim protokolima za prijenos mutimedijskih sadraja
svakako su RSVP, RTP, RTCP i RTSP. Evo njihovog kratkog pregleda:
RSVP je protokol koji se bavi niim slojevima (koji imaju direktnu
kontrolu nad mrenim resursima) i on rezervira resurse za stvarnovremenske
aplikacije u usmjeriteljima. Zbog te svoje uloge on je kljucan za prijenos
multimedijskih sadraja.
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 traene kvalitete usluge.
RTCP je kontrolni dio RTP-a koji pomae oko kvalitete usluge i kontrole
pristupa.
RTSP je kontrolni protokol koji inicira i usmjerava isporuku stvarno-vremenskog
toka podataka iz mrenih posluitelja. On je internetski "daljinski
upravljac".
Naravno da ovo nisu svi protokoli koji se danas koriste za prijenos multimedijskih
sadraja. Postoje još mnoge alternative i nadopune gore navedenim
protokolima, a koji od njih ce u buducnosti prevladati, tek ce se vidjeti.
K. D.: Mreni 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. |
Mreni protokoli za multimedijske usluge
|
LITERATURA
[1]. RFC 0768 User Datagram Protocol. J. Postel.
[2]. RFC 0791 Internet Protocol. J. Postel.
[3]. RFC 0793 Transmission Control Protocol. J. Postel.
[4]. RFC1889 RTP: A Transport Protocol for Real-Time Applications. Audio-Video
Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V.
Jacobson.
[5]. RFC 2236 Internet Group Management Protocol, Version 2. W. Fenner.
[6]. RFC 2326 Real Time Streaming Protocol. H. Schulzrinne, A. Rao,
R. Lamphier
[7]. http://www.cisco.com/warp/public/759/ipj 2-4/ipj 2-4 multicast.html
[8]. http://oac3.uth.tmc.edu/staff/snewton/tcp-tutorial/
[9]. http://www.itprc.com/tcpipfaq/default.html [10]. http://www.isi.edu
[11]. http://www.cs.columbia.edu [12]. http://www.acm.org [13]. http://www.researchindex.com
[14]. http://www.cis.ohio-state.edu
PROCITAJ
/ PREUZMI I DRUGE SEMINARSKE RADOVE IZ OBLASTI:
|
|
preuzmi
seminarski rad u wordu » » »
Besplatni Seminarski Radovi
SEMINARSKI RAD
|