Chapter 7

Download Report

Transcript Chapter 7

Poglavlje 7 Multimedijalno umrežavanje

Computer Networking: A Top Down Approach Featuring the

Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. 7: Multimedijalno umrežavanje 7 - 1/121

Multimedija, Quality of Service: Šta je to?

Multimedijalne aplikacije:

mrežni audio i video (“kontinualni mediji”)

QoS

mreža obezbeđuje aplikaciji

aplikacije nivo performansi potreban za funkcionisanje

7: Multimedijalno umrežavanje 7 - 2/121

Poglavlje 7: Ciljevi Principi

 Klasifikacija multimedijalnih aplikacija    Identifikacija mrežnih servisa koji su potrebni aplikaciji Odabrati najbolji od best effort servisa Mehanizmi za obezbeđivanje QoS

Protokoli i arhitekture

  Specifični protokoli za servis najboljeg pokušaja Arhitekture za QoS 7: Multimedijalno umrežavanje 7 - 3/121

Poglavlje 7: sadržaj

    7.1 Multimedijalne mrežne aplikacije 7.2 Streaming uskladištene audio i video aplikacije 7.3 Multimedija u realnom vremenu: Proučavanje telefoniranja preko Internet-a 7.4 Protokoli za interaktivne aplikacije koje rade u realnom vremenu  RTP,RTCP,SIP      7.5 Distribuirane multimedijalne aplikacije: distribuirane mreže bazirane na sadržaju 7.6 Iznad najboljeg pokušaja 7.7 Mehanizmi raspoređivanja i vođenja politike 7.8 Integrisani servisi i diferencirani servisi 7.9 RSVP 7: Multimedijalno umrežavanje 7 - 4/121

MM aplikacije umrežavanja Klase MM aplikacija:

1) Streaming uskladištenog audio i video sadržaja 2) Streaming audio i video signala-zapisa "uživo" 3) Interaktivni audio i video u realnom vremenu Jitter je promena kašnjenja paketa unutar istog toka paketa (packet stream)

Osnovne karakteristike:

 Tipično

osetljivost na kašnjenje

 end-to-end kašnjenje  jitter kašnjenje  Tolerancija gubitaka: koji se ne pojavljuju često prouzrokovani minornim greškama-kvarovima Ove karakteristike se razlikuju od "elastičnih" Web aplikacija, e mail, FTP i Telnet, koje su netolerantne na gubitke ali tolerantne na kašnjenje gubici 7: Multimedijalno umrežavanje 7 - 5/121

Streaming uskladištenih multimedijanih aplikacija Streaming:

 medijalna aplikacija uskladištena na izvoru   transmitovana do klijenta streaming: klijentovo preslušavanje ili gledanje - playout počinje pre nego što svi podaci stignu - vremenska ograničenja za podatke koji još uvek treba da se prenesu nisu toliko stroga kao kod aplikacija "uživo", interaktivnih aplikacija kao što su telefoniranje preko Interneta i video konferensing.

7: Multimedijalno umrežavanje 7 - 6/121

Streaming uskladištene multimedijalne aplikacije: Šta je to ?

1. video recorded 2. video sent

network delay

3. video received, played out at client vreme

streaming:

deo videa u ovom trenutku, klijent izvodi (play out) rani-početni deo videa, dok server još uvek šalje preostali 7: Multimedijalno umrežavanje 7 - 7/121

Streaming uskladištene multimedijalne aplikacije: interaktivnost



Funkcionalnost kao-kod-VCR-a:

klijent može da pauzira, premota video zapis itd.

 10 sec početno kašnjenje OK   1-2 sec dok komanda ne počne da se izvršava OK RTSP je često korišćen 7: Multimedijalno umrežavanje 7 - 8/121

Streaming multimedijalnih aplikacija "uživo" Primeri:

 Internet radio talk show  Uživo sportski događaji

Streaming

 playback bafer  playback može da se uspori nekoliko desetina sekundi nakon transmisije  postoje vremenska ograničenja još uvek

Interaktivnost

  nemuguće brzo premotavanje premotavanje pa pauza, to je moguće 7: Multimedijalno umrežavanje 7 - 9/121

Interaktivnost, Multimedija u realnom vremenu

  

aplikacije:

IP telefoniranje, video konferencija, distribuirani interaktivni svet

zahtevi end-end kašnjenja:

  za glas, kašnjenja manja od 150 msec slušalac ne primećuje kašnjenja između 150 msec i 400 msec mogu biti prihvatljiva • uključuju aplikacioni-nivo (paketizacija) i mrežna kašnjenja • značajno veća kašnjenja slabe interaktivnost

inicijalizacija sesija

 kako onaj koji poziva oglašava svoju IP adresu, broj porta, algoritme kodiranja?

7: Multimedijalno umrežavanje 7 - 10/121

Multimedija preko današnjeg Internet a TCP/UDP/IP:



nema

?

“servis najboljeg pokušaja”

garancija da neće biti kašnjenja, gubitaka

?

Ali rekli ste da multimedijalne aplikacije zahtevaju da QoS i nivo performansi budu efikasni!

?

Današnje multimedijalne aplikacije na Internet-u koriste tehnike aplikacionog nivoa da bi smanjile (što je moguće više) uticaje kašnjenja i gubitaka 7: Multimedijalno umrežavanje 7 - 11/121

Kako treba razvijati Internet da bolje podržava multimediju?

Filozofija integrisanih servisa:  Fundamentalne promene na Internet-u tako da aplikacije mogu da rezervišu end-to-end širinu opsega  Zahteva novi, kompleksan softver na hostovima i ruterima Nemešanje   nema promena kao gore ISP povećavaju širinu opsega kako zahtevi rastu   mreže sa distribucijom sadržaja repliciraju uskladišten sadržaj na krajeve Internet-a (Web strane, MP3, video) višestruko upućivanje na overlay mrežama na aplikacionom sloju  sportski događaji Filozofija različitih servisa:  Male promene Internet infrastrukture tako da se obezbeđuje prva i druga klasa servisa 7: Multimedijalno umrežavanje 7 - 12/121

Nekoliko reči o audio kompresiji

    pre prenosa preko računarskih mreža signal treba biti digitalizovan i komprimovan Analogni signal (glas, muzika) je semplovan konstantnom brzinom   telefon: 8,000 samples/sec CD muzika: 44,100 samples/sec Svaki odbirak je kvantizovan, tj. zaokružen  npr. 2 8 =256 mogućih kvantizacionih veličina Svaka kvantizaciona veličina je predstavljena bit-ovima  8 bit-ova za 256 vrednosti     PCM impulsno kodna modulacija primer: 8,000 samples/sec, 8 bitova --> 64,000 bps Prijemnik vrši konverziju nazad u analogni signal:  postoji smanjenje kvaliteta CD - 44100 samples/sec, 16 bits per sample Primeri brzina  CD stereo: 1.411 Mbps   tehnike kompresije MPEG 1 sloj 3 - MP3: 96, 128, 160 kbps. Kada se datoteka MP3 razbije na delove, svaki deo još uvek može da se reprodukuje.

7: Multimedijalno umrežavanje 7 - 13/121

