aplikácia softvérového smerovania (sdn) v gprs sieti fileÚvod tento dokument obsahuje prehľad o...

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií

Ilkovičova 2, 842 16 Bratislava 4

Aplikácia softvérového smerovania (SDN) v GPRS sieti

Tímový projekt - Dokumentácia riadenia

Študijný program: Počítačové a komunikačné systémy a siete Predmet: Tímový projekt I Ak. rok: 2013/14 Tím: Tím č. 4 Vedúci tímu: doc. Ing. Ivan Kotuliak, PhD. Členovia tímu: Peter Balga, Tibor Hirjak, Martin Kalčok, Matúš Križan, Ján Skalný

Obsah

Úvod 1 1 Ponuka 1

1.1 O nás 1 1.2 Aktuálny stav 2 1.3 Motivácia 3 1.4 Naša predstava 3 1.5 Časový rozvrh 4

2 Plán projektu 4 3 Úlohy členov tímu 5

3.1 Autorstvo členov v dokumentácii 6 4 Záznamy zo stretnutí 7

4.1 Zapisnica zo stretnutia č.1 7 4.2 Zapisnica zo stretnutia č.2 8 4.3 Zapisnica zo stretnutia č.3 9 4.4 Zapisnica zo stretnutia č.4 10 4.5 Zapisnica zo stretnutia č.5 10 4.6 Zapisnica zo stretnutia č.6 11 4.7 Zapisnica zo stretnutia č.7 11 4.8 Zapisnica zo stretnutia č.8 11 4.9 Zapisnica zo stretnutia č.9 12 4.10 Zapisnica zo stretnutia č.10 12 4.11 Zapisnica zo stretnutia č.11 12 4.12 Zapisnica zo stretnutia č.12 12 4.13 Zapisnica zo stretnutia č.13 13 4.14 Zapisnica zo stretnutia č.14 13 4.15 Zapisnica zo stretnutia č.15 13 4.16 Zapisnica zo stretnutia č.16 14 4.17 Zapisnica zo stretnutia č.17 14 4.18 Zapisnica zo stretnutia č.18 14 4.19 Zapisnica zo stretnutia č.19 15 4.20 Zapisnica zo stretnutia č.20 15

5 Štandardy kódovania 16 6 Manažment verzií, komunikačné nástroje 16 Prílohy 17

Úvod Tento dokument obsahuje prehľad o riadení a vývoji projektu, poskytuje informácie o tíme a úlohách jej členov. Tiež obsahuje ponuku, zápisnice zo stretnutí tímu, posudky nášho projektu a projektu konkurenčného tímu.

1 Ponuka

1.1 O nás Peter Balga

Bakalársky titul získal na FIIT STU, so zameraním na počítačové a komunikačné siete - v tomto štúdiu teraz pokračuje na inžinierskom stupni. Popri štúdiu je správca počítačovej siete na internáte Mladá Garda a pracuje v oblasti telekomunikácií.

Tibor Hirjak

Ukončil bakalárske štúdium na FIIT STU v odbore Informatika. Od júna 2012 pracuje ako administrátor počítačových sietí a serverov na platforme Windows. Je držiteľom certifikátu CCNA a taktiež sa zaoberá virtualizáciou.

Martin Kalčok

Bakalárske stúdium dokončil na Univerzite Konštantína filozofa v Nitre v odbore Aplikovaná informatika. Na katedre FIIT STU absolvoval štyri semestre CISCO CCNA.

Matúš Križan

Čerstvý bakalár Ústavu Počítačových Systémov a Sietí FIIT STU. Počas svojho štúdia pôsobil v OZ Ynet, kde sa okrem iného podieľal aj na návrhu a realizácii počítačovej siete na ŠD Jura Hronca. Od januára roku 2013 pôsobí ako sieťový inžinier u jednej z najväčších globálnych telekomunikačných firiem, AT&T Global Network Services, kde sa sieťam venuje profesionálne.

Ján Skalný

Titul Bc. získal v roku 2011 na FIIT STU, kde pokračuje v inžinierskom štúdiu v odbore PKSS. Popri škole pracuje ako programátor na voľnej nohe a venuje sa UNIXu, sieťam, bezpečnosti a vnoreným systémom. Vo voľnom čase sa pripravuje na CCIE R&S skúšku a pôsobí ako CCNA/CCNP Inštruktor na CNA FIIT STU.

1

1.2 Aktuálny stav Pri nasadzovaní nových technológií v poskytovateľských sieťach je dnes bežné, že nové technológie so sebou prinesú nové zariadenia stavané na určitú funkciu. Rovnako je tomu aj v prípade GPRS sietí, ktoré pri nasadzovaní do GSM sietí okrem úpravy BSC so sebou priniesli SGSN a GGSN uzly.

GGSN a SGSN sa starajú o manažment mobility a reácií v dátovej časti siete, ako aj zbieraní fakturačných údajov, riadenie prístupu a prenosu požívateľských dát.

