12 Qos Intserv Diffserv

Viemedijske komunikacije 2005/2006
(c) FER, Zavod za telekomunikacije
Postoji mnogo definicija kvalitete usluge. Npr. ITU-T E.800 definira kvalitetu usluge kao ukupni uinak djelovanja usluge koje odreuju razinu zadovoljstva korisnika usluge. Visoka kvaliteta usluge je kategorija koja bitno ovisi o oekivanjima korisnika. Tako npr. u fiksnoj telefonskoj mrei korisnik oekuje stalnu raspoloivost sustava. Nadalje, kad se poziv jednom prihvati, korisnik oekuje da nee biti neoekivano prekinut i da e kvaliteta biti stalna. U j pak j j mobilnoj se p telefonskoj mrei korisnici lake mire s injenicom da ne mogu uvijek ostvariti poziv, da se on ponekad prekine, kao i da kvaliteta veze varira. U Internetu je standardni model usluge tzv. best-effort model: mrea e pokuati zadovoljiti korisnikove zahtjeve, ali bez ikakvih garancija da e traena kvaliteta zaista biti pruena. U veini primjena zastupa se elastian pristup kvaliteti usluge, tj. prilagoavanje promjenama u propusnosti i kanjenju, dok se niti u sluaju mrenog zaguenja usluga ne kanjenju odbija, ve svi korisnici osjeaju pogoranje kvalitete. Iako su korisnici Interneta navikli na ekanje i prolazne probleme s kanjenjem i propusnou, kod npr. pregledavanja Web stranica, za viemedijske primjene (npr. za prijenos govora, glazbe ili videa), kao i primjene u stvarnom vremenu (npr. igre, zajedniki rad) takav model nije prihvatljiv.
Best-effort model usluge znai da e mrea pokuati zadovoljiti korisnikove zahtjeve, ali bez ikakvih garancija da e traena kvaliteta zaista biti pruena. Taj model posljedica je datagramskog naina rada Interneta, koji nema ugraene mehanizme za razliito postupanje s paketima koji nose podatke sa stvarno-vremenskim karakteristikama. Jedini cilj datagramske mree je da bilo kako prenese datagram od izvora do odredita, ako je to mogue. Poznato nam je da se datagram usmjerava tako da se u svakom usmjeritelju neovisno odreuje sljedei skok, odn. sljedei usmjeritelj, na putu prema odreditu. Sljedei skok odreuje se na temelju tablica usmjeravanja, temeljem same injenice da postoji put prema odreditu, pri emu se ne vodi rauna o trenutnom optereenju na odabranom putu. Ukupno kanjenje na putu od izvora do odredita je zbroj propagacijskog kanjenja i kanjenja u usmjeriteljima i drugoj spojnoj opremi i openito varira ovisno o uvjetima u mrei. U svakom usmjeritelju d i i j i i k j i lj datagram ulazi na l i kraj repa ekanja s FIFO sustavom posluivanja. Dakle, vrijeme ekanja proporcionalno je duljini repa, odn. trenutnom optereenju usmjeritelja, neovisno o tome radi li se o stvarno-vremenskom prometu ili ne. Ako se rep prepuni, odbacuju se novo-pristigli datagrami.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Integrirane usluge (IntServ) je naziv za proirenje Internet arhitekture i protokola kako bi se pruile integrirane usluge, tj. kako bi se IP koristio za podrku usluga u stvarnom vremenu (real-time), kao i dosadanjih (nonreal-time) usluga. Ta proirenja voena su rastuim potrebama za podrku usluga u stvarnom vremenu za napredne i viemedijske primjene. Kljuna komponenta IntServ arhitekture je skup definiranih usluga, koji za sada sadri dvije usluge, uslugu kontroliranog optereenja i garantiranu g ( j ) g pruaju p j j pojedinom toku (flow), ( ), uslugu (o emu vie kasnije). Usluge se p slino virtualnom krugu kod komutacije kanala. Nadalje, IntServ arhitektura polazi od pretpostavke da mora postojati izravan mehanizam za rezervaciju kapaciteta u mrenim elementima, kako bi se oni pripremili za pruanje usluge tokovima koji uslugu zahtijevaju. Taj mehanizam u sadanjim IntServ izvedbama prua Resource Reservation Protocol (RSVP). Suprotno usmjerenosti k pojedinanom toku, mree k j slijede model S j i ka j di k koje lij d d l diferenciranih usluga (Diffserv) klasificiraju pakete u mali broj agregiranih (objedinjenih) tokova ili klasa, ovisno o kdu (Diffserv codepoint, DSCP, RFC 2474) u zaglavlju IP datagrama. Klasifikacija paketa se provodi samo na rubovima mree, a dalje se na svakom Diffserv usmjeritelju s paketima postupa prema obrascu ponaanja za klasu kojoj paketi pripadaju (per-hop behavior).
33
34
Specifikacija integriranih usluga je RFC 1633, Integrated Services in the Internet Architecture, iz 1994. godine. U integriranim uslugama definirane su, uz best-effort uslugu, dvije usluge usmjerene prema stvarno-vremenskim primjenama: usluga kontroliranog optereenja (controlled load service) i garantirana usluga (guaranteed service). Specifikacija usluge kontroliranog optereenja je RFC 2211, Specification of the Controlled Load Network Element Service, a specifikacija Controlled-Load Service garantirane usluge je RFC 2212 Specification of Guaranteed Quality of Service. Integrirane usluge su izvedene u mrenim elementima (npr. usmjeritelji, veze), a promatraju se za pojedinani tok. S uslugom kontroliranog optereenja, tok podataka ima kvalitetu usluge kakvu bi imao p malom optereenju mrenog elementa u bestg pri p j g effort sluaju, s tim da se koristi kontrola prihvata i evt. rezervacija, kako bi se osigurala takva usluga ak i kada je mreni element preoptereen. Garantirana usluga je slina ponaanju kod komutacije kanala. Kod garantirane usluge, postoji vrsta, matematiki dokaziva gornja granica kanjenja s kraja na kraj, pri emu su uzeta u obzir kanjenja svih mrenih elemenata na putu, te propusnost u skladu sa zahtjevima. Kako K k bi se mogla pruiti traena usluga, za rezerviranje kapaciteta k i ti l iti t l i j k it t koristi se Resource Reservation Protocol (RSVP).
35
Specifikacija RSVP-a je RFC 2205, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, s dodacima u RFC 2750 RSVP Extensions for Policy Control. RSVP ima status Proposed Standard protokola. Dokument RFC 2210, The Use of RSVP with IETF Integrated Services opisuje koritenje RSVP-a u arhitekturi integriranih usluga. U arhitekturi integriranih usluga, RSVP igra ulogu signalizacijskog p protokola, tj. slui za uspostavu rezervacija resursa u mrenim elementima , j p j du staze. Pri tome RSVP ne uspostavlja vezu, niti sudjeluje u odabiru staze (to je uloga protokola usmjeravanja!), niti sam vri prijenos podataka (to je uloga transportnih protokola!). RSVP se moe koristiti i uz IPv4 i IPv6. Za IPv6 je ve ugraena podrka za razlikovanje tokova prema flow label polju u IPv6 zaglavlju. Kako e biti pokazano kasnije, RSVP je pogodan i za pojedinano i za vieodredino razailjanje. razailjanje Osnovni princip rezervacije je da se resursi rezerviraju za svaki tok za koji se zahtijeva QoS, u svakom mrenom elementu (vezi ili usmjeritelju) na putu od izvora do odredita, tj. s kraja na kraj. Vidljivo je da kod integriranih usluga sveukupna mrena infrastruktura, tj. svi mreni elementi na putu od primatelja do poiljatelja moraju podravati RSVP.
36
Postupak rezervacije kod RSVP-a zapoinje primatelj. Izvor (aplikacija poiljatelja) opisuje svojstva prometa kojeg e generirati, a primatelj trai eljeni QoS od mree za pojedini tok(ove) od nekog izvora, aljui poruke sa zahtjevom za rezervaciju prema izvoru toka. Na temelju rezervacijskih poruka, svaki usmjeritelj na putu vri rezervaciju potrebnih resursa (npr. spremnika, komunikacijskih veza i sl.) i, ako je rezervacija uspjena, proslijeuje zahtjev sljedeem usmjeritelju uz tok (prema poiljatelju) Ako je rezervacija neuspjena npr u nedostatku poiljatelju). neuspjena, npr. potrebnih slobodnih resursa, usmjeritelj alje primatelju poruku o greci. Kada rezervacijska poruka doe do posljednjeg usmjeritelja u nizu (to znai da je rezervacija uspjeno provedena po cijelom putu) usmjeritelj alje primatelju potvrdu. Posljednji usmjeritelj u nizu je ili usmjeritelj najblii poiljatelju, ili usmjeritelj na kojem se spajaju rezervacijski zahtjevi kod vieodredinih tokova. Stanje S j rezervacija po putu osvjeuje se periodikim rezervacijskim ij j j i diki ij ki porukama. Prednost tog pristupa je da se izgubljene RESV poruke automatski nadoknauju sljedeom porukom, a svakom novom porukom moe se izvriti i promjena rezervacije. S obzirom da nije potrebno izravno postavljati i raskidati rezervacije, podaci o rezervacijama se uvaju kao tzv. soft state (za razliku od hard state-a kod ATM-a i telefonske mree).
37
Poiljatelji karakteriziraju odlazni promet preko specifikacije prometa, Tspec (traffic specification), koja definira gornju i donju granicu za propusnost, kanjenje i kolebanje kanjenja. Od aplikacije poiljatelja oekuje se i stalno nadzire pridrava li se generirani promet najavljene specifikacije prometa. S prometom koji se ne uklapa u Tspec postupa se kao s best-effort prometom. Kako bi izvrio rezervaciju, svaki primatelj alje zahtjev za rezervaciju natrag p g prema p j poiljatelju. Zahtjev, uz Tspec na kojeg se rezervacija j j , p j g j odnosi (prema pripadnom Tspec-u poiljatelja), sadri: vrstu usluge (kontrolirano optereenje ili garantirana), specifikaciju zahtjeva, Rspec (request specification), koja opisuje eljenu razinu kvalitetu odabrane usluge, odn. dodatne parametre, specifikaciju filtera (filterspec), koja karakterizira pakete na koje se rezervacija odnosi ( p odredina adresa, transportni p j (npr. , p protokol i transportna adresa (port)). Vrsta usluge, Tspec i Rspec primatelja zajedno ine specifikaciju toka (flowspec). Specifikacija toka i specifikacija filtera ine oznaku toka (flow descriptor) koju usmjeritelji koriste za identifikaciju svake rezervacije.
38
Poiljatelj alje RSVP PATH poruku koja sadri Tspec na odredinu adresu, koja moe biti bilo pojedinana, bilo vieodredina. Svaki usmjeritelj koji podrava RSVP na putu od izvora do odredita pamti da se nalazi na stazi i koji mu je prvi skok uz stazu, tj. u smjeru poiljatelja. Ta informacija koristi se za kasnije prosljeivanje rezervacijskih poruka prema poiljatelju. Kako bi izvrio rezervaciju, svaki primatelj alje zahtjev za rezervaciju RESV porukom natrag p p g prema p j poiljatelju. RESV p j poruka sadri ranije j opisane parametre, a staza kojom putuje je ona prethodno uspostavljena PATH porukama. Nakon uspjene rezervacije du cijele staze s kraja na kraj (u svakom usmjeritelju), poiljatelj moe poeti slati tok podataka, kojem je na temelju prethodne rezervacije osigurana traena kvaliteta usluge. Napomena: U ovom pojednostavljenom prikazu, nisu posebno obraene neke znaajke RSVP-a: Adspec u PATH poruci, razliiti stilovi rezervacija, specifikacije filtera koje omoguuju oznaavanje pod-tokova za hijerarhijski kodirane podatke, namijenjene razliitim primateljima (npr. razliita rezolucija slike ili videa, glazbeni kanali, itd.), podatke koji se odnose na kontrolu politike kod rezervacije resursa.
39
40
Ve je spomenuto da su integrirane usluge izvedene u mrenim elementima. Primjer mrenog elementa je usmjeritelj s ugraenim funkcijama opisanima u nastavku. Mreni element sastoji se od nekoliko komponenata. Klasifikacija paketa razdvaja pakete u tokove i dostavlja ih komponenti koja vri rasporeivanje paketa na dodijeljene resurse. Npr. u usmjeritelju se paketi pohranjuju u memorijske meuspremnike i obrauju u procesoru. Komponenta koja vri rasporeivanje p p j p j paketa mora osigurati dovoljno g j memorije i procesorske moi za obradu paketa kako bi se postigla traena kvaliteta usluge. Dio koji upravlja rezervacijom resursa (recimo, primjenom RSVP-a) upravlja usmjeravanjem, a koristi kontrolu politike i kontrolu prihvata. Za svaku dolaznu rezervaciju se u mrenom elementu (usmjeritelju) prvo se vri kontrola prihvata. Kontrola prihvata ukljuuje provjeru postoje li resursi koji se mogu dodijeliti za podrku traene kvalitete usluge za promatrani tok. Kontrola politike je provjera administrativnih ogranienja za korisniku aplikaciju (npr. provjera ovlasti, zabrane koritenja, uspostavljenog rauna i sl.). Ako bilo koja od tih dviju kontrola ne proe, poiljatelju se vraa poruka o greci. Inae, vri se rezervacija resursa potrebnih za pruanje traene kvalitete usluge, te se konano tokovima dodjeljuju rezervirani resursi (rasporeivanje paketa).
41
RSVP je pogodan za vieodredino razailjanje te se dobro prilagoava veliini skupine. Na primjeru je prikazana rezervacija za sluaj vieodredinog razailjanja s jednim poiljateljem i tri primatelja (R1, R2, R3). Poiljatelj alje PATH poruku na vieodredinu odredinu adresu. Poruke putuju prema primateljima niz stablo vieodredinog usmjeravanja. Primatelji zatim alju RESV poruke prema poiljatelju. Kako rezervacijske poruke putuju uz stablo vieodredinog usmjeravanja, tako se u usmjeriteljima spajaju g j j , j j p j j rezervacijski zahtjevi za primjene kod kojih je to mogue. Npr. ako jedan primatelji R2 i R3 rezerviraju svaki 64 kbit/s za isti tok audio podataka, tada je spojeni zahtjev (koji se prosljeuje sljedeem usmjeritelju) 64 kbit/s, a ne 128 kbit/s.
42
43
Najvea prednost RSVP-a je mogunost da aplikacija moe tono definirati rezervacijske zahtjeve za tok i za prihvaen zahtjev dobiti vrstu garanciju kvalitete usluge. Najvei nedostatak je upravo cijena u vidu sloenosti pristupa koji sve to omoguuje, kao i obrade za svaki tok u svakom usmjeritelju. Ostale prednosti vezane su za soft state stanja rezervacija. Moe se izdvojiti pouzdanost rezervacije, budui da se izgubljene RESV poruke nadoknauju p j periodikim ponavljanjem, i p g j p j j , prilagodljivost rezervacije, budui j , da se promjena rezervacijskih parametara od strane primatelja ogleda ve u sljedeoj RESV poruci. S obzirom da se stanje rezervacija osvjeuje periodikim rezervacijskim porukama, ako nema novih RESV poruka u zadanom intervalu, resursi se automatski oslobaaju. Nadalje, mogua je dinamika promjena puta kojim tok putuje i promjena rezervacije, to se ne moe ostvariti kod mrea s komutacijom kanala, kao to su npr. ATM i te e o s a e a telefonska mrea.
44
45
Specifikacija diferenciranih usluga dana je u RFC 2475, An Architecture for Differentiated Services. Suprotno usmjerenosti ka pojedinanom toku, mree koje slijede model diferenciranih usluga (Diffserv) klasificiraju pakete u mali broj agregiranih tokova ili klasa, ovisno o kdu (Diffserv codepoint, DSCP, RFC 2474) u zaglavlju IP datagrama. Na svakom Diffserv usmjeritelju, s paketima se postupa prema zadanom ponaanju za klasu kojoj pripadaju (p (per-hop behavior, PHB). Napredne i sloene metode klasifikacije, p , ) p j , oznaavanja, nadzora i oblikovanja prometa moraju biti izvedene samo na rubovima mree. Dakle, kod DiffServ pristupa nema obrade svakog paketa, niti voenja brige o svakom pojedinanom toku na svim usmjeriteljima u mrei, ime je ovaj pristup prikladniji za velike mree. Koritenje diferenciranih usluga pretpostavlja postojanje ugovora o razini usluge (Service Level Agreement, SLA) meu mreama na granici. SLA definira kriterije politike i profil prometa Od graninih ulaznih toaka prometa. oekuje se nadzor i oblikovanje prometa prema zadanom profilu.
46
Na slici je primjer DiffServ mree. Korisnik moe postaviti DS j j polje, ali to nije obavezno. Konanu odluku o postavljanju DC polja donosi rubni usmjeritelj (usmjeritelj na rubu mree), oznaen s E (Edge Router). Rubni usmjeritelj moe raditi i mjerenje prometa, redardsvo i oblikovanje korisnikog prometa. Usmjeritelj u sredinjoj mrei, oznaen s C (Core Router), p j j j ponaane p primjenjuje p prema skoku na p paketu koji ima j postavljeno DS polje.
47
U modelu diferenciranih usluga paketi se klasificiraju prema kdu, nazvanom differentiated services codepoint (DSCP) u zaglavlju IP datagrama , sa znaenjem bitova u oktetu kao na slici.. RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers detaljno opisuje DSCP polje i postupke prosljeivanja. U svakom usmjeritelju, s paketima se postupa prema zadanom ponaanju za klasu kojoj pripadaju (per-hop behavior, PHB). Dva definirana ponaanja su: ubrzano prosljeivanje (Expedited Forwarding) osigurano prosljeivanje (Assured Forwarding)
48
U modelu diferenciranih usluga paketi se klasificiraju prema kdu, nazvanom differentiated services codepoint (DSCP) u zaglavlju IP datagrama. RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers detaljno opisuje DSCP polje i postupke prosljeivanja. Diferencirane usluge za IPv4 uvode novu definiciju Type of Service (TOS) polja, koje, iako zamiljeno za podrku usluga koje best-effort model ne j , g j j zadovoljava, uglavnom nije iskoriteno u sadanjem Interenetu. Za IPv6 koristi se class polje.
49
Razine usluga kod diferenciranih usluga odreene su ponaanjem prema paketu u svakom skoku, odn. u svakom usmjeritelju. To ponaanje odreeno je za klasu, odn. DSCP u zaglavlju paketa. Ubrzano prosljeivanje (Expedited Forwarding) je postupak koji paketima u klasi osigurava male gubitke, nisko kanjenje i nisko kolebanje kanjenja u usmjeritelju. Kako bi se postiglo malo kanjenje, za ubrzano prosljeivanje je definirano da suma brzina primljenih paketa na ulazu u j j vor ne smije biti vea od minimalne brzine transmisije na izlazu. Time se osigurava da se u vorovima ne stvara rep ekanja, to smanjuje kanjenje i kolebanje kanjenja.
50
Osigurano prosljeivanje (Assured Forwarding) definira N (trenutno 4) neovisnih klasa prosljeivanja, oznaenih kao AF1 do AFn. Unutar svake od tih klasa, postoji M pod-klasa (trenutno 3) za vjerojatnost isporuke. to je vea vjerojatnost isporuke, vea je vjerojatnost da paket nee biti odbaen u sluaju zaguenja. Za svaku klasu se neovisno konfiguriraju resursi, kao npr. memorijski meuspremnici i transmisijski kapacitet.
51
52
53
54
55
Preporuka ITU-T E.860 (Framework of a service level agreement) definira SLA kao formalni sporazum izmeu dvaju ili vie strana, do kojeg se dolazi pregovaranjem, i koji ukljuuje karakteristike usluge, odgovornosti i prioritete svakog dijela. SLA moe sadravati i odredbe o performancama, naplati, isporuci usluge, kao i o ekonomskim i pravnim pitanjima. Dio SLA koji se odnosi na kvalitetu usluge naziva se sporazum o kvaliteti usluge (QoS Agreement) i ukljuuje nadzor, mjerenje i odluivanje o parametrima kvalitete usluge.
56
57
http://www.rfc-archive.org/getrfc.php?rfc=3260 New Terminology and Clarifications for Diffserv 2. Terminology Related to Service Level Agreements (SLAs) The Diffserv Architecture [2] uses the term "Service Level Agreement" (SLA) to describe the "service contract... that specifies the forwarding service a customer should receive". The SLA may include traffic conditioning rules which (at least in part) constitute a Traffic Conditioning Agreement (TCA). A TCA is "an agreement specifying classifier rules and any corresponding an traffic profiles and metering, marking, discarding and/or shaping rules which are to apply...." As work progressed in Diffserv (as well as in the Policy WG [6]), it came to be believed that the notion of an "agreement" implied considerations that were of a pricing, contractual or other business nature, as well as those p g, , that were strictly technical. There also could be other technical considerations in such an agreement (e.g., service availability) which are not addressed by Diffserv. It was therefore agreed that the notions of SLAs and TCAs would be taken to represent the broader context, and that new terminology would be used to d t describe those elements of service and traffic conditioning that are ib th l t f i d t ffi diti i th t addressed by Diffserv. -A Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a DS domain. (c) FER, Zavod za telekomunikacije A Traffic Conditioning Specification (TCS) is a set of parameters and their
58
59
60
61
62
63
64
65
Slika saima usporedbu IntServ i DiffServ pristupa. Vano je napomenuti da IntServ i DiffServ nisu meusobno iskljuive mogunosti, ve prije mogunosti s razliitim primjenama. Relativno novi dokument (iz studenog 2000), RFC 2998, A Framework for Integrated Services Operation over Diffserv Networks opisuje okvir za koritenje IntServ preko mrea koje podravaju DiffServ.
66
67

12 Qos Intserv Diffserv

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

12 Qos Intserv Diffserv

Uploaded by

Copyright:

Available Formats

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006

(c) FER, Zavod za telekomunikacije

Viemedijske komunikacije 2005/2006