Nekoliko reči o video kompresiji

    Video je niz slika prikazanih konstantnom brzinom  npr. 24 ili 30 slika/sec Digitalna slika je niz piksela Svaki piksel je predstavljen bit-ovima koji definišu osvetljenje i boju Redundantnost   prostorna vremenska

Primeri:

   MPEG 1 (CD-ROM) 1.5 Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (za objektno orijentisanu video kompresiju, često korišćen na Internet-u, < 1 Mbps)

Istraživanje:

 Uslojeni (skalabilni) video  prilagođava slojeve na iskoristljivu širinu opsega 7: Multimedijalno umrežavanje 7 - 14/121

Poglavlje 7: sadržaj

Streaming uskladištene multimedijalne aplikacije

RealTimeProtocol, RTStreamingP Tehnike streaming-a aplikacionog nivoa za pravljenje najboljeg rešenja servisa najboljeg pokušaja:  bafering na klijent strani   korišćenje UDP-a u odnosu na TCP višestruka kodiranja multimedije Media Player    dekompresija uklanja jitter korekcija greške 7: Multimedijalno umrežavanje 7 - 16/121

Multimedija na Iternet-u: najprostiji pristup

   audio ili video uskladišten u fajl pretraživač uspostavlja TCP konekciju sa Web serverom i zahteva audio/video fajl sa HTTP zahtev-porukom fajl transferovan kao HTTP objekat   primljen u potpunosti na klijent strani onda prosleđen plejeru

audio, video nisu stream-ovani:

 ne postoji, “pipelining,” duga kašnjenja, dok ne bude playout!

7: Multimedijalno umrežavanje 7 - 17/121

Multimedija na Iternet-u: streaming pristup

    pretraživač dobija (GET)

metafile

(URL ili tip kodiranja) pretraživač startuje player, prosleđujući mu metafile player kontaktira server server

stream-uje

audio/video ka player-u 7: Multimedijalno umrežavanje 7 - 18/121

Streaming sa streaming servera

  Ova arhitektura dozvoljava protokole koji nisu HTTP između servera i medija player-a Koristi UDP radije nego TCP 7: Multimedijalno umrežavanje 7 - 19/121

Streaming multimedijalne aplikacije: bafering na klijent strani constant bit rate video transmission

variable network delay

client video reception constant bit rate video playout at client client playout delay  Bafering na klijent strani, playout kašnjenje kompenzuje dodatno kašnjenje na mreži, jitter kašnjenje time 7: Multimedijalno umrežavanje 7 - 20/121

Streaming multimedijalne aplikacije: bafering na klijent strani variable fill rate, x(t) constant drain rate, d buffered video  Bafer na klijent strani se puni brzinom x(t) i prazni brzinom d 7: Multimedijalno umrežavanje 7 - 21/121

Streaming multimedijalne aplikacije: UDP ili TCP?

UDP

  server šalje brzinom koja odgovara klijentu (ne obazire se na mrežna zagušenja !)  brzina slanja = brzina kodovanja = konstantna brzina  zatim, brzina punjenja = konstantna brzina - paketni gubici kratko playout kašnjenje (2-5 sekundi) da bi kompenzovao mrežno jitter kašnjenje  oporavak od greške

TCP

    slanje je sa maksimalno mogućom brzinom kod TCP-a brzina punjenja se menja zbog TCP kontrole zagušenja, retransmisije izgubljenih paketa veće playout kašnjenje: "glatka" TCP brzina isporuke HTTP/TCP prolaze lakše kroz firewalls 7: Multimedijalno umrežavanje 7 - 22/121

Streaming multimedijalne aplikacije: klijentova brzina (e)

1.5 Mbps encoding 28.8 Kbps encoding Q: kako rukovati različitim sposobnostima klijentove brzine prijema?

 28.8 Kbps dialup  100Mbps Ethernet A: server skladišti, transmituje više kopija videa, kodiranih različitim brzinama 7: Multimedijalno umrežavanje 7 - 23/121

Korisnička kontrola streaminga media: Real Time Streaming Protocol - RTSP

HTTP  Nije mu cilj multimedijalni sadržaj  Nema komande za brzo premotavanje, repozicioniranje, itd.

RTSP: RFC 2326  Klijent-server protokol aplikacionog sloja.

 Za korisnika da bi kontrolisao display: rewind, fast forward, pause, resume, repositioning itd. … Šta ne radi:  ne definiše kompresione šeme za audio i video    ne definiše kako je audio/video enkapsuliran za streaming preko mreže ne određuje kako se streamed media transportuje; može biti transportovan preko UDP-a ili TCP-a ne specificira kako media player baferuje audio/video 7: Multimedijalno umrežavanje 7 - 24/121

RTSP: out of band kontrola

FTP koristi “out-of-band” kontrolni kanal:  Fajl je prenešen preko jedne TCP konekcije.

  Kontrolne informacije (promena direktorijuma, brisanje fajla, promena imena fajla, itd.) se šalju preko odvojene TCP konekcije.

“out-of-band” i “in-band” kanali koriste različite brojeve portova RTSP poruke su takođe poslate out-of-band:  RTSP kontrolne poruke koriste različite brojeve portova u odnosu na media stream: out of-band.

  Port 554 media stream se posmatra “in band”.

7: Multimedijalno umrežavanje 7 - 25/121

RTSP Primer Scenario:

   metafile za komunikaciju ka web browser-u browser startuje player player postavlja RTSP control konekciju, data konekciju ka streaming server-u 7: Multimedijalno umrežavanje 7 - 26/121

Metafile primer

Twister 7: Multimedijalno umrežavanje 7 - 27/121

Kako radi RTSP

7: Multimedijalno umrežavanje 7 - 28/121

RTSP primer razmene

C - client, S - sender C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0 .

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 .

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK 7: Multimedijalno umrežavanje 7 - 29/121

Poglavlje 7: sadržaj

Interaktivne aplikacije koje rade u realnom vremenu

   PC-2-PC telefoniranje  instant messaging servisi obezbeđuju ovo PC-2-telefon  Dialpad  Net2phone video konferensing koristeći Web kamere 7: Multimedijalno umrežavanje 7 - 31/121

Interaktivne multimedijalne aplikacije: telefoniranje preko Internet-a Predstavljanje telefoniranja preko Internet-a kroz primer

 govornikov glas-audio: naizmenično se smenjuje priča i tišina.

 64 kbps za vreme talkspurt  paketi su generisani samo za vreme priče-talk spurts  20 msec chunks na 8 Kbytes/sec: 160 bytes podataka   heder aplikacionog sloja dodat svakom komadu-chunk.

Chunk+header su enkapsulirani u UDP segment.

 aplikacija šalje UDP segment na soket svakih 20 msec za vreme talkspurt.

7: Multimedijalno umrežavanje 7 - 32/121

Internet telefoniranje: gubici i kašnjenje paketa

  

mrežni gubici:

IP datagram izgubljen zbog zagušenja mreže (prepunjen bafer rutera)

gubici usled kašnjenja:

