Priklad dokumentu



Slovenská technická univerzita v BratislaveFakulta informatiky a?informa?n?ch technológiíIlkovi?ova 2, 842 16 Bratislava 4In?inierske dieloDalibor Turay, Kristián Ko??ál, Patrik Kraj?a, Patrik Perneck?, Peter Radványi, Roman Kop?o, Vladimír ?ápka?tudijn? program: Softvérové in?inierstvoRo?ník: 1, Krú?ok: Po 16:00, U120Predmet: Tímov? projektVedúci: Ing. Rastislav BencelAk. rok: 2015/16Obsah TOC \o "1-2" 1Big picture PAGEREF _Toc437557178 \h 11.1?vod PAGEREF _Toc437557179 \h 11.2Globálne ciele pre zimn? semester PAGEREF _Toc437557180 \h 21.3Rámcové ciele z?poh?adu ?printov PAGEREF _Toc437557181 \h 22Anal?za PAGEREF _Toc437557182 \h 32.1Softvérové kontrolóry PAGEREF _Toc437557183 \h 32.2OpenVSwitch PAGEREF _Toc437557184 \h 42.3Roz?írenie MiniNet-u pridaním podpory pre WiFi PAGEREF _Toc437557185 \h 52.4?tandard 802.1X PAGEREF _Toc437557186 \h 52.5?tandard 802.11i PAGEREF _Toc437557187 \h 72.6?tandard 802.11k – Assisted roaming PAGEREF _Toc437557188 \h 122.7?tandard 802.11r – Fast transition roaming PAGEREF _Toc437557189 \h 122.8SDN-Wifi PAGEREF _Toc437557190 \h 172.9SDN kontrolór RYU PAGEREF _Toc437557191 \h 192.10SDN kontrolór Floodlight PAGEREF _Toc437557192 \h 202.11WLAN s Odin architektúrou PAGEREF _Toc437557193 \h 212.12Virtualizácia Wifi siete PAGEREF _Toc437557194 \h 233Návrh PAGEREF _Toc437557195 \h 273.1Komunika?n? protokol PAGEREF _Toc437557196 \h 273.2WTP - Wireless Termination Point PAGEREF _Toc437557197 \h 363.3AFCP – Additional Functionality of Control Plane PAGEREF _Toc437557198 \h 403.4HDS - Handover Decision Server PAGEREF _Toc437557199 \h 474Implementácia PAGEREF _Toc437557200 \h 534.1Postup in?talácie Mininet-WiFi PAGEREF _Toc437557201 \h 534.2Nasadenie firmvéru na smerova? PAGEREF _Toc437557202 \h 534.3Nasadenie a?spojazdnenie SDN kontrolóra a?prepína?a PAGEREF _Toc437557203 \h 675Testovanie PAGEREF _Toc437557204 \h 695.2Simulácia v?OpenNet PAGEREF _Toc437557205 \h 705.3Flow tabu?ky PAGEREF _Toc437557206 \h 705.4Vizualizácia topológie PAGEREF _Toc437557207 \h 706Literatúra PAGEREF _Toc437557208 \h 72Big picture?vodTáto dokumentácia bola vytvorená, aby slú?ila na popísanie in?inierskeho diela, ktoré je vyvíjané na?ím tímom inWifi. Hlavn?m cie?om ná?ho projektu je analyzova? a?pochopi?, ak?m princípom fungujú softvérovo definované siete (SDN), softvérové kontrolóry v?t?chto sie?ach a?sp?sob komunikácie wifi prístupov?ch bodov tzv. access pointov (AP). Po tejto anal?ze vytvoríme jednoduchú sie?ovú architektúru, ktorá bude fungova? na princípe SDN a?do nej implementujeme viaceré funkcionality spomedzi ktor?ch, hlavnú funkcionalitu predstavuje plynul? prechod koncového wifi zariadenia medzi dvoma AP. Ide nám o?to, aby pou?ívate? tejto siete nezaregistroval zmenu toku prúdenia dát medzi koncov?m zariadením a?meniacimi sa AP. Kv?li tomuto faktu sme sa nazvali inWifi, ?o vlastne predstavuje skratku invisible Wifi, teda nevidite?ná Wifi sie?. V?dne?nom svete tento plynul? prechod e?te nie je plne funk?n? a?jeho nasadenie v?SDN sie?ach je e?te menej preskúmané, ako nasadenie v??tandardn?ch sie?ach. Tento projekt pre nás predstavuje ur?itú v?zvu, lebo m??eme poveda?, ?e na?a práca má v?skumn? charakter. Ve?a práce budeme musie? venova? nau?eniu sa a pochopeniu nov?ch technológií, aby sme sa vedeli dobre pohybova? v?tejto doméne. Okrem iného, sa budeme sna?i?, aby prechody nastali bez konfigurácie koncového zariadenia. Ak budeme úspe?ní, budeme m?c? poskytova? klientom vysoko kvalitné sie?ové slu?by, ?o bude vies? k?ich vy??ej spokojnosti. Na?e rie?enie by sa dalo vyu?i? v?ade tam, kde je potrebná nepretr?itá wifi komunikácia. Napríklad skladoví roboti, ktorí by boli ovládaní wifi AP, by nemali problém s?v?padkami komunikácie pri pohybe.Cie?om prvého semestra pre nás bude analyzova? r?zne SDN technológie, komunika?né protokoly wifi zariadení a?iné technológie, ktoré pou?ijeme pre splnenie po?iadaviek projektu. Vytvoríme testovacie prostredie, respektíve architektúru, na ktorej budeme m?c? testova? a?pozorova?, akí sme úspe?ní, ?o sa t?ka plynulosti prechodu.Cie?om druhého semestra bude hlavne tvori? softvér pre SDN a robi? ve?a testov, ktor?ch úspe?nos? budeme porovnáva?. Na konci vyberieme najúspe?nej?iu softvérovú implementáciu SDN, ktorá ponúka najrobustnej?ie fungovanie a?plynul? prechod. Pod?a toho ako sa nám bude dari?, máme aj?ved?aj?ie ciele a?tie predstavujú pridávanie nov?ch funkcií do na?ej SDN architektúry. T?kajú sa hlavne bezpe?nosti a?jednoduchosti ovládania siete.Globálne ciele pre zimn? semesterOboznámenie sa s existujúcimi rie?eniami roamingu v sie?ach.Oboznámenie sa s SDN sie?ami a ako tieto siete fungujú.Podrobné oboznámenie sa s Wifi technológiou.Oboznámenie sa so ?tandardami Wifi technológie (autentifikácia, bezpe?nos?, at?.)Vytvorenie testovacieho prostredia pre SDN siete.Simulácia prechodu medzi AP (roaming) v SDN sie?ach.Pripravi? zariadenia (AP) pre vykonávanie roamingu v SDN sieti.?iasto?né vytvorenie prototypu pre roaming.Rámcové ciele z?poh?adu ?printov?print 1: Oboznámenie sa s Wifi roamingom a SDN sie?ami.?print 2: Spojazdnenie AP a kontrolóra, vytvorenie metodík, definovanie rizík.?print 3: Návrh architektúry, testovanie integrácie Wifi s kontrolórom.?print 4: Vytvorenie prototypu. Anal?zaSoftvérové kontrolórySoftvérov? kontrolór je softvérová platforma ktorá nám umo?ňuje spravova? a kontrolova? sie?. Tento SDN (Software Defined Networking) softvérov? kontrolór musí sp?ňa? základnú po?iadavku a to, ?e musí podporova? OpenFlow verziu 1.3. V?eobecne platí, ?e SDN kontrolór je "mozgom" v prostredí SDN, ktor? oznamuje informácie "dole" k prepína?om a smerova?om zo southbound API a "hore" do aplikácií a obchodnej logiky z northbound API.Analyzovali sme tieto softvérové kontrolóry:NOX bol prv?m Openflow kontrolórom av?ak podporoval iba OpenFlow 1.0 a to znamená, ?e nesp?ňa na?e kritéria.POX je v?eobecn? SDN kontrolór, ktor? podporuje OpenFlow. Ma vysokú úroveň SDN API vrátane grafov topológií a podpory pre vizualizáciu. Taktie? nesp?ňa kritériá, preto?e je príli? nov?m na trhu a nemá zatia? dostato?nú komunitu.OpenDaylight je open-source projekt, ktorého cie?om je ur?chli? prijatie SDN a vytvori? pevn? základ pre sie?ové virtualizácie (NFV). Tento softvér sme odmietli z d?vodu zl?ch skúseností minuloro?ného bakalára. FlowVisor je kontrolór ur?en? na ?peciálny ú?el, kde sa chová ako transparentné proxy medzi OpenFlow switchmi a viacer?mi OpenFlow kontrolórmi. Nesp?ňa po?iadavky, preto?e slú?i iba na ?peciálne ú?ely.OpenContrail systém je roz?írite?ná platforma pre SDN, av?ak má iba ve?mi slabú dokumentáciu, taktie? nesp?ňa kritéria.The Floodlight Open SDN kontrolór je kontrolór podnikovej triedy, licencovan? Apachom a zalo?en? na jave. Je príli? komplikovan?, ?o znamená ?asovo náro?n? na pochopenie a preto nesp?ňa po?iadavky. Ale je zaraden? ako plán B.Beacon kontrolór je prepojen? s Floodlight a preto taktie? nevyhovuje.Ryu je open-source SDN kontrolór dizajnovan? na zv??enie agilnosti siete t?m, ?e sa dá jednoducho spravova? a prisp?sobi? tomu, ako sa zaobchádza s prevádzkou siete. Tento SDN kontrolór sme si vybrali pre jeho ve?kú komunitu a obsiahlu dokumentáciu a sp?ňa hlavnú po?iadavku a to, ?e podporuje OpenFlow 1.3.OpenVSwitchOpen vSwitch je softvérov? viacvrstvov? prepína? licencovan? pod Open Source Apache 2.0 licenciou. Je navrhnut? tak, aby umo?ňoval masívnu automatizáciu sietí pomocou programov?ch roz?írení. V???ina zdrojového kódu je napísaná v?natívnom jazyku C a?je jednoducho prenosite?n? do r?znych prostredí, kam patria predov?etk?m aj vnorené systémy.OpenWrt je opisovan? ako distribúcia Linux pre vnorené systémy. Namiesto snahy vytvori? jeden, statick? firmvér, OpenWrt poskytuje plne zapisovate?n? systém súborov s mana?mentom modulov a balíkov. To oslobodzuje od v?beru aplikácií a konfigurácií poskytnut?ch v?robcom a umo?ňuje upravi? zariadenie prostredníctvom pou?itia ak?chko?vek balíkov pre danú aplikáciu. Pre v?vojára, OpenWrt je v?vojové prostredie na vytvorenie aplikácie bez potreby vytvori? cel? nov? firmvér; pre pou?ívate?a to znamená schopnos? plnej úpravy zariadenia v sp?soboch, o ktor?ch nikto nevedel.Aktuálna verzia Open vSwitch (v2.4.0) podporuje nasledovné vlastnosti:Monitorovanie komunikácie medzi virtuálnymi systémami (inter-VM) cez protokoly NetFlow, sFlow(R), IPFIX, SPAN, RSPAN a?pomocou GRE tunelov.LACP (IEEE 802.1AX-2008)?tandard 802.1Q – podpora VLAN pomocou trunk liniekMulticast snoopingIETF Auto-Attach SPBM a?podpora LLDP?tandard 802.1ag pre správu a?údr?bu sietíSTP (IEEE 802.1D-1998) a RSTP (IEEE 802.1D-2004)Konfigurácia QoS a?riadenie premávkyPodpora pre HFSC qdiscRiadenie premávky medzi VM rozhraniamiNIC bonding with source-MAC load balancing, active backup, and L4 hashingPodpora protokolu OpenFlow (s mnoh?mi roz?íreniami pre virtualizáciu)Podpora IPv6Tunelovacie protokoly (GRE, VXLAN, STT, a Geneve, s IPsec podporou)Protokol na vzdialenú konfiguráciu pomocou C a?Python v?ziebPrepínanie (forwarding) v?rámci jadra (kernel) a?pou?ívate?ského priestoru (user-space)Abstraktná vrstva prepínania (forwarding) umo?ňuje jednoduchú prenosite?nos? do nov?ch softvérov?ch a?hardvérov?ch platforiemHlavnou v?hodou Open vSwitch je to, ?e podporuje naraz nieko?ko verzií protokolu OpenFlow a?je kompatbiln? s?firmvérom OpenWrt pre SOHO smerova?e. Sú?asná podpora jednotliv?ch verzií OpenFlow vyzerá nasledovne:Verzie Open vSwitchVerzie OpenFlow1.01.11.21.31.41.51.9 a?star?ieánonienienienienie1.10ánonie?iasto?ne?iasto?nenienie1.11ánonie?iasto?ne?iasto?nenienie2.0áno?iasto?ne?iasto?ne?iasto?nenienie2.1áno?iasto?ne?iasto?ne?iasto?nenienie2.2áno?iasto?ne?iasto?ne?iasto?ne?iasto?ne?iasto?ne2.3ánoánoánoáno?iasto?ne?iasto?ne2.4ánoánoánoáno?iasto?ne?iasto?neTab.?.1 - Stav podpory jednotliv?ch verzií OpenFlowPosledné verzie u? majú plnú podporu pre OpenFlow v1.3, ktorá je pre ná? projekt posta?ujúca. Preto vznikol nápad vyu?i? Open vSwitch v?prepína?och SDN v?rámci rie?enia projektu.Roz?írenie MiniNet-u pridaním podpory pre WiFiMininet-WiFi je vetva MiniNet-u, ktorá je roz?írená s podporou pre bezdr?tové siete WiFi. Virtuálne stanice (STA) a prístupové body (AP) sú pridané na základe známeho ovláda?a mac80211/SoftMac. V sú?asnosti v???ina bezdr?tov?ch ovláda?ov na Linuxe pou?íva mac80211/SoftMac, ktor? podporuje podstatnú ?as? funkcií skuto?ného bezdr?tového WiFi adaptéra (NIC) a pre Mininet-WiFi umo?ňuje simuláciu bezdr?tov?ch sietí aj na ni??ích vrstvách sie?ovej architektúry.V?voj na Mininet-WiFi v sú?asnosti prebieha ako ?ist? doplnok emulátora MiniNet, pridaním nov?ch abstrakcií a?tried, s cie?om zabezpe?enia podpory virtuálnych bezdr?tov?ch rozhraní a emulovan?ch liniek, pri?om funkcionality ako natívna simulácia a podpora pre OpenFlow ostanú nezmenené.?tandard 802.1XIEEE 802.1X je názov protokolu, ktor? umo?ňuje zabezpe?enie prístupu do po?íta?ovej siete. Pokia? sa klient (po?íta?) pripojí k pripojovaciemu bodu, je po ňom pomocou IEEE 802.1X vy?adovaná autentizácia (napr. pou?ívate?ské meno a heslo). Pripojen? bod blokuje v?etok dátov? tok klienta do tej doby, ne? je úspe?ne autentizovan?. Pre riadenie autentizácie je u klienta pou?ívan? suplikant , v pripojenom bode je po?adovaná dostato?ná podpora.Princíp ?innostiPokia? sa pou?ívate? pripojí na sie?ov? port, má blokovanú v?etku komunikáciu okrem EAP protokolu, ktor? zais?uje autentizáciu. Autentizácia prebieha nasledovne:Klient sa pripojí k prístupovému boduPrístupov? bod akceptuje iba?autentiza?né EAP rámceostatn? (dátov?) tok od klienta je zablokovan?klient odo?le autentiza?né informácie pomocou EAP protokoluprístupov? bod prepo?le ?iados? RADIUS serveruna RADIUS serveri prebehne overenie pou?ívate?apokia? je pou?ívate? lokálny prebehne jeho overenie priamo na RADIUS serveri pokia? pou?ívate? nie je lokálny, prebehne ?iados? o autentizáciu cez ?truktúru RADIUS serverov a? k pou?ívate?ovej domovskej sietiv?sledkom autentizácie je informovan? prístupov? bod, ktor? v prípade úspechu odblokuje klientovi dátov? tok.Obr.?. SEQ Obrázok \* ARABIC 1 - Autentifikácia pomocou RADIUS servera [1]?tandard 802.11iIEEE 802.11i-2004, alebo 802.11i skrátene, je zmenou p?vodného ?tandardu IEEE 802.11, realizovaného ako Wi-Fi Protected Access II (WPA2). Návrh ?tandardu bol ratifikovan? 24. júna 2004. Táto norma stanovuje bezpe?nostné mechanizmy pre bezdr?tové siete, nahradzuje dolo?ku pre krátku autentifikáciu a bezpe?nos? z p?vodného ?tandardu. V procese, novela u? nepou?íva rozbité Wired Equivalent Privacy (WEP).802.11i nahrádza predchádzajúcu ?pecifikáciu zabezpe?enia, Wired Equivalent Privacy (WEP), pri ktorom bolo preukázané, ?e má chyby zabezpe?enia. Wi-Fi Protected Access (WPA), bol zaveden? Wi-Fi Alianciou ako prechodné rie?enie neistoty pri ?WEP. Wi-Fi Protected Access (WPA) je predchodca WPA2, namiesto implementácie úplného ?tandardu IEEE 802.11i implementuje iba 3. návrh tohoto ?tandardu, teda iba podmno?inu 802.11i. WPA2 pou?íva blokovú ?ifru Advanced Encryption Standard (AES). Predchádzajúce WEP a WPA pou?ívajú prúdovú ?ifru RC4.Typy zabezpe?eniaWPA2 (WI-FI Protected access 2)WPA2 implementuje povinné prvky ?tandardu IEEE 802.11i. Pridáva ?k TKIP nov? algoritmus CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) zalo?en? na AES, ktor? je pova?ovan? za úplne bezpe?n?.WPA2 Enterprise (WPA2)Vyu?íva RADIUS (Remote Authentication Dial In User Service) – u?ívate?ská vytá?aná slu?ba pre vzdialenú autentizáciu. Autentiza?ná metóda 802.1 X/EAP s predvolenou ?ifrovacou metódou AES (CCMP), taktie? podporuje aj TKIP. Pou?ívanou ?ifrou je AES a volite?nou je aj RC4.WPA2 Personal (WPA2-PSK)Pou?íva zdie?an? k?ú? PSK (Pre-shared key), ktor? sa skladá z frázy od 8 do 63 znakov. Táto fráza sa ?ifruje TKIP alebo AES algoritmom. Pou?ívanou autentiza?nou metódou je PSK (Pre-shared key) s predvolenou ?ifrovacou metódou AES (CCMP). Pou?ívanou ?ifrou je AES a volite?nou je aj RC4.?ifrovacie algoritmyTKIPTKIP bol zostrojen? tak aby sa dal jednoducho vlo?i? do nov?ch firmvérov pre zariadenia siete 802.11. TKIP vyu?íva rovnak? ?ifrovací algoritmus ako WEP. ?tandardne v?ak pou?íva 128bitov? k?ú? a na rozdiel od WEP obsahuje dynamické do?asné k?ú?e. TKIP pracuje s automatick?m k?ú?ov?m mechanizmom, ktor? mení do?asn? k?ú? ka?d?ch 10 000 paketov. ?al?ou ve?kou v?hodou TKIP je Message Integrity Check (MIC), teda kontrola integrity správ. MIC je podstatne lep?ie zabezpe?enie integrity správ ne? dovtedy pou?ívan? jednoduch? kontroln? sú?et CRC. MIC znemo?ňuje úto?níkom zmeni? správy po prenose.AES (CCMP)?ifra vyu?íva symetrick? k?ú?. Ten ist? k?ú? je pou?it? aj pre de?ifrovanie. D??ka k?ú?a m??e by? 128, 192 alebo 256 bitov. Metóda ?ifruje dáta postupne v blokoch s pevnou d??kou 128 bitov. ?ifra sa vyzna?uje vysokou r?chlos?ou ?ifrovania. V sú?asnej dobe nebol uverejnen? známy prípad prelomenia tejto metódy ochrany dát.EAP (Extensible Authentication Protocol)Roz?irujúci autentifika?n? protokol. Protokol, pri ktorom sa na autentifikáciu pou?íva digitálny certifikát, ktor? sa musí predin?talova? na klientsk? PC. Typicky sa pou?íva s RADIUS serverom na autentifikáciu pou?ívate?ov pri ve?k?ch podnikov?ch sie?ach. EAP protokol je pou?ívan? v ?tandardoch 802.1X a v ochranách WPA Enterprise a WPA2 Enterprise.LEAP (Lightweight EAP)LEAP protokol vyvinula firma Cisco, je postaven? na 802.1X a minimalizuje bezpe?nostné chyby pri pou?ití s WEP. Táto verzia EAP je bezpe?nej?ia ako EAP-MD5. Na autentizáciu pou?íva MAC adresy. Samozrejme, ?e tento protokol nie je bezpe?n? pred crackermi. V sú?asnosti firma CISCO odporú?a pou?ívate?om aby pou?ívali nov?ie verzie EAP ako sú – EAP-FAST, PEAP, alebo EAP-TLS.PEAP (Protected EAP)PEAP nie je ?ifrovací protokol. PEAP len autentifikuje klientov v sieti. Na autentizáciu pou?íva verejné k?ú?ové certifikáty. Potom sa vytvára ?ifrovan? SSL/TLS tunel medzi klientom a autentiza?n?m serverom. Táto metóda bola vytvorená v?aka Cisco, Microsoft a RSA Security.PEAPV0/EAP-MSCHAPV2Je naj?astej?ie pou?ívaná forma PEAP. Vnútro autentizácie tvorí Microsoft's Challenge Handshake Authentication Protocol. PEAPv0/EAP-MSCHAPv2 je druh? ?iroko podporovan? EAP ?tandard na svete.PEAPV1/EAP-GTCBol vytvoren? firmou Cisco. Microsoft nikdy nepridala do svojho opera?ného systému podporu pre PEAPV1. Hlavne aj preto je len zriedka pou?ívan?.EAP-TLS (EAP – Transport Layer Security)Bezpe?nos? TLS (predt?m oficiálne a teraz neoficiálne SSL – Secure Sockets Layer) protokolu je ve?mi silná. Pou?íva tzv. PKI (Public key infrastructure – infra?truktúru verejn?ch k?ú?ov) na ochranu komunikácie pre RADIUS autentiza?n? server. Napriek tomu, ?e je tento protokol zriedka roz?íren?, je pova?ovan? ako jeden z najbezpe?nej?ích ?tandardov EAP. Univerzálne podporovan? v?etk?mi v?robcami wireless hardvéru a tie? Microsoftom.EAP-TTLS/MSCHAPV2 (EAP – Tunneled Transport Layer Security)Je to EAP protokol ktor? roz?íril EAP-TLS. Bol vytvoren? firmami Funk Software a Certicom. Síce nie je natívna podpora od opera?ného systému Microsoft Windows, je ?iroko podporovan? cez v?etky platformy. Na pou?ívanie je potrebné nain?talova? mal? program, napr. SecureW2.EAP-TTLS ponúka ve?mi dobrú ochranu. Klientsk? po?íta? nepotrebuje by? autentifikovan? cez certifika?nú autoritu - prihlásenie s PKI certifikátom na server, ale sta?í klasické spojenie server – klient. Toto zna?ne zjednodu?ilo procedúry nastavovania, preto?e v tomto prípade nie je potrebné aby boli nain?talované certifikáty na ka?dom klientovi.EAP-SIM?pecifick? mechanizmus pre vzájomnú autentizáciu a prijatie k?ú?ového spojenia pri pou?ívaní GSM-SIM alebo GSM-based mobiln?ch telefónnych sietí.V?mena správIEEE 802.11i roz?iruje IEEE 802.11-1999 t?m, ?e poskytuje robustné zabezpe?enie siete (RSN - Robust Security Network) s dvoma nov?mi protokolmi: 4-Way Handshake a Group Key Handshake. Tie vyu?ívajú overovacie slu?by a kontrolu prístupov?ch portov, sú opísané ?v IEEE 802.1X na vytvorenie a zmenu príslu?n?ch kryptografick?ch k?ú?ov. RSN je bezpe?nostná sie?, ktorá iba povo?uje tvorbu robustn?ch bezpe?nostn?ch sie?ov?ch asociácií (RSNAs), ktoré sú typom asociácie pou?ívan?m dvojicou staníc (STA) v prípade, ?e postup autentizácie alebo asociácie, medzi nimi zah?ňa 4-Way Handshake (4 cestn? handshake).Po?iato?n? proces overovania sa uskuto?ňuje, bu? pomocou vopred zdie?an?ého k?ú?a (PSK - pre-shared key), alebo na základe v?meny EAP prostredníctvom 802.1x (známy ako EAPOL, ktor? vy?aduje prítomnos? autentiza?ného servera). Tento proces zabezpe?uje, ?e klientská stanica (STA) je overená prístupov?m bodom (AP). Po PSK alebo autentizácii 802.1X, je generovan? zdie?an? tajn? k?ú?, nazvan? Pairwise Master Key (PMK). Pre odvodenie PMK z PSK, PSK je prelo?en? cez PBKDF2-SHA1 ako kryptografická hashovacia funkcia. Ak sa vykonala v?mena 802.1X EAP, PMK je odvodené od parametrov EAP vykonan?ch autentifika?n?m serverom.Kontrola prístupu:Domáce pou?itie: Zdie?an? k?ú? ako v prípade WEPWPA-Personal, WPA2-Personal Korporátne pou?itie:802.1X (EAP, Radius) WPA-Enterprise, WPA2-Eterprise V?stupom autentiza?ného procesu je ?Master key“ (MK) medzi stanicou a autentiza?n?m serverom. Master key je platn? len pre danú reláciuInicializácia k?ú?ovAutomatická: vyu?íva 802.1X Po skon?ení autentizácie 802.1X, stanica aj autentiza?n? server vypo?ítajú na základe Master Key tzv. Pairwise Master Key (PMK) Autentiza?n? server po?le PMK do AP Stanica a AP pou?ijú PMK na vygenerovanie PTK (Pairwise transient key) Na ?ifrovanie správ medzi AP a jednou STA Vypo?íta sa pomocou tzv. 4-way handshake protokolu Následne AP vygeneruje GTK Na ?ifrovanie ?broadcast“ správ od AP ku v?etk?m STA Manuálna WPA/WPA2-Personal PMK je odvodené z pre-shared key, ?alej sa postupuje rovnako ako v predo?lom bodeObr.?. SEQ Obrázok \* ARABIC 2 - Inicializácia k?ú?ov [1]4-way handshake protokolAP vysiela nonce hodnotu do STA (Anonce). Klient má teraz v?etky atribúty pre zostrojenie PTK.STA vysiela svoju vlastnú nonce hodnotu (SNonce) na AP spolu s MIC, vrátane autentifikácie, ?o je v skuto?nosti Message Authentication and Integrity Code (MAIC).AP vytvorí a odo?le GTK a poradové ?íslo spolu s inou MIC. Toto poradové ?íslo sa pou?ije v budúcom multicast alebo broadcast rámci tak, ?e prijímacie STA m??e vykonáva? základnú detekciu.STA po?le potvrdenie do prístupového bodu.Group key handshake protokolSkupinu do?an?ch k?ú?ov (GTK - Group Temporal Key), pou?it?ch v sieti m??e by? potrebné aktualizova? kv?li uplynutiu prednastaveného ?asova?a. Ke? prístroj opustí sie?, GTK je potrebné aktualizova?. Je to preto, aby sa zabránilo zariadeniu prijíma? akéko?vek multicast alebo broadcast správy z AP.AP vysiela novú GTK ka?dému STA v sieti. GTK je za?ifrovan? pomocou KEK, ktor? je priraden? k tomuto STA, a chráni dáta pred manipuláciu, za pou?itia MIC.STA potvrdzuje nov? GTK a odpovedá na AP.?tandard 802.11k – Assisted roaming802.11k redukuje ?as roamingu povolením klientovi r?chlej?ie ur?i?, ku ktorému AP sa pripoji?. Hlavn? cie? je doda? inteligentn? a?optimalizovan? zoznam susedov (Neighbor list) 802.11k podporovan?m klientom na optimalizáciu vyh?adávania kanálov, roamingu ?i vyu?itia batérie. 802.11k povo?uje klientom po?iada? o správu obsahujúcu informácie o?známych susedn?ch AP, ktoré sú kandidátmi pre roaming.Klient posiela po?iadavku o?zoznam susedn?ch AP – tzv. action paket, AP odpovie na rovnakej WLAN a rovnakom kanáli – tie? action paket. Z?tohto paketu potom klient vie, ktoré AP sú kandidátmi pre ?al?í roaming. Pou?itie 802.11k Radio resource management (RRM) umo?ňuje ú?inn? a?r?chly roaming.Klient teda nepotrebuje v?etky z 2,4 alebo 5 GHz kanálov na nájdenie AP – zni?uje to vyu?itie kanálov, ?ím sa zvy?uje bandwith kanálov, redukuje to aj ?as a?zlep?uje klientove rozhodnutia, zvy?uje ?ivotnos? batérie.Zoznam susedov obsahuje len susedov v?rovnakom pásme, obsahuje BSSID, kanál a?opera?né detaily susedn?ch AP. Pou?itie zoznamu susedov m??e obmedzi? potrebu pou?itia aktívneho ?i pasívneho skenovania. Zoznam susedov je generovan? dynamicky na po?iadanie a?nie je udr?iavan? na prepína?i. Dvaja klienti na rovnakom prepína?i, ale odli?n?ch AP m??u ma? odli?né zoznamy susedov. Klient posiela po?iadavku pre zoznam susedov iba po asociovaní s?AP. Ke? prepína? príjme po?iadavku o?zoznam susedov, preh?adá RRM tabu?ku susedov pre zoznam susedov na rovnakom pásme ako AP, s?ktor?m je klient asociovan?. Potom skontroluje susedov, aktuálne umiestnenie AP, históriu roamingu na prepína?i na redukciu zoznamu susedov k?6 na ka?dom pásme. ?tandard 802.11r – Fast transition roaming802.11r je ?tandard IEEE pre r?chly roaming. Tento ?tandard bol navrhnut? pre bezdr?tové LAN systémy na zr?chlenie autentifika?ného procesu. Handshake s?nov?m AP sa vykoná pred samotn?m roamingom (FT - fast transition), teda mobilná stanica poskytne novému AP nevyhnutné informácie potrebné na prechod do tohto AP. Handshake dovo?uje AP a?klientovi vytvori? tzv. Pairwise Transient Key (PTK) vopred. PTK obsahujú potrebné informácie a sú pou?ité u?klienta a?AP potom, ?o klient robí re-asociation request/response s?nov?m cie?ov?m AP. FT key hierarchia dovo?uje klientom robi? BSS (Basic service set) prechody medzi AP bez po?adovania autentifikácie na ka?dom AP. Autentifikácia teda prebieha len raz. 802.11r redukuje handoff medzi AP pri poskytovaní QoS a?bezpe?nosti.Existujú dve metódy pohybu klienta:Over the air FT roaming Klient komunikuje priamo s?cie?ov?m AP pomocou IEEE 802.11 autentifikácie pou?itím FT autentifika?ného algoritmu.Obr.?.3 - Over the Air Fast Transition Roaming [4]Over the Air Intra Controller Roam – AP1 a?AP2 sú pripojené na rovnak? kontrolór. Klient je asociovan? s?AP1 a?chce prejs? do AP2.Klient po?le na AP2 FT authentication request a?potom od neho príjme FT authentication response. Následne po?le na AP2 reassociation request a?potom od neho príjme reassociation response.Klient úspe?ne prejde do AP2.Obr.?.4 - Over the Air Intra Controller Roam [4]Over the Air Inter Controller Roam – AP1 a?AP2 sú pripojené na odli?né kontrolóry. Klient je asociovan? s?AP1 a?chce prejs? do AP2.Klient po?le na AP2 FT authentication request a?potom od neho príjme FT authentication response.Kontrolór, na ktor? je pripojen? AP1 po?le Pairwise Master Key (PMK) na druh? kontrolór (na ktorom je pripojen? AP2).Klient úspe?ne prejde do AP2.Obr.?.5 - Over the Air Inter Controller Roam [4]Over the DS (Distribution System) FT roaming Klient komunikuje s?cie?ov?m AP cez aktuálny AP. Komunikácia sa vykonáva prostredníctvom tzv.?FT action paketov medzi klientom a?aktuálnym AP a?potom je poslaná cez kontrolór.Obr.?.6 - Over the DS Fast Transition roaming [4]Over the DS Intra Controller Roam – AP1 a?AP2 sú pripojené na rovnak? kontrolór. Klient je asociovan? s?AP1 a?chce prejs? do AP2.Klient po?le na AP1 FT authentication request a?potom od neho príjme FT authentication response.Ke??e sú oba AP pripojené na rovnak? kontrolór, pred-autentifika?né informácie sú poslané z?kontrolóra na AP2.Následne po?le klient na AP2 reassociation request a?potom od neho príjme reassociation response.Klient úspe?ne prejde do AP2.Obr.?.7 - Over the DS Intra Controller Roam [4]Over the DS Inter Controller Roam - AP1 a?AP2 pripojené na odli?né kontrolóry. Klient je asociovan? s?AP1 a?chce prejs? do AP2.Klient po?le na AP1 FT authentication request a?potom od neho príjme FT authentication response.Kontrolór, na ktor? je pripojen? AP1 po?le Pairwise Master Key (PMK) na druh? kontrolór (na ktorom je pripojen? AP2).Klient úspe?ne prejde do AP2.Obr.?.8 - Over the DS Inter Controller Roam [4]SDN-WifiWireless termination point (WTP) – predstavuje nám Access Point.SD-RAN controller – predstavuje SDN kontrolér. Obsahuje viacero virtuálnych sietí alebo ?astí (sie?ová ?as? je virtuálna sie? s?SSID a?setom WTP). Sie?ové aplikácie nad kontrolórom, ktoré sú prístupné len pre sie?ové ?asti, ktor?m sú ur?ené.Pou?ívame 4 druhy abstrakcie a?to:Light virtual access point (LVAP) – Reprezentuje abstraktné spojenie medzi klientom a WTP. Ka?dé fyzické WTP má ulo?ené v?etky LVAP, ktoré sú na ňom pripojené. Premiestnením LVAP z jedného WTP na druhé WTP dosiahneme efektívny handover. V podstate si ka?d? klient v?aka LVAP myslí, ?e je v sieti sám, a to nám umo?ňuje, aby komunikovali WTP s klientom unicastom. LVAP obsahuje MAC adresu klienta, IP adresu klienta, lvap SSID a BSSID.Resource pool – abstrakcia je silne sp?tá s abstrakciou LVAP. Obsahuje kolekciu zdrojov v ?ase, frekvencií a vo?ného miesta v sieti. Najmen?ia jednotka je resource blok, ktor? je definovan? frekven?n?m pásmom, ?asov?m intervalom a WTP, na ktorom je prístupn?. Na v?ber resource bloku, ktor? uspokojí po?iadavky LVAP sa vyberá zo setu resource blokov z unionu vo?n?ch resource blokov podporovan?ch WTP. Samotn? v?ber robí kontrolór.Channel quality and interference maps – channel quality maps nám poskytujú celkov? preh?ad o?sieti v?podobe kvality kanálu vytvoreného medzi LVAP a?WTP cez resource bloky. Na zistenie kvality kanálu ukladáme silu signálu pomocou RSSI. V?rámci channel quality maps máme dve dátové ?truktúry a?to:User channel quality map (UCQM) – medzi LVAP a work channel quality map (NCQM) – medzi dvoma WTP.Obe sú trojdimenzionálne matice a?v?ka?dej je záznam v?decibeloch cez resource bloky.Port – dovo?uje kontrolóru prekonfigurova? alebo nahradi? ur?itú stratégiu ovládania medzi LVAP a?WTP. Ka?dé WTP má to?ko portov ko?ko má na sebe pripojen?ch LVAP. Samotn? port obsahuje tri veci a?to:p – sila prenosu,m – dostupné modulácie,a – MIMO konfiguráciu (po?et priestorov?ch prúdov).Prepojenie medzi jednotliv?mi abstrakciami m??eme vidie? na obrázku 9.Proximity detection – jedno z?mo?n?ch vyu?ití tejto technológie. Ide o?navigáciu vo vnútri budov, preto?e GPS vo vnútorn?ch priestoroch nedosahuje potrebnú kvalitu. Vyu?ívame schopnos? vedie? o?zariadeniach v?blízkosti WTP pomocou RSSI stopovacej aplikácie. Na obrázku 10 m??eme vidie? rozmiestnenie jednotliv?ch WTP a?pozícií testovacieho subjektu. Ka?d?ch 5 minút stál subjekt na pozícií P a?potom sa presunul na ?al?iu pozíciu. V?sledky testu m??eme vidie? na obrázku 11.Obr.?.9 - Diagram tried abstrakciíObr.?.10 – Rozmiestnenie v rámci poschodiaObr.?.11 - V?sledky testuSDN kontrolór RYURyu je open source SDN kontrolór, ktor? ponúka softvérové komponenty pou?ívané v?aplikáciách, ktoré vyu?ívajú technológiu SDN. V?vojári m??u v?aka nemu vytvára? nov? mana?ment siete ?i riadiace aplikácie. Ryu podporuje r?zne protokoly pre správu siete, napr. OpenFlow protokol (Ryu podporuje aj najnov?iu verziu OpenFlow 1.4). Ryu teda m??e vytvára? a?posiela? OpenFlow správy a?taktie? rozobera? a?spracováva? prichádzajúce pakety. SDN kontrolór Ryu je postaven? na programovacom jazyku Python.Na obrázku 12 je zobrazená architektúra Ryu.Obr.?.12 - Architektúra Ryu [2]Ako m??eme vidie? na obrázku, Ryu podporuje ve?a r?znych protokolov, okrem OpenFlow aj OF-Config, Open vSwitch Database Management Protocol (OVSDB), NETCONF a XFlow (Netflow and Sflow). ?o sa t?ka OpenFlow kontrolóra, je to jedna z?najd?le?itej?ích sú?astí Ryu, preto?e je zodpovedn? za správu OpenFlow prepína?ov. Ryu-Manager slú?i na po?úvanie na konkrétnej IP adrese a?porte,?tak sa m??e k?nemu pripoji? OpenFlow prepína?. App-Manager je základn? komponent pre v?etky aplikácie Ryu.SDN kontrolór FloodlightFloodlight je open source SDN kontrolór, ktor? je postaven? na programovacom jazyku Java. Tento kontrolór tie? podporuje protokol OpenFlow, av?ak vie zvládnu? aj zmie?ané OpenFlow a?non-OpenFlow siete. Floodlight je sú?as?ou Big Switch projektov a?vie pracova? s?virtuálnymi aj fyzick?mi OpenFlow prepína?mi. Floodlight pou?íva ako základ kontrolór Beacon, av?ak v?porovnaní s?t?mto kontrolórom sa Floodlight v?razne rozrástol, pri?om má dokonalej?ie funkcie a?lep?í v?kon.Floodlight má modulárnu architektúru, pri?om zah?ňa r?zne moduly, ako napr. správa topológie, správa zariadení a?koncovej stanice, v?po?et cesty, infra?truktúru pre prístup na web a?iné. Základné komponenty architektúry sú okrem OpenFlow protokolu aplikácie (Rest-API, Module applications) a slu?by (Core-services, Utility-services, Internal services). Architektúra je zobrazená na obrázku 13.Obr.?.13 - Architektúra Floodlight [3]WLAN s Odin architektúrouLight virtual AP (LVAP) – Reprezentuje abstraktné spojenie medzi klientom a AP. Ka?dé fyzické AP má ulo?ené v?etky LVAP, ktoré sú na ňom pripojené. Premiestnením LVAP z jedného AP na druhé AP dosiahneme efektívny handover. V podstate si ka?d? klient v?aka LVAP myslí, ?e je v sieti sám, a to nám umo?ňuje aby komunikovali AP s klientom unicastom. LVAP obsahuje MAC adresu klienta, IP adresu klienta, lvap SSID a BSSID.Odin Master – V?na?om prípade openflow aplikácia nad kontrolórom. Je implementovan? nad Floodlight OpenFlow kontrolórom. M??e vytvori?, prida? alebo odobra? LVAP a??iada? ?tatistiky z AP, updatova? jednotlivé forward tabu?ky a?podobne. Odin Agent – Aplikácia nad fyzick?m AP. Okrem pre SDN klasick?ch forward tabuliek doká?u spracova? LVAP a?uklada? informácie o?klientoch ktor? sú naňho pripojen? (pou?íva tzv. radiotap headers). Ako to funguje – Odin agenti zachytávajú probe request od klientov. V?prípade, ?e zachytí probe request správu od klienta, ktorého nepozná prepo?le túto správu na Odin mastera. Pokia? pre tohto klienta e?te nebol vytvoren? LVAP, tak ho master vytvorí a?zapí?e na agenta. Toto m??eme vidie? aj na obrázku 14.Obr.?.14 – Zachytenie správy od klientaAgent potom odpovedá správou probe response s?unikátnym BSSID, ktor? mu dodá master. Potom nasleduje autentifikácia a?asociácia. Autentifikácia prebieha tak, ?e si agent ulo?í do LVAP k?ú? na ?ifrovanie správ, na ktorom sa pri autentifikácií dohodne s?klientom. Po asocíacii agent oznámi ?i bol povolen? prístup do siete pre klienta, alebo nie.Handover – prebieha tak, ?e master získava od agentov ?tatistiky o?klientoch z?probe správ, ktoré porovnáva so ?tatistikou od?agenta na ktorom sú klienti pripojen?. V?prípade, ?e zistí ?e niekde má klient lep?í signál, po?le správu agentovi, na ktorom je LVAP ulo?ené na preposlanie tohto LVAP masterovi, ktor? ho po?le na druhé AP, ktoré má lep?í signál, spolu so správou na následné zmazanie tohto LVAP, a?agentovi, na ktor? sa má preposla? LVAP, aby pridal nové LVAP, ktoré mu master po?le, ?o m??eme vidie? na obrázku 15. Obr.?.15 – HandoverTestovanie handoveru – na testovanie handoveru bola pou?itá sie? s?jedn?m kontrolórom, dvoma AP a?jedn?m pou?ívate?om. Pri teste boli s?ahované dáta. Na obrázku 16 vidíme handover v?klasickej sieti 802.11. D?sledkom odpojenia a?op?tovného pripojenia do siete vidíme, ?e priepustnos? klesla. Na obrázku 17 m??eme vidie? handover v?SDN sieti pri pou?ití LVAP. Priepustnos? neklesne z?d?vodu, ?e si jednotlivé AP iba vymenia LVAP daného pou?ívate?a bez toho, aby o?tom vedel, pri?om nedochádza k?odpojeniu zo siete. Obr.?.16 – 802.11 handoffObr.?.17 – LVAP handoffVirtualizácia Wifi sieteVirtualizácia Wifi siete – m??eme si ju predstavi? ako viacero fyzick?ch AP, ktoré poskytujú jednu slu?bu, zapojen?ch do jedného virtuálneho AP. Na obrázku 18 m??eme vidie? viacero fyzick?ch (na najni??ej vrstve) AP zapojen?ch do viacer?ch virtuálnych AP (na najvy??ej vrstve). V?etky virtuálne AP v?rámci jednej siete majú rovnaké ESSID a?BSSID. Na obrázku vidíme, ?e vBS#A1 a vBS#A2 patria do jednej siete.Obr.?.18 – Model Wifi network virtualizationFunk?n? model navrhnutej architektúry – Na obrázku 19 m??eme vidie? tento návrh, pri?om sa skladá z?kontrolóra, prepína?u a?samotného zoznamu virtuálnych AP. Tento zoznam vytvára kontrolór, ako aj samotnú logiku asociácie spolu s?kontrolórom BS pre jednotlivé BS, s?ktor?m potom komunikuje. Ka?dé fyzické AP má rovnaké BSSID,?ESSID a?MAC adresu. Lí?ia sa len v?kanále. Kontrolór vyberá, na ktoré fyzické AP sa pou?ívate? pripojí pod?a toho, ko?ko je na jednotliv?ch fyzick?ch AP pripojen?ch pou?ívate?ov, pri?om vyberie to s?najmen?ím po?tom.Obr.?.19 – Funk?n? model navrhnutej architektúryPripojenie pou?ívate?a do siete – m??eme vidie? na obrázku 20. Pou?ívate? (STA#1) posiela probe request správu do siete. V?etky fyzické AP ktoré túto správu dostanú ju prepo?lú na BS kontrolór, ktor? následne prepo?le v?etky tieto requesty sie?ovému kontrolóru. Ten následne vyberie jedno fyzické AP ktorému sa má priradi? dan? pou?ívate?. Nasleduje autentifikácia so sie?ov?m kontrolórom a?následná asociácia, v?mena k?ú?om a?následn? data plane (na obrázku m??eme vidie? aj PTK ktoré je vytvorené 4-way handshakom medzi pou?ívate?om a?BS). Cel? proces pripojenia pou?ívate?a do siete vidíme preh?adne na obrázku 20.Handover – vyvoláva sie?ov? kontrolór, ktor? aby sme zabránili strate údajov po?le openflow sieti aby za?al pripravova? správy. Zo starého BS získa sie?ov? kontrolór stav a?ten priradí novému BS. Následne si sie?ov? kontrolór prekonfiguruje cestu pre pou?ívate?a, a?po?le starému BS správu Handover request, ktor? po?le pou?ívate?ovi správu o?zmene kanála. Potom kontrolór po?le openflow sieti nech prestane pripravova? správy a?za?ne posiela? správy cez nov? BS pou?ívate?ovi. Nov? BS potvrdí handover sie?ovému kontrolóru a?t?m sa skon?il handover. Toto funguje pri jednocestnom móde. Máme v?ak k?dispozícií aj viaccestn? mód. Ten funguje tak, ?e duplikuje pakety a?preposiela ich do starého BS aj do nového BS zároveň, tak?e zariadenie m??e hne? zmeni? BS. Po úspe?nom handoveri sa znova prechádza na jednocestn? mód. Cel? priebeh handoveru m??eme vidie? na obrázku 21.Obr.?.20 – Pripojenie pou?ívate?a do sieteObr.?.21 – Priebeh handoveruNávrhKomunika?n? protokolScenár prihlásenia bez autentifikácieNastavi? open flow tabu?ky pre probe správy – Ako prvé je potrebné nastavi? aby sa preposielali v?etky probe správy na HDS server. Toto docielime nastavením pomocou AFCP kontrolór ktor? prepí?e flow tabu?ky na jednotliv?ch WTP. Nastavenie vyh?adávacieho pravidla na probe request správu (v 802.11 typ 00 ?i?e mgmt a?subtype 0100).Nastavenie akcie na preposlanie cez port ktor?m sme pripojen? k?danému WTP (napríklad output:2 ?ím nám WTP prepo?le správu na port 2). Nastavi? open flow tabu?ky pre autentifika?né správy – Nastavujú sa rovnako ako pri probe správe len s?rozdielom v?prvom kroku – namiesto 0100 sa pou?ije 1011. Ke??e pou?ívame nezabezpe?en? ?t?l pripojenia, neoverujú sa ?iadne k?ú?e.Nastavenie open flow tabu?ky pre potvrdenie autorizácie – Op?? prebieha rovnako ako pri vy??ie spísan?ch správach, a? na kód, ktor? je v?tomto prípade 0000 pre Association request. V?prípade ze prebehne asociácia v?poriadku a?stanica sa m??e pripoji? do siete, ulo?í si HDS server pre dané VAP na ktorom fyzickom WTP je stanica pripojená.Prijatie probe request správy od WTP– V?prípade ?e sa chce stanica pripoji? do siete po?le probe request správu, pomocou ktorej zis?uje dostupné siete. Ak WTP zachytí probe request správu, prepo?le ju pod?a vopred stanoveného pravidla vo flow tabu?kách na HDS server.V?ber WTP ktor? má komunikova? so zariadením – Po zachytení probe správy na HDS servery musí by? vybrané jedno WTP ktoré bude komunikova? so zariadením. Po v?bere daného WTP sa mu po?le VAP pre stanicu s?ktor?m má komunikova?. Komunikácia pritom prebieha unicastovo.Poslanie ACK pri asociácií HDS serveru – Po úspe?nom prebehnutí asociácie sa posiela HDS serveru potvrdenie. V?prípade ?e dostane po autentifikácií WTP od zariadenia správu Association request prepo?le HDS serveru túto správu.Vytvorenie virtuálneho AP(VAP) – ke??e pou?ívame sie? bez zabezpe?enia, nemá zmysel ?aka? s?vytvorením VAP na samotné wep/wpa správy. V?prípade ?e by sme pou?ili wep/wpa, museli by sme ?aka? na priebeh autentifikácie ke??e tá prebieha cez HDS server v?ktorom sa ulo?ia autentifika?né informácie aby nemuselo dochádza? k?odpojeniu pou?ívate?a od siete a?op?tovnému pripojeniu. Následne po vytvorení VAP WTP po?le HDS serveru správu ASLAN VAP ack o?vytvorení VAP.Nastavenie cesty cez flow tabu?ky pomocou kontrolóra cez AFCP.Po asociácií prebieha následne dátov? prenos.Obr.?.22 – V?mena správ pri prihlasovaníScenár prihlásenia s?autentifikáciou pre RADIUS serverStanica po?le Probe request do WTP.WTP odo?le ASLAN Probe request do HDS.HDS sa rozhodne, ktoré WTP sa so stanicou spojí (ur?ujúci faktor je najlep?ia kvalita signálu).HDS odo?le odpove? na WTP ASLAN Probe response.Probe response sa po?le z?WTP stanici.Stanica po?iada o?autentifikáciu (Authentification request).WTP po?iada stanicu o?identitu (Identity request)Stanica po?le username, ktoré sa cez WTP prepo?le do RADIUS server.RADIUS prepo?le cez WTP Authentification challenge.Stanica prepo?le cez WTP Authetification response.RADIUS server prepo?le cez WTP Authentification success.Stanica po?le cez WTP Authentification challenge do RADIUS server.RADIUS cez WTP odo?le Authentification response.Stanica odo?le cez WTP Successful authentification do RADIUS server.RADIUS server odo?le Aslan Successful authentification na HDS server.Pokra?uje sa ako v?scenári prihlásenia.Obr.?.23 – V?mena správ pri autentifikáciiScenár reasociáciaZistenie strácajúceho sa signálu – Z?ka?dého WTP dostáva periodicky HDS server správy o?sile signálu vo?i zariadeniam. HDS server zistí z?periodick?ch správ od WTP ?e na inom WTP dosahuje lep?í signál.Rozhodnutie o?WTP na ktor? sa má robi? reasociácia – V?prípade ?e máme v?sieti WTP s?rovnak?m kanálom, tak sa na chví?u zosilní signál na tomto WTP na ?as reasociácie. V?inom prípade vyberáme WTP ktoré má najv???iu silu signálu.Preposlanie VAP novému WTP – Novému WTP sa prepo?le VAP daného zariadenia. Nové WTP si ho ulo?í.Nastavenie flow tabuliek na novom WTP – HDS server cez AFCP nastaví pomocou kontroléra flow tabu?ky na novom WTP.Oboznámenie zariadenia so zmenou kanála – V?prípade ?e je nutná zmena kanála sa oboznámi stanicu o?zmene kanála na ktorom má komunikova? s?WTP. Potvrdenie prepojenia nového WTP so zariadením – V?prípade, ?e sa stanica úspe?ne spojí s?nov?m WTP, po?le nové WTP HDS serveru potvrdenie o?úspe?nom prechode zariadenia. Zmazanie záznamu flow tabuliek na starom WTP - V?prípade, ?e prebehla reasociácia úspe?ne, HDS server po?le správu AFCP aby pomocou kontroléra zmazal na starom WTP záznamy vo flow tabu?kách o?stanici. Zru?enie VAP na starom WTP – V?prípade, ?e prebehla reasociácia úspe?ne, po?le HDS server starému WTP správu na zru?enie VAP zariadenia.Obr.?.24 – V?mena správ pri reasociáciiScenár odhlásenia:Odhlásenie – WTP odo?le informácie o?zariadení, ?e chce ukon?i? komunikáciu.Správa odhlásenia – odosiela sa cez WTP na HDS server. Správa je typu mgmt a?podtyp je 1010 ?o znamená Disasociácia. Tento paket je jednocestná komunikácia (?o znamená, ?e nepotrebuje potvrdenie, alebo odozvu) a?musí by? akceptovaná. Takáto správa u?iní efekt ihne? po prijatí.Prijatie správy odhlásenia – HDS príjme správu, zma?e polo?ku o?zariadení vo svojej tabu?ke.Zru?enie ciest – na AFCP sa odo?le správa, aby sa zru?ili cesty cez flow tabu?ky do VAP zariadenia, ktoré sa odhlasuje.Zru?í sa VAP a?komunikácia je zru?ená.Obr.?.25 – V?mena správ pri odhláseníScenár monitorovaniaMonitorovanie – WTP monitoruje v?etky zariadenia v?sieti.Posielanie stavov?ch správ - V?etky WTP periodicky posielajú správy o?stave signálu vo?i zariadeniam v?sieti. Tieto správy sa posielajú HDS serveru.Ukladanie stavov – HDS server v?etky prijaté správy o?stave signálu porovnáva. Uchováva si v?dy posledn?ch 5 stavov z?WTP ku ktorému je daná stanica pripojená.Rozhodnutie o?zmene WTP – V?prípade ?e u? signál z?WTP ku ktorému je pripojené zaradenie slabne (posledn?ch 5 stavov ukazujú pokles signálu) a?HDS zistí ?e je v?sieti iné WTP ktoré má za posledn?ch 5 stavov lep?iu intenzitu signálu, rozhodne sa HDS o?handovery na nové WTP.Scenár reportovania:Reportovanie – WTP odosiela informácie ko?ko má zariadení a?aká je sila signálu jednotliv?ch zariadení.Odosielanie reportovacích správ – WTP periodicky odosielajú správy HDS serveru o?stave pripojen?ch zariadení.Tabu?ka stavov – prijaté stavy na HDS servery sa ukladajú do tabuliek, ktoré majú 30 sekundové ?asova?e ?ivotnosti.Rozhodovanie – HDS sa rozhoduje pod?a informácií ?i spravi? prechod.Obr.?.26 – V?mena správ pri reportovaníScenár pád WTPZistenie pádu WTP – HDS server o?akáva periodicky hlásenie od WTP v?sieti. V?prípade, ?e sa WTP nehlási po?le mu HDS server správu (ASLAN asleep). Ak na túto správu WTP neodpovie nastal pád stanice.Zistenie v?etk?ch VAP ktoré boli pripojené na WTP - HDS server pri páde stanice musí okam?ite reagova?, a?sna?í sa nájs? vhodné WTP pre ka?dú stanicu, ktorá bola pripojená na nereagujúce WTP. Ako prvé sa h?adajú WTP ktoré boli v?rámci jedného kanála. Ak takéto WTP nie je k?dispozícií sna?í sa pripoji? stanicu k?WTP ktoré je ako druhé v?tabu?ke signálov.Presmerovanie staníc na WTP – HDS server po?le správu novému WTP na vytvorenie v?etk?ch VAP ktoré majú by? pripojené z?nereagujúceho WTP.Nastavenie flow tabuliek na novom WTP – HDS server ?tandardnou cestou nastaví flow tabu?ky na novom WTP.Prenos dát.Obr.?.27 – V?mena správ pri páde WTPNávrh protokoluV?prípade správy ASLAN VAP create pou?ívanej na vytvorenie VAP na danom WTP pou?ívame vopred stanoven? protokol, ktor? vidíme na obrázku vy??ie. V?prípade ostatn?ch správ pou?ívame protokol, ktor? vidíme na obrázku ni??ie. Obr.?.28 – Návrh VAP a správWTP - Wireless Termination PointPersonal APPersonal AP je experimentálny projekt, ktor? priná?a v?razné zlep?enia do problematiky r?chleho a plynulého prechodu medzi prístupov?mi bodmi. Autori projektu odstránili nutnos? reasociácie klienta pri roamingu z jedného prístupového bodu na druh?.Klasické prístupové body sú rozdelené na dva základné typy – WTP a AC. AC funguje ako centrálny riadiaci bod celého systému, prípadne podsystému ak sa v ňom nachádza viacero tak?chto radiacich bodov. WTP predstavuje prístupov? bod, ktor? má implementovanú v???inu funkcií klasického prístupového bodu pou?ívaného v bezdr?tov?ch systémoch. Tak?to sp?sob rozdelenia funkcionality sa naz?va ?Local MAC“.Okrem spomenutého sp?sobu existujú aj ?al?ie: ?Split MAC“, ktor? sa vyzna?uje t?m, ?e na WTP zariadení sú implementované iba funkcie, na vykonanie ktor?ch je potrebné minimálne oneskorenie a ?Remote MAC“, kde v?etka funk?nos? prístupového bodu je implementovaná na strane centrálneho riadiaceho bodu AC.Hlavnou my?lienkou celého tohto sp?sobu riadenia prevádzky v sieti je, ?e ka?d? klient pripojen? do systému má pridelen? vlastn? ?virtuálny― prístupov? bod. V?etky prístupové body v sieti pravidelne posielajú hlásenia o svojich pripojen?ch klientoch. Ak nastane situácia, ?e je vhodné vykona? roaming mobilného ú?astníka na nov? prístupov? bod, star? prístupov? bod odo?le v?etky informácie o ú?astníkovi novému. Následne nov? prístupov? bod takmer ihne? za?ne pracova? rovnako ako star?, t.j. s rovnak?m BSSID a pod. V?hodou je, ?e mobiln? klient nepocíti ?iadnu zmenu. To znamená, ?e ka?d? klient má v podstate svoj vlastn? ?virtuálny― prístupov? bod, s ktor?m je asociovan? a ktor? si WTP zariadenia doká?u medzi sebou posiela?. Ve?kou v?hodou Personal AP je, ?e nepotrebuje ?iadne dodato?né zmeny na strane ú?astníka.Remote MACRozdelenie Remote MAC je charakteristické t?m, ?e v?etky funk?né prvky sú implementované na centrálnom bode riadenia AC.WTP zariadenia slú?ia v podstate len na preposielanie dát AC. Ich ?al?ou funkciou je zbieranie informácií o ú?astníkoch pohybujúcich sa v sieti. Tieto informácie následne posielajú pomocou navrhnutého protokolu centrálnemu riadiacemu bodu AC. Na základe t?chto informácií si AC vytvára graf susedov, ktor? mu slú?i na rozhodovanie, ktoré WTP zariadenie pou?i? pri roamingu.WTP zariadenia tak zohrávajú d?le?itú úlohu v navrhovanej architektúre. Predstavujú prepojovací systém medzi riadiacou jednotkou a mobiln?mi klientskymi stanicami. Zabezpe?ujú ich vzájomnú komunikáciu a riadia prístup do siete. Zároveň prepájajú dve sie?ové architektúry a to bezdr?tov? systém ?tandardu 802.11 a pevnú sie? ?tandardu 802.3.Virtual APMy?lienkou navrhovaného sp?sobu riadenia prevádzky v sieti je, ?e ka?d? klient pripojen? do systému má pridelen? vlastn? ?virtuálny“ prístupov? bod. Jedine?nos? prístupového bodu je ur?ená na základe BSSID, ktor? predstavuje adresu prístupového bodu. Ke??e ka?dá sie?ová karta má k dispozícií iba jednu MAC adresu, je teda potrebné vytvori? virtuálne rozhrania pre tieto ú?ely. T?m zabezpe?íme dostatok komunika?n?ch adries pre v?etk?ch pripojen?ch klientov. BSSID, ktoré je pridelené mobilnej stanici, vyu?íva stanica od prvého prihlásenia do siete a? po odpojenie a teda v rámci mobility adresa ?cestuje s?ňou“.Príklady názvov rozhraní v?prostredí Linux:wl0 – predstavuje fyzické rozhraniewl0.1 – predstavuje virtuálne rozhranie s?ID 1 nad fyzick?m rozhraním wl0wl0.2 – predstavuje virtuálne rozhranie s?ID 2 nad fyzick?m rozhraním wl0Virtuálne rozhrania m??u ma? odli?nú MAC adresu, ale nem??u vysiela? na inom vysielacom kanáli ako je nastavené fyzické rozhranie patriace k?danému virtuálnemu rozhraniu.Monitoring na WTPKa?dé WTP zariadenie si uchováva informácie o v?etk?ch staniciach v jej dosahu. Tieto údaje získava z monitorovania bezdr?tovej siete. Konkrétne sa jedná o riadiace rámce 802.11, ktoré zachytáva pomocou rozhrania v monitorovacom re?ime. Získané hodnoty posiela riadiacej jednotke. AC spracuje prijaté informácie a ur?í, aké mechanizmy sa majú vykona?.Na monitorovanie stavu siete sa dajú mana?mentové rámce, ktoré v sebe nesú informáciu o indexe sile signálu (RSSI), ktor? je prijíman? na prijíma?i – t.j. bezdr?tovej sie?ovej karte WTP zariadenia. Tieto ?tatistiky sa vyu?ívajú pre rozhodovanie o uskuto?není prechodu medzi prístupov?mi bodmi. Zo v?etk?ch mana?mentov?ch rámcov prijat?ch na monitorovacom rozhraní sa vyberie informácia o sile signálu (RSSI) pre dané STA a posiela sa na AC vo forme ?tatistického údaju. V správe je STA identifikovaná svojou MAC adresou.Ak AC zistí pomocou informácií z monitorovania siete, ?e daná stanica má prejs? na in? WTP za?ne vykonáva? prechod. Najprv oznámi novému WTP zariadeniu, ?e mobilná stanica sa dostala do jeho dosahu a má tam najlep?í signál. Nové WTP, t.j. prístupov? bod, na ktor? by sa mala stanica presunú?, odpovie, ?i je schopn? prija? túto stanicu. V prípade akceptovania mobilnej stanice AC po?iada p?vodn? prístupov? bod, ktor? sa staral o komunikáciu stanice, aby zaslal kontext pre danú stanicu. AC prepo?le túto informáciu novému WTP a následne presmeruje dátovú prevádzku na neho. Na základe tejto informácie si nové WTP nastaví po?adované parametre a za?ne komunikova? so stanicou.V?prípade SDN sietí presmerovanie dátovej prevádzky pri prechode klienta medzi WTP sa rie?i aktualizáciu pravidiel vo Flow tabu?kách na SDN prepína?och. AC musí najprv po?iada? SDN kontrolóra, aby po rozhodovaní vygeneroval príslu?né riadiace správy pre prepína?e pre efektívne presmerovanie dátového toku patriaceho k?danému STA smerom na nové WTP.Ke??e komunika?n?m médiom je vzduch, stanica sa nestará, kde sa nachádza WTP, cez ktoré momentálne pristupuje do siete, ale komunikuje s ním na základe adresy – BSSID. Roaming je preto úplne transparentn? a stanica nijak nepocíti zmenu, preto?e komunikuje stále s tou istou cie?ovej fyzickou adresou druhej vrstvy.Obr.?.29 - Sekven?n? diagram roaminguNávrh architektúry WTPNavrhnutá architektúra vnoreného systému pre WTP sa skladá z?nasledovn?ch blokoch:Systémov? ?ip (SoC) – obsahuje CPUPam?? RAMPam?? Flash vo ve?kosti minimálne 8MBProgramovate?n? prepína? s?podporou VLAN a?TrunkVnútorn? bezdr?tov? modul s?podporou pre virtuálne bezdr?tové rozhraniaUSB modul + aspoň 1 USB portExtern? bezdr?tov? modul pripojen? k?WTP cez rozhranie USB s?podporou monitorovacieho re?imuArchitektúra bola navrhnutá tak, aby bola kompatibilná s?existujúcim hardvérom Asus RT-N16 a?opera?n?m systémom (firmvérom) OpenWRT.Obr.?.30 - Bloková schéma architektúry WTPAFCP – Additional Functionality of Control PlaneRiadiaca rovina (Control Plane)V?smerovaní je riadiaca rovina sú?as?ou architektúry smerova?a, ktorá sa zaoberá kreslením topológie siete alebo informáciami v?smerovacích tabu?kách, ktoré hovoria, ?o robi? s?prijat?mi paketmi. Funkcie riadiacej roviny be?ia v?architektonickom riadiacom elemente. Hlavnou funkciou je ur?i?, ktoré cesty budú v?hlavnej smerovacej tabu?ke. Multicast smerovanie m??e vy?adova? ?al?iu smerovaciu tabu?ku pre multicast cesty. Riadiaca rovina zah?ňa funkcie konfigurácie a?správy systému. Oby?ajne sa riadiaca rovina nachádza vo firmvéri smerova?a spolu s?dátovou rovinou, v?SDN sie?ach je v?ak implementovaná v?softvéri. Implementácia riadiacej roviny v?softvéri umo?ňuje dynamick? prístup a?administráciu siete, poskytuje programov? prístup, a?teda robí administráciu siete flexibilnej?ou. Správca siete tak m??e riadi? prevádzku siete z?centralizovanej riadiacej konzoly a?m??e meni? pravidlá prepína?ov v?sieti (napr. prideli? vysokú prioritu ?i blokova? niektoré typy paketov). Flow tabu?kyOpenFlow definuje tri typy tabuliek. Flow tabu?ka smeruje pakety na konkrétny tok a??pecifikuje funkcie, ktoré majú by? s?paketmi vykonané. Flow tabuliek m??e by? viac, pri?om fungujú tzv. zre?azen?m spracovaním. Flow tabu?ka m??e nasmerova? tok do Group tabu?ky, ktorá m??e vyvola? r?zne akcie vpl?vajúce na jeden alebo viacero tokov. Meter tabu?ka m??e vyvola? r?zne s?v?konom súvisiace akcie na tok.Obr.?.31 – OpenFlow prepína? [1]Komponenty Flow tabuliekKa?d? paket vstupujúci do SDN prepína?a prechádza cez jednu alebo viaceré Flow tabu?ky. Ka?dá Flow tabu?ka obsahuje záznamy pozostávajúce zo 6 komponentov:Match fields – slú?i na v?ber paketov, ktoré zodpovedajú hodnotám v?poliach.Priority – relatívna priorita záznamov tabu?ky.Counters – aktualizované pre zodpovedajúce pakety, sú to r?zne typy ?asova?ov.Instructions – akcie, ktoré treba vykona?, ak nastane zhoda paketu so záznamom v tabu?ke.Timeouts – maximálny ?as ne?innosti predt?m ako je tok expirovan?. Cookie – neprieh?adná hodnota dát vybraná kontrolórom, ktorá m??e by? pou?itá na filtrovanie ?tatistík tokov, modifikácie tokov a?vymazania tokov. Flow tabu?ka m??e zah?ňa? tzv. ?table-miss“ záznam, ktor? má najmen?iu prioritu (0) a?ka?dé pole z?Match Fields má hodnotu ?wildcard“, ?o znamená, ?e zodpovedá ?ubovo?nej hodnote. Komponent Match Fields sa skladá z?nasledujúcich polí:Ingress Port – identifikátor portu prepína?a, na ktor? paket pri?iel, pri?om to m??e by? fyzick? alebo prepína?om definovan? virtuálny port.Ethernet Source and Destination Addresses – zdrojová a?cie?ová MAC adresa.IPv4 or IPv6 Protocol Number –??íslo protokolu indikujúce nasledujúcu hlavi?ku v?pakete.IPv4 or IPv6 Source Address and Destination Address – zdrojová a?cie?ová IP adresa.TCP Source and Destination Ports – zdrojov? a?cie?ov? TCP port.User Datagram Protocol (UDP) Source and Destination Ports - zdrojov? a?cie?ov? UDP port.Predchádzajúce polia sú podporované ka?d?m OpenFlow prepína?om. Niektoré OpenFlow prepína?e m??u v?ak podporova? aj nasledujúce polia:Physical Port – pou?íva sa na ozna?enie fyzického portu, ke? je paket prijat? na logickom porte. Metadata – ?al?ie informácie, ktoré m??u by? posunuté z?jednej tabu?ky do inej po?as spracovávania paketu. Ethernet Type – typ Ethernetu.VLAN ID and VLAN User Priority –?polia v IEEE 802.1Q Virtual LAN hlavi?ke.IPv4 or IPv6 DS and ECN – polia diferencovan?ch slu?ieb a?explicitn?ch notifikácií zahltenia.Stream Control Transmission Protocol (SCTP) Source and Destination Ports – zdrojov? a?cie?ov? SCTP port.Internet Control Message Protocol (ICMP) Type and Code Fields – ICMP polia.Address Resolution Protocol (ARP) OpcodeSource and Target IPv4 Addresses in Address Resolution Protocol (ARP) Payload – zdrojové a cie?ové IPv4 adresy v?ARP.IPv6 Flow LabelICMPv6 Type and Code fields – ICMPv6 polia.IPv6 Neighbor Discovery Target Address – v IPv6 správe o?zistení suseda.IPv6 Neighbor Discovery Source and Target Addresses – nastavenia adresy v?IPv6 správe o?zistení suseda na linkovej vrstve. Multiprotocol Label Switching (MPLS) Label Value, Traffic Class, and Bottom of Stack (BoS) – polia vo vrchnom labeli MPLS label zásobníka.Komponent Instructions pozostáva zo sady in?trukcií vykonávan?ch, ak paket zodpovedá záznamu. Existujú 2 typy in?trukcií – akcie a?sady akcií. Akcie opisujú posielanie paketov, modifikácie paketov a?operácie spracúvania Group tabu?ky. OpenFlow zah?ňa tieto akcie:Output – poslanie paketu na konkrétny port.Set-Queue - nastaví ID fronty pre paket. Ke? je paket poslan? na port, ID frontu ur?uje, ktor? front pripojen? k?tomuto portu sa pou?ije pre plánovanie a?posielanie paketu. Group – spracovanie paketu cez ?pecifickú skupinu.Push-Tag/Pop-Tag – vlo?í alebo odstráni tag pre VLAN alebo MPLS paketSet-Field – r?zne akcie, ktoré sú identifikované pod?a typu po?a, modifikujú hodnoty príslu?n?ch hlavi?kov?ch polí paketu.Change-TTL – r?zne akcie, ktoré modifikujú IPv4 Time To Live (TTL), IPv6 Hop Limit alebo MPLS TTL v?pakete.Sady akcií sú zoznamy akcií spojen?ch s?paketom, ktoré sú nahromadené, k?m je paket spracovávan? ka?dou tabu?kou a?vykonávané, ke? paket vystupuje zo zre?azeného spracovania. Existujú ?tyri typy:Direct packet through pipeline – in?trukcia Goto-table smeruje paket do nasledujúcej tabu?ky zre?azeného spracovania. In?trukcia Meter smeruje paket do ?pecifického mera?a.Perform action on packet – akcie s?paketom m??u by? vykonávané, ke? paket zodpovedá záznamu v?tabu?ke.Update action set – zlú?enie akcií do sady akcií pre dan? paket v?danom toku, alebo zru?enie v?etk?ch akcií v?sade akcií.Update metadata – hodnota metadát m??e by? spojená s?paketom, ?o sa pou?íva na prenos informácií z?jednej tabu?ky do inej.Flow tabu?ky - zre?azené spracovávanieKa?d? SDN prepína? obsahuje jednu alebo viac Flow tabuliek. Ak ich obsahuje viac, sú ?íslované od 0 a?sú?zre?azené za sebou. Obr.?.32 – Spracovanie paketov cez Flow tabu?ky [1]Ke? je paket predlo?en? tabu?ke pre porovnanie so záznamami, vstup pozostáva z?paketu, identity vstupného portu, príslu?nej hodnoty metadát a?príslu?nej sady akcií. Pre prvú tabu?ku (tabu?ka 0) je hodnota metadát prázdna a?sada akcií je nulová. Potom proces prebieha nasledovne:Nájdenie zhodného záznamu z?najvy??ou prioritou vo Flow tabu?ke. Ak tu nie je zhoda so ?iadnym záznamom a?neexistuje ?table-miss“ záznam, paket je zahoden?. Ak tu je zhoda iba s ?table-miss“ záznamom, vykoná sa jedna z?troch akcií:Paket sa po?le na SDN kontrolór, ?o povolí kontrolóru definova? nov? tok pre tento a?jemu podobné pakety, alebo rozhodnú? o?zahodení paketu.Paket sa po?le k nasledujúcej Flow tabu?ke v?re?azci.Paket sa zahodí.Ak sa nájde zhoda s?in?m záznamom okrem ?table-miss“ záznamu, záznamu sa priradí najvy??ia priorita a?m??u nasledova? nasledujúce akcie:Aktualizujú sa po?ítadlá spojené s?t?mto záznamom.Vykonajú sa in?trukcie spojené s?t?mto záznamom.Paket je poslan? k?nasledujúcej Flow tabu?ke v?re?azci, na Group tabu?ku alebo na Meter tabu?ku, alebo m??e by? smerovan? na v?stupn? port.Ke? je paket poslan? na v?stupn? port, vykoná sa nahromadená sada akcií a?paket je vo fronte pre v?stup.OpenFlow protokolOpenFlow protokol opisuje v?menu správ medzi OpenFlow kontrolórom a?OpenFlow prepína?om. Protokol je typicky implementovan? nad SSL alebo TLS (Transfer Layer Security) a?poskytuje bezpe?n? OpenFlow kanál. Povo?uje kontrolóru vykonáva? akcie pridania, aktualizovania a?odstraňovania záznamov Flow tabuliek. Podporuje tri typy správ:Controller-to-Switch – správy iniciované kontrolórom a?v?niektor?ch prípadoch vy?adujú odpove? prepína?a. Tieto správy umo?ňujú kontrolóru riadi? logick? stav prepína?a vrátane konfigurácie a?detailov záznamov vo Flow a?Group tabu?kách. Medzi tieto správy patrí aj správa ?Packet-out“, ktorá sa vyu?íva, ke? prepína? posiela paket kontrolóru a?ten sa rozhodne nezahodi? paket, ale posla? ho na v?stupn? port.Asynchronous – správy odosielané bez za?a?ovania kontrolóra. Patria sem r?zne stavové správy posielané kontrolóru. Patrí sem aj správa ?Packet-In“, ktorá sa pou?íva, ke? prepína? posiela paket kontrolóru, preto?e sa nena?la zhoda v?záznamoch.Symmetric – správy odosielané bez ob?a?ovania kontrolóra a?prepína?a. Sú jednoduché, ale u?ito?né. Tabu?ka správ:SprávaPopisController-to-SwitchFeaturesKontrolór ?iada o schopnosti prepína?a, prepína? po?le odpove?, ktorá ?pecifikuje jeho schopnosti.ConfigurationKontrolór nastavuje a ?iada o konfigura?né parametre, prepína? po?le odpove? s nastaveniami t?chto parametrov.Modify-StatePridanie, vymazanie a modifikovanie flow/group záznamova nastavenie vlastností portu na prepína?i.Read-StateKontrolór zozbiera informácie z prepína?a, ako napr. sú?asnúkonfiguráciu, ?tatistiky ?i schopnosti.Packet-outSmeruje paket na konkrétny port prepína?a.BarrierTieto správy sa pou?ívajú kontrolórom pre zabezpe?enie, ?e závislosti správy boli splnené alebo pre prijatie notifikácií pre kompletné operácie. Role-RequestNastavenie alebo ?iadanie o rolu OpenFlow kanála, ?o je u?ito?né pri pripojení prepína?a k viacer?m kontrolórom.Asynchronous-ConfigurationNastavenie filtra pre asynhrónne správy alebo ?iados? o tento filter, ?o je u?ito?né pri pripojení prepína?a k viacer?m kontrolórom.AsynchronousPacket-InTransfer paketu na kontrolór.Flow-RemovedInformovanie kontrolóra o vymazaní záznamu z Flow tabu?ky.Port-StatusInformovanie kontrolóra o zmene portu.ErrorInformovanie kontrolóra o problémovom alebo chybovom stave.SymmetricHelloV?mena správ medzi kontrolórom a prepína?om pri spustenípripojenia.EchoTieto správy m??u by? posielané bu? prepína?om alebo kontrolórom, pri?om musí by? prijatá odpove?. Slú?ia na meranie oneskorenia ?i ?írky pásma kontrolór-prepína? pripojenia, alebo iba overujú, ?e zariadenie je v?prevádzke.ExperimenterPre ?al?ie funkcie, ktoré majú by? sú?as?ou budúcich verzií OpenFlow.HDS - Handover Decision ServerRozhodovací server prechodov HDS (z angl. Handover Decision Server) – má na starosti funkcionalitu o rozhodovaní prechodov v sieti. Pre uskuto?ňovanie zmien dátové toku v sieti vyu?íva komponent AFCP, ktor? ma na starosti doplnenie funkcionality riadiaceho plánu. InicializáciaHDS odo?le správu so svojou konfiguráciou na AFCP. AFCP rozpo?le skrze kontrolér broadcastom informáciu WTP, ?e ak sa tak?to protokol spáruje s protokolom vo flow tabu?ke má ho posiela? na HDS, ak nie tak je potrebné posiela? protokol na Kontrolór, ktor? rozhodne ?o s ním.Scenár autentifikácie Suplicant <->HDS <-> Radius HDS vykonáva komunikáciu s Radius serverom pre identifikáciu a prihlásenie koncového zariadenia. Vykonáva sa tu v?mena správ pomocou ?tandardu 802.1 xVstupy a v?stupy potrebné pre vykonanie autentifikácie sú opísané na obrázku ?íslo 33.Proces: Pokia? sa pou?ívate? pripojí na sie?ov? port, má blokovanú v?etkú komunikáciu okrem EAP protokolu, kter? zais?uje autentizáciu. Autentizácia prebieha nasledovne:Klient sa pripojí k prístupovému boduPrístupov? bod akceptuje iba autentiza?né EAP rámceostatn? (datov?) tok od klienta je zablokovan?klient odo?le autentiza?né informácie pomocou EAP protokoluprístupov? bod prepo?le ?iados? na HDS server a ten prepo?le informácie RADIUS serveruna RADIUS servery prebehne overenie pou?ivate?apokia? je pou?ívate? lokálny prebehne jeho overenie priamo na RADIUS servery v?sledku autentizácie je informovan? HDS server, ktor? preposiela informácie prístupovému bodu, ktor? v prípade úspechu odblokuje klientovi datov? tok.Obr.?.33 - Autentifikácia koncového zariadeniaScenár prihlásenia bez autentifikácie WTP <-> HDS <-> AFCPVstupy: hw -probe správy, autentifika?né správy, potvrdzovacie správyV?stupy: hw - správa obsahujúca VAP, BSSID, WTP hh - riadiace správy na nastavenie toku smerom na HDS (správy:probe, autentifika?né, ACK )Proces: HDS odo?le správu na nastavenie open flow tabuliek do AFCP. Táto správa má za následok preposielanie v?etk?ch probe správ na HDS. Následne je potrebné odosla? správu na AFCP pre nastavenie open flow tabuliek pre autentifika?né správy. Po nastavení open flow tabuliek pre autentifikáciu je potrebné nastavenie open flow tabuliek pre potvrdzovanie autentifikácie taktie? pomocou správy odoslanej na AFCP. Následne m??e prebieha? komunikácia pre autentifikáciu. HDS prijíme od WTP probe správu, ktorú spracuje. Spracovaním sa chápe v?ber WTP, ktoré je ku zariadeniu najbli??ie. Vyberie sa najlep?ie WTP na základe prijatej sily signálu. HDS vyberie WTP a odo?le mu VAP pre nové koncové zariadenie, ktoré si HDS ulo?í do tabu?ky. HDS následne obr?í potvrdzovaciu správu od WTP o vytvorení asociácie. HDS po obdr?aní správy odo?le správu AFCP. Táto správa bude obsahova? nastavenie toku pre VAP a koncové zariadenie cez konkrétne WTP. Následne u? prebieha dátov? tok.Scenár reasociácia WTP <->HDS <-> AFCPVstupy: hw - SNR, kanál, VAP, informácie o okolit?ch WTP, MAC (id koncového zariadenia).V?stupy: hh - stará VAP, nová VAP, id koncového zariadenia, MAC, IP, WTPProces: Komunikácia slú?i na zachytenie a vykonanie zmien v architektúre pri prechode koncovej stanice z jedného WTP na iné WTP. Rozhodovanie zále?í, ?i WTP podporuje správy CSA, alebo nie. Na komusinkáciu medzi HDS a AFCP slú?i protokol hh. Tento protokol je bli??ie opísan? v integra?nom manuály. HDS slú?i na udr?iavanie preh?adu o pripojen?ch zariadeniach v rámci koncov?ch bodov. WTP odosiela informácie ako silu signálu, kanál na ktorom be?í a informácie o okolit?ch staniciach WTP. Z t?chto informácií sa vytvorí tabu?ka s preh?adom, ktorá bude slú?i? na rozhodovanie pri prechode koncového zariadenia z jednej WTP do inej WTP. Pre rozhodovanie sa pou?íva HDS , ktor? odosiela WTP informácie o prechode VAP na inú WTP. Následne ako sa vykoná zmena HDS odo?le správu AFCP na zmenu toku WTP1 na WTP2, preto?e VAP bola premiestnená z WTP1 na WTP2.Správy z WTP sa budú zasiela? ka?dú sekundu.Postup rozhodovania o uskuto?není prechodu na základe prijat?ch informáciíNa obrázku ?íslo 34 je znázornen? diagram rozhodovania HDS po prijatí informácií z WTP. Obr.?.34 - Rozhodovanie o prechode koncového zariadenia v?HDSScenár odhláseniaVstupy: hw - kanál, VAP, informácie o WTP, MAC (id koncového zariadenia).V?stupy: odhlásené koncové zariadenie, vymazané z tabu?ky v HDSProces: Koncové zariadenie odo?le na WTP správu pre odhlásenie (definovaná v komunika?nej matici). WTP túto správu prepo?le na HDS. HDS prijme správu pomocou rozhrania hw. HDS sú pracuje správu, vyma?e koncové zariadenie s informáciami z tabu?ky a odo?le WTP správu o vymazaní. Scenár monitorovaniaVstupy: hw - SNR, kanál, VAP, informácie o okolit?ch WTP, informácie o WTP (zah?ňa aj obsadenos? WTP), MAC (id koncového zariadenia).V?stupy: hh - zmena kanála, zv??enie v?konu WTPProces: WTP odosiela monitorovacie správy do HDS. HDS prijme správy pomocou rozhrania hw. Následne HDS správy spracuje a vykonáva porovnanie s nastaven?mi pravidlami. V prípade, ak je WTP plne obsadené a chce sa na neho pripoji? ?al?ia koncová stanica, je potrebné rozhodnú?, ktorá najbli??ia koncová stanica má dostato?né pokrytie, aby dokázala prija? koncové zariadenie a poskytla mu dostato?né QoS. V prípade, ak WTP má ru?enie s in?m kanálom , je potrebné prestavi? kanál, tak aby nekolidoval s ostatn?mi prekr?vajúcimi sa kanálmi. V?etky správy s?rozhodnutiami sa?posielajú na AFCP prostredníctvom hh rozhrania.Scenár reportovVstupy: hw - SNR, kanál, VAP, informácie o okolit?ch WTP, informácie o WTP (zah?ňa aj obsadenos? WTP), MAC (id koncového zariadenia).V?stupy: Informácie spracované pre monitorovanie.Proces: Reporty sú posielané z WTP na HDS pomocou rozhrania hw. Tieto reporty sú spraované pri monitorovaní siete, ktoré je opísané v kapitole 5.Scenár pádu WTPVstupy: hw - Reporty z WTPV?stupy: hh - správa obsahujúca (staré WTP, nové WTP, VAP, BSSID koncového zariadenia, MAC a IP koncového zariadenia) hw - správa ?iadosti (vy?iadanie reportu)Proces: HDS prijíme reporty od WTP pomocou rozhrania hw. Pri vyhodnocovaní zistí, ?e WTP nie je funk?né. Odo?le správu ?iadosti na WTP cez rozhranie hw. Ak WTP neodo?le v ur?enom ?ase 0,5 sekundy ?iaden report, HDS odosiela túto správu znovu. Ak ani an druh? pous WTP neodo?le správu, HDS vyhodnotí WTP ako nekatívne a odo?le v?etky informácie na AFCP pomocou rozhrania hh na vykonanie prechodu VAP a koncov?ch staníc do in?ch WTP na základe rozhodnutia. Po vykonan?ch zmenách HDS o?akáva reporty od WTP, kde kontroluje priradenie koncov?ch staníc s VAP do nov?ch WTP. Ak reporty prídu a HDS vyhodnotí, ?e v?etky stanice boli priradené nov?m WTP pokra?uje v monitorovaní siete. Ak ale HDS zistí nepriradenie koncov?ch staníc na nové WTP ani po prijatí druhého reportu, HDS znovu odosiela správu ?iadosti do AFCP pre priradenie koncov?ch staníc.ImplementáciaPostup in?talácie Mininet-WiFiNasledovn? postup bol otestovan? na opera?nom systéme Ubuntu v14.04 a na Windowse pomocou virtuálneho stroja, kde bol spusten? tie? Ubuntu v14.04. Po?as in?talácie sa nain?talujú v?etky potrebné balíky a skompiluje sa zdrojov? kód stiahnut? z GitHub projektu. In?taláciu u?ah?uje automatizovan? skript, kde v?sledkom bude nain?talované prostredie MiniNet roz?írené s podporou pre bezdr?tové siete WiFi.Na konzole musia by? vykonané nasledovné príkazy za sebou:$ sudo apt-get update$ sudo apt-get install git$ git clone $ cd mininet-wifi$ sudo util/install.sh –WnfvNasadenie firmvéru na smerova?Táto ?as? sa venuje problematike smerova?ov a OpenFlow. Pre potreby tímového projektu je nutné, aby na?e zariadenie podporovalo centralizované ovládanie a dokázalo fungova? ako SDN (softvérovo riaden?) prepína?. Be?ne takúto funkcionalitu nemá ?iadny smerova?, ale po anal?ze sa nám podarilo zisti?, ?e je mo?nos? prerobi? takmer hocijak? smerova? na prepína? s podporou OpenFlow a centralizovan?m prístupom. Ako základ slú?i niektor? z dvojice open-source firmvérou OpenWrt alebo DD-Wrt. Spo?iatku sme sa uberali cestou DD-Wrt, ale po mno?stve komplikácií a nevyrie?en?ch problémov, ?i?e v d?sledku neúspe?nej doimplementácie sme sa rozhodli zmeni? na?e orientovanie na OpenWrt. T?mto dokumentom ilustrujeme ako zmeni? be?n? komer?n? smerova? prepálen? s OpenWrt firmvérom na OpenFlow prepína?. Po?as práce bola vyu?itá zatia? najnov?ia stabilná verzia OpenWrt, ktorá je 15.05 a?je známa pod názvom Chaos Calmer a?je dostupná z?webovej stránky OpenWrt. Ako kompatibiln? hardvér pre?tento firmvér sme mali k?dispozícii SOHO smerova? Asus RT-N16. Hardvérové parametre tohto smerova?a sú:CPU: Broadcom BCM4718 SoC 480 MHz (architektúra MIPS 74K)Pam?? RAM: 128 MBVnútorná pam?? Flash: 32 MBRozhrania: 4+1 portov? gigabitov? prepína?, bezdr?tové (WiFi) rozhranie 802.11 b/g/n s?max. r?chlos?ou 300MB/s, 2x USB 2.0 rozhranie, sériov? v?stup, JTagNapájanie: 12V 1,25A (extern? zdroj)Mo?nosti doimplementovania OpenFlow do OpenWrt sú hne? dve. Prvá je vzia? ?ist? firmvér OpenWrt vo forme zdrojov?ch kódov, stiahnu? implementáciu ?isto protokolu OpenFlow pre OpenWrt, prida? súbory do zdrojov?ch adresárov OpenWrt a potom skompilova? nov? firmvér.Druhou vo?bou je prida? softvérov? Open vSwitch ako aplikáciu do implementácie OpenWrt.V tomto dokumente sú popísané návody pre obe vy??ie spomenuté mo?nosti.Rie?enie pomocou OpenFlow implementácie (Stanford implementácia OpenFlow 1.0 a?1.3 ) V tejto kapitole sa venujeme doimplementovaniu OpenFlow protokolu do zdrojov?ch kódov. Spo?iatku sme sa rozhodli doimplementova? do OpenWrt verziu OpenFlow 1.0. K tejto verzii bola dobrá dokumentácia s názvom projektu Pantou vytvorená univerzitou v americkom Stanforde. Po úspe?nom doimplementovaní sme ale zistili, ?e verzia OpenFlow 1.0 nie je dosta?ujúca pre potreby ná?ho tímového projektu a tak sme museli postúpi? na verziu 1.3. Tú sa nám podarilo nájs? samotn? modul OpenFlow 1.3 pre OpenWrt bol vytvoren? brazílskou nadáciou pre telekomunikácie CPqD. Openflow je implementovan? ako aplikácia na vrchu OpenWrt. Tento návod je rozdelen? na tri ?asti:získa? prislúchajúci firmvér pre smerova?vlo?i? firmvér do zariadeniapridanie OpenFlow roz?íreniakonfiguráciaPre tento proces je potrebné sp?ňa? nasledovné po?iadavky:Opera?n? systém: Linux distribúcia (otestované s?Ubuntu 14.04)Internetové pripojenieVo?né miesto na disku minimálne 10GBMinimálne 1GB dostupnej pam?ti RAMZískanie firmvéruRozhodli sme sa vytvori? firmvér zo zdrojov?ch kódov. Poznámka: V nasledujúcich krokoch pova?ujeme za pracovn? adresár ~/openwrt.In?talácia závislostí potrebn?ch pre OpenWrt.apt-get install build-essential binutils flex bison autoconf gettext git \ sharutils subversion libncurses5-dev ncurses-term zlib1g-dev gawk libssl-devPre potreby OpenWrt potrebujeme aj program Texinfo, ale v star?ej verzii ako je ?íren? dnes, tak?e ten musíme nain?talova? ru?ne.wget -dc < texinfo-4.13.tar.gz | tar -xf -cd texinfo-4.13./configuremakemake installcd ..Stiahneme a pripravíme si zdrojové súbory Chaos Calmer Openwrt.cd ~/openwrtgit clone git://git.15.05/openwrt.gitcd openwrt./scripts/feeds update -a./scripts/feeds install -aVytvoríme konfigura?n? súbor.make menuconfigTu je d?le?ité nastavi? target system = Broadcom BCM47xx (MIPS), subtarget = MIPS 74K.Potom m??eme zatla?i? ESC a potvrdi? ulo?enie Y.Skontrolujeme, ?i máme v?etko potrebné pre firmvér.make prereqA napokon spustíme build Chaos Calmer. Prepína? -j2 slú?i na vyu?itie viac jadier.make -j2Nahranie firmvéru do zariadeniaTeraz pre overenie je potrebné nahra? firmvér do smerova?a. V?etky skompilované firmvéry sú pod zlo?kou ~/openwrt/bin/brcm. Ten ná? sa volá openwrt-brcm47xx-mips74k-asus-rt-n16-squashfs.trx. Overenie sa robí sp?sobom:Pripojíme kábel do hociktorého "LAN" portu smerova?a, nie "WAN"PC zmeníme IP adresu 192.168.1.10, maska 255.255.255.0Smerova? dáme do recovery re?imu - stla?ené tla?idlo reset pok?m zapájam zdrojRecovery re?im spoznáme neustálym blikaním symbolu "power" na smerova?iAk?mko?vek TFTP klientom po?leme firmvér na IP adresu 192.168.1.1Po?káme dve minúty, potom power resetneme smerova?Znova po?káme 2 minúty a vyskú?ame telnet na 192.168.1.1Mala by nás uvíta? OpenWrt úvodná obrazovka. Pridanie OpenFlow roz?íreniaPresunieme sa do pracovného adresára a stiahneme OpenFlow roz?írenie.cd ~/openwrt/git clone áme symbolickú linku na OpenFlow.cd ~/openwrt/package/ln -s ~/openwrt/openflow-openwrt/openflow-1.3/Pridáme základné konfigura?né súbory.cd ~/openwrt/ln -s ~/openwrt/openflow-openwrt/openflow-1.3/filesZnova vytvoríme konfigura?n? súbor, tento krát u? s OpenFlow.make menuconfigZvolíme nasledovné:Target system = Broadcom BRCM47xx (MIPS)Subtarget = MIPS 74kPod network zvolíme balík tc, aby sa nain?talovalPod Kernel Modules -> Network Support zvolíme kmod-tun na in?taláciuukon?íme a ulo?ímePridáme podporu pre frontu.make kernel_menuconfigPod Networking Support -> Networking options -> QoS zvolíme Hierarchical Token Bucket (HTB) na in?taláciu. Ukon?íme a ulo?íme.Spustíme build.makeNain?talujeme firmvér do smerova?a, napríklad vy??ie spomenut?m sp?sobom cez recovery.OverenieZákladne, firmvér vytvoren? zo zdrojov?ch súborov bude ma? port ozna?en? ako "internet" (WAN) nastaven? ako mana?ovací port, so statickou IP 192.168.1.1. Mali by sme by? schopn? pripoji? sa cez tento port ak máme IP adresu PC v podsieti 192.168.1.0/24. Ke? sme nakonfigurovali PC, m??eme sa pokúsi? pripoji?.telnet 192.168.1.1Po pripojení overím, ?i be?ia potrebné OpenFlow procesy.ps aux | grep ofprotocolps aux | grep ofdatapathKonfiguráciaPre OpenFlow sa nachádzajú v smerova?i tri potrebné konfigura?né súbory. Pre sie? (/etc/config/network) a wifi (/etc/config/wireless) a konfiguráciu (/etc/config/openflow).Primárne je wifi vypnuté. Tento smerova? vie by? pou?it? ako 5 portov? prepína?. Najsk?r musíme nastavi? /etc/config/network.config 'switch' option 'name' 'eth0' option 'reset' '1' option 'enable_vlan' '1' config 'switch_vlan' option 'device' 'eth0' option 'vlan' '1' option 'ports' '4 8t'config 'switch_vlan' option 'device' 'eth0' option 'vlan' '2' option 'ports' '3 8t'config 'switch_vlan' option 'device' 'eth0' option 'vlan' '3' option 'ports' '2 8t'config 'switch_vlan' option 'device' 'eth0' option 'vlan' '4' option 'ports' '1 8t'config 'switch_vlan' option 'device' 'eth0' option 'vlan' '0' option 'ports' '0 8t'config 'interface' 'loopback' option 'ifname' 'lo' option 'proto' 'static' option 'ipaddr' '127.0.0.1' option 'netmask' '255.0.0.0' config 'interface' option 'ifname' 'eth0.1' option 'proto' 'static' config 'interface' option 'ifname' 'eth0.2' option 'proto' 'static' config 'interface' option 'ifname' 'eth0.3' option 'proto' 'static' config 'interface' option 'ifname' 'eth0.4' option 'proto' 'static' config 'interface' option 'ifname' 'eth0.0' option 'proto' 'static' option type 'bridge' option 'ipaddr' '192.168.1.1' option 'netmask' '255.255.255.0'Mana?ovací port je WAN. Tu bude pripojen? aj kontrolór. Zvy?né porty LAN1-4 sú pou?ite?né pre prepína?.E?te potrebujeme nastavi? wifi, ktoré je stále vypnuté. Základne je povolené maximálne 802-11g, ale smerova? je schopn? fungova? aj v ?tandarde n. Pre vyu?itie sú tieto príkazy.opkg remove kmod-b43 kmod-b43legacy opkg updateopkg install kmod-brcmsmacrm -f /etc/config/wirelesswifi detect > /etc/config/wirelesswifiNastavíme konfigura?n? súbor pre wifi /etc/config/wireless.config wifi-device wlan0option type mac80211option channel 5option macaddr00:25:9c:30:2c:f4option hwmode11n# REMOVE THIS LINE TO ENABLE WIFI:# option disabled 0config wifi-ifaceoption device wlan0#option network lanoption mode apoption ssid OpenFlow-OpenWrtoption encryption none?alej potrebujeme nastavi? /etc/config/openflow.config 'ofswitch'option 'dp' 'dp0'option 'ofports' 'eth0.0 eth0.1 eth0.2 eth0.3 eth0.4 wlan0 'option 'ofctl' 'tcp:192.168.1.10:6633' #ip adresa controlleraoption 'mode' 'outofband'Nakoniec spravíme re?tart, nech sa v?etky zmeny prejavia. Ale pre istotu aj fyzick? re?tart./etc/init.d/openflow restart/etc/init.d/network restartRie?enie pomocou Open vSwitch - Pridanie moduluNa pridanie balíka Open vSwitch do firmvéru máme k?dispozícii 2 mo?nosti:Pridanie OVS do zdrojového kódu a?kompilácia firmvéruIn?talácia hotového balíka OVS pomocou mana?éra balíkov na be?iacom systémePo?as rie?enia boli otestované obe metódy. Postup je podrobne opísan? v?nasledujúcich ?astiach tejto podkapitoly.Metóda 1: Pridanie OVS do zdrojového kódu a?kompiláciaPre tento proces je potrebné sp?ňa? nasledovné po?iadavky:Opera?n? systém: Linux distribúcia (otestované s?Ubuntu 14.04)Internetové pripojenieVo?né miesto na disku minimálne 10GBMinimálne 1GB dostupnej pam?ti RAMV?prvom kroku je potrebné skontrolova?, ?i sú nain?talované v?etky potrebné balíky pre kompiláciu pou?itím tohto príkazu:$ apt-get install build-essential binutils flex bison autoconf gettext texinfo sharutils subversion git libncurses5-dev ncurses-term zlib1g-dev gawkTeraz máme na mo?nos? vybra? si verziu OpenWrt, ktoru chceme pou?i?. V?tomto prípade to bude verzia Chaos Calmer. Najnov?ia, ale nestabilná sa naz?va v?dy ako trunk.Predpokladáme, ?e sa nachádzame v?domovskom adresári, kde vykonáme tieto príkazy:$ svn co svn://svn.openwrt/branches/chaos_calmer$ cd chaos_calmer$ ./scripts/feeds update –a$ ./scripts/feeds install –a$ make menuconfigPo vykonaní posledného príkazu by sa malo objavi? automaticky okno s?konfiguráciou, ktoré vyzerá podobne ako na obrázku:Obr.?.35 - Konfigura?né okno ?menuconfig“Ako prvé vyberieme si polo?ku Target system pomocou <Select>. Následne si vyberieme Broadcom BCM47xx/53xx (MIPS) v?prípade Asus RT-N16. Pri stla?ení kláves je odporú?ané sa riadi? pokynmi, ktoré sa v?dy objavujú na obrazovke v?hornej ?asti okna menuconfig.Ako Subtarget si vyberieme mo?nos? MIPS 74K. (samozrejme v?prípade RT-N16)V??asti Target Profile máme mo?nos? vybra? si ovláda? pre WiFi. D?le?ité je ?e predvolen? ovláda? b43 podporuje maximálne re?im 802.11g.V??asti Kernel modules a?Network support potrebujeme e?te kmod-tun.V??asti Network potrebujeme e?te modul openvswitch.V?prípade potreby pou?ívate?ského rozhrania, máme na mo?nos? vybra? si a prisp?sobi? balík Luci, napríklad takto:v??asti Luci -> Collections si vyberieme luci.v??asti Luci -> Modules si vyberieme luci-base, luci-mod-admin-full.v??asti Luci -> Applications si vyberieme luci-app-firewall, luci-app-ntpc.v??asti Luci -> Themes si zvolíme vzh?ad webového rozhrania. Predvolen? je luci-theme-bootstrap.v??asti Luci -> Protocols si vyberieme ipv6 a?ppp.v??asti Luci -> Libraries si vyberieme httpclient, ip, json a nixio.Hotovú konfiguráciu si ulo?íme pomocou tla?idla <Exit> a?následne Yes v dialógovom okne. Po návrate do konzoly spustíme príkaz:$ make kernel_menuconfigObjaví sa podobné okno ako menuconfig ale tento krát s?in?mi polo?kami. Na ceste Networking Support -> Networking Options si pridáme balík Hierarchical Token Bucket (HTB) do kompilácie.Obr.?.36 - Konfigura?né okno ?Kernel menuconfig“ a?polo?ka HTBNasleduje posledn? krok tejto metódy a?to je spustenie kompilácie, ktorá sa spustí vydaním príkazu:$ makeProces kompilácie m??e trva? aj nieko?ko hodín. Pre zr?chlenie procesu sa dá zapnú? multithreading a?to tak ?e pomocou prepína?a -j pre make pridáme do procesu vykonanie viac úloh naraz. Napríklad v prípade -j2 sa budú vykonáva? dve úlohy naraz, ?o je odporú?ané mno?stvo v?prípade dvojjadrového procesora a?1GB RAM.Hotov? binárny súbor sa bude nachádza? v?adresári ./bin/<SoC_type> . V?prípade RT-N16 to bude: openwrt-brcm47xx-mips74k-asus-rt-n16-squashfs.trx.In?talácia firmvéru na router RT-N16Predpokladáme, ?e máme k?dispozícii binárny súbor s?príponou .trx, ktor? je ur?en? pre dané zariadenie. V?nasledujúcich krokoch je opísan? postup in?talácie pri pou?ití opera?ného systému Windows. Na OS Linux je to mo?né tie?, napr. pomocou nástroja tftp. Stiahneme si a?nain?talujeme program Asus Firmware Restoration Utility zo stránkach v?robcu.Smerova?a si prepneme do tzv. Recovery re?imu pomocou tla?idla RESET. Po úspe?nom prepnutí do tohto re?imu sa bude LED PWR nepreru?ene blika?.IP adresu po?íta?a si nastavíme na 192.168.1.10 a?masku na 255.255.255.0.Pripojíme si zariadenie k?po?íta?u pou?itím niektorého portu LAN. (napr. LAN1)Spustíme program Firmware Restoration a?pomocou Browse si vyberieme súbor s?firmvérom (prípona .trx).Klikneme na Upload a??akáme k?m sa neobjaví informácia o?úspe?nom dokon?ení procesu in?talácie. (obrázok ?íslo 37)Zariadenie sa po in?talácie firmvéru re?tartuje.úspe?nosti in?talácie sa presved?íme pomocou nástroja telnet. Pripojíme sa na adresu 192.168.1.1. Mala by sa objavi? konzola s?nadpisom OpenWrt.Obr.?.37 - Okno aplikácie Firmware RestorationMetóda 2: In?talácia hotového balíka OVS pomocou mana?éra balíkovTáto metóda je jednoduch?ia a?r?chlej?ia ako predchádzajúca, ke??e je to bez dlhotrvajúcej kompilácie firmvéru. Nepotrebujeme tu ani prostredie pre kompiláciu. Nev?hodou v?ak je ?e in?talácia na zariadení trvá dlh?ie, ke??e potrebné balíky sú nain?talované manuálne pomocou mana?éra balíkov opkg. Taktie? je nevyhnutná dostupnos? internetového pripojenia na smerova?i cez WAN port.V?prvom kroku si stiahneme u? kompilovan? firmvér zo stránky OpenWrt pre príslu?né zariadenie. V na?om prípade je to verzia Chaos Calmer (15.05) pre router Asus RT-N16. Názov súboru s?firmvérom vyzerá nasledovne:openwrt-15.05-brcm47xx-mips74k-asus-rt-n16-squashfs.trxV??al?om kroku si nain?talujeme tento stiahnut? firmvér na koncové zariadenie pod?a návodu vy??ie In?talácia firmvéru na router RT-N16 (v prípade Asus). Po úspe?nej in?talácii by sme mali ma? k?dispozícii prístup do zariadenia cez telnet.Pomocou príkazu passwd je potrebné nastavi? si heslo. Po úspe?nom nastavení hesla budeme ma? k?dispozícii aj prístup cez SSH a?cez webového rozhrania Luci. Pou?ívate?ské meno bude v?dy ?root“.Potrebné balíky si nain?talujeme do vnútornej pam?ti zariadenia pomocou nasledovn?ch príkazov:$ opkg update # aktualizácia databázy o?dostupn?ch balíkoch$ opkg --force-depends install kmod-tun openvswitchV prípade potreby pou?ívate?ského rozhrania, máme tu mo?nos? nain?talova? si a?prisp?sobi? balík Luci. Minimálna konfigurácia sa in?taluje takto:$ opkg --force-depends install luciIn?taláciu dokon?íme re?tartovaním zariadenia a?pokra?ujeme s?konfiguráciou SDN prepína?a.Konfigurácia prepína?aPredpokladáme, ?e u? máme pripravené zariadenie s?firmvérom OpenWrt, ktor? obsahuje funk?né pou?ívate?ské prostredie Open vSwitch. Musia be?a? procesy ovsdb-server a?ovs-vswitchd.Nasledovné kroky konfigurácie a?obsahy konfigura?n?ch súborov sú kompatibilné predov?etk?m s?verziou OpenWrt 15.05, Open vSwitch 2.3.9 a?zariadením Asus RT-N16. V?prípade in?ch softvérov?ch verzií alebo iného hardvéru obsah niektor?ch konfigura?n?ch súborov m??e vyzera? inak. Postup:Pripojíme sa na IP adresu prepína?a (predvolene 192.168.1.1) cez protokol SSH a?zadáme pou?ívate?ské meno (root) a?heslo.Pomocou ob?úbeného textového editora (napríklad vi alebo nano) zmeníme obsah niektor?ch konfigura?n?ch súborov.Súbor /etc/config/network :config switch option name 'eth0' option reset '1' option enable_vlan '1'config switch_vlan option device 'eth0' option vlan '0' option ports '1 8t'config switch_vlan option device 'eth0' option vlan '1' option ports '4 8t'config switch_vlan option device 'eth0' option vlan '2' option ports '3 8t'config switch_vlan option device 'eth0' option vlan '3' option ports '2 8t'config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0'config globals 'globals' option ula_prefix 'fd1a:8ff4:8d69::/48'config interface 'lan' option ifname 'eth0.0' option force_link '1' option type 'bridge' option proto 'static' option ipaddr '192.168.1.1' # zmenit podla potreby option netmask '255.255.255.0' option ip6assign '60'config interface option ifname 'eth0.1' option proto 'static'config interface option ifname 'eth0.2' option proto 'static'config interface option ifname 'eth0.3' option proto 'static'Kontrolované porty prepína?a budú LAN1-3 a?port pre pripojenie kontrolóra bude LAN4. Port WAN je vypnut?.Súbor /etc/config/wireless :Odstránime riadky ?option disabled 1“, ?option network lan“ a?pridáme alebo zmeníme tieto riadky v??asti config wifi-iface:option ssid 'inWifi'option encryption 'psk2' pod?a potrebyoption key 'my_password' pod?a potreby, je to heslo typu WPA2-PSKPre správnu funk?nos? WLAN LED je potrebné roz?íri? obsah súboru /etc/config/system pridaním nasledovn?ch riadkov:config led wlan_led option name 'WLAN' option sysfs 'bcm47xx:blue:wlan' option trigger 'netdev' option dev 'wlan0' option mode 'link tx rx'Po dokon?ení zmien v?konfigura?n?ch súboroch je potrebné re?tartova? prepína?.Po?íta? kde robíme konfiguráciu u? musí by? pripojen? v?hradne do portu LAN4.Spojíme sa so zariadením cez SSH, rovnako ako v?predchádzajúcich krokoch.Vytvoríme si most (bridge) pomocou príkazu:$ ovs-vsctl add-br br0Parameter br0 je názov vytvoreného rozhrania.Do vytvoreného virtuálneho rozhrania br0 pridáme rozhrania portov. Predpokladáme, ?e sme vyu?ili obsah súboru network opísaného vy??ie.$ ovs-vsctl add-port br0 eth0.1$ ovs-vsctl add-port br0 eth0.2$ ovs-vsctl add-port br0 eth0.3$ ovs-vsctl add-port br0 wlan0 # ak chceme pridat do switchu aj WiFiNastavíme si IP adresu a?port kontrolóra. V?na?om prípade to bude 192.168.1.10:6633.$ ovs-vsctl set-controller br0 tcp:192.168.1.10:6633Nastavíme si po?adovanú/é verziu/e OpenFlow. Prv?m príkazom sa povolí iba OpenFlow 1.3, druh?m sa povolia verzie 1.0 a?1.3.$ ovs-vsctl set bridge br0 protocols=OpenFlow13$ ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow13Konfiguráciu si overíme pomocou príkazu:$ ovs-vsctl showNasadenie a?spojazdnenie SDN kontrolóra a?prepína?aAko kontrolór sme sa rozhodli pou?i? Ryu v najnov?ej verzii, ktorá podporuje OpenFlow od 1.0 a? do 1.5. Je to open-source kontrolór, do ktorého si vieme doimplementova? potrebné veci, ak by to bolo ?iadané. Je implementovan? v jazyku Python a v dne?nej dobe ?elí obrovskej popularite z poh?adu SDN. Pre nain?talovanie Ryu potrebujeme po?íta? s nain?talovanou distribúciou Linux. Pod?a nastavení ná?ho prepína?a sa má kontrolór nachádza? na IP adrese 192.168.1.10:6633, tak?e musíme zmeni? IP po?íta?a tak, aby sedela. Potom cez konzolu spustíme ako super user príkazy: % git clone git://osrg/ryu.git % sudo apt-get install python3.5% cd ryu; python ./setup.py installNásledne m??eme RYU spusti? a za?a? komunikáciu. Spustíme cvi?n? OpenFlow 1.3 skript.% cd bin % ./ryu-manager ryu/app/simple_switch13.pyTeraz máme spusten? kontrolór a komunikácia m??e za?a?. Po zapnutí prepína?a vidíme, ?e spolu s kontrolórom komunikujú, dokonca ke? zapojíme do smerova?a internet, tak v?etky správy sú ?írené.TestovanieMininet-WiFiPo?as testovania simulátora boli vyskú?ané príklady z prie?inka examples, a bol navrhnut? a implementovan? aj vlastn? skript, kde sú simulované prechody 4 staníc medzi 3 prístupov?mi bodmi. Po?as simulácie bola zapnutá aj vizualizácia simulácie v reálnom ?ase, ktorú je vidno na obrázku ni??ie:Obr.?.38 - Simulácia navrhnutej topológie v?Mininet-WiFiPo?as simulácie bolo zistené, ?e simulátor má nieko?ko nedostatkov, ktoré sú:-Ping medzi niektor?mi stanicami niekedy bez d?vodu prestane fungova?-Simulovan? prechod medzi prístupov?mi bodmi neodzrkad?uje reálnu situáciu-Sila signálu nie je vypo?ítaná-R?zne nerie?ite?né chyby pri spustení simulácie-Slabá v?konnos?Tieto nedostatky e?te m??u by? opravené v neskor?ích verziách simulátora (momentálne sa prebieha aktívny v?voj s t??denn?mi aktualizáciami), ale zatia? nie je posta?ujúce na to, aby sme ho pou?ili na testovanie ná?ho projektu.Simulácia v?OpenNetAko mo?né rie?enie pre nedostatkov, ktor?ch sme zistili pri otestovaní simulátora Mininet-WiFi bolo vyskú?anie simulátora OpenNet. Simulátor OpenNet vznikol spájaním emulátora MiniNet so simulátorom NS3 a t?m pádom bola dosiahnutá podobná funkcionalita ako pri Mininet-WiFi.Nov? simulátor umo?ňuje spo?ahlivej?iu simuláciu prechodov, av?ak nám to e?te nesta?í na overenie rie?enia s r?chlim prechodom v rámci roamingu. ?alej neumo?ňuje priamu doimplementáciu funkcionality centralizovaného riadenia procesov v bezdr?tov?ch prístupov?ch bodoch (AP), ?o neumo?ňuje ani Mininet-WiFi.Na rozdiel od Mininet-WiFi tento simulátor priamo nepodporuje ani vizualizáciu (animáciu) v reálnom ?ase.Na základe t?chto nedostatkov pri simulátoroch sme rozhodli na?e rie?enie testova? u? priamo v rámci reálnych zariadení a sie?ovej topológie.Flow tabu?kyPo úspe?nom spustení SDN topológie s niektorou verziou OpenFlow spolu s kontrolórom nasleduje úloha na overenie stavu Flow tabuliek na ka?dom prepína?i. Stav Flow tabuliek by mal odzrkad?ova? toku dát cez sie?.Flow tabu?ky sa dajú zobrazi? na prepína?och s Open vSwitch vydaním nasledovn?ch príkazov, kde predpokladáme ?e názov rozhrania bridge máme nastavené na br0:ovs-ofctl dump-flows br0 # zobrazí OpenFlow flows a hidden flowsovs-appctl bridge/dump-flows br0 # zobrazí OpenFlow flows a hidden flowsovs-appctl dpif/dump-flows br0 # zobrazí informácie o bridge a datapathovs-dpctl dump-flows [dp] # zobrazí informácie o Linux kernel a?datapathVizualizácia topológieKe? máme na?u SDN architektúru korektne zapojenú, m??eme vyu?i? vla?nosti RYU kontrolóra na vizualizáciu na?ej topológie. Táto vizualizácia závisí od troch aplikácií:ryu.app.rest_topology: získa dáta z?uzlov a?liniekryu.app.ws_topology: notifikuje o?zmene spojenia (up/down)ryu.app.ofctl_rest: získa dátové cesty tokovNa terminálovom okne kontrolóra RYU sta?í zavola? nasledovn? príkaz:$ PYTHONPATH=. ./bin/ryu run --observe-links ryu/app/gui_topology/gui_topology.pyPotom na lokálnej adrese RYU host na porte 8080 m??eme cez webové GUI rozhranie vidie? pekne zvidite?nenú na?u topológiu ako je vidie? na obrázku 39.Obr.?.39 – GUI na vizualizáciu topológie pomocou RYU [5]LiteratúraMichal Rja?ko: Bezpe?nos? bezdr?tov?ch sietí [online], Univerzita komenského, Fakulta matematiky, fyziky a informatiky UK, 2013, [cit: 2013-04-11]. Dostupné na internete: <, Rao.: SDN Series Part Four: Ryu, a Rich-Featured Open Source SDN Controller Supported by NTT Labs. [online]. THENEWSTACK, 2015. [cit: 2015-16-11]. Dostupné na internete: <, Rao.: SDN Series Part Five: Floodlight, an OpenFlow Controller. [online]. THENEWSTACK, 2015. [cit: 2015-16-11]. Dostupné na internete: <.: 802.11r Fast Transition Roaming. [online]. Verzia 3.3. Cisco. [cit: 2015-16-11]. Dostupné na internete: < Telegraph and Telephone Corporation.: Topology Viewer. [online]. Nippon Telegraph and Telephone Corporation, 2011-2014. [cit: 2015-16-11]. Dostupné na internete: <;. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download