OZNACENIA NA OBRAZKOCH SU MOMENTALNE PO ANGL. MAM ICH MENIT? AJ TERAZ SA PRACUJE NA ODSTRANENI GRAMATICKYCH A INYCH CHYB, KTORE VZNIKLI POCAS PREKLADU A EDITOVANIA. DALEJ ESTE PRACUJEM NA DALSICH ALTERNATIVACH ROZSIRENIA PRACE KTORE PRIDAVAM CIASTOCNE

Todo

- zadavacie listy - done
- analyza podla zad. list - caka sa na nazory

• ZADAVACI LIST JE NA TRACI

Úvod

Bakalárska práca sa zaoberá s podporou pre monitorovanie prevádzkových charakteristík siete v reálnom čase. Multimediálne siete súčasnosti prenášajú údaje rôznych typov, ako sú video, hlas a dáta. Každý z nich má vlastnú sadu charakteristík prevádzky a funkčné požiadavky. Tieto siete sa líšia od tradičných dátových sietí v spôsobe spravovaní objektov.
V tradičných sieťach, ktoré sú založené na modeli najlepšej prevádzky s minimálnym úsilím (best-effort traffic model), sa väčšinou posielajú textové údaje. Tieto údaje, ako FTP súbory a e-maily, sú kritické na správnosť.
Avšak, v multimediálnych sieťach, dôležitú súčasť sieťovej prevádzky tvoria multimediálne aplikácie, ktoré sú kritické na čas a majú rôzne požiadavky.
Aby bola zaručená požadovaná kvalita služieb, je potrebné prideliť každému typu údajov dostačujúce prostriedky (parametre). Pre určenie parametrov QoS^?, a následne pre jeho distribúciu v rôznych sieťových segmentov, sa používa monitorovanie sieťovej prevádzky a jej charakteristík v reálnom čase. Teda, monitorovanie v reálnom čase je nevyhnutné pre správu multimediálnych sietí a ich služieb.
V súčasnosti je vyvinutých viacero mechanizmov pre monitorovanie a meranie parametrov kvality služieb. Jedným z nich je protokol IPFIX, štandard, ktorý slúži na export informácií súvisiace s IP tokmi.

Formulácia úlohy

Cieľom bakalárskej práce je navrhnúť a implementovať aplikačné rozhranie pre obsluhu protokolu ACP, ktorý umožňuje komunikáciu medzi Analyzerom a Collectorom (Analyzer Controller Protocol) meracieho nástroja BasicMeter. V rámci tejto úlohy je potrebné :

• Analyzovať môznosti monitorovania prevádzkových charakteristík siete v reálnom čase
• Analyzovať protokol ACP
• Navrhnúť aplikačné rozhranie pre obsluhu protokolu ACP
• Implementovať navrhnute rozhranie v jazyku Java
• Overiť funkčnosť implementovaného rozhrania v meracej plartforme BasicMeter

QoS

Problematika kvality služieb (QoS^?) patria k jednej z najvýznamnejších diskusných tém v počítačových sieťach. Avšak v súčasnosti neexistuje jednotná alebo formálna definícia QoS^?.

• ITU referuje na QoS^? ako “Súbor kvalitatívnych požiadaviek na kolektívne správanie jedného alebo viacerých objektov.”
• ATM Lexikón definuje QoS^? ako “Výraz, ktorý odkazuje na súbor výkonových ATM parametrov, ktoré charakterizujú prevádzky na danom virtuálnom spojení.”
• Podľa IEEE QoS^? je “Množina tých kvantitatívnych a kvalitatívnych charakteristík distribuovaného multimediálneho systému, ktoré sú potrebné k dosiahnutiu požadovanej funkčnosti aplikácie.”