IP datagram stiže suviše kasno za playout kod primaoca   kašnjenja: procesiranje, rad sa redovima u mreži; kašnjenja end-system-a (pošiljalac i primalac) tipično maksimalno dozvoljeno kašnjenje: 400 ms tolerancija gubitaka: zavisno od kodiranja glasa, prikrivanje gubitaka, brzina gubitaka paketa između 1% i 20% može da se toleriše 7: Multimedijalno umrežavanje 7 - 33/121

Kašnjenje usled jitter-a

constant bit rate transmission

variable network delay (jitter)

client reception constant bit rate playout at client client playout delay time   Posmatramo end-to-end kašnjenja dva susedna paketa: razlika može biti veća od 20 msec izbegavanje jitter-a: sequence numbers, timestamps, playout delay.

7: Multimedijalno umrežavanje 7 - 34/121

Internet telefoniranje: fiksno playout kašnjenje

  Primalac pokušava da izvede-playout svakog chunk-a tačno q msecs nakon generisanja chunk-a.

 chunk ima vremensku markicu t: play out chunk je u t+q .

 chunk stiže nakon t+q: podaci stižu isuviše kasno za playout, podaci su “izgubljeni” Tradeoff za q:   veliko q: manji gubici paketa malo q: bolja interaktivnost 7: Multimedijalno umrežavanje 7 - 35/121

Fiksno playout kašnjenje

• Sender generates packets every 20 msec during talk spurt.

• First packet received at time r • First playout schedule: begins at p • Second playout schedule: begins at p’ packets

packets generated packets received

loss r p p'

playout schedule p' - r playout schedule p - r

time 7: Multimedijalno umrežavanje 7 - 36/121

Adaptivno playout kašnjenje, I

  Goal: minimize playout delay, keeping late loss rate low Approach: adaptive playout delay adjustment:    Estimate network delay, adjust playout delay at beginning of each talk spurt. Silent periods compressed and elongated.

Chunks still played out every 20 msec during talk spurt.

t i d i   timestamp r i  the time packet i is received by receiver r p i  i  t i the time  packet network i is delay played at receiver for ith p acket estimate of of the ith average packet network delay after receiving ith packet Dynamic estimate of average delay at receiver:

d i

 ( 1 

)

d i

 1 

(

r i

 where u is a fixed constant (e.g., u = .01).

t i

) 7: Multimedijalno umrežavanje 7 - 37/121

Adaptivno playout kašnjenje, II

Also useful to estimate the average deviation of the delay, v

v i

 ( 1 

)

v i

 1 

r i



t i



d i

| The estimates d

and v

are calculated for every received packet, although they are only used at the beginning of a talk spurt.

For first packet in talk spurt, playout time is:

p i



t i



d i



Kv i

where K is a positive constant.

Remaining packets in talkspurt are played out periodically 7: Multimedijalno umrežavanje 7 - 38/121

Adaptivno playout kašnjenje, III Q:

How does receiver determine whether packet is first in a talkspurt?

  If no loss, receiver looks at successive timestamps.

 difference of successive stamps > 20 msec -->talk spurt begins .

With loss possible, receiver must look at both time stamps and sequence numbers.

 difference of successive stamps > 20 msec and numbers without gaps --> talk spurt begins.

sequence 7: Multimedijalno umrežavanje 7 - 39/121

Oporavak od gubitaka paketa (1) forward error correction (FEC): šema

 za svaku grupu od n chunks kreirati redundant chunk koristeći exclusive OR nad n originalnih chunks   poslati n+1 chunks, povećavajući širinu opsega za faktor 1/n.

može se rekonstrurati original od n chunks ako postoji najviše jedan izgubljeni chunk od n+1 chunks   Playout kašnjenje treba da bude fiksirano na vreme za prijem svih n+1 paketa Tradeoff:    veće n, manje trošenje širine opsega veće n, veće playout kašnjenje veće n, veća verovatnoća da će dva ili više chunks biti izgubljena 7: Multimedijalno umrežavanje 7 - 40/121

Oporavak od gubitaka paketa (2)

2nd FEC scheme • “piggyback lower quality stream” • send lower resolution audio stream as the redundant information • for example, nominal stream PCM at 64 kbps and redundant stream GSM at 13 kbps.

• Whenever there is non-consecutive loss, the receiver can conceal the loss. • Can also append (n-1)st and (n-2)nd low-bit rate chunk 7: Multimedijalno umrežavanje 7 - 41/121

Oporavak od gubitaka paketa (3)

Preklapanje  chunks se dele na manje jedinice   npr. 4 x 5 msec jedinica po chunk-u Paket sadrži male jedinice od različitih chunks    ako je paket izgubljen, još uvek sadrži dovoljno informacija za svaki chunk nema redundancy overhead ali utiče na povećanje playout kašnjenja 7: Multimedijalno umrežavanje 7 - 42/121

Zaključak:

Internet multimedija

 koristiti

UDP

da bi se izbegla TCP congestion control (kašnjenja) za vremenski-osetljiv saobraćaj    na klijent strani koristiti

adaptive playout delay

: za kompenzaciju kašnjenja na server strani

podesiti stream bandwidth

na iskoristljivu širinu opsega putanje od klijenta do servera  izabrati između pre-encoded stream rates  dynamic server encoding rate oporavak od grešaka (na vrhu UDP-a)   FEC, preklapanje retransmisija 7: Multimedijalno umrežavanje 7 - 43/121

Poglavlje 7: sadržaj

Real-Time Protocol (RTP)

   RTP određuje strukturu paketa za pakete koji nose audio i video podatke RFC 1889.

RTP paket omogućava    payload type identifikaciju packet sequence numbering timestamping    RTP radi na krajevima sistema.

RTP paketi su enkapsulirani u UDP segmente Interoperabilnost: ako dve Internet phone aplikacije startuju RTP, onda one mogu biti sposobne da rade zajedno 7: Multimedijalno umrežavanje 7 - 45/121

RTP radi na vrhu UDP-a

RTP biblioteke obezbeđuju interfejs transportnog-sloja što proširuje UDP: • broj porta, IP adrese • payload type identifikacija • packet sequence numbering • time-stamping 7: Multimedijalno umrežavanje 7 - 46/121

RTP primer

   Posmatramo slanje 64 kbps PCM-kodirani glas preko RTP-a. Aplikacija sakuplja kodirane podatke u chunks, npr. svakih 20 msec = 160 bytes u chunk-u. Audio chunk sa RTP header-om formira RTP paket, koji je enkapsuliran u UDP segment.   RTP header pokazuje tip audio kodiranja u svakom paketu  sender može da menja kodiranje za vreme konferencije. RTP header takođe sadrži sequence numbers i timestamps.

7: Multimedijalno umrežavanje 7 - 47/121

RTP i QoS

  RTP ne daje bilo kakav mehanizam za obezbeđivanje isporuke podataka za određeno vreme ili druge garancije za kvalitet servisa. RTP enkapsulacija se jedino vidi na krajevima sistema: ona se ne vidi na ruterima između.  Ruteri koji obezbeđuju best-effort servis ne čine bilo kakav specijalan napor da bi obezbedili da RTP paketi stignu na odredište za određeno vreme.

7: Multimedijalno umrežavanje 7 - 48/121

RTP Header

