Poglavlje 7 Multimedijalno umre

1
Poglavlje 7Multimedijalno umrežavanje
Computer Networking A Top Down Approach
Featuring the Internet, 3rd edition. Jim
Kurose, Keith RossAddison-Wesley, July 2004.
2
Multimedija, Quality of Service Šta je to?
Multimedijalne aplikacije mrežni audio i
video (kontinualni mediji)
3
Poglavlje 7 Ciljevi

• Principi
• Klasifikacija multimedijalnih aplikacija
• Identifikacija mrežnih servisa koji su potrebni
  aplikaciji
• Odabrati najbolji od best effort servisa
• Mehanizmi za obezbedivanje QoS
• Protokoli i arhitekture
• Specificni protokoli za servis najboljeg pokušaja
• Arhitekture za QoS

4
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 RSVP

5
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

• Osnovne karakteristike
• Tipicno osetljivost na kašnjenje
• end-to-end kašnjenje
• jitter kašnjenje
• Tolerancija gubitaka gubici koji se ne
  pojavljuju cesto prouzrokovani minornim
  greškama-kvarovima
• Ove karakteristike se razlikuju od "elasticnih"
  Web aplikacija, e-mail, FTP i Telnet, koje su
  netolerantne na gubitke ali tolerantne na
  kašnjenje

Jitter je promena kašnjenja paketa unutar istog
toka paketa (packet stream)
6
Streaming uskladištenih multimedijanih aplikacija

• Streaming
• medijalna aplikacija uskladištena na izvoru
• transmitovana do klijenta
• streaming klijentovo preslušavanje ili gledanje
  - playout pocinje pre nego što svi podaci stignu

- vremenska ogranicenja 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
Streaming uskladištene multimedijalne
aplikacijeŠta je to ?
Kumulativni podaci
vreme
8
Streaming uskladištene multimedijalne aplikacije
interaktivnost

• Funkcionalnost kao-kod-VCR-a
• klijent može da pauzira, premota video zapis
  itd.
• 10 sec pocetno kašnjenje OK
• 1-2 sec dok komanda ne pocne da se izvršava OK
• RTSP je cesto korišcen

9
Streaming multimedijalnih aplikacija "uživo"

• Primeri
• Internet radio talk show
• Uživo sportski dogadaji
• Streaming
• playback bafer
• playback može da se uspori nekoliko desetina
  sekundi nakon transmisije
• postoje vremenska ogranicenja još uvek
• Interaktivnost
• nemuguce brzo premotavanje
• premotavanje pa pauza, to je moguce

10
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
  primecuje
• kašnjenja izmedu 150 msec i 400 msec mogu biti
  prihvatljiva
• ukljucuju aplikacioni-nivo (paketizacija) i
  mrežna kašnjenja
• znacajno veca kašnjenja slabe interaktivnost
• inicijalizacija sesija
• kako onaj koji poziva oglašava svoju IP adresu,
  broj porta, algoritme kodiranja?

11
Multimedija preko današnjeg Internet-a

• TCP/UDP/IP servis najboljeg pokušaja
• nema garancija da nece biti kašnjenja, gubitaka

12
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 povecavaju š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 upucivanje na overlay mrežama na
  aplikacionom sloju
• sportski dogadaji

• Filozofija razlicitih servisa
• Male promene Internet infrastrukture tako da se
  obezbeduje prva i druga klasa servisa

13
Nekoliko reci o audio kompresiji

• pre prenosa preko racunarskih 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. 28256 mogucih kvantizacionih velicina
• Svaka kvantizaciona velicina je predstavljena
  bit-ovima
• 8 bit-ova za 256 vrednosti

• PCM impulsno kodna modulacija
• primer 8,000 samples/sec, 8 bitova --gt 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.

14
Nekoliko reci 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,
  cesto korišcen na Internet-u, lt 1 Mbps)
• Istraživanje
• Uslojeni (skalabilni) video
• prilagodava slojeve na iskoristljivu širinu opsega

15
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 RSVP

16
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šcenje UDP-a u odnosu na TCP
• višestruka kodiranja multimedije

Media Player

• dekompresija
• uklanja jitter
• korekcija greške

17
Multimedija na Iternet-u najprostiji pristup

• audio ili video uskladišten u fajl
• pretraživac 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 prosleden plejeru

• audio, video nisu stream-ovani
• ne postoji, pipelining, duga kašnjenja, dok ne
  bude playout!

18
Multimedija na Iternet-u streaming pristup

• pretraživac dobija (GET) metafile (URL ili tip
  kodiranja)
• pretraživac startuje player, prosledujuci mu
  metafile