Ako vidíme, v rôznych literatúrach sa QoS^? udáva v rôznych formách, ale kvalitu služieb by sme všeobecne mohli opišať ako schopnosť poskytovať rôzne priority pre rôzne aplikácie, užívateľov, dátové toky alebo schopnosť garantovať určitú hodnotu výkonu pre dátový tok. Garantovanie kvality služby je dôležité v prípade ak sieťová kapacita je nedostačujúca, špeciálne pre real-time streamujúce multimediálne aplikácie ako napríklad prenos hlasu cez IP (VoIP^?), on-line hry a IP-TV, pretože tieto často vyžadujú pevnú prenosovú rýchlosť a sú citlivé na meškanie. Pri aplikáciách takého typu, k prevedeniu dát v požadovanej kvalite, nie je dostatočná iba výber vhodnej šírky pásma, ale tiež je potrebné zabezpečiť celý rad ďalších parametrov.

Parametre QoS^?

Parametre QoS^? je možné prezentovať ako charakteristiky dátových tokov a sieťových liniek vyjadrujúce ich výkonnosť a kvalitu. Procedúry merania týchto parametrov sa nazývajú metriky. Parametre QoS^? sú:

• Šírka pásma (bandwidth) je maximálne množstvo informácií (bitov za sekundu), ktoré môžu byť prenesené cez kanál
• Stratovosť paketov (packet loss) je množstvo nedoručených paketov, ktoré neboli prijaté v cieli, alebo boli prijaté s chybou
• Jednosmerné oneskorenie (one-way delay alebo OWD) je čas potrebný pre paket dosiahnuť svoj cieľ (čas od odoslania paketu zo zdroja až po jeho prijatie v cieli).
• Kolísanie oneskorenia (delay variation, jitter) je definované pre dva pakety ako rozdiel medzi jednosmerným oneskorením jedného paketu a jednosmerným oneskorením druhého paketu
• Spiatočné oneskorenie (round trip time, RTT) je čas cesty paketu od zdroja do cieľu a späť. Ide o súčet OWD od uzlu A do B a od uzlu B do A, plus doba odozvy v uzlu B.
• Priepustnosť paketov (packet rate) je množstvo prenesených paketov za jednotku času.

Spôsoby merania QoS^? parametrov

Aby sa hodnoty pre QoS^? parametrov zabezpečili v požadovanom rozsahu správne, administrátori počítačovej siete potrebujú poznať ich skutočné hodnoty. ISP taktiež potrebujú poznať ich hodnoty, aby sa zabezpečilo splnenie podmienok uvedených v Service Level Agreement (SLA).

Na získanie reálnych hodnôt QoS^? parametrov sa používajú:

• Aktívne ( intruzívne) merania - Tieto merania sú založené na generovaní testovacej prevádzky v sieti. Sú riadenými experimentmi, ktoré môžu byt vykonané v ľubovoľnom čase a pre ľubovoľný druh prevádzky, ktorá je predmetom merania . Aktívne merania vyžadujú vyslanie prídavného testu prevádzky do siete pri meraní. Tento test prevádzky vždy spôsobuje zvýšenie zaťaženia sieťových liniek a aktívnych prvkov siete a môže podstatne ovplyvňovať výsledky merania, ktoré nemusia byť v súlade so skutočnou prevádzkou. Môže tiež spôsobovať zvýšené náklady, ak je použité účtovanie na základe využívania.

• Pasívne (neintruzívne) merania – Merania sú vykonávané len na základe monitorovania aktuálnej prevádzky v sieti. Pri pasívnych meraniach nie je generovaný žiadny test prevádzky. Pasívne merania nespôsobujú dodatočné zaťaženie siete a serverov. Výsledky meraní nie sú ovplyvnené prídavnou prevádzkou, ktorá môže spôsobiť zmenu spracovania normálnych prevádzkových údajov v sieti. Údaje o činnosti, ktoré vyplývajú z meraní, sú aplikované v príslušnej reálnej prevádzke, a to je dôvoď, prečo ponúkajú reálnejšie výsledky. Okrem toho, ak je použitá tarifikácia na základe intenzity prevádzky, nie sú zvýšené náklady spôsobené prenosom údajov testu prevádzky. Jednou z nevýhod pasívnych meraní je, že sú to neriaditeľné experimenty. V sieti musí byt zavedený požadovaný test prevádzky.