Payload Type (7 bits): pokazuje tip kodiranja koji se tekuće koristi.

Ako pošiljalac menja kodiranje usred konferencije, on informiše primaoca preko ovog payload type polja. •Payload type 0: PCM mu-law, 64 kbps •Payload type 3, GSM, 13 kbps •Payload type 7, LPC, 2.4 kbps •Payload type 26, Motion JPEG •Payload type 31. H.261

•Payload type 33, MPEG2 video Sequence Number (16 bits): se povećava za jedan za svaki poslati RTP paket i može da se koristi za detekciju gubitaka paketa i za restauriranje niza paketa.

7: Multimedijalno umrežavanje 7 - 49/121

RTP Header (2)

 Timestamp polje (32 bits dugo). Prikazuje trenutak sempliranja prvog bajta u RTP paketu podataka.  Za audio, timestamp clock se tipično povećava za jedan za svaki period odabiranja (npr. svakih 125 mikrosecs za 8 KHz sampling clock)  ako aplikacija generiše chunks od 160 kodiranih odbiraka samples, onda se timestamp povećava za 160 za svaki RTP paket kada je izvor aktivan. Timestamp clock nastavlja da se povećava konstantnom brzinom čak i kada je izvor neaktivan.

 SSRC polje (32 bits dugo). Synchronization source identifier identifikuje izvor RTP stream-a. Svaki stream u RTP sesiji treba da ima različit SSRC. 7: Multimedijalno umrežavanje 7 - 50/121

RTSP/RTP programski zadatak

  Napraviti server koji enkapsulira uskladištene video frejmove u RTP pakete   grab-ovati video frejm, dodati RTP headers, kreirati UDP segments, poslati segmente na UDP socket uključiti seq numbers i time stamps  obezbeđen je client RTP-a Takođe napisati klijent stranu RTSP-a   play i pause komande obezbeđen je server RTSP-a 7: Multimedijalno umrežavanje 7 - 51/121

Real-Time Control Protocol (RTCP)

   Radi u spoju sa RTP-om. Svaki učesnik u RTP sesiji periodično transmiruje RTCP kontrolne pakete svim ostalim učesnicima.

Svaki RTCP paket sadrži sender i/ili receiver izveštaje-statistiku   Statistika uključuje broj poslatih paketa, broj izgubljenih paketa, međudolazni jitter, itd.

Povratna sprega može da se koristi za kontrolu performansi  Pošiljalac može da modifikuje svoje transmisije koristeći povratnu spregu-feedback 7: Multimedijalno umrežavanje 7 - 52/121

RTCP

- Za jednu RTP sesiju postoji tipično jedna multicast adresa; svi RTP i RTCP paketi koji pripadaju toj sesiji koriste tu multicast adresu. - RTP i RTCP paketi se razlikuju međusobno po različitim brojevima portova (+1). - Da bi ograničili saobraćaj, svaki učesnik smanjuje svoj RTCP saobraćaj kako se broj učesnika na konferenciji povećava.

7: Multimedijalno umrežavanje 7 - 53/121

RTCP paketi Receiver report paketi:

 deo izgubljenih paketa, poslednji sequence number, srednja vrednost međudolaznih jitter-a.

Sender report paketi:

 SSRC od RTP stream-a, tekuće vreme, broj poslatih paketa i broj poslatih bajtova.

Source description paketi:

 e-mail adresu pošiljaoca, njegovo ime, SSRC pridruženog RTP stream-a.  Obezbeđuje mapiranje između SSRC i user/host imena.

7: Multimedijalno umrežavanje 7 - 54/121

Sinhronizacija stream-ova

   RTCP može da sinhronizuje različite media streams unutar RTP sesije. Razmotrimo videoconferencing aplikaciju za koju svaki sender generiše jedan RTP stream za video i jedan za audio. Timestamps u RTP paketu se spajaju sa video i audio sampling clocks   Svaki RTCP sender-report paket sadrži (za najskorije generisani paket u pridruženom RTP stream-u):  timestamp od RTP paketa  wall-clock time kada je paket bio kreiran. Primalac može da koristi ovo za sinhronizaciju playout-a audia i videa. 7: Multimedijalno umrežavanje 7 - 55/121

RTCP Bandwidth Scaling

 RTCP pokušava da ograniči svoj saobraćaj na 5% širine opsega sesije.

Primer   Pretpostavimo da jedan sender šalje video brzinom od 2 Mbps. RTCP pokušava da ograniči svoj saobraćaj na 100 Kbps. RTCP daje 75% od ove brzine primaocu; preostalih 25% pošiljaocu    75 kbps se podjednako deli između primaoca:  Sa R primaoca, svaki primalac dobije da pošalje RTCP saobraćaj na 75/R kbps. Pošiljalac dobija za slanje RTCP traffic na 25 kbps.

Učesnik određuje RTCP packet transmission period proračunavajući srednju vrednost veličine RTCP paketa (kroz celu sesiju) i deleći je sa alociranom brzinom.

7: Multimedijalno umrežavanje 7 - 56/121

Session Initiation Protocol - SIP

  Protokol za inicijalizaciju sesije IETF

SIP dugoročna vizija

 Zamislimo da svi telefonski pozivi i pozivi video konferencija idu preko Internet-a   Ljudi se identifikuju po imenima ili e-mail adresama radije nego po telefonskim brojevima.

Možete naći pozivaoca bez obzira gde je ili koji IP uređaj pozivalac trenutno koristi.

7: Multimedijalno umrežavanje 7 - 57/121

SIP servisi

 Postavljanje poziva    Obezbeđuje mehanizme za pozivaoca da upozna pozvanog da želi da uspostavi poziv Obezbeđuje mehanizme da se pozivalac i pozvani mogu složiti oko tipa medija i kodiranja.

Obezbeđuje mehanizme za završetak poziva   Obezbeđuje tekuću IP adresu pozivaoca.

 Mapira mnemonički identifikator na tekuću IP adresu Upravljanje pozivom   Dodaje nove media streams za vreme poziva Menja kodiranje za vreme poziva   Poziva druge Transferuje i zadržava pozive 7: Multimedijalno umrežavanje 7 - 58/121

Alice

Postavljanje poziva ka poznatoj IP adresi

Bob 167.180.112.24

INVITE [email protected]

m=audio 38060 RT 4.210.89

12.24

P/AVP 0 193.64.210.89

port 5060 Bob's terminal rings 200 OK c=IN IP4 193.6

4.210.89

m=audio 48753 RTP/AVP 3 port 5060 • Alisin SIP invite message indicira njen broj porta i IP adresu. Indicira kodiranje koje Alisa preferira da primi (PCM ulaw) • Bobova 200 OK poruka indicira njegov broj porta, IP adresu i preferirano kodiranje (GSM) ACK port 5060 port 38060 m Law audio • SIP poruke mogu da budu poslate preko TCP ili UDP-a; ovde preko RTP/UDP.

GSM port 48753 •Default SIP port number je 5060.

time time 7: Multimedijalno umrežavanje 7 - 59/121

