poglavlje 7 multimedi jalno umrežavanje

7: Multimedijalno umrežavanje 7 - 1/121

Poglavlje 7Multimedijalno umrežavanje

Computer Networking: A Top Down Approach

Featuring the Internet, 3rd edition.

Jim Kurose, Keith RossAddison-Wesley, July 2004.


Multimedija, Quality of Service: Šta je to?

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

mreža obezbeđuje aplikaciji nivo performansi potreban za funkcionisanje aplikacije

QoS


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


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


MM aplikacije umrežavanja

Osnovne karakteristike: Tipično osetljivost na

kašnjenje end-to-end kašnjenje jitter kašnjenje

Tolerancija gubitaka: gubici 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

Klase MM aplikacija:1) Streaming uskladištenog

audio i video sadržaja2) Streaming audio i video

signala-zapisa "uživo"3) Interaktivni audio i video

u realnom vremenu

Jitter je promena kašnjenja paketa unutaristog toka paketa (packet stream)


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.


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

1. videorecorded

2. videosent

3. video received,played out at client

Kum

ula

tivni

podaci

streaming: u ovom trenutku, klijent izvodi (play out) rani-početni deo videa, dok server još uvek šalje preostali deo videa

networkdelay

vreme


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


Streaming multimedijalnih aplikacija "uživo"

Primeri: Internet radio talk show Uživo sportski događajiStreaming playback bafer playback može da se uspori nekoliko desetina

sekundi nakon transmisije postoje vremenska ograničenja još uvekInteraktivnost nemuguće brzo premotavanje premotavanje pa pauza, to je moguće


Interaktivnost, Multimedija u realnom vremenu

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?

aplikacije: IP telefoniranje, video konferencija, distribuirani interaktivni svet


Multimedija preko današnjeg Internet-aTCP/UDP/IP: “servis najboljeg pokušaja” nema garancija da neće biti kašnjenja, gubitaka

Današnje multimedijalne aplikacije na Internet-ukoriste tehnike aplikacionog nivoa da bi smanjile (što je moguće više) uticaje kašnjenja i gubitaka

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

?? ???

?

? ??

?

?


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


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. 28=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.


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.6 Iznad najboljeg pokušaja 7.7 Mehanizmi raspoređivanja

i vođenja politike 7.8 Integrisani servisi i

diferencirani servisi 7.9 RSVP


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

dekompresija uklanja jitter korekcija greške

Media Player


Multimedija na Iternet-u: najprostiji pristup

audio, video nisu stream-ovani: ne postoji, “pipelining,” duga kašnjenja, dok ne

bude playout!

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


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


Streaming sa streaming servera

Ova arhitektura dozvoljava protokole koji nisu HTTP između servera i medija player-a

Koristi UDP radije nego TCP


constant bit rate videotransmission

Cum

ula

tive

data

time

variablenetwork

delay

client videoreception

constant bit rate video playout at client

client playoutdelay

bu

ffere

dvid

eo

Streaming multimedijalne aplikacije: bafering na klijent strani

Bafering na klijent strani, playout kašnjenje kompenzuje dodatno kašnjenje na mreži, jitter kašnjenje


Streaming multimedijalne aplikacije: bafering na klijent strani

Bafer na klijent strani se puni brzinom x(t) i prazni brzinom d

bufferedvideo

variable fillrate, x(t)

constant drainrate, d


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


Streaming multimedijalne aplikacije: klijentova brzina (e)

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

1.5 Mbps encoding

28.8 Kbps encoding


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


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”.


RTSP Primer

Scenario: metafile za komunikaciju ka web browser-u browser startuje player player postavlja RTSP control konekciju, data

konekciju ka streaming server-u


Metafile primer

<title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>


Kako radi RTSP


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


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


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.


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


constant bit ratetransmission

Cum

ula

tive

data

time

variablenetwork

delay(jitter)

clientreception

constant bit rate playout at client

client playoutdelay

bu

ffere

ddata

Kašnjenje usled jitter-a

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.


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


Fiksno playout kašnjenje