Na strane BSC prinieslo GPRS rozšírenie vo forme PCU. Voči BSC si PCU rezervuje hlasový kanál a následne sa stará o jeho manažment a prideľovanie koncovým staniciam. PCU ako súčasť BSC sa ku GGSN pripája cez Gb rozhranie, ktoré kombinuje dátové a signalizačné protokoly ako SNDCP, BSSAP, GMM a iné.

Typická štruktúra GPRS siete je vidieť aj na obrázku č. 1.

Obr. č. 1: GPRS sieť.

Riešením problému s narastajúcim počtom jednoúčelových zariadení u poskytovateľa služieb a ich údržbou je oddelenie riadenia siete od smerovania v sieti, koncept, ktorý sa naplno prejavil v softvérovo definovaných sieťach a v Network Function Virtualization. [1]

Myšlienkou softvérového smerovania je oddeliť tok dát od jeho riadenia. Zariadenia zodpovedné za smerovanie sa stanú nezávislé od protokolu a funkcie, čo umožní ich využitie pre rôzne siete a aplikácie u poskytovateľa služieb. O riadenie toku dát sa v takýchto sieťach stará centralizovaný uzol - SDN controller. Ten umožňuje efektívnejšie využívanie siete, keďže má objektívny prehľad o vyťažení a umiestnení rôznych zdrojov v sieti, čím umožňuje aplikáciám lepšiu kontrolu nad nimi.

1.3 Motivácia Vybrali sme si tému Aplikácia softvérového smerovania (SDN) v GPRS sieti, pretože sa najviac dotýka našich spoločných záujmov - komunikačných sietí, a zároveň nám umožňuje zúčastniť sa výskumu v zatiaľ neprebádanej oblasti aplikácie SDN nad GPRS.

2

Keďže 3G siete sú na rozdiel od GPRS viac orientované na IP protokol, aplikácia SDN na ich internú architektúru bola výrazne jednoduchšia, čo sa prejavilo aj na vzniku pokusnej implementácie. [2]

V oblasti aplikácie SDN v 2G sieťach nám však nie sú známe zatiaľ žiadne publikácie.

Keďže si myslíme, že aj v nasledujúcich rokoch, hlavne vďaka aplikácií mobilných sietí vo vnorených systémoch zostane GPRS pre jeho nižšie nároky na energetickú spotrebu, prenosový kanál, ako aj výrobné náklady narozdiel od 3G a LTE štandardov konkurencie schopné. Veríme, že snaha aplikácie SDN by mohla znížiť budúce náklady pri údržbe a prípadnom rozširovaní existujúcich GPRS sietí.

1.4 Naša predstava Našim cieľom je analyzovať technológiu softvérového smerovania, súčasnú architektúru GPRS sietí, navrhnúť a následne implementovať SDN pre GPRS.

Obr. č. 2: GPRS sieť s SDN

Radi by sme funkcie GPRS jadra presunuli do SDN controlleru. Jednou z možností by bolo vytvorenie adaptéru PCU-ng, ktorý by sa nachádzal medzi existujúcim PCU a SDN sieťou poskytovateľa. Jeho úlohou by bolo:

1. oddelovať signalizáciu z protokolov Gb rozhrania a jej preklad do OpenFlow, 2. zabalovať požívateľské dáta do vhodného tunelovacieho protokolu (GRE) a preposielať ich

skrz SDN sieť.

Okrem translačného PCU by naša sieť obsahovala úpravy do SDN controlleru, ako aj jeho napojenie na databázu používateľov (HSS).

Výsledkom by malo byť odstránenie GGSN a SGSN uzlov a výrazné zjedodušenie sieťovej topológie, ako je vidieť na obr. č. 2.

3

1.5 Časový rozvrh Vzhľadom na to, že sa každý z členov tímu venuje počítačovým sieťam aj profesionálne, bolo ťažké nájsť termíny v rozvrhu, ktoré by vyhovovali každému, ako je možné vidieť na priloženej rozvrhovej tabuľke. Ideálny termín pre nás by bol vo štvrtok od 17:00.

Obr. č. 3: tabuľka prekrytia rozvrhov

2 Plán projektu

Zimný semester -‐ týždeň č. 1

● zostavenie tímu ● vypracovanie ponuky


● prezentácia ponuky Zimný semester -‐ týždeň č. 3

● pridelenie témy ● prvé stretnutie s vedúcim projektu ● rozdelenie úloh ● testovanie existujúcich zariadení ● analýza problematiky


● analýza problematiky ● vytvorenie prvotnej predstavy riešenia ● vytvorenie webovej stránky


● testovanie softvéru, ktorý by sme mohli použiť Zimný semester -‐ týždeň č. 6

4

● testovanie softvéru a vytvorenie návodov k nemu Zimný semester -‐ týždeň č. 7