• Semi-aktívne (hybridné) merania - sú modifikované len pakety existujúcej prevádzky (napr. časová značka pridaná k paketu) a pod. Najväčšou nevýhodou semi-aktívnych meraní je, že aspoň prvý merací bod musí byt priamo v ceste údajov. Pretože pakety musia byt modifikované a poslané späť do siete, klasifikácia a modifikácia musia byt urobené v reálnom čase, zatiaľ čo pri čisto pasívnych meraniach kópie paketov môžu byt spracované v iných zariadeniach.

Sú známe nasledujúce skupiny pasívnych meracích metód: PRACUJE SA NA ROZSIRENI

• A Pasívne metódy s jedným meracím miestom - je možné merať iba v uzavretej slučke (RTT)
• B Pasívne metódy s dvoma meracími bodmi - môže byt meraná jedna cesta (smer)

Monitorovanie sieťovej prevádzky na základe IP tokov

Monitorovanie sieťovej prevádzky na základe IP tokov je veľmi dôležité u rozsiahlych počítačových sieťach. Umožňuje získať podrobnú informáciu o tokoch v reálnom čase, ktoré prebiehajú na zariadeniach siete, čím dáva administrátorom a manažérom podrobný pohľad do prevádzky ich sieti. Aj preto tvorí nenahraditeľnú súčasť zabezpečenia každej počítačovej siete. Umožňuje zníženie nákladov na sieťovú prevádzku, čím sa zabezpečí QoS^? multimediálnych aplikácií. Práve taktové prostriedky ponuka technológia NetFlow^?.

NetFlow

Protokol NetFlow^? je najpoužívanejší štandard, vyvinutý spoločnosťou Cisco Systems, pre meranie a monitorovanie počítačových sietí na základe IP tokov. Jeho primárnym cieľom je export informácií tokov zo sieťových zariadení.

NetFlow architektúra

Netflow architektúra sa typicky skladá z niekoľkých Netflow exportérov a jedného Netflow kolektoru. Exportér je pripojený k monitorovanej linke a analyzuje prechádzajúce pakety. Na základe zachytených IP tokov generuje NetFlow^? štatistiky a zhromažďuje ich v takzvanom NetFlow^? cache urýchľovači . Keď sa urýchľovač zaplní štatistiky sa exportujú na kolektor. Kolektor je zariadenie s veľkou úložnou kapacitou, ktorá zbiera štatistiky z viacerých exporterov a ukladá ich do databázy. Nad týmito dátami obvykle beží aplikácia (front end aplikácia - analyzer), ktorá ich vie efektívne vizualizovať a generovať z nich pohľady v podobe grafov a tabuliek, ktoré umožňujú jednoducho analyzovať monitorovanú prevádzku aj bežnému používateľovi. Pomocou NetFlow^? štatistík je možné odhaľovať vnútorné a vonkajšie útoky, dominantne zdroje prevádzky, sledovať, kto s kým komunikoval, ako dlho, pomocou ktorého protokolu a efektívnejšie plánovať budúci rozvoj siete.

IP tok (flow)

Tok je v terminológii NetFlow^? definovaný ako sekvencia paketov so zhodnou päticou údajov:

• cieľová/zdrojová IP adresa
• cieľový/zdrojový port
• číslo protokolu

Pre každý tok sa zaznamenáva:

• doba jeho vzniku a dĺžka jeho existencie
• počet prenesených paketov
• počet prenesených bajtov

a ďalšie údaje.