Postavljanje poziva

 Codec pregovaranje:  Pretpostavimo da Bob nema PCM ulaw encoder.   Bob će odgovoriti 606 Not Acceptable Reply i listom encodera koje može koristiti. Alisa može onda poslati novu INVITE poruku, oglašavajući odgovarajući enkoder.

  Odbacivanje poziva  Bob može odbaciti poziv sa odgovorom “busy,” “gone,” “payment required,” “forbidden”.

Media može da se pošalje preko RTP ili nekog drugog protokola 7: Multimedijalno umrežavanje 7 - 60/121

Primer SIP poruke

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 167.180.112.24

From: sip:[email protected]

To: sip:[email protected] Call-ID: [email protected]

Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24

m=audio 38060 RTP/AVP 0 Napomena:    HTTP message sintaksa sdp = session description protocol Call-ID je jedinstven za svaki poziv • Ovde neznamo Bobovu adresu. Intermediate SIP servers će biti neophodni • Alisa šalje i prima SIP poruke koristeći SIP default port number 5060. • Alisa specificira preko Via: header kojim SIP klijent šalje i prima SIP poruke preko UDP 7: Multimedijalno umrežavanje 7 - 61/121

Prevođenje imena i lokacija korisnika

  Pozivalac želi da pozove pozvanog, ali ima samo njegovo ime ili e-mail address.

Treba da dobije IP adresu tekućeg hosta pozvanog:    korisnik putuje DHCP protokol korisnik ima različite IP uređaje (PC, PDA)  Resultat može biti baziran na različitim stvarima: vreme dana i noći, nema uznemiravanja ...

Servisi obezbeđeni od SIP servera:

  SIP registrar server SIP proxy server 7: Multimedijalno umrežavanje 7 - 62/121

SIP Registrar

 Kada Bob startuje SIP client, klijent šalje SIP REGISTER poruku ka Bobovom registrar serveru (slične funkcije kao kod Instant Messaging)

Register Message:

Via: SIP/2.0/UDP 193.64.210.89 From: sip:[email protected]

To: sip:[email protected]

Expires: 3600 7: Multimedijalno umrežavanje 7 - 63/121

SIP proxy

    Alisa šalje invite message svom proxy serveru  sadrži adresu sip:[email protected]

Proxy je sposoban za rutiranje SIP messages ka pozvanom  moguđe kroz više proksija.

Pozvani šalje odziv nazad kroz isti skup proksija.

Proxy vraća SIP response message Alisi  sadrži Bobovu IP adresu  Napomena: proxy je analogan lokalnom DNS serveru 7: Multimedijalno umrežavanje 7 - 64/121

Primer

Caller [email protected] with places a call to [email protected]

SIP registrar upenn.edu

(1) Jim sends INVITE message to umass SIP proxy.

(2) Proxy forwards request to upenn registrar server. (3) upenn server returns redirect response, indicating that it should try [email protected]

SIP proxy umass.edu

1 8

SIP client 217.123.56.89

2 3 4 7 9

SIP registrar eurecom.fr

6 5

SIP client 197.87.54.21