● výber softvéru ktorý budeme používať ● vytvorenie github účtu ● zvolenie funkcií ktoré bude podporovať prototyp


● implementácia experimenter action ● hodnotenie konkurenčného tímu


● implementácia experimenter match Zimný semester -‐ týždeň č. 10

● implementácia experimenter match ● implementácia experimenter action


● dokončenie implementácie prototypu ● spracovanie dokumentácie


● príprava prezentácie

3 Úlohy členov tímu

Peter Balga

● tvorba zápisníc zo stretnutí ● formátovanie dokumentácie ● dokumentácia riadenia ● analýza Netconf, Yang ● testovanie Pox, Open vSwitch

Tibor Hirjak

● analýza SDN, OpenFlow, GRE tunelov ● testovanie Pox, Open vSwitch ● implementácia forwarderu

Martin Kalčok

● správa webu ● tvorba zápisníc zo stretnutí ● testovanie ofsoftswitch13 a Open Daylight ● implementácia controlleru

5

Matúš Križan

● analýza controllerov ● testovanie Open vSwitch a Trema ● návrh posudku konkurenčného tímu ● implementácia controlleru

Ján Skalný

● vedúci tímu ● analýza GPRS ● návrh riešenia ● testovanie ofsoftswitch13, Mul, Ryu ● implemenácia forwarderu

3.1 Autorstvo členov v dokumentácii

Úvod - Balga 1. Analýza - Balga

1.1 GPRS - Balga 1.1.1 Architektúra - Skalný 1.1.2 Gb rozhranie - Skalný 1.1.3 Gn rozhranie - Hirjak 1.1.4 Signalizácia - Skalný

1.2 SDN - Hirjak 1.2.1 Openflow - Hirjak 1.2.2 NETCONF a YANG - Balga

1.3 Existujúce projekty 1.3.1 SDN Controllery - Kalčok, Skalný, Hirjak, Balga, Križan 1.3.2 OpenFlow forwardery - Kalčok, Skalný, Hirjak, Balga, Križan 1.3.3 Testovanie SDN - Skalný 1.3.4 GSM a GPRS - Balga, Skalný

2. Návrh - Skalný 2.1 Architektúra - Skalný 2.2 Funkcie jednotlivých uzlov - Kalčok, Hirjak, Skalný

2.2.1 Forwarder - prijatie rámca od BSS - Skalný 2.2.2 Forwarder - prijatie rámca z externej IP siete - Skalný 2.2.3 SNDCP Fragmentácia na forwarderoch - Skalný 2.2.4 Rozšírenie openflow protokolu - Skalný 2.2.5 Controller - Skalný 2.2.6 vGSN - Skalný

2.3 Výber Controlleru a Forwarderu - Skalný, Kalčok, Križan 2.4 Mapovanie GTP na GRE - Hirjak 2.5 Špecifikácia OpenFlow rozhrania - Kalčok, Skalný

2.5.1 GPRS Experimenter actions - Kalčok, Skalný 2.5.2 OXM_GPRS Match Class - Kalčok, Skalný

2.6 Špecifikácia REST rozhrania - Skalný

6

2.7 Špecifikácia Gb-sig rozhrania - Skalný 3. Implementácia

3.1 Controller (Ryu) - Kalčok, Skalný 3.1.1 Experimenter Actions - Kalčok 3.1.2 Custom Matches - Kalčok 3.1.3 Základná logika controlleru - Kalčok

3.2 Forwarder (ofsoftswitch13) - Skalný 3.2.1 Ako funguje ofsoftswitch13 - Skalný 3.2.2 Podpora pre Experimenter actions v oflib-exp - Skalný 3.2.3 Implementácia GPRS Experimenter actions - Hirjak 3.2.4 Implementácia vlastných OXM_GPRS_ match pravidiel - Skalný

3.3 Prototyp a jeho testovanie - Hirjak, Skalný 4. Záver - Balga, Hirjak, Skalný

4 Záznamy zo stretnutí

4.1 Zápisnica zo stretnutia č.1

Dátum a čas: 10.10.2013, 16:30-20:30 Prítomný pedagóg: Martin Nagy Prítomní členovia tímu: Balga, Hirjak, Kalčok, Križan, Skalný

Čo vieme nové:

● Máme pozreté Open Daylight, Open Floodlight. ● Máme pozretú špecifikáciu OpenFlow 1.0 - 1.4. ● Rozbehať Open Daylight je problematické. ● Cisco zdržuje Open Daylight. ● Open Daylight je dobrý nápad lebo sa mame na koho obrátiť, stojí za ním veľká

komunita. ● Alternatíva k openFlow - Forces.

Nové nápady/predstavy:

● Predstava(Nagy) - SGSN ako plugin do Open Daylightu. ● Predstava(Skalný) – EPCU oddeľuje signalizáciu a dáta. Používateľské dáta sa balia