• player kontaktira server
• server stream-uje audio/video ka player-u

19
Streaming sa streaming servera

• Ova arhitektura dozvoljava protokole koji nisu
  HTTP izmedu servera i medija player-a
• Koristi UDP radije nego TCP

20
Streaming multimedijalne aplikacije bafering na
klijent strani
constant bit rate video transmission
Cumulative data
time

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

21
Streaming multimedijalne aplikacije bafering na
klijent strani
constant drain rate, d
variable fill rate, x(t)
buffered video

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

22
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 mogucom brzinom kod TCP-a
• brzina punjenja se menja zbog TCP kontrole
  zagušenja, retransmisije izgubljenih paketa
• vece playout kašnjenje "glatka" TCP brzina
  isporuke
• HTTP/TCP prolaze lakše kroz firewalls

23
Streaming multimedijalne aplikacije klijentova
brzina (e)
1.5 Mbps encoding
28.8 Kbps encoding

• Q kako rukovati razlicitim sposobnostima
  klijentove brzine prijema?
• 28.8 Kbps dialup
• 100Mbps Ethernet

A server skladišti, transmituje više kopija
videa, kodiranih razlicitim brzinama
24
Korisnicka kontrola streaminga mediaReal 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 odreduje kako se streamed media transportuje
  može biti transportovan preko UDP-a ili TCP-a
• ne specificira kako media player baferuje
  audio/video

25
RTSP out of band kontrola

• RTSP poruke su takode poslate out-of-band
• RTSP kontrolne poruke koriste razlicite brojeve
  portova u odnosu na media stream out-of-band.
• Port 554
• media stream se posmatra in-band.

• 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
  razlicite brojeve portova

26
RTSP Primer

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

27
Metafile primer

• lttitlegtTwisterlt/titlegt
• ltsessiongt
• ltgroup languageen lipsyncgt
• ltswitchgt
• lttrack typeaudio
• e"PCMU/8000/1"
• src
  "rtsp//audio.example.com/twister/audio.en/lofi"gt
  
• lttrack typeaudio
• e"DVI4/16000/2"
  pt"90 DVI4/8000/1"
• src"rtsp//audio.ex
  ample.com/twister/audio.en/hifi"gt
• lt/switchgt
• lttrack type"video/jpeg"
• src"rtsp//video.ex
  ample.com/twister/video"gt
• lt/groupgt
• lt/sessiongt

28
Kako radi RTSP
29
RTSP primer razmene

• C - client, S - sender
• C SETUP rtsp//audio.example.com/twister/audi
  o RTSP/1.0
• Transport rtp/udp compression
  port3056 modePLAY
• 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 npt0-
• .
• C PAUSE rtsp//audio.example.com/twister/audi
  o.en/lofi RTSP/1.0
• Session 4231
• Range npt37
• .
• C TEARDOWN rtsp//audio.example.com/twister/a
  udio.en/lofi RTSP/1.0
• Session 4231

30
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 RSVP

31
Interaktivne aplikacije koje rade u realnom
vremenu

• PC-2-PC telefoniranje
• instant messaging servisi obezbeduju ovo
• PC-2-telefon
• Dialpad
• Net2phone
• video konferensing koristeci Web kamere

32
Interaktivne multimedijalne aplikacije
telefoniranje preko Internet-a

• Predstavljanje telefoniranja preko Internet-a
  kroz primer
• govornikov glas-audio naizmenicno se smenjuje
  prica i tišina.
• 64 kbps za vreme talkspurt
• paketi su generisani samo za vreme price-talk
  spurts
• 20 msec chunks na 8 Kbytes/sec 160 bytes
  podataka
• heder aplikacionog sloja dodat svakom
  komadu-chunk.
• Chunkheader su enkapsulirani u UDP segment.
• aplikacija šalje UDP segment na soket svakih 20
  msec za vreme talkspurt.

33
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)
• tipicno maksimalno dozvoljeno kašnjenje 400 ms
• tolerancija gubitaka zavisno od kodiranja glasa,
  prikrivanje gubitaka, brzina gubitaka paketa
  izmedu 1 i 20 može da se toleriše

34
Kašnjenje usled jitter-a
constant bit
rate transmission
Cumulative data
time

• Posmatramo end-to-end kašnjenja dva susedna
  paketa razlika može biti veca od 20 msec
• izbegavanje jitter-a
• sequence numbers, timestamps, playout delay.

35
Internet telefoniranje fiksno playout kašnjenje

• Primalac pokušava da izvede-playout svakog
  chunk-a tacno q msecs nakon generisanja chunk-a.