(4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrar forwards INVITE to 197.87.54.21, which is running keith’s SIP client. (6-8) SIP response sent back (9) media sent directly between clients. Note: nije prikazano i SIP ack message.

7: Multimedijalno umrežavanje 7 - 65/121

Poređenje sa H.323

   H.323 je drugi signaling protokol za real-time interaktivnost H.323 je kompletno, vertikalno integrisan skup protokola za multimedijalni konferensing: signaling, registration, admission control, transport i codecs.

SIP je jedno komponentni. Radi sa RTP-om. Može da se kombinuje sa drugim protokolima i servisima   H.323 potiče iz ITU (telefonije).

SIP dolazi iz IETF-a: pozajmljujući mnogo od HTTP a. SIP ima Web-primese, dok H.323 ima telefon-primese. 7: Multimedijalno umrežavanje 7 - 66/121

Poglavlje 7: sadržaj

Mreže sa distribuiranim sadržajem

Content distribution networks (CDNs)

Replikacija sadržaja

  Izazov je stream velikih fajlova (npr. video) sa jednog izvorišnog servera u realnom vremenu Rešenje: pravljenje replika sadržaja na stotine servera kroz Internet  sadržaj download-ovan sa CDN servera pre roka   smeštanje sadržaja "blizu" korisnika izbegavajući pogoršanje (gubici, kašnjenje) sadržaja koji se šalje duž dugih putanja CDN server je tipično na ivici/pristupnoj mreži origin server in North America CDN distribution node CDN server in S. America CDN server in Europe CDN server in Asia 7: Multimedijalno umrežavanje 7 - 68/121

Mreže sa distribuiranim sadržajem (CDNs) Replike sadržaja

  CDN (npr. Akamai) korisnik je provajder sadržaja (npr. CNN) CDN pravi replike korisnikovih sadržaja na CDN serverima. Kada provajder ažurira sadržaj, CDN ažurira servere origin server in North America CDN distribution node CDN server in S. America CDN server in Europe CDN server in Asia 7: Multimedijalno umrežavanje 7 - 69/121

CDN primer

HTTP request for www.foo.com/sports/sports.html

1 Origin server 3 2 DNS query for www.cdn.com

CDNs authoritative DNS server HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif

Nearby CDN server

izvorni server (www.foo.com)

 distribuira HTML  zamenjuje: http://www.foo.com/sports.ruth.gif

sa h ttp://www.cdn.com/www.foo.com/sports/ruth.gif

CDN kompanija (cdn.com)

 distribuira gif fajlove  koristi svoj authoritative (nadležan) DNS server da rutira preusmerene zahteve 7: Multimedijalno umrežavanje 7 - 70/121

Više o CDNs rutiranje zahteva

 CDN kreira“mapu”, koja sadrži rastojanja od lista ISPs i CDN čvorova   kada upit stigne na authoritative DNS server:   server određuje ISP sa koga upit potiče koristi “mapu” za određivanje najboljeg CDN servera CDN čvorovi kreiraju overlay (preklapanje) mreže aplikacionog sloja 7: Multimedijalno umrežavanje 7 - 71/121

Poglavlje 7: sadržaj

Poboljšanje QoS u IP mrežama

Do sada: “nalaženje najboljeg od best effort” U budućnosti: sledeća generacija Interneta sa QoS garancijama  RSVP: signalizira rezervaciju resursa    Differentiated servisi: Integrated Services: differential garancije garancije nepromenljivosti jednostavan model za proučavanje deljenja i zagušenja: 7: Multimedijalno umrežavanje 7 - 73/121

Principi QoS garancija

 Primer: 1Mbps IP telefon i FTP dele 1.5 Mbps link.   FTP-podaci mogu da zaguše ruter prouzrokujući gubitke audio podataka potrebno je dati prioritet audio podacima u odnosu na FTP Princip 1 markiranje paketa potrebno za ruter da bi vodio računa o različitim klasama kao i nova politika rutera na osnovu koje se tretiraju paketi 7: Multimedijalno umrežavanje 7 - 74/121

Principi QoS garancija (2)

  šta ako se aplikacije "loše ponašaju" (audio podaci se šalju većom brzinom od deklarisane)  politika: prisiliti izvor da se pridržava dodeljene širine opsega markiranje i politika na ivici mreže:  slično ATM UNI (User Network Interface)

Princip 2

obezbediti zaštitu (izolaciju) jedne klase od drugih 7: Multimedijalno umrežavanje 7 - 75/121

Principi QoS garancija (3)

 Dodeljivanje fiksne (ne-deljive) širine opsega toku: neefikasno korišćenje širine opsega ako tokovi ne koriste svoja dodeljivanja

Princip 3

Dok je obezbeđena izolacija između protoka, poželjno je koristiti što efikasnije resurse 7: Multimedijalno umrežavanje 7 - 76/121

Principi QoS garancija (4)

 Osnovna činjenica: ne može se podržati saobraćajni zahtevi iznad kapaciteta linka

Princip 4

Dopuštanje poziva: protok deklariše svoje potrebe, mreža može da blokira poziv (npr. signal zauzeća) ako ne može ispuniti zahtevani uslov 7: Multimedijalno umrežavanje 7 - 77/121

QoS principi: zaključak

7: Multimedijalno umrežavanje 7 - 78/121

Poglavlje 7: sadržaj

Mehanizmi raspoređivanja i politike

 

raspoređivanje:

izabrati sledeći paket za slanje linkom

FIFO (first in first out) raspoređivanje:

redosledu stizanja u red  šalje po politika odbacivanja: ako paket stigne u popunjen red: koji paket odbaciti?

• Tail drop: ispustiti dolazeći paket • prioritet: ispustiti/ukloniti na osnovu prioriteta • slučajno: ispustiti/ukloniti slučajno 7: Multimedijalno umrežavanje 7 - 80/121

Politika raspoređivanja: više Raspoređivanje na osnovu prioriteta:

reda sa najvećim prioritetom  prenositi paket iz više klasa, sa različitim prioritetima  klasa može da zavisi od markiranja ili drugih informacija hedera npr. IP izvorište/odredište, brojevi portova ...

7: Multimedijalno umrežavanje 7 - 81/121

Politika raspoređivanja: još više round robin raspoređivanje:

 više klasa  ciklično skeniranje klasa redova, uslužiti jedan iz svake klase redova (ako je iskoristljiv) 7: Multimedijalno umrežavanje 7 - 82/121

Politika raspoređivanja: još uvek više Težinski fair rad sa redovima:

 generalizovani Round Robin  svaka klasa uzima težinsku količinu servisa u svakom ciklusu 7: Multimedijalno umrežavanje 7 - 83/121

Mehanizmi politike Cilj:

ograničiti saobraćaj da ne prelazi deklarisane parametre Tri zajednički-korišćena kriterijuma:   

(Dugoročna) srednja vrednost brzine:

može da se pošalje u jedinici vremena  koliko paketa osnovno pitanje: šta je interval length: 100 paketa u sekundu ili 6000 paketa u minutu imaju istu srednju vrednost!

Vršna vrednost brzine:

npr. 6000 pkts per min. (ppm) srednja vrednost; 1500 ppm vršna vrednost brzine

(Max.) Burst Size:

max. broj paketa poslatih uzastopno (bez uplitanja besposlenosti-idle) 7: Multimedijalno umrežavanje 7 - 84/121

Mehanizmi politike Token Bucket:

ograničava ulaz na određenu veličinu burst-a i srednju vrednost brzine    bucket može da drži b token-a token-i su generisani brzinom r token/sec dok se bafer bucket ne napuni

preko intervala dužine t: broj dopuštenih paketa je manji od ili jednak (r t + b).

7: Multimedijalno umrežavanje 7 - 85/121

Mehanizmi politike (više)

 token bucket, obezbediti garantovanu gornju granicu kašnjenja npr.

QoS garancije

arriving traffic token rate, r bucket size, b WFQ per-flow rate, R 7: Multimedijalno umrežavanje 7 - 86/121

Poglavlje 7: sadržaj

    7.1 Multimedijalne mrežne aplikacije 7.2 Streaming uskladištene audio i video aplikacije 7.3 Multimedija u realnom vremenu: Proučavanje telefoniranja preko Internet-a 7.4 Protokoli za interaktivne aplikacije koje rade u realnom vremenu  RTP,RTCP,SIP      7.5 Distribuirane multimedijalne aplikacije: distribuirane mreže bazirane na sadržaju 7.6 Iznad najboljeg pokušaja 7.7 Mehanizmi raspoređivanja i vođenja politike 7.8 Integrisani servisi i različiti servisi 7.9 RSVP 7: Multimedijalno umrežavanje 7 - 87/121

IETF integrisani servisi

   arhitektura za obezbeđivanje QoS garancija u IP mrežama za individualne aplikacione sesije rezervacija resursa: ruteri održavaju informacije o stanju (kao VC) dodeljenih resursa, QoS zahteva prihvati/odbi zahteve za setup poziva: Pitanje: da li može da novo pristigli tok bude prihvaćen sa garancijom performansi dok se ne naruši QoS garancije načinjene za već prihvaćene tokove?

7: Multimedijalno umrežavanje 7 - 88/121

Integrisani servisi: scenario QoS garancija



Rezervacija resursa

   setap poziva, signaliziranje (RSVP) saobraćaj, QoS deklaracija kontrola prihvatanja po elementu request/ reply  QoS-sensitive scheduling (e.g., WFQ) 7: Multimedijalno umrežavanje 7 - 89/121

Prihvatanje poziva Dolazeća sesija mora da:

   deklariše svoje QoS zahteve 

R-spec:

definiše QoS koji se zahteva okarakteriše saobraćaj koji će biti poslat u mrežu 

T-spec:

definiše karakterisitke saobraćaja signaling protokol: potreban za nošenje R-spec i T spec ruterima (gde se rezervacija zahteva) 

RSVP

7: Multimedijalno umrežavanje 7 - 90/121

Integrisani servisi QoS: modeli servisa

[rfc2211, rfc 2212]

Garantovani servisi:

  najgori slučaj dolaznog saobraćaja: leaky-bucket policed source jednostavno (matematički dokazivo)

bound

kašnjenje [Parekh 1992, Cruz 1988]

Kontrolisani servisi opterećenja:

 "kvalitet servisa koji približno aproksimira QoS koji će isti tok da ima od neopterećenog mrežnog elementa" arriving traffic token rate, r bucket size, b WFQ per-flow rate, R 7: Multimedijalno umrežavanje 7 - 91/121

IETF diferencirani servisi

Povezano sa integrisanim servisima: 

Skalabilnost:

signaling, održavanje po-toku stanja rutera teško je kada je veliki broj tokova 

Fleksibilni modeli servisa:

Intserv ima samo dve klase. Takođe se žele “kvalitetne” klase servisa  relativno različiti servisi: Platinum, Gold, Silver Diffserv pristup:  proste funkcije u jezgru mreže, relativno složene funkcije na ivici rutera (ili hostova)  Obezbeđuju se funkcionalne komponente za građenje clasa servisa 7: Multimedijalno umrežavanje 7 - 92/121

Diffserv arhitektura

Ruter na ivici:  upravljanje  označavanje paketa kao profile i out-profile in-

Core router:

   za klasu upravljanje saobraćajem buferovanje i raspoređivanje bazirani na markiranju na ivici davanje prednosti in-profile  Obezbediti prosleđivanje

b r

7: Multimedijalno umrežavanje 7 - 93/121

Edge-router markiranje paketa

  profile: pred-pregovaranje o brzini A, bucket veličina B markirani paket na ivici baziran je per-flow profajlu Rate A B User packets Moguće korišćenje markiranja:   na klasi bazirano markiranje: paketi različitih klasa markirani različito intra-class markiranje: podešen deo toka-protoka markiranog različito u odnosu na nepodešen 7: Multimedijalno umrežavanje 7 - 94/121

Klasifikacija i uslovljavanje

   Paket je markiran u Type of Service (TOS) u IPv4, i Traffic Class u IPv6 6 bits se koriste za Differentiated Service Code Point (DSCP) i određuju PHB koji će paket da primi 2 bits su tekuće neiskorišćena 7: Multimedijalno umrežavanje 7 - 95/121

Klasifikacija i uslovljavanje

mogu biti poželjna za ograničavanje brzine saobraćaja nekih klasa:  korisnik deklariše traffic profile (npr. brzinu, veličinu burst-a)  merač saobraćaja, oblikovan ako nije podešen 7: Multimedijalno umrežavanje 7 - 96/121

Prosleđivanje (PHB)

   PerHopBehavior rezultat u različito posmatranom merenom prosleđivanju ponašanja performansi PHB ne specificira koje mehanizme da koristi da bi omogućio željeno PHB ponašanje performansi Primeri:   Klasa A uzima x% od širine opsega odlaznog linka kroz vremenske intervale specifične dužine Paketi klase A prvo odlaze pre paketa iz klase B 7: Multimedijalno umrežavanje 7 - 97/121

Prosleđivanje (PHB) PHBs se razvijaju:



Očekivano prosleđivanje:

paketa jedne klase jednaka je ili veća od specificirane brzine brzina otpremanja  logical link with a minimum guaranteed rate 

Zajamčeno prosleđivanje:

 4 klase saobraćaja svaka garantuje minimalnu količinu širine opsega 7: Multimedijalno umrežavanje 7 - 98/121

Poglavlje 7: sadržaj

Skaliranje na Internet-u

bez uspostavljanja konekcije (bez nformacija o stanju) prosleđivanje duž IP rutera

+

servis najboljeg pokušaja

=

bez mrežnih signaling protokola u početnom IP dizajnu    Novi zahtevi: end (kraj sistema, ruteri) za QoS za multimedijalne aplikacije rezervacija resursa duž putanje end-to RSVP:  Resource Reservation Protocol [RFC 2205] “ … dozvoljava korisnicima da komuniciraju zahtevima na mreži na robustan i efikasan način ” npr. signaling-om !

raniji Internet Signaling protokol: ST-II [RFC 1819] 7: Multimedijalno umrežavanje 7 - 100/121

RSVP ciljevi dizajna

prilagoditi putanje) heterogene primaoce prilagoditi različite aplikacije resursima (različite širine opsega duž različitim zahtevima za učiniti multicast servise prve klase multicast grupe adaptivnim na članove uticaj postojećeg multicast/unicast rutiranja , adaptacijom na promene postojećih unicast i multicast ruta overhead kontrolnog protokola slučaju) linearno broj primaoca da bi se povećao (u najgorem modularni design za heterogenu raspoloživu tehnologiju 7: Multimedijalno umrežavanje 7 - 101/121

RSVP: ne radi …

   ne specificira kako se resursi rezervišu  radije: određuje mehanizam potrebnih komunikacija ne određuje kako će da se uzmu rutirani paketi  to je posao protokola rutiranja  signaling odvojen od rutinga ne radi interakciju sa prosleđivanjem paketa  odvajanje područja kontrole (signaling-a) i podataka (prosleđivanja) 7: Multimedijalno umrežavanje 7 - 102/121

RSVP: pregled rada

    pošiljaoci, primalac se pridružuju multicast grupi   dato izvan RSVP-a nije potrebno da se pošiljaoci pridruže grupi signaling od pošiljaoca-ka-mreži  

path message:

čini prisustvo pošiljaoca poznatim ruterima path teardown: briše stanje putanja pošiljaoca na ruterima signaling od-primaoca-ka-mreži  

reservation message:

ili više) do primaoca rezerviše resurse od pošiljaoca (jednog reservation teardown: uklanja rezervacije primaoca signaling od-mreže-ka-kraju sistema   path error reservation error 7: Multimedijalno umrežavanje 7 - 103/121

Putanja poruka: RSVP

pošiljalac-mreža

signaling

  putanja poruke      sadrži:

adresu:

unicast odredište ili multicast grupu

flowspec-specifikaciju protoka:

širinom opsega specifikaciju zahteva za

filter flag:

ako je pozitivno-yes, zapis identifikuje upstream pošiljaoce (da bi dozvolili filtriranje paketa od strane izvora)

predhodni hop:

upstream ruter/host ID

vreme osvežavanja:

vreme kada ove informacije ističu putanja poruke: komunicira sender informacijama i reverzna putanja-ka-senderu ruting informacijama  kasnije upstream prosleđivanje rezervacija primaoca 7: Multimedijalno umrežavanje 7 - 104/121

RSVP: jednostavna audio konferencija

     H1, H2, H3, H4, H5 i pošiljaoci i primaoci multicast grupa m1 nema filtriranja: paketi od bilo kog pošiljaoca se prosleđuju brzina audio sadržaja: b samo jedno multicast stablo rutiranja je moguće H2 H3 R1 R2 R3 H4 H1 H5 7: Multimedijalno umrežavanje 7 - 105/121

RSVP: građenje stanja putanje

  H1, …, H5 svi šalju path messages preko m1: (address=m1, Tspec=b, filter-spec=no-filter, refresh=100) Pretpostavimo da H1 šalje prvu path message m1: in out L1 L2 L6 H2 H1 L2 L1 R1 m1: in out L5 L6 L7 m1: in out L3 L4 L7 L6 H5 R2 L5 L7 R3 L4 L3 H3 H4 7: Multimedijalno umrežavanje 7 - 106/121

RSVP: građenje stanja putanje

 sledeće, H5 šalje path message, kreirajući više stanja na ruterima m1: in out L1 L6 L1 L2 L6 H2 H1 L2 L1 R1 m1: in out L5 L5 L6 L6 L7 m1: in out L3 L4 L7 L6 H5 R2 L5 L7 R3 L4 L3 H3 H4 7: Multimedijalno umrežavanje 7 - 107/121

RSVP: građenje stanja putanje

 H2, H3, H5 šalju path msgs, kompletirajući tabele stanja putanje m1: in out L1 L2 L6 L1 L2 L6 H2 H1 L2 L1 R1 m1: in out L5 L5 L6 L7 L6 L7 m1: in out L3 L3 L4 L4 L7 L7 L6 H5 R2 L5 L7 R3 L4 L3 H3 H4 7: Multimedijalno umrežavanje 7 - 108/121

Poruke rezervacije:

od-primaoca-ka-mreži

signaling

  sadržaj rezervacione poruke:   

željena širina opsega: tip filtera:

• nema filtra: bilo koji paketi adresirani na multicast grupu mogu da koriste rezervaciju • fiksirani filtar: samo paketi iz određenog skupa pošiljaoca mogu da koriste rezervaciju • dinamički filtar: pošiljaoci čiji paketi mogu biti prosleđeni po linku će se menjati (po izboru primaoca) vremenom.

filter spec

rezervacije upstream toka od primaoca-ka-pošiljaocu, rezervacija resursa, kreiranje dodatnog stanja

povezanog sa primaocem

na ruterima 7: Multimedijalno umrežavanje 7 - 109/121

RSVP: primer 1 - rezervacija

primaoca

H1 želi da primi audio sadržaj od svih ostalih pošiljaoca  H1 poruka rezervacije teče po stablu do izvora   H1 samo rezerviše dovoljno širine opsega za 1 audio stream rezervacija je tipa “no filter” – bilo koji pošiljalac može da koristi rezervisanu širinu opsega H3 H2 H1 L2 L1 R1 L6 H5 R2 L5 L7 R3 L4 L3 H4 7: Multimedijalno umrežavanje 7 - 110/121

RSVP: primer 1 - rezervacija

primaoca

  H1 poruke rezervacije teku po stablu do izvora ruteri, hostovi rezervišu potrebnu širinu opsega b na downstream linkovima prema H1 m1: in out L1 L1

(b)

L2 L2 L6 L6 m1: in out L5 L5 H2 H1 L2 b b L1 R1 L6 b L6 L6

(b)

L7 L7 b R2 L5 b L7 m1: in out L3 L3 R3 L4 L4 b L3 b L4 H5 L7 L7

(b)

H3 H4 7: Multimedijalno umrežavanje 7 - 111/121

RSVP: primer 1 - rezervacija

primaoca

(nastavak)

   sledeće, H2 čini no-filter rezervaciju za širinu opsega b H2 prosleđuje ka R1, R1 prosleđuje ka H1 i R2 (?) R2 ne čini nikakvu akciju, dok je opseg b već rezervisan na L6 m1: in out L1 L1(

) L2 L2

(b)

L6 L6 m1: in out L3 L3 L4 L4 L7 L7 (

) m1: in out L5 L5 L6 L6 (

) L7 L7 H2 H1 b L2 b b b L1 R1 L6 b b R2 L5 b L7 R3 b L3 b L4 H3 H4 H5 7: Multimedijalno umrežavanje 7 - 112/121

RSVP: rezervacija

primaoca

: izdanje

Šta ako ima više pošiljaoca (npr. H3, H4, H5) preko linka (npr. L6)?

 proizvoljno preklapanje-interleaving paketa  L6 ima leaky bucket politiku toka: ako brzina slanja H3+H4+H5 prelazi b, gubitak paketa će se pojaviti m1: in out L1 L1(

) L2 L2

(b)

L6 L6 m1: in out L5 L5 H2 H1 b L2 b b b L1 R1 L6 b L6 L6 (

) L7 L7 b R2 L5 b L7 m1: in out L3 L3 R3 L4 L4 b L3 b L4 H5 L7 L7 (

) H3 H4 7: Multimedijalno umrežavanje 7 - 113/121

RSVP: primer 2

  H1, H4 su jedini pošiljaoci  šalju

path messages

kao ranije, indicirajući rezervaciju  ruteri skladište upstream pošiljaoca za svaki upstream link H2 želi da prima od H4 (samo) H1 L1 R1 L6 R2 L7 R3 L4 H4 7: Multimedijalno umrežavanje 7 - 114/121

RSVP: primer 2

 H1, H4 su jedini pošiljaoci  šalju

path messages

rezervaciju kao ranije, indicirajući filtriranu in out L1, L6 L2(H1-via-H1 ; H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) in out L4, L7 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-R2 ) L7(H4-via-H4 ) H1 L1 R1 R2 L6 L7 in out L6, L7 L6(H4-via-R3 ) L7(H1-via-R1 ) R3 L4 H4 7: Multimedijalno umrežavanje 7 - 115/121