do GRE-tunelu, signalizácia sa cez OSMO posiela do controlleru. ● SGSN stále ovláda mobility management. ● Pri aktivácii PDP kontextu sa zobudí controller a vytvorí tunel. ● EPCU by malo byť čo najmenej "custom" hardware/soft. ● BSSky budú používať len IP protokol, nebude použitý frame relay. ● Je to nový projekt, treba sa sústrediť na základnú funkcionalitu.

7

Ešte potrebujeme:

● Pozrieť si call flow-y. ● Rozdeľovanie signalizácie od dát: SAPI indetifikátor, SAPI1=signalizácia. ● Treba zohnať controller ktorý je schopný ovládať vSwitch/balenie/oddeľovanie. ● Pozrieť patenty od google.

Úlohy do budúceho týždňa:

● Naštudovať možnosti OpenFlow. ● Napísať si mail o Nokia dokumente o GPRS. ● Zhodnotiť ktorý controller/ktorým smerom chceme ísť. ● Rozbehať vSwitch.

Progres na stretnutí:

● Rozbehali sme hovor cez BTS. ● GPRS nechodilo. Po reštarte BTS začalo chodiť GPRS pre jeden telefón s externou

SIM kartou (SIM karta nebola "domáca" na našej sieti). SGSNa je nastavená tak aby to behalo nezávysle od toho aké APNko je nastavene v mobile a vždy to pošle len na to jedine GGSN ktoré mame. Pakety naspäť nechodia - Podozrenie na zlé nastavenie NAT.


Dátum a čas: 17.10.2013, 16:30-18:00 Prítomný pedagóg: Martin Nagy, Ivan Kotuliak, Pavol Helebrandt Prítomní členovia tímu: Balga, Hirjak, Križan, Skalný


● Použitie Yang/netconf. ● Šifrovanie riešiť nebudeme. ● Neriešime mobility management. ● Riešime prihlasovanie do siete.

Ešte potrebujeme:

● Čo chceme od controllera? Aké možnosti podporuje aký controller? ● Spôsob komunikácie ePCU - Controller (vlastný socket +volania/java-c/yang/netconf). ● Navrhnúť testovacie prostredie. ● Pozrieť balíčky Open Daylight. ● Ktoré scenáre by mala architektúra zvládnuť?

8


● Spísať 2-3 A4, o architektúre, čo chceme, aké interface-i, moduly ktorých sa nedotkneme, moduly ktoré zmeníme a dať tam základný popis funkcionality jednotlivých blokov. (Skalný)

● Zistiť či vieme použiť yang a netconf. Pozrieť sa na jeho výhody. (Balga) ● Možnosť mapovania GTP na GRE. Ako vyzerá hlavička? ako to mapovať? Prečo

chceme GRE? (Hirjak) ● Aké vlastnosti podporuje aký controller, forwarder? (Križan) ● Vytvorenie webovej stránky. (Kalčok)




● Nepoužijeme netconf. ● Podľa teoretickej analýzy je najlepší RYU controller. ● GRE použijeme, podporuje ho aj OpenFlow. ● OpenFlow nepozná Gb pakety - musíme doimplementovať pomocou “extension 42” ● Funkcionalitu “extension 42” musíme doimplementovať aj do controlleru.

Ešte potrebujeme:

● Nájsť forwarder s podporou “extension 42”.


● Rozbehnúť SDN sieť. ● Každý si vyberie kombináciu forwarder/controller a vyskúša:

○ Tibor a Peter - Open vSwitch + POX ○

Martin - CPQD + Open Daylight-

○ Matúš - Open vSwitch + Trema ○

Jano - CPQD + Mul-

● Spraviť návody, ako rozbehať forwarder/controller.


Dátum a čas: 29.10.2013, 14:00-15:00 Prítomný pedagóg: Martin Nagy, Ivan Kotuliak Prítomní členovia tímu: Balga, Hirjak, Kalčok, Skalný

9


● MUL je síce pekný a funguje, má zlú dokumentáciu. ● RYU môže byť, podarilo sa ho rozbehať. ● Open vSwitch a POX sme vedeli prepojiť. ● Ryu a Trema sú po Open Daylighte najpopulárnejšie.


● Spraviť tabuľku s kontrontolermi + info o nich.


Dátum a čas: 07.11.2013, 16:00-17:00 Prítomný pedagóg: Martin Nagy, Pavol Helebrandt Prítomní členovia tímu: Balga, Hirjak, Kalčok, Križan, Skalný


● Rozhodujeme sa medzi RYU a Trema-edge, hlasujeme za RYU.

Ešte potrebujeme:

● Do dokumentácie pekný opis SDN. ● Návody dáme ako prílohu do dokumentácie. ● Prototyp bude podporovať experimenter match a experimenter action.


● Práca na dokumentácii: ○ Analyza openFlow, SDN - Hirjak. ○ Návrh riešenia - Skalný. ○ Zjednocovanie dokumentácie - Balga.