packets

tim e

packetsgenerated

packetsreceived

loss

r

p p '

playout schedulep' - r

playout schedulep - r

• 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’


Adaptivno playout kašnjenje, I

packetith receivingafter delay network average of estimated

acketpith for delay network tr

receiverat played is ipacket timethep

receiverby received is ipacket timether

packetith theof timestampt

i

ii

i

i

i

Dynamic estimate of average delay at receiver:

)()1( 1 iiii trudud

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

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.


Adaptivno playout kašnjenje, II

Also useful to estimate the average deviation of the delay, vi :

||)1( 1 iiiii dtruvuv

The estimates di and vi 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:

iiii Kvdtp

where K is a positive constant.

Remaining packets in talkspurt are played out periodically


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

sequence numbers without gaps --> talk spurt begins.


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



2nd FEC scheme• “piggyback lower quality stream” • send lower resolutionaudio stream as theredundant information• for example, nominal stream PCM at 64 kbpsand redundant streamGSM at 13 kbps.

• Whenever there is non-consecutive loss, thereceiver can conceal the loss. • Can also append (n-1)st and (n-2)nd low-bit ratechunk



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


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


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


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


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.


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.


RTP Header

Payload Type (7 bits): pokazuje tip kodiranja koji se tekuće koristi.Ako pošiljalac menja kodiranje usred konferencije, on informišeprimaoca 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 poslatiRTP paket i može da se koristi za detekciju gubitaka paketa i zarestauriranje niza paketa.


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.


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


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


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.


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.


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.


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.


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.


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


Postavljanje poziva ka poznatoj IP adresi• 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)

• SIP poruke mogu da budu poslate preko TCP ili UDP-a; ovde preko RTP/UDP. •Default SIP port number je 5060.time time

Bob'stermina l rings

A lice

167.180.112.24

Bob

193.64.210.89

port 38060

Law audio

G SMport 48753


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


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 SIPservers ć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


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


SIP Registrar

REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89

From: sip:[email protected]

To: sip:[email protected]

Expires: 3600

Kada Bob startuje SIP client, klijent šalje SIP REGISTER poruku ka Bobovom registrar serveru

(slične funkcije kao kod Instant Messaging)

Register Message:


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


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

(1) Jim sends INVITEmessage to umass SIPproxy.(2) Proxy forwardsrequest to upenn registrar server. (3) upenn server returnsredirect response,indicating that it should try [email protected]

(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.

SIP client217.123.56.89

SIP client197.87.54.21

SIP proxyum ass.edu

SIP registrarupenn.edu

SIPregistrareurecom .fr

1

2

34

5

6

7

8

9


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.


Mreže sa distribuiranim sadržajemContent 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 serverin S. America CDN server

in Europe

CDN serverin Asia


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 serverin S. America CDN server

in Europe

CDN serverin Asia


CDN primer

izvorni server (www.foo.com) distribuira HTML zamenjuje: http://www.foo.com/sports.ruth.gif

sa

http://www.cdn.com/www.foo.com/sports/ruth.gif

HTTP request for

www.foo.com/sports/sports.html

DNS query for www.cdn.com

HTTP request for

www.cdn.com/www.foo.com/sports/ruth.gif

1

2

3

Origin server

CDNs authoritative DNS server

NearbyCDN server

CDN kompanija (cdn.com) distribuira gif fajlove koristi svoj

authoritative (nadležan) DNS server da rutira preusmerene zahteve


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


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: differential garancije Integrated Services: garancije nepromenljivosti

jednostavan model za proučavanje deljenja i zagušenja:


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

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

Princip 1


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)

obezbediti zaštitu (izolaciju) jedne klase od drugih

Princip 2



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

Dok je obezbeđena izolacija između protoka, poželjno je koristiti što efikasnije

resurse

Princip 3



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

Dopuštanje poziva: protok deklariše svoje potrebe, mreža može dablokira poziv (npr. signal zauzeća) ako ne može ispuniti zahtevani uslov

Princip 4


QoS principi: zaključak