RSVP: primer 2

 primalac H2 šalje reservation message za izvor H4 širine opsega b  prostirući upstream prema H4, rezervišući b in L1, L6 out L6(H1-via-H1 ) L1(H4-via-R2 ) in out L4, L7 L3(H4-via-H4 ; H1-via-R2 ) L4(H1-via-62 ) H1 b R1 L6 b R2 b L7 in L6, L7 out L7(H1-via-R1 ) R3 L4 b H4 7: Multimedijalno umrežavanje 7 - 116/121

RSVP: soft-stanje

   pošiljaoci periodično ponovo pošalju path msgs da bi osvežili (održavali) stanje primaoci periodično ponovo pošalju resv msgs da bi osvežili (održavali) stanje path i resv msgs imaju TTL polje, specificirajući interval osvežavanja in L1, L6 out L6(H1-via-H1 ) L1(H4-via-R2 ) in out L4, L7 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-62 ) H1 b R1 L6 b R2 b L7 in L6, L7 out L7(H1-via-R1 ) R3 L4 b H4 7: Multimedijalno umrežavanje 7 - 117/121

RSVP: soft-stanje

  pretpostavimo da H4 (pošiljalac) odlazi bez izvršavanja teardown-a konačno stanje na ruterima će isteći i nestati!

in L1, L6 out L6(H1-via-H1 ) L1(H4-via-R2 ) in out L4, L7 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-62 ) H1 b R1 L6 b R2 b L7 in L6, L7 out L7(H1-via-R1 ) R3 L4 b gone fishing!