● Rozbehať github. ● Preštudovať forwarder - Križan. ● Preštudovať controller - Kalčok.


Dátum a čas: 14.11.2013, 16:00-16:30 Prítomný pedagóg: Martin Nagy, Pavol Helebrandt Prítomní členovia tímu: Balga, Hirjak, Kalčok, Križan, Skalný

Hotové:

● Dokumentácia

10


● Každý si rozbehá doma topológiu controller - forwarder. ● Ohodnotiť dokumentáciu konkurenčného tímu - Križan. ● Experimenter action - kontroler - Balga, Kalčok. ● Experimenter action - forwarder - Skalný, Hirjak. ● Doniesť notebook na budúce stretnutie - Kalčok.


Dátum a čas: 21.11.2013, 16:00-17:00 Prítomný pedagóg: Martin Nagy, Pavol Helebrandt Prítomní členovia tímu: Balga, Hirjak, Kalčok

Hotové:

● Experimenter action. ● Hodnotenie konkurenčného tímu.

Ešte potrebujeme:

● Vie wireshark rozpoznávať openflow?


● Preradenie: Balga aj Hirjak idu do forwardera. ● Experimenter match.


Dátum a čas: 28.11.2013, 16:00-18:00 Prítomný pedagóg: Martin Nagy, Ivan Kotuliak, Pavol Helebrandt Prítomní členovia tímu: Balga, Hirjak, Kalčok, Križan, Skalný


● Nepodarilo sa naimplementovať experimenter match na forwarderi, spravíme radšej vlastnú triedu oxm_class.

● Wireshark vie openflow 1.3, ale potrebuje dissector.


● controller - upraviť na viac matchov - Kalčok, Križan ● ďalsie akcie do fw - Hirjak ● ďalsie matche - Skalný ● dokumentácia - Balga


Dátum a čas: 5.12.2013, 16:30-18:00

11

Prítomný pedagóg: Martin Nagy, Pavol Helebrandt Prítomní členovia tímu: Balga, Hirjak, Kalčok, Križan, Skalný

Hotové:

● Úlohy z predošlého stretnutia.


● forwarder - push akcie ● dokumentácia


Dátum a čas: 22.01.2014, 12:00-13:00 Prítomný pedagóg: - Prítomní členovia tímu: Balga, Križan, Skalný

Úlohy na nasledujúce týždne:

● upraviť dokumentáciu




● ako sa Ryu dozvie o sieti?


● controller - vytvárať GRE-tunely - Kalčok, Križan ● forwarder - push akcie - Hirjak, Skalný ● test topológia - Skalný ● dokumentácia, reprezentácia grafu - Balga




● openflow nevie vytvárať GRE tunely ● budeme meniť MAC adresy packetov

12


Dátum a čas: 11.03.2014, 12:00-15:00 Prítomný pedagóg: Martin Nagy, Ivan Kotuliak Prítomní členovia tímu: Balga, Hirjak, Kalčok, Skalný

Ešte potrebujeme:

● Ako riešiť L2 pakety v sieti?


● push akcie - Hirjak ● testovanie - Skalný ● session management - Skalný, Kalčok ● yang - traffic engineering parametre - Balga


Dátum a čas: 18.03.2014, 12:00-14:00 Prítomný pedagóg: Martin Nagy, Ivan Kotuliak Prítomní členovia tímu: Balga, Hirjak, Kalčok, Križan, Skalný

Hotové:

● Dokumentacia - kapitola o tunelovani sprav

Ešte potrebujeme:

● IIT.SRC článok ● Controller/vGSN ReST API design ● vGSN implementation


● REST rozhranie na controlleri + specifikacia do dokumentácie ● Generovanie openflow pravidiel pre tunely z grafu



Hotové:

● [edge FW] Push akcie / cesta späť ● IIT.SRC článok ● Generovanie openflow pravidiel pre tunely z grafu

Ešte potrebujeme:

● dokumentovať co je naprogramované

13

● spojenie GPRS a tunelov


● počítadlá a sekvečné čísla na forwarder



Hotové:

● počítadlá a sekvečné čísla na forwarder



Hotové:

● Výpadok linky a forwarderu - prepocitavanie trás pre (vybrané) tunely

Ešte potrebujeme:

● Testovanie existujúcej topológie s osmoBTS ● Pridanie do XML, Data Path ID, description, type, bandwidth, physical delay, link type

(optical,wireline wireless) (pre edge aj pre node) ● štartovanie forwarderov na zaklade XML ● testovacie scenáre


● IITSrc poster



Hotové:

● REST rozhranie na controlleri + špecifikácia ● vGSN implementation ● Pridanie do XML, Data Path ID, description, type, bandwidth, physical delay, link type

(optical,wireline wireless) (pre edge aj pre node)

Ešte potrebujeme:

● Článok na konferenciu

14