• chunk ima vremensku markicu t play out chunk je
  u tq .
• chunk stiže nakon tq podaci stižu isuviše kasno
  za playout, podaci su izgubljeni
• Tradeoff za q
• veliko q manji gubici paketa
• malo q bolja interaktivnost

36
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

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

Dynamic estimate of average delay at receiver
where u is a fixed constant (e.g., u .01).
38
Adaptivno playout kašnjenje, II
Also useful to estimate the average deviation of
the delay, vi
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
where K is a positive constant. Remaining
packets in talkspurt are played out periodically
39
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 gt 20 msec --gttalk
  spurt begins.
• With loss possible, receiver must look at both
  time stamps and sequence numbers.
• difference of successive stamps gt 20 msec and
  sequence numbers without gaps --gt talk spurt
  begins.

40
Oporavak od gubitaka paketa (1)

• forward error correction (FEC) šema
• za svaku grupu od n chunks kreirati redundant
  chunk koristeci exclusive OR nad n originalnih
  chunks
• poslati n1 chunks, povecavajuci širinu opsega za
  faktor 1/n.
• može se rekonstrurati original od n chunks ako
  postoji najviše jedan izgubljeni chunk od n1
  chunks

• Playout kašnjenje treba da bude fiksirano na
  vreme za prijem svih n1 paketa
• Tradeoff
• vece n, manje trošenje širine opsega
• vece n, vece playout kašnjenje
• vece n, veca verovatnoca da ce dva ili više
  chunks biti izgubljena

41
Oporavak od gubitaka paketa (2)

• 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

42
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 razlicitih chunks

• ako je paket izgubljen, još uvek sadrži dovoljno
  informacija za svaki chunk
• nema redundancy overhead
• ali utice na povecanje playout kašnjenja

43
Zakljucak Internet multimedija

• koristiti UDP da bi se izbegla TCP congestion
  control (kašnjenja) za vremenski-osetljiv
  saobracaj
• 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 izmedu pre-encoded stream rates
• dynamic server encoding rate
• oporavak od grešaka (na vrhu UDP-a)
• FEC, preklapanje
• retransmisija

44
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 RSVP

45
Real-Time Protocol (RTP)

• RTP odreduje strukturu paketa za pakete koji nose
  audio i video podatke
• RFC 1889.
• RTP paket omogucava
• 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

46
RTP radi na vrhu UDP-a

• RTP biblioteke obezbeduju interfejs
  transportnog-sloja
• što proširuje UDP
• broj porta, IP adrese
• payload type identifikacija
• packet sequence numbering
• time-stamping

47
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 takode sadrži sequence numbers i
  timestamps.

48
RTP i QoS

• RTP ne daje bilo kakav mehanizam za obezbedivanje
  isporuke podataka za odredeno vreme ili druge
  garancije za kvalitet servisa.
• RTP enkapsulacija se jedino vidi na krajevima
  sistema ona se ne vidi na ruterima izmedu.
• Ruteri koji obezbeduju best-effort servis ne cine
  bilo kakav specijalan napor da bi obezbedili da
  RTP paketi stignu na odredište za odredeno vreme.
  

49
RTP Header

• Payload Type (7 bits) pokazuje tip kodiranja
  koji se tekuce 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 povecava za jedan
  za svaki poslati
• RTP paket i može da se koristi za detekciju
  gubitaka paketa i za
• restauriranje niza paketa.

50
RTP Header (2)

• Timestamp polje (32 bits dugo). Prikazuje
  trenutak sempliranja prvog bajta u RTP paketu
  podataka.
• Za audio, timestamp clock se tipicno povecava 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 povecava za
  160 za svaki RTP paket kada je izvor aktivan.
  Timestamp clock nastavlja da se povecava
  konstantnom brzinom cak 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 razlicit SSRC.

51
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
• ukljuciti seq numbers i time stamps
• obezbeden je client RTP-a
• Takode napisati klijent stranu RTSP-a
• play i pause komande
• obezbeden je server RTSP-a

52
Real-Time Control Protocol (RTCP)

• Radi u spoju sa RTP-om.
• Svaki ucesnik u RTP sesiji periodicno transmiruje
  RTCP kontrolne pakete svim ostalim ucesnicima.
• Svaki RTCP paket sadrži sender i/ili receiver
  izveštaje-statistiku

• Statistika ukljucuje broj poslatih paketa, broj
  izgubljenih paketa, medudolazni jitter, itd.
• Povratna sprega može da se koristi za kontrolu
  performansi
• Pošiljalac može da modifikuje svoje transmisije
  koristeci povratnu spregu-feedback