Najpoužívanejšími formátmi pre export dát o IP tokoch sú protokoly NetFlow^? verzia 5 a verzia 9. Verzia 9 zaviedla prácu so šablónami a štruktúru odosielaných dát na kolektor si môže používateľ definovať podľa svojich potrieb. Jedna z nevýhod bola, že export prebiehala pomocou UDP protokolu, ktorý nezaručuje spoľahlivé doručenie. Preto na základe protokolu verzii 9 vznikol nový IETF štandard nazývaný Internet Protocol Flow Information eXport (IPFIX), ktorý je už teraz veľmi obľúbený a dá sa očakávať, že sa v blízkej budúcnosti stane najpoužívanejším priemyslovým štandardom pre export dát o tokoch.

Internet Protocol Flow Information eXport (IPFIX)

IPFIX je nástupcom Netflow v9. Vznikol ako úplne otvorený formát, s väčšou podporou nových typov dát použiteľných v šablóne. Súčasnú (zatiaľ jedinú) verziu definuje RFC 3917. Takisto ako Netflow slúži k prenosu informácií o jednotlivých tokoch. Pre prenos vlastných dát môže používať SCTP, TCP alebo UDP.

BasicMeter

Koncepcia meracej architektúry je vybudovaná v súlade s IPFIX požiadavkami (NetFlow^? 9). Táto architektúra bola vyvinutá v rámci troch podprojektov (obr. 1): (1) BasicMeter ako exportovaci proces (2) JXColl ako kolektor proces (3) BM Analyzer ako front-end aplikácia.

Opísaná architektúra môže byť použitý aj v iných ako IP sieťach. Vďaka modulárnej architektúre nástroja BM je ľahké k nemu pridať moduly, napr. špeciálny modul, ktorý potenciálne umožňuje merať prevádzkové parametre siete pre danú infraštruktúru.

Pre komunikáciu medzi časťami meracieho nástroja boli vytvorené dva protokoly. Akákoľvek exportovacia, zhromaždovacia a analyzujúca aplikácia môže použiť navrhnuté protokoly na priame pripojenie. Vzhľadom na úlohy BasicMeter-a, JXColl-a a BM Analyzera budeme ich ďalej označovať ako exporter, kolektor a analyzer.

Analyzer - Exporter Protokol (AEP) je navrhnutý pre riadiace/kontrolne spojenie medzi analyzerom a exporterom

Analyzer – Collector Protokol (ACP) je navrhnutý pre dátové a riadiace/kontrolne spojenie medzi analyzerom a kolektorom.

NetFlow^? je použitý ako exportovaci protokol medzi exporterom a kolektorom.

Obr 1

Analyzer – Collector Protocol

Základné charakteristiky

Analyzer - Collector Protocol je binárny protokol aplikačnej vrstvy. Na komunikáciu sa používa TCP, ale bolo by možné použiť ľubovoľný spojovo-orientovaný, spoľahlivý, protokol. Komunikácia je obojsmerná a funguje na princípe komunikácie klient-server, pričom klientsku stranu predstavuje analyzer a serverskú kolektor. Primárnou funkciou protokolu je získať požadované informácie o prevádzke od kolektora bez neefektívneho pristupovaniu k databáze. Na dosiahnutie tohto cieľa, okrem dát sa zasielajú aj kontrolne informácie, ktoré slúzia na kontrolu správnosti a formatu prijatych dát analyzerom.

Princíp komunikácie

Komunikácia je založená na posielaní žiadostí analyzerom a posielaní odpovedí a dát kolektorom. Takáto komunikácia môže byť znázornená automatom (Finite State Machine) oboch strán. Jednotlivé komunikačné fázy sú reprezentované stavmi automatu, pričom každá správa má svoj jedinečný identifikátor (ID).

Riadiace správy sú :

• nastavenie šablóny
• nastavenie filtra
• pozastavenie posielania dát
• obnovenie posielania dát

Správy analyzera sú :