● keepalive medzi vGSN a controllerom, kvôli aktívnym PDP kontextom ● testovanie vGSN (GMM scenáre)


● úpravy návodov na používanie / testovanie ● zisťovanie MAC adresy APN cez ARP ● vytváranie tunelu na komunikáciu medzi BSS a vGSN ● DHCP na controlleri



Hotové:

● počítadlá a sekvečné čísla forwarder ● pridelenie IP adries - controller



Hotové:

● zisťovanie MAC adresy APN cez ARP

4.x Zápisnica zo stretnutia č.x


Hotové:

●

Ešte potrebujeme:

● V


● P

15

5 Štandardy kódovania Formátovanie dokumentácie:

● horný okraj: 3,0 cm ● dolný okraj: 2,0 cm ● ľavý okraj: 2,5 cm ● pravý okraj: 2,5 cm ● typ písma: Arial ● veľkosť písma: 11 ● farba písma: čierna ● riadkovanie: 1,15

Použité nástroje a jazyky pri implementácii:

● Ubuntu 12.04 ● sysmoBTS ● Osmocom OpenBSC ● Python ● C ● OpenFlow ● veth ● ip-netns ● git ● XML ● NetworkX

6 Manažment verzií, komunikačné nástroje Náš tím v rámci projektu používa viaceré nástroje na uľahčenie a zefektívnenie práce:

● Facebook: Ako hlavný komunikačný kanál medzi členmi tímu, sme si vytvorili facebook skupinu. V rámci nej je jednoduché prispievať ku každej téme zlášť a prehľadne. Využívame aj spoločný chat na facebooku na rýchlu diskusiu.

● Google Drive: Na správu spoločných dokumentov využívame službu Google Drive, ktorá nám poskytuje bezplatné úložisko. Väčšinu naších dokumentov vytvárame a rozširujeme tiež pomocou služieb Google, ako je napríklad Google Doc. Súbory sú uložené online, a členovia tímu môžu na nich pracovať aj súčasne.

● GitHub: Na zdieľanie zdrojových súborov softvéru využívame služby online hostingu GitHub. Pomocou nej sme si spravili vlastnú vetvu vývoja Open vSwitchu a RYU kontrollera. Na správu verzií používame softvérový systém git.

● Trello: Na zápis a udržanie úloh používame trello.com

16

Slovenská technická univerzita v Bratislave

Fakulta informatiky a informačných technológií

Aplikácia softvérového smerovania (SDN) v GPRS sieti

Posudok na vytvorený produkt tímu č.4

Študijný program: Počítačové a komunikačné systémy a siete

Študijný odbor: 9.2.4 Počítačové inžinierstvo

Miesto vypracovania: Ústav počítačových systémov a sietí, FIIT STU Bratislava

Členovia tímu:

Bc. Filip Filip

Bc. Koren Jan

Bc. Meliš Peter

Bc. Ondruš Vladimír

LS 2013/2014

Úvod

Účelom tohto dokumentu je posúdiť vytvorený produkt a jeho dokumentáciu nášho

konkurenčného tímu č.4 v rámci tímového projektu. V prvej časti sa nachádza posudok na

vytvorený produkt vytvorený na základe prezentácie, po ktorom nasleduje posúdenie

formálnej stránky dokumentu. V poslednej časti tohto dokumentu sa nachádza celkové

zhodnotenie vykonanej a prezentovanej práce.

1.Produkt Úlohou produktu vytvoreného konkurenčným tímom bolo oddeliť v sieti GPRS

signalizáciu od dát pomocou SDN, čo dokáže v reálnej prevádzke 2G siete odstrániť niektoré

zariadenia a tým ušetriť náklady.

Na základe analýzy v zimnom semestri sa rozhodli využiť controller Ryu a forwarder

ofsoftswitch13. Kľúčovým v tomto rozhodnutí bol controller Ryu (výber forwarder-u

vychádzal z tohto rozhodnutia), ktorého výber hodnotíme na základe opísanej analýzy

pozitívne.

Kladne hodnotíme aj použitie vlastného riešenia využívania lokálne-signifikantných

MAC adries ako identifikátorov point-to-point spojení, čím sa vyhli vytváraniu GRE tunelov

cez OpenFlow.

Pomocou Ryu controlleru sa najskôr automaticky získajú informácie o topológií v sieti

na základe ICMP správ rozosielaných všetkými portami novo vloženého forwarderu do siete.

Pomocou zakódovanej informácie o odosielateľovi v payload-e ICMP správy získajú tieto

informácie o sieti kompletné.

Vo vytvorenej sieti nahrádza úlohu SGSN uzla uzol vGSN. Komunikáciu medzi

vGSN a controller-om riešia pomocou REST rozhrania. Pomocou vGSN uzlu taktiež nahradili

úlohu GGSN uzlu odpovedať na aktiváciu PDP kontextu. Túto funkcionalitu dosiahli