53
RTCP
- Za jednu RTP sesiju postoji tipicno jedna
multicast adresa svi RTP i RTCP paketi koji
pripadaju toj sesiji koriste tu multicast adresu.
- RTP i RTCP paketi se razlikuju medusobno po
razlicitim brojevima portova (1). - Da bi
ogranicili saobracaj, svaki ucesnik smanjuje svoj
RTCP saobracaj kako se broj ucesnika na
konferenciji povecava.
54
RTCP paketi

• Source description paketi
• e-mail adresu pošiljaoca, njegovo ime, SSRC
  pridruženog RTP stream-a.
• Obezbeduje mapiranje izmedu SSRC i user/host
  imena.

• Receiver report paketi
• deo izgubljenih paketa, poslednji sequence
  number, srednja vrednost medudolaznih jitter-a.
• Sender report paketi
• SSRC od RTP stream-a, tekuce vreme, broj poslatih
  paketa i broj poslatih bajtova.

55
Sinhronizacija stream-ova

• RTCP može da sinhronizuje razlicite 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.

56
RTCP Bandwidth Scaling

• RTCP pokušava da ogranici svoj saobracaj na 5
  širine opsega sesije.
• Primer
• Pretpostavimo da jedan sender šalje video brzinom
  od 2 Mbps. RTCP pokušava da ogranici svoj
  saobracaj na 100 Kbps.
• RTCP daje 75 od ove brzine primaocu preostalih
  25 pošiljaocu

• 75 kbps se podjednako deli izmedu primaoca
• Sa R primaoca, svaki primalac dobije da pošalje
  RTCP saobracaj na 75/R kbps.
• Pošiljalac dobija za slanje RTCP traffic na 25
  kbps.
• Ucesnik odreduje RTCP packet transmission period
  proracunavajuci srednju vrednost velicine RTCP
  paketa (kroz celu sesiju) i deleci je sa
  alociranom brzinom.

57
Session Initiation Protocol - SIP

• Protokol za inicijalizaciju sesije
• IETF
• SIP dugorocna 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 naci pozivaoca bez obzira gde je ili koji
  IP uredaj pozivalac trenutno koristi.

58
SIP servisi

• Postavljanje poziva
• Obezbeduje mehanizme za pozivaoca da upozna
  pozvanog da želi da uspostavi poziv
• Obezbeduje mehanizme da se pozivalac i pozvani
  mogu složiti oko tipa medija i kodiranja.
• Obezbeduje mehanizme za završetak poziva

• Obezbeduje tekucu IP adresu pozivaoca.
• Mapira mnemonicki identifikator na tekucu IP
  adresu
• Upravljanje pozivom
• Dodaje nove media streams za vreme poziva
• Menja kodiranje za vreme poziva
• Poziva druge
• Transferuje i zadržava pozive

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

60
Postavljanje poziva

• Codec pregovaranje
• Pretpostavimo da Bob nema PCM ulaw encoder.
• Bob ce odgovoriti 606 Not Acceptable Reply i
  listom encodera koje može koristiti.
• Alisa može onda poslati novu INVITE poruku,
  oglašavajuci odgovarajuci 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

61
Primer SIP poruke

• INVITE sipbob_at_domain.com SIP/2.0
• Via SIP/2.0/UDP 167.180.112.24
• From sipalice_at_hereway.com
• To sipbob_at_domain.com
• Call-ID a2e3a_at_pigeon.hereway.com
• Content-Type application/sdp
• Content-Length 885
• cIN IP4 167.180.112.24
• maudio 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 ce biti neophodni

• Alisa šalje i prima SIP poruke koristeci SIP
  default port number 5060.
• Alisa specificira preko Viaheader kojim SIP
  klijent šalje i prima SIP poruke preko UDP

62
Prevodenje imena i lokacija korisnika

• Pozivalac želi da pozove pozvanog, ali ima samo
  njegovo ime ili e-mail address.
• Treba da dobije IP adresu tekuceg hosta pozvanog
• korisnik putuje
• DHCP protokol
• korisnik ima razlicite IP uredaje (PC, PDA)

• Resultat može biti baziran na razlicitim
  stvarima vreme dana i noci, nema uznemiravanja
  ...
• Servisi obezbedeni od SIP servera
• SIP registrar server
• SIP proxy server

63
SIP Registrar

• Kada Bob startuje SIP client, klijent šalje SIP
  REGISTER poruku ka Bobovom registrar serveru
• (slicne funkcije kao kod Instant Messaging)

Register Message