Mehanizmi raspoređivanja i politike

raspoređivanje: izabrati sledeći paket za slanje linkom

FIFO (first in first out) raspoređivanje: šalje po redosledu stizanja u red 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


Politika raspoređivanja: više

Raspoređivanje na osnovu prioriteta: prenositi paket iz reda sa najvećim prioritetom

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 ...


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)


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


Mehanizmi politike

Cilj: ograničiti saobraćaj da ne prelazi deklarisane parametre

Tri zajednički-korišćena kriterijuma: (Dugoročna) srednja vrednost brzine: koliko paketa

može da se pošalje u jedinici vremena 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)


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).


Mehanizmi politike (više)

token bucket, obezbediti garantovanu gornju granicu kašnjenja npr. QoS garancije!

WFQ

token rate, r

bucket size, b

per-flowrate, R

D = b/Rmax

arrivingtraffic









i vođenja politike 7.8 Integrisani servisi i različiti

servisi 7.9 RSVP


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 QoSgarancije načinjene za već prihvaćene tokove?


Integrisani servisi: scenario QoS garancija

Rezervacija resursa setap poziva, signaliziranje

(RSVP) saobraćaj, QoS deklaracija kontrola prihvatanja po elementu

QoS-sensitive scheduling (e.g.,

WFQ)

request/reply


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


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"

WFQ

token rate, r

bucket size, b

per-flowrate, R

D = b/Rmax

arrivingtraffic


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


Ruter na ivici: po-toku upravljanje

saobraćajem

označavanje paketa kao in-profile i out-profile

Core router: za klasu upravljanje

saobraćajem buferovanje i raspoređivanje

bazirani na markiranju na ivici davanje prednosti in-profile

paketi Obezbediti prosleđivanje

Diffserv arhitektura

scheduling

...

r

b

marking


Edge-router markiranje paketa

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

profile: pred-pregovaranje o brzini A, bucket veličina B markirani paket na ivici baziran je per-flow profajlu

Moguće korišćenje markiranja:

User packets

Rate A

B


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


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


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


Prosleđivanje (PHB)

PHBs se razvijaju: Očekivano prosleđivanje: brzina otpremanja

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

Zajamčeno prosleđivanje: 4 klase saobraćaja svaka garantuje minimalnu količinu širine opsega








7.6 Iznad najboljeg pokušaja 7.7 Mehanizmi raspoređivanja i

vođenja politike 7.8 Integrisani servisi i

diferencirani servisi 7.9 Resource Reservation

Protocol - RSVP


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: rezervacija resursa duž putanje end-to-end (kraj sistema, ruteri) za QoS za multimedijalne aplikacije

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]


RSVP ciljevi dizajna

1. prilagoditi heterogene primaoce (različite širine opsega duž putanje)

2. prilagoditi različite aplikacije različitim zahtevima za resursima

3. učiniti multicast servise prve klase adaptivnim na članove multicast grupe

4. uticaj postojećeg multicast/unicast rutiranja, adaptacijom na promene postojećih unicast i multicast ruta

5. overhead kontrolnog protokola da bi se povećao (u najgorem slučaju) linearno broj primaoca

6. modularni design za heterogenu raspoloživu tehnologiju


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)


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: rezerviše resurse od pošiljaoca

(jednog ili više) do primaoca reservation teardown: uklanja rezervacije primaoca

signaling od-mreže-ka-kraju sistema path error reservation error


Putanja poruka: RSVP pošiljalac-mreža signaling

putanja poruke sadrži: adresu: unicast odredište ili multicast grupu flowspec-specifikaciju protoka: specifikaciju zahteva za

širinom opsega 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


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

H5

H3

H4H1

R1 R2 R3


inout

inout

inout

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

H2

H5

H3

H4H1

R1 R2 R3L1

L2 L3

L4L5

L6 L7

L5 L7L6

L1L2 L6 L3

L7L4m1:

m1:

m1:


inout

inout

inout


sledeće, H5 šalje path message, kreirajući više stanja na ruterima

H2

H5

H3

H4H1

R1 R2 R3L1

L2 L3

L4L5

L6 L7

L5 L7L6

L1L2 L6 L3

L7L4

L5

L6L1

L6

m1:

m1:

m1:


inout

inout

inout


H2, H3, H5 šalju path msgs, kompletirajući tabele stanja putanje

H2

H5

H3

H4H1

R1 R2 R3L1

L2 L3

L4L5

L6 L7

L5 L7L6

L1L2 L6 L3

L7L4

L5

L6L1

L6L7

L4L3L7

L2m1:

m1:

m1:


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


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 opsegaH2

H5

H3

H4H1

R1 R2 R3L1

L2 L3

L4L5

L6 L7


inout

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

H2

H5

H3

H4H1

R1 R2 R3L1

L2 L3

L4L5

L6 L7

L1L2 L6

L6L1(b)

inout

L5L6 L7

L7L5 (b)

L6

inout

L3L4 L7

L7L3 (b)

L4L2

b

bb

b

bb

b

m1:

m1:

m1:


inout

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

H2

H5

H3

H4H1

R1 R2 R3L1

L2 L3

L4L5

L6 L7

L1L2 L6

L6L1(b)

inout

L5L6 L7

L7L5 (b)

L6

inout

L3L4 L7

L7L3 (b)

L4L2

b

bb

b

bb

b

b

b

(b)m1:

m1:

m1:


inout

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

H2

H5

H3

H4H1

R1 R2 R3L1

L2 L3

L4L5

L6 L7

L1L2 L6

L6L1(b)

inout

L5L6 L7

L7L5 (b)

L6

inout

L3L4 L7

L7L3 (b)

L4L2

b

bb

b

bb

b

b

b

(b)m1:

m1:

m1:


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)

H2 H3

H4H1

R1 R2 R3L1

L2 L3

L4L6 L7

H2 H3

L2 L3


RSVP: primer 2

H1, H4 su jedini pošiljaoci šalju path messages kao ranije, indicirajući filtriranu

rezervaciju

H2 H3

H4H1

R1 R3L1

L2 L3

L4L6 L7

H2 H3

L2 L3

L2(H1-via-H1 ; H4-via-R2 )L6(H1-via-H1 )L1(H4-via-R2 )

in

out

L6(H4-via-R3 )L7(H1-via-R1 )

in

out

L1, L6

L6, L7

L3(H4-via-H4 ; H1-via-R3 )L4(H1-via-R2 )L7(H4-via-H4 )

in

out

L4, L7

R2


RSVP: primer 2

primalac H2 šalje reservation message za izvor H4 širine opsega b prostirući upstream prema H4, rezervišući b

H2 H3

H4H1

R1 R3L1

L2 L3

L4L6 L7

H2 H3

L2 L3

L2(H1-via-H1 ;H4-via-R2 )L6(H1-via-H1 )L1(H4-via-R2 )

in

out


in

out

L1, L6

L6, L7

L3(H4-via-H4 ; H1-via-R2 )L4(H1-via-62 )L7(H4-via-H4 )

in

out

L4, L7

R2

(b)

(b)

(b)

L1

bb b

b


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

H2 H3

H4H1

R1 R3L1

L2 L3

L4L6 L7

H2 H3

L2 L3


in

out


in

out

L1, L6

L6, L7


in

out

L4, L7

R2

(b)

(b)

(b)

L1

bb b

b


RSVP: soft-stanje pretpostavimo da H4 (pošiljalac) odlazi bez izvršavanja teardown-a

H2 H3

H4H1

R1 R3L1

L2 L3

L4L6 L7

H2 H3

L2 L3


in

out


in

out

L1, L6

L6, L7


in

out

L4, L7

R2

(b)

(b)

(b)

L1

bb b

b

konačno stanje na ruterima će isteći i nestati!

gonefishing!


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


RSVP: napomene

multicast kao servis “prve klase” rezervacije orijentisane ka primaocu korišćenje soft-stanja


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

poglavlje 7 multimedi jalno umrežavanje

Documents