pomocou rozumného spojenia volaní knižnice libgtp a časti vytvoreného open-ggsn projektu.

Oba uzly označené počas návrhu za nadbytočné, teda SGSN aj GGSN, sa teda tímu

č.4 podarilo odstrániť a ich funkcionalitu nahradil vGSN uzol, ktorý bol vytvorený za pomoci

existujúcich riešení doplnených o ich vlastné rozšírenia. Konkurenčnému tímu sa teda

podarilo vytvoriť funkčné riešenie tak, ako ho navrhli na začiatku práce na projekte, teda

oddelenie signalizácie od používateľských dát. O mapovanie používateľských dát z PDP

kontextov do tunelov (a naopak) sa teda stará controller riadený správami od vGSN.

Počas praktickej prezentácie nám bola na viacerých zariadeniach (aj jednom našom)

demonštrovaná funkčnosť celého systému. Telefón pripojený do pokusnej mobilnej siete

nemal problém pripojiť sa k internetu a pretekajúce pakety sme sledovali pomocou programu

Wireshark na jednotlivých uzloch.

V bežných mobilných sieťach môže byť problém, že v prípade zlyhania niektorého zo

zariadení nie je možné toto zariadenie jednotlivo reštartovať a je nutné odznova spustiť celý

okruh. Veľkou výhodou riešenia konkurenčného tímu je aj fakt, že okrem zníženia nákladov

spôsobeného odstránením nadbytočných uzlov, je možné reštartovať napríklad controller

a celá sieť s tým nemá žiaden problém.

Aj vďaka spomenutým vlastnostiam hodnotíme vytvorený a odprezentovaný produkt

v rámci tímového projektu stupňom „vynikajúci“.

2.Formálna stránka

Evidujeme viditeľné zlepšenie formálnej stránky záverečného dokumentu oproti

predchádzajúcim správam, aj keď veľké množstvo skratiek v texte stále zostalo a počas

čítania dokumentácie sme museli listovať slovník pojmov viackrát, než obvykle pri čítaní

podobných dokumentov. Tento problém je ale z veľkej časti spôsobený aj vysokou

odbornosťou projektu a človek neznalý problematiky len ťažko porozumie tejto správe bez

adekvátnej prípravy. Po gramatickej stránke je dokument v poriadku, zaregistrovali sme len

veľmi málo pravopisných chýb, ktoré však pri čítaní dokumentu nepôsobia vôbec rušivo.

Formálnu stránku dokumentácie teda hodnotíme stupňom „veľmi dobrý“.

3.Zhodnotenie

Celkovo hodnotíme prácu konkurenčného tímu na tímovom projekte, vytvorený

produkt, predvedenie jeho funkčnosti a dokumentáciu k produktu stupňom „výborný“.

Fakulta informatiky a informačných technológií

Slovenská technická univerzita

Vypracoval tím č. 4: Bc. Peter Balga, Bc. Tibor Hirjak, Bc. Martin Kalčok, Bc. Matúš Križan, Bc. Ján Skalný Vedúci tímu: doc. Ing. Ivan Kotuliak, PhD. Akademický rok: 2013/14

Správa o testovaní posudzovaného systému a

posudok dokumentácie tímu č. 5 Interaktivita mobilného zariadenia a televízie

2

1. Úvod Tento dokument obsahuje správu o testovaní posudzovaného systému prezentovaného tímom

č. 5 a posudok dokumentácie. Tím pracoval na projekte s názvom "Interaktivita mobilného

zariadenia a televízie". Posudok obsiahnutý v tomto dokumente sa skladá z dvoch častí. V

prvej časti hodnotíme prezentovaný produkt a v druhej časti hodnotíme predloženú

dokumentáciu.

2. Správa o testovaní posudzovaného systému Posudzovaný systém sa skladá z troch častí:

x serverová časť

x aplikácia pre mobilné zariadenie

x webová aplikácia

2.1. Serverová časť Základ serverovej časti tvorí Apache web server, podporovaný MySQL databázou. Ako zdroj

multimédií slúži VLC media player, ktorý zároveň zabezpečuje aj transkódovanie.

Počas prezentácie nám bola predvedená bezproblémová funkčnosť systému, vrátane

záťažového testu viacerými zariadeniami a aj možnosti transkódovania.

2.2. Aplikácia pre mobilné zariadenie Prezentovaná aplikácia pre mobilné zariadenie potrebuje na svoj chod verziu Android

minimálne 4.0 a je závislá od externej aplikácie VLC. Pre správnu funkčnosť je potrebné si

ručne nainštalovať VLC beta z Google Play Store, čo môže byť mierne neintuitívne.

Po spustení aplikácie nás privítala úvodná obrazovka so základnými možnosťami. Prvou je

prihlásenie do systému, druhou je možnosť priamo zadať adresu streamu a začať ho sledovať

bez prihlásenia.

Pre prihlásenie do systému treba zadať meno a heslo, pod ktorým sa užívateľ registroval na