• REGISTER sipdomain.com SIP/2.0
• Via SIP/2.0/UDP 193.64.210.89
• From sipbob_at_domain.com
• To sipbob_at_domain.com
• Expires 3600

64
SIP proxy

• Alisa šalje invite message svom proxy serveru
• sadrži adresu sipbob_at_domain.com
• Proxy je sposoban za rutiranje SIP messages ka
  pozvanom
• mogude kroz više proksija.
• Pozvani šalje odziv nazad kroz isti skup
  proksija.
• Proxy vraca SIP response message Alisi
• sadrži Bobovu IP adresu
• Napomena proxy je analogan lokalnom DNS serveru

65
Primer
Caller jim_at_umass.edu with places a call to
keith_at_upenn.edu (1) Jim sends INVITEmessage to
umass SIPproxy. (2) Proxy forwardsrequest to
upenn registrar server. (3) upenn server
returnsredirect response,indicating that it
should try keith_at_eurecom.fr
(4) umass proxy sends INVITE to eurecom
registrar. (5) eurecom registrar forwards INVITE
to 197.87.54.21, which is running keiths SIP
client. (6-8) SIP response sent back (9) media
sent directly between clients. Note nije
prikazano i SIP ack message.
66
Poredenje 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 potice iz ITU (telefonije).
• SIP dolazi iz IETF-a pozajmljujuci mnogo od
  HTTP-a. SIP ima Web-primese, dok H.323 ima
  telefon-primese.

67
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 RSVP

68
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 izbegavajuci
  pogoršanje (gubici, kašnjenje) sadržaja koji se
  šalje duž dugih putanja
• CDN server je tipicno na ivici/pristupnoj mreži

origin server in North America
CDN distribution node
CDN server in S. America
CDN server in Asia
CDN server in Europe
69
Mreže sa distribuiranim sadržajem (CDNs)
origin server in North America

• 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

CDN distribution node
CDN server in S. America
CDN server in Asia
CDN server in Europe
70
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

• CDN kompanija (cdn.com)
• distribuira gif fajlove
• koristi svoj authoritative (nadležan) DNS server
  da rutira preusmerene zahteve

71
Više o CDNs

• rutiranje zahteva
• CDN kreiramapu, koja sadrži rastojanja od lista
  ISPs i CDN cvorova
• kada upit stigne na authoritative DNS server
• server odreduje ISP sa koga upit potice
• koristi mapu za odredivanje najboljeg CDN
  servera
• CDN cvorovi kreiraju overlay (preklapanje) mreže
  aplikacionog sloja

72
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 RSVP

73
Poboljšanje QoS u IP mrežama

• Do sada nalaženje najboljeg od best effort
• U buducnosti sledeca generacija Interneta sa QoS
  garancijama
• RSVP signalizira rezervaciju resursa
• Differentiated servisi differential garancije
• Integrated Services garancije nepromenljivosti
• jednostavan model za proucavanje deljenja i
  zagušenja

74
Principi QoS garancija

• Primer 1Mbps IP telefon i FTP dele 1.5 Mbps
  link.
• FTP-podaci mogu da zaguše ruter prouzrokujuci
  gubitke audio podataka
• potrebno je dati prioritet audio podacima u
  odnosu na FTP

Princip 1
markiranje paketa potrebno za ruter da bi vodio
racuna o razlicitim klasama kao i nova politika
rutera na osnovu koje se tretiraju paketi
75
Principi QoS garancija (2)

• šta ako se aplikacije "loše ponašaju" (audio
  podaci se šalju vecom brzinom od deklarisane)
• politika prisiliti izvor da se pridržava
  dodeljene širine opsega
• markiranje i politika na ivici mreže
• slicno ATM UNI (User Network Interface)

Princip 2
obezbediti zaštitu (izolaciju) jedne klase od
drugih
76
Principi QoS garancija (3)

• Dodeljivanje fiksne (ne-deljive) širine opsega
  toku neefikasno korišcenje širine opsega ako
  tokovi ne koriste svoja dodeljivanja

Princip 3
Dok je obezbedena izolacija izmedu protoka,
poželjno je koristiti što efikasnije resurse
77
Principi QoS garancija (4)

• Osnovna cinjenica ne može se podržati
  saobracajni zahtevi iznad kapaciteta linka

Princip 4
Dopuštanje poziva protok deklariše svoje
potrebe, mreža može da blokira poziv (npr. signal
zauzeca) ako ne može ispuniti zahtevani uslov
78
QoS principi zakljucak
79
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 RSVP

80
Mehanizmi rasporedivanja i politike

• rasporedivanje izabrati sledeci paket za slanje
  linkom