• A_0 (A_1) - nesprávny (správny) autentifikačný údaj
• 0_0 (0_1) - nesprávna (správna) šablóna nastavený/zmenený
• 1_0 (1_1) - nesprávny (správny) filter natavený/zmenený
• 2_0 (2_1) - neúspešné (úspešné) prerušenie posielania dát
• 3_0 (3_1) - neúspešná (úspešná) obnova posielania dát

Správy kolektora sú :

• 0 - požadovaná šablóna neprijatá
• 1 – autentifikácia OK (po vytvorení spojenia), požadovaná šablóna prijatá
• 10 (11) - filter neprijatý (prijatý)
• 20 (21) - prerušenie posielania dát odmietnutá (prijatá)
• 30 (31) - obnova posielania dát odmietnutá (prijatá)

Každý príjem úspešnej správy môže (ale nemusí) priviesť jednu a / alebo druhú stranu k prechodu z jedného stavu do druhého, a opačne - každá neprijateľná správa je oznámená druhej strane v podobe negatívnej odpovedí.

Opis komunikácie

Grafy a tabuľky automatov, popisujú iba kontrolnú komunikáciu medzi kolektorom a analyzerom. Kontrolné správy odoslané kolektorom pôsobia len ako odpovede na požiadavky generované analyzerom. Prenos dát, aj keď sa vykonáva cez rovnakého spojenie, z jedného hľadiska predstavuje akúsi špeciálnu autonómnu činnosť kolektora, ktorú inicializuje príjem informácií IP tokov od exportera (ov). Vzhľadom na požadovanú jednoduchosť a účinnosť protokolu, záhlavie správy kontrolnej informácie sa líši od záhlavie správy údajov o jeden-byte (hodnota 0 pre kontrolnú informáciu a hodnota 1 pre dáta).

Pred začatím komunikácie strana servera (kolektor) čaká na pripojenie klienta (analyzer) na dohodnutom porte (predvolená hodnota pre JXColl je 2138). Ak sa pri tom nevyskytne žiadna chyba, dôjde k nadviazaniu spojenia a obe strany komunikácie sa vyskytnú vo svojom "S" stave. Aby analyzer mohol začať komunikáciu s kolektorom, musí poslať správne autentifikačné údaje. Preto, po pripojení analyzer automaticky pošle meno a heslo v šifrovanej podobe (MD5). Úspešná autentifikácia prináša obe strany do ich "W" stavy, ale v prípade neúspešnej autentifikácie, kolektor ukončí spojenie a analyzer sa musí znovu pripojiť pre ďalší pokus.

V stave "W" sa od analyzera očakáva správa určená pre nastavenie šablóny, ktorá informuje kolektor o požadovanom formáte údajov (správa 0). Tieto šablóny sú zatiaľ v programe napevno zadefinovane, v budúcnosti sa však počíta priamo so zasielaním binárneho popisu šablóny. Po obdŕžaní šablóny kolektor odpovie jej prijatím (správa 1) alebo zamietnutím (správa 0). Ak šablóna je zamietnutá, analyzer musí poslať inú. Počas tejto fázy, kým kolektor neakceptuje šablónu neodpovie potvrdzujúcou správou, komunikácia je pozastavená. V prípade, že kolektor šablónu akceptoval sa prepne do stavu "T" a začne okamžite posielať dáta vo formáte špecifikovanom touto šablónou. Na druhej strane, ako náhle analyzer dostane správu o prijatí šablóny, prepne sa do stavu "R" a začne prijímať dáta od kolektora. V tejto fáze šablónu je môže zmeniť kedykoľvek a ak kolektor akceptuje novú šablónu, začne hneď po jej potvrdení posielať dáta vo formáte tejto zmenenej šablóny. Reálne dáta, ktoré získal/poslal kolektor/analyzer vedľa kontrolných informácií sú prenesené iba za stavoch "T" a "R".