serveri.

3

Po úspešnom prihlásení sa používateľovi zobrazí zoznam dostupných TV staníc. Po kliknutí

na jednu z nich si zvolí, či ju chce prehrať na svojom zariadení, poslať na iné zariadenie alebo

pozrieť si TV program pre danú stanicu.

Zvolenie možnosti prehrávania presmeruje používateľa na obrazovku, kde musí manuálne

kliknúť na tlačidlo, ktoré spustí VLC. Toto riešenie by bolo vhodné spraviť viac intuitívne.

Pre spustenie streamu na inom zariadení musí byť toto zariadenie aktuálne prihlásené a mať

aktivované počúvanie prichádzajúcich streamov.

Možnosť "TV programme" spustí webový prehliadač a presmeruje používateľa na externý

server. Lepším riešením by bolo použitie napríklad webview prvku, aby sme zabránili

odídeniu z aplikácie. Za pomerne nešťastné riešenie tiež pokladáme pomenovanie

programového sprievodcu ako "TV programme", keďže to znamená niečo iné, ako funkcia

robí.

2.3. Webová aplikácia Webová aplikácia ponúka možnosť registrácie používateľa a ďalšie spravovanie

používateľských účtov. Ďalej je možné spustiť vybraný stream z ponuky a taktiež zobraziť

TV pogram.

Po prihlásení do účtu správcu je možné sledovať štatistiky pozeraných TV programov a

autorizovanie zariadení.

2.4. Zhodnotenie Projekt ako celok spĺňa požadovanú funkcionalitu. Vzhľadom na zmenšenie tímu bolo z

finálnych požiadaviek vypustených zopár zaujímavých funkcií, ako napríklad ovládanie

gestami.

Do budúcna by sme konkurenčnému tímu doporučili zapracovať na užívateľskom prostredí

aplikácie, ktoré teraz pôsobí naozaj sparťansky. Taktiež by bolo vhodné naštudovať si

možnosti Android Intent a kontrolovať si, či spadol externý program a v takomto prípade ho

znova spustiť, alebo aspoň oznámiť používateľovi, čo sa stalo.

4

3. Posudok dokumentácie V tejto kapitole posudzujeme projektovú dokumentáciu spolu s dokumentáciou riadenia, z

pohľadu formálnej aj obsahovej stránky.

3.1. Projektová dokumenácia 3.1.1. Formálna stránka

Formálnu stránku odovzdanej dokumentácie k prototypu tímu č. 5 musíme hodnotiť na

výbornú. Tím sa poučil z predchádzajúcich chýb a v dokumentácii sa nenachádzajú žiadne

obrázky bez popisu alebo odkazu v texte. Štylisticky a gramaticky vyzerá text v poriadku.

3.1.2. Obsahová stránka V porovnaní s dokumentáciou z predchádzajúceho semestra, konkurenčný tím doplnil obsah

kapitoly analýzy, návrhu a pridal kapitoly pojednávajúce o implementácii, overení riešenia a

zhodnotenie.

Štvrtá kapitola, návrh riešenia, obsahuje dostatočne obšírny popis návrhu systému a jeho častí,

vrátane databázy a prípadov použitia. Vynikajúco spracovaný je opis komunikácie medzi

jednotlivými časťami systému.

Kapitola číslo 5 pojednáva o implementácii štyroch hlavných komponentov systému:

serverovej aplikácie, mobilnej aplikácie, web aplikácie a databázy. V tejto kapitole by sme

prijali okrem dostatočného popisu implementácie aj zaujímavé časti kódu, prípadne popis

častí, ktoré boli najväčšou výzvou.

Šiesta kapitola pojednávajúca o overení riešenia je krátka, dôvod čoho je vysvetlený v ďalšej

kapitole dokumentu, zhodnotení.

Jediná výtka siedmej kapitoly je pomenovanie jednej z jej častí "Čo sme nestihli", bolo by

vhodné pouvažovať nad diplomatickejším názvom.

Veľmi oceňujeme pridané diagramy vo všetkých kapitolách, ktoré zjednodušujú pochopenie

celej architektúry a uvažovania pri návrhu.

5

3.2. Dokumentácia riadenia Dokumentácia riadenia tímu č.5 je spracovaná excelentne. Obsahuje ponuku z prvého

semestra, plán projektu, úlohy členov tímu a záznamy zo všetkých stretnutí.

Zápisy zo stretnutí sú veľmi podrobné a obsahujú všetky potrebné informácie.

Po formálnej, ani po obsahovej stránke, naozaj nie je čo vytknúť.

3.3. Zhodnotenie Je zrejmé, že konkurenčný tím si dal na dokumentácii záležať, aj po formálnej aj po

obsahovej stránke.

aplikácia softvérového smerovania (sdn) v gprs sieti fileÚvod tento dokument obsahuje prehľad o...

Documents