• FIFO (first in first out) rasporedivanje šalje
  po redosledu stizanja u red
• politika odbacivanja ako paket stigne u popunjen
  red koji paket odbaciti?
• Tail drop ispustiti dolazeci paket
• prioritet ispustiti/ukloniti na osnovu
  prioriteta
• slucajno ispustiti/ukloniti slucajno

81
Politika rasporedivanja više

• Rasporedivanje na osnovu prioriteta prenositi
  paket iz reda sa najvecim prioritetom
• više klasa, sa razlicitim prioritetima
• klasa može da zavisi od markiranja ili drugih
  informacija hedera npr. IP izvorište/odredište,
  brojevi portova ...

82
Politika rasporedivanja još više

• round robin rasporedivanje
• više klasa
• ciklicno skeniranje klasa redova, uslužiti jedan
  iz svake klase redova (ako je iskoristljiv)

83
Politika rasporedivanja još uvek više

• Težinski fair rad sa redovima
• generalizovani Round Robin
• svaka klasa uzima težinsku kolicinu servisa u
  svakom ciklusu

84
Mehanizmi politike

• Cilj ograniciti saobracaj da ne prelazi
  deklarisane parametre
• Tri zajednicki-korišcena kriterijuma
• (Dugorocna) 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)

85
Mehanizmi politike

• Token Bucket ogranicava ulaz na odredenu
  velicinu 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).

86
Mehanizmi politike (više)

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

87
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i razliciti servisi
• 7.9 RSVP

88
IETF integrisani servisi

• arhitektura za obezbedivanje 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
prihvacen sa garancijom performansi dok se ne
naruši QoS garancije nacinjene za vec prihvacene
tokove?
89
Integrisani servisi scenario QoS garancija

• Rezervacija resursa
• setap poziva, signaliziranje (RSVP)
• saobracaj, QoS deklaracija
• kontrola prihvatanja po elementu

request/ reply
90
Prihvatanje poziva

• Dolazeca sesija mora da
• deklariše svoje QoS zahteve
• R-spec definiše QoS koji se zahteva
• okarakteriše saobracaj koji ce biti poslat u
  mrežu
• T-spec definiše karakterisitke saobracaja
• signaling protokol potreban za nošenje R-spec i
  T-spec ruterima (gde se rezervacija zahteva)
• RSVP

91
Integrisani servisi QoS modeli servisa rfc2211,
rfc 2212

• Garantovani servisi
• najgori slucaj dolaznog saobracaja
  leaky-bucket-policed source
• jednostavno (matematicki dokazivo) bound
  kašnjenje Parekh 1992, Cruz 1988

• Kontrolisani servisi opterecenja
• "kvalitet servisa koji približno aproksimira QoS
  koji ce isti tok da ima od neopterecenog mrežnog
  elementa"

92
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. Takode se žele kvalitetne klase servisa
• relativno razliciti servisi Platinum, Gold,
  Silver
• Diffserv pristup
• proste funkcije u jezgru mreže, relativno složene
  funkcije na ivici rutera (ili hostova)
• Obezbeduju se funkcionalne komponente za gradenje
  clasa servisa

93
Diffserv arhitektura

• Ruter na ivici
• po-toku upravljanje saobracajem
• oznacavanje paketa kao in-profile i out-profile

• Core router
• za klasu upravljanje saobracajem
• buferovanje i rasporedivanje bazirani na
  markiranju na ivici
• davanje prednosti in-profile paketi
• Obezbediti prosledivanje

94
Edge-router markiranje paketa

• profile pred-pregovaranje o brzini A, bucket
  velicina B
• markirani paket na ivici baziran je per-flow
  profajlu

User packets
Moguce korišcenje markiranja

• na klasi bazirano markiranje paketi razlicitih
  klasa markirani razlicito
• intra-class markiranje podešen deo toka-protoka
  markiranog razlicito u odnosu na nepodešen

95
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 odreduju PHB koji ce paket da
  primi
• 2 bits su tekuce neiskorišcena

96
Klasifikacija i uslovljavanje

• mogu biti poželjna za ogranicavanje brzine
  saobracaja nekih klasa
• korisnik deklariše traffic profile (npr. brzinu,
  velicinu burst-a)
• merac saobracaja, oblikovan ako nije podešen

97
Prosledivanje (PHB)

• PerHopBehavior rezultat u razlicito
  posmatranom-merenom prosledivanju ponašanja
  performansi
• PHB ne specificira koje mehanizme da koristi da
  bi omogucio željeno PHB ponašanje performansi
• Primeri
• Klasa A uzima x od širine opsega odlaznog linka
  kroz vremenske intervale specificne dužine