V štandardne kolektor posiela každú informáciu o prevádzke, ktoré získal od exportera (ov). Ak by však bolo potrebné prijímať len špecifické informácie o prevádzke, tak by sa to dalo dosiahnuť pomocou správy, ktorá slúži na nastavenie filtra (správa 1). Ide o voliteľný krok a kolektor prijíma takúto kontrolnú správu len za stavu "T" a musí byť nastavená práve jedna šablóna. V súčasnosti je podporované filtrovanie tok na základe nasledujúcich kritérií:

• Ipv4 adresa/maska meracieho bodu - zatiaľ je možné vybrať merací bod zo zoznamu načítaného z databázy, alebo zvoliť adresu 0.0.0.0/0, ktorá reprezentuje ľubovoľný merací bod
• zdrojová a cieľová IPv4 adresa/maska pre daný tok - kombináciou IP adresy a masky je možné dosiahnúť špecifikovanie nielen jedného konkrétného hostiteľa, ale aj celú podstieť. Vzhľadom na to, že je možné zadať kombináciu viacerých IP adries, je možné jedným pravidlom špecifikovať aj viacero podsietí, prípadne hostiteľov
• zdrojový a cieľový port - toto kritérium umožňuje špecifikovať konkrétny typ prevádzky na základe čísla portu transportnej vrstvy, je tiež možné zadať viacero hodnôt, rozsah hodnôt aj viacero rozsahov hodnôt
• protokol - jedná sa o hodnotu nesenú v hlavičke IP paketu, ktorá označuje typ protokolu, zatiaľ je podporované rozoznávanie podľa čísla a rovnako ako v prípade portov je možné zadať ľubovoľnú kombináciu hodnôt a rozsahov hodnôt, neskôr sa plánuje prehľadnejší výber protokolu zo zoznamu

Kolektor potvrdzuje prijatie filtra správou 11, alebo odmieta ho správou 10. Filter môže byť zmenený alebo zrušený pravidlom prázdneho filtra kedykoľvek za stavu "T" kolektora.

Sú definované dve ďalšie kontrolné správy, ktoré slúžia na pozastavenie a obnovenie posielania dát. V stave "T", kolektor prijíma správu prerušenia posielania dát (správa 2). Príjem tejto správy spôsobí, že kolektor pozastaví prenos dát a odpovie správou prijatie prerušenia (správa 21), ktorá informuje analyzera, že posielanie dát sa pozastaví. Obe strany komunikácie prepnú do stavu "P". Od tejto chvíle analyzer neprijíma dáta. Jediným spôsobom, ako pokračovať v prenose dát je poslanie správy obnovy posielania dát (správa 3) analyzerom, ktorá prinesie obe strany späť do svojich predchádzajúcich stavov. Po prijatí tejto správy kolektor odpovie so správou prijatie obnovy posielania dát (správa 31) a začne ďalej prenášať dáta. Analyzer pred prijatím tejto správy nebude pokračovať v prijímaní údajov. Všeobecne možno povedať, že neexistuje žiadny dôvod pre kolektor aby zamietol kontrolné správy pozastavenia (správa 20) alebo obnovy (správa 30).

Opis kontrolných správ

Protokol definuje dva typy správ. Jeden pre analyzer a jeden pre kolektor. Správy generované analyzerom sa skladajú z informácií o šablóne a o filtri. Správy generované kolektorom obsahujú odpovede o prijatí/odmietnutí šablónov a filtrov. Gramatika správ ACP sa nachádza na Obr. 4 (terminálové symboly sú zvýraznené).

Obr.4

Pri použití protokolu ACP treba rátať s hodnotou doby odozvy, ktorá závisí od výkonu siete. Môžeme ju však uvažovať za konštantnú hodnotu. Kým údaje ťahané z databázy nie sú časovo reálne, ACP je oveľa efektívnejšie na monitorovanie a meranie rôznych charakteristík siete v reálnom čase.

• save.doc: navrh a analyza