7: Multimedijalno umrežavanje 7 - 118/121

Osvežavanje pri višestrukom korišćenju rezervacije/putanje

   oporavak od ranije izgubljene poruke osvežavanja  očekivano vreme dok se refresh ne primi mora biti duže od timeout intervala! (poželjan je kratak vremenski interval) Rukovanje primaocem/pošiljaocem koje nestaje bez teardown-a  Sender/receiver stanje će isteći i nestati Osvežavanja rezervacija će prouzrokovati da nove rezervacije budu načinjene za primaoca od pošiljaoca koji se priključio od kada su primaoci osvežili poslednji put rezervaciju   Npr. u prethodnom primeru, H1 je jedino primalac, H3 samo pošiljalac. Path/reservation messages completiraju tokove podataka H4 se pridružuje kao pošiljalac, ništa se ne dešava dok H3 ne osveži rezervaciju, prouzrokujući da R3 prosledi rezervaciju na H4, koji dodeljuje širinu opsega 7: Multimedijalno umrežavanje 7 - 119/121

RSVP: napomene

   multicast kao servis “prve klase” rezervacije orijentisane ka primaocu korišćenje soft-stanja 7: Multimedijalno umrežavanje 7 - 120/121

Multimedijalno umrežavanje: Zaključak

   

multimedijalne aplikacije i zahtevi izbor najboljeg od današnjih servisa najboljeg pokušaja mehanizmi raspoređivanja i politike Internet sledeće generacije: Intserv, RSVP, Diffserv

7: Multimedijalno umrežavanje 7 - 121/121