• Paketi klase A prvo odlaze pre paketa iz klase B

98
Prosledivanje (PHB)

• PHBs se razvijaju
• Ocekivano prosledivanje brzina otpremanja paketa
  jedne klase jednaka je ili veca od specificirane
  brzine
• logical link with a minimum guaranteed rate
• Zajamceno prosledivanje 4 klase saobracaja
• svaka garantuje minimalnu kolicinu širine opsega

99
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 Proucavanje
  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 rasporedivanja i vodenja politike
• 7.8 Integrisani servisi i diferencirani servisi
• 7.9 Resource Reservation Protocol - RSVP

100
Skaliranje na Internet-u
bez mrežnih signaling protokola u pocetnom IP
dizajnu
servis najboljeg pokušaja
bez uspostavljanja konekcije (bez nformacija o
stanju) prosledivanje duž IP rutera

• 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 nacin
  npr. signaling-om !
• raniji Internet Signaling protokol ST-II RFC
  1819

101
RSVP ciljevi dizajna

1. prilagoditi heterogene primaoce (razlicite širine
   opsega duž putanje)
2. prilagoditi razlicite aplikacije razlicitim
   zahtevima za resursima
3. uciniti multicast servise prve klase adaptivnim
   na clanove multicast grupe
4. uticaj postojeceg multicast/unicast rutiranja,
   adaptacijom na promene postojecih unicast i
   multicast ruta
5. overhead kontrolnog protokola da bi se povecao (u
   najgorem slucaju) linearno broj primaoca
6. modularni design za heterogenu raspoloživu
   tehnologiju

102
RSVP ne radi

• ne specificira kako se resursi rezervišu
• radije odreduje mehanizam potrebnih komunikacija
• ne odreduje kako ce da se uzmu rutirani paketi
• to je posao protokola rutiranja
• signaling odvojen od rutinga
• ne radi interakciju sa prosledivanjem paketa
• odvajanje podrucja kontrole (signaling-a) i
  podataka (prosledivanja)

103
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 cini 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

104
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
  isticu
• putanja poruke komunicira sender informacijama i
  reverzna-putanja-ka-senderu ruting informacijama
• kasnije upstream prosledivanje rezervacija
  primaoca

105
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 prosleduju
• brzina audio sadržaja b
• samo jedno multicast stablo rutiranja je moguce

H3
H2
R1
R2
R3
H4
H1
H5
106
RSVP gradenje stanja putanje

• H1, , H5 svi šalju path messages preko m1
• (addressm1, Tspecb, filter-specno-filter,
  refresh100)
• Pretpostavimo da H1 šalje prvu path message

m1
m1
m1
H3
H2
L3
L2
L7
L6
R1
R2
R3
L4
H4
L1
L5
H1
H5
107
RSVP gradenje stanja putanje

• sledece, H5 šalje path message, kreirajuci više
  stanja na ruterima

L6
m1
m1
L1
L5
m1
L6
H3
H2
L3
L2
L7
L6
R1
R2
R3
L4
H4
L1
L5
H1
H5
108
RSVP gradenje stanja putanje

• H2, H3, H5 šalju path msgs, kompletirajuci tabele
  stanja putanje

L4
L3
L6
L2
m1
m1
L7
L1
L7
L5
m1
L6
H3
H2
L3
L2
L7
L6
R1
R2
R3
L4
H4
L1
L5
H1
H5
109
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 odredenog skupa
  pošiljaoca mogu da koriste rezervaciju
• dinamicki filtar pošiljaoci ciji paketi mogu
  biti prosledeni po linku ce se menjati (po izboru
  primaoca) vremenom.
• filter spec
• rezervacije upstream toka od primaoca-ka-pošiljaoc
  u, rezervacija resursa, kreiranje dodatnog stanja
  povezanog sa primaocem na ruterima

110
RSVP primer 1 - rezervacija primaoca

• H1 želi da primi audio sadržaj od svih ostalih
  pošiljaoca
• H1 poruka rezervacije tece 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
L3
L2
L7
L6
R1
R2
R3
L4
H4
L1
L5
H1
H5
111
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

in out
L3
L7
L4
L6
in out
L1
L2
m1
m1
(b)
L7
L3
L4
(b)
L2
L6
L1
in out
L5
L7
L6
m1
(b)
L6
L7
L5
H3
H2
L3
L2
L7
L6
R1
R2
R3
L4
H4
L1
L5
H1
H5
112
RSVP primer 1 - rezervacija primaoca (nastavak)

• sledece, H2 cini no-filter rezervaciju za širinu
  opsega b
• H2 prosleduje ka R1, R1 prosleduje ka H1 i R2 (?)
• R2 ne cini nikakvu akciju, dok je opseg b vec
  rezervisan na L6

in out
L3
L7
L4
L6
in out
L1
L2
m1
m1
(b)
L7
L3
L4
(b)
(b)
L2
L6
L1
in out
L5
L7
L6
m1
(b)
L6
L7
L5
H3
H2
L3
L2
L7
L6
R1
R2
R3
L4
H4
L1
L5
H1
H5
113
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 H3H4H5 prelazi b, gubitak paketa ce se
  pojaviti

in out
L3
L7
L4
L6
in out
L1
L2
m1
m1
(b)
L7
L3
L4
(b)
(b)
L2
L6
L1
in out
L5
L7
L6
m1
(b)
L6
L7
L5
H3
H2
L3
L2
L7
L6
R1
R2
R3
L4
H4
L1
L5
H1
H5
114
RSVP primer 2

• H1, H4 su jedini pošiljaoci
• šalju path messages kao ranije, indicirajuci
  rezervaciju
• ruteri skladište upstream pošiljaoca za svaki
  upstream link
• H2 želi da prima od H4 (samo)

H3
H3
H2
H2
L3
L3
L2
L2
L7
L6
R1
R2
R3
L4
H4
L1
H1
115
RSVP primer 2

• H1, H4 su jedini pošiljaoci
• šalju path messages kao ranije, indicirajuci
  filtriranu rezervaciju

in out
L1, L6
L2(H1-via-H1 H4-via-R2 ) L6(H1-via-H1
) L1(H4-via-R2 )
H3
H3
H2
H2
R2
L3
L3
L2
L2
L7
L6
R1
R3
L4
H4
L1
H1
in out
L6, L7
L6(H4-via-R3 ) L7(H1-via-R1 )
116
RSVP primer 2

• primalac H2 šalje reservation message za izvor H4
  širine opsega b
• prostiruci upstream prema H4, rezervišuci b

in out
L1, L6
(b)
L2(H1-via-H1 H4-via-R2 ) L6(H1-via-H1
) L1(H4-via-R2 )
(b)
H3
H3
H2
H2
R2
L3
L3
L2
L2
L7
L6
R1
R3
L4
H4
L1
L1
H1
in out
L6, L7
(b)
L6(H4-via-R3 ) L7(H1-via-R1 )
117
RSVP soft-stanje

• pošiljaoci periodicno ponovo pošalju path msgs da
  bi osvežili (održavali) stanje
• primaoci periodicno ponovo pošalju resv msgs da
  bi osvežili (održavali) stanje
• path i resv msgs imaju TTL polje, specificirajuci
  interval osvežavanja

in out
L1, L6
(b)
L2(H1-via-H1 H4-via-R2 ) L6(H1-via-H1
) L1(H4-via-R2 )
(b)
H3
H3
H2
H2
R2
L3
L3
L2
L2
L7
L6
R1
R3
L4
H4
L1
L1
H1
in out
L6, L7
(b)
L6(H4-via-R3 ) L7(H1-via-R1 )
118
RSVP soft-stanje

• pretpostavimo da H4 (pošiljalac) odlazi bez
  izvršavanja teardown-a

• konacno stanje na ruterima ce isteci i nestati!

in out
L1, L6
(b)
L2(H1-via-H1 H4-via-R2 ) L6(H1-via-H1
) L1(H4-via-R2 )
(b)
H3
H3
H2
H2
R2
L3
L3
L2
L2
L7
gone fishing!
L6
R1
R3
L4
H4
L1
L1
H1
in out
L6, L7
(b)
L6(H4-via-R3 ) L7(H1-via-R1 )
119
Osvežavanje pri višestrukom korišcenju
rezervacije/putanje

• oporavak od ranije izgubljene poruke osvežavanja
• ocekivano 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 ce isteci i nestati
• Osvežavanja rezervacija ce prouzrokovati da nove
  rezervacije budu nacinjene za primaoca od
  pošiljaoca koji se prikljucio 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,
  prouzrokujuci da R3 prosledi rezervaciju na H4,
  koji dodeljuje širinu opsega

120
RSVP napomene

• multicast kao servis prve klase
• rezervacije orijentisane ka primaocu
• korišcenje soft-stanja

121
Multimedijalno umrežavanje Zakljucak

• multimedijalne aplikacije i zahtevi
• izbor najboljeg od današnjih servisa najboljeg
  pokušaja
• mehanizmi rasporedivanja i politike
• Internet sledece generacije Intserv, RSVP,
  Diffserv