7   Liberouter

Zkušenosti několika posledních let ukazují, že CESNET může hrát velmi užitečnou roli koordinátora výzkumných projektů, na nichž kromě vlastních kmenových pracovníků spolupracují zaměstnanci a studenti několika vysokých škol či Akademie věd ČR. Tento model se osvědčil zvláště u komplexnějších projektů jako je DataGrid (viz kapitola 13) a v posledních dvou letech i Liberouter. Efektivní a cílená spolupráce různých výzkumných pracovišť je problémem nejen naším, ale přinejmenším i evropským, o čemž svědčí mimo jiné podpora vytváření "Networks of Excellence" v rámci 6. rámcového programu EU. CESNET může v takovýchto případech sloužit jako potřebná neutrální platforma a garant výzkumných aktivit, na nichž pracují týmy sestavené ad hoc pro konkrétní projekt. Je rovněž důležité, že CESNET je schopen pro takovéto distribuované týmy technicky zajistit nezbytné nástroje pro spolupráci - videokonference, webové portály a jiné služby.

Na projektu Liberouter se v současnosti podílí přibližně 50 osob, z nichž polovinu tvoří studenti pěti vysokých škol (MU a VUT v Brně, ČVUT a VŠE v Praze a ZČU v Plzni). Základním úkolem projektu je vývoj směrovače IPv6 a IPv4 na bázi osobního počítače. Oproti běžnému řešení PC směrovače s unixovým operačním systémem a směrovacími démony (Zebra, GateD apod.) má směrovač Liberouter zajistit:

  1. Vyšší propustnost směrovače, přibližně v rozmezí 5-10 Gb/s, tedy zhruba desetinásobně v porovnání se standardním hardwarem PC.
  2. Jednotné konfigurační rozhraní srovnatelné s komerčními směrovači.

K dosažení prvního cíle má sloužit hardwarový akcelerátor založený na technologii programovatelného hardwaru. Řešení druhého cíle jsme se rozhodli pojmout poněkud šířeji a vytvořit obecný konfigurační systém, jenž bude možno použít i pro běžně používané platformy směrovačů a také pro efektivnější konfiguraci celých sítí.

Všechny výsledky projektu jsou veřejně dostupné včetně zdrojových kódů. Pro různé součásti projektu používáme vždy jednu z následujících licencí, které jsou všechny typu open source:

Podíleli jsme se také na přípravě licenční politiky CESNETu a směrnic pro ochranu duševního vlastnictví.

7.1   Hardwarový akcelerátor

Architektura hardwarového akcelerátoru PC směrovače, popsaná v loňské zprávě [Gru03], nedoznala žádných výraznějších změn. Je založena na principu hardwarově-softwarového kodesignu, při němž se hledá optimální rozdělení funkcí mezi hardware a software. V případě směrovače IP je takové rozdělení nasnadě:

Důležitým principem, který nám umožňuje v co největší míře využít existující software, je plná integrace specializovaného hardwaru do prostředí operačního systému. Jinak řečeno, operační systém pracuje s naším hardwarovým akcelerátorem přesně tak, jako by to byla běžná víceportová ethernetová karta.

Do roku 2003 jsme vstupovali s prvním vyrobeným exemplářem hlavní karty COMBO6. V průběhu ledna a února byla tato karta postupně oživována a testována. Přitom jsme zjistili dva drobné nedostatky hardwarového návrhu, které nijak neomezují funkce, pouze zabraňují dosáhnout plného výkonu hardwaru. Proto jsme se rozhodli vyrobit pro vývojové účely ještě další čtyři kusy karty COMBO6 podle původního návrhu. V druhém pololetí 2003 jsme pak navrhli novou revizi karty, na níž jsou nalezené chyby odstraněny. Další kusy karty budou již vyráběny podle opraveného návrhu.

Karta COMBO6 není sama o sobě osazena žádnými porty síťových rozhraní. Ty je nutno doplnit připojením dceřiné karty. V roce 2003 byly navrženy a vyrobeny dvě takové karty:

  1. COMBO-4MTX se čtyřmi metalickými porty gigabitového Ethernetu, viz obrázek.
  2. COMBO-4SFP se čtyřmi porty gigabitového Ethernetu v podobě klecí pro adaptéry GBIC typu SFP, kterými lze realizovat různá optická rozhraní (jedno- i mnohavidová, CWDM) a dokonce i metalická. Viz obrázek.
[Obrázek]

Obrázek 7.1: Karta COMBO-4MTX

[Obrázek]

Obrázek 7.2: Karta COMBO-4SFP

Obrázek ukazuje výsledný "sendvič", v němž je karta COMBO6 spojena speciálními konektory s kartou rozhraní COMBO-4SFP.

[Obrázek]

Obrázek 7.3: Spojení karet COMBO6 a COMBO-4SFP

Ve stadiu návrhu je rovněž karta se dvěma porty desetigigabitového Ethernetu. Narážíme zde ovšem na obtížnou dostupnost obvodů pro 10GE. První karta rozhraní 10GE, jež by měla být vyrobena v 1. čtvrtletí 2004, proto bude interně rozkládat čistý kanál 10GE na čtyři kanály po 1 Gb/s. V další verzi pak použijeme buď čipové sady 10GE, bude-li již možno je získat, anebo příslušné funkce implementujeme sami v hradlovém poli.

Návrh hardwaru je podrobně popsán v článku [NAF03] a technických zprávách 12/2003 a 13/2003.

7.2   Firmware

Nejobtížnějším úkolem, který se v roce 2003 nepodařilo zcela dokončit, je vývoj firmwaru, tedy speciálních programů pro hradlové pole, které zajišťují přijetí paketu ze vstupního síťového rozhraní, zpracování informací z jeho hlaviček, rozhodnutí o tom, jak se s paketem naloží, a konečně jeho odeslání příslušným výstupním rozhraním.

[Obrázek]

Obrázek 7.4: Schéma firmwaru karty COMBO6

Obrázek znázorňuje celkové schéma firmwaru, který sestává z následujících modulů:

HFE (Header field extractor)
Tento modul má za úkol získat potřebné informace z hlaviček linkové a síťové vrstvy (stavové registry L2 a L3, zdrojové a cílové adresy MAC a IP, zdrojový a cílový port, značka VLAN aj.) a uložit je do struktury zvané unifikovaná hlavička (UH, unified header). Ta má celkem 596 bitů a obsahuje potřebné údaje na pevných relativních pozicích.
DRAM (Dynamic random access memory)
V průběhu zpracování hlavičky je celý obsah paketu uložen v dynamické paměti karty COMBO6. Ostatní moduly pracují pouze s jeho adresou v DRAM a teprve na konci procesu modul OPE vybere obsah paketu z DRAM a sestaví celý paket.
LUP (Look-up processor)
Nejsložitější firmwarový modul, který musí rozhodnout o tom, jak se má s paketem naložit, tedy především, zda se má paket vůbec předat dále a pokud ano, tak jak se má upravit a na jaké (jaká) rozhraní se má odeslat. Proces vyhledávání v LUP si můžeme představit jako vyhledávací strom, který postupně čte pole unifikované hlavičky a na základě jejich obsahu volí další postup. Implementace LUP tento problém řeší ve dvou fázích: Nejprve se použije rychlého vyhledání v asociativní paměti CAM (Content Addressable Memory), která však je schopna pokrýt maximálně zhruba polovinu bitů UH a navíc ji nelze použít pro efektivní vyhledávání rozsahů (např. rozmezí portů). Bity UH, které nepokryje CAM, se proto dohledávají algoritmem implementovaným přímo v hradlovém poli. Návrh modulu LUP je podrobně popsán v článku [ICN04].
REP (Replicator)
Tento modul v případě potřeby replikuje pakety (přesněji ukazatele na pakety). To je potřeba především pro IP multicast, ale také například pro implementaci podpory programů typu tcpdump.
QUE (Output queue)
Paket připravený k odeslání je zařazen do jedné z výstupních front. Soubor těchto front je v současné verzi firmwaru spravován v režimu prioritních front.
OPE (Output packet editor)
Úkolem výstupního editoru paketů je znovusestavit celý paket a upravit všechny potřebné údaje jak podle požadavků příslušného protokolu (např. TTL v hlavičce IPv4), tak i podle instrukcí předaných modulem LUP.

Většina výše uvedených modulů se ve firmwaru nachází ve čtyřech exemplářích - po jednom pro každý vstupní nebo výstupní port. Počet výstupních front (QUE) je konfigurovatelný.

Jak je též vyznačeno v obrázku, všechny moduly mohou v případě potřeby komunikovat s hostitelským počítačem přes sběrnici PCI. Této cesty se využívá například při zpracování výjimek, které (dosud) nejsou řešeny přímo v hardwaru.

Všechny uvedené moduly byly paralelně vyvíjeny a simulovány. Vývojáři již také zahájili poměrně komplikovaný proces integrace celého návrhu firmwaru a jeho konečného umístění v hradlovém poli.

7.2.1   Metody a nástroje vývoje firmwaru

Programy pro hradlová pole jsou vyvíjeny v jazyku VHDL (Very High Speed Integrated Circuits Hardware Description Language). Hardwarový tým má k dispozici profesionální vývojové prostředí složené z programů Leonardo Spectrum, FPGA Advantage, HDL Designer a Modelsim, které ovšem mají pro naše účely také některé nevýhody:

  1. Základní uživatelské rozhraní je grafické, což jednak ztěžuje jejich sdílení a vzdálený přístup, ale také neumožňuje efektivně automatizovat a dokumentovat vývojové postupy.
  2. Vývoj v duchu open source obvykle ve velké míře využívá příspěvků nezávislých dobrovolníků, kteří jsou schopni jak nalézat a opravovat chyby, tak i samostatně programovat. To je ovšem v jazyku VHDL možné jen velmi omezeně, neboť zatím neexistuje volně dostupné vývojové prostředí, takže aktivně přispívat mohou jen vývojáři, kteří mají k dispozici nákladné profesionální nástroje.

Vyřešení prvního problému naštěstí nebylo příliš obtížné, protože všechny kroky na cestě od zdrojového kódu ve VHDL k mikrokódu příslušného čipu stejně provádějí programy s řádkovým rozhraním. Proto byl vytvořen alternativní vývojový systém založený na tradičním unixovém nástroji make. S ním lze uspokojivě pracovat i na řádkovém terminálu a navíc v souborech Makefile je možné přesně zachytit všechny fáze překladu programů VHDL.

Problém otevření vývoje firmwaru jsme vyřešili pouze zčásti, a to vytvořením další úrovně abstrakce hardwarového návrhu - tzv. nanoprocesorů. Jde o procesory implementované uvnitř hradlového pole s velmi malou, ale úzce specializovanou instrukční sadou. Implementace výše uvedených firmwarových modulů karty COMBO6 tak má dvě fáze: Nejprve se navrhne vhodný nanoprocesor i s instrukční sadou a pak se pro něj napíše "nanoprogram" v jeho vlastní instrukční sadě, který realizuje všechny potřebné funkce. Zatímco implementace nanoprocesoru vyžaduje plnohodnotné vývojové prostředí VHDL, úpravy nanoprogramů jsou podstatně jednodušší.

Přímá práce se strojovým kódem není ovšem ani u nanoprocesorů příliš pohodlná, a tak bylo naší snahou vytvořit pro každý nanoprocesor efektivnější vývojové prostředí, v němž by bylo možné nanoprocesory programovat alespoň na úrovni jazyka symbolických adres (assembleru). Filip Höfer nakonec ve své bakalářské práci [Hof03] dospěl k pěknému obecnému řešení. Jeho program nsim je generický kompilátor, simulátor a ladicí nástroj pro libovolný nanoprocesor, jehož instrukční sada i sémantika instrukcí se programu nsim popíše jednoduchým deklarativním jazykem. K úplnému vývojovému prostředí chybí již pouze disassembler, který je rovněž ve vývoji.

[Obrázek]

Obrázek 7.5: Snímek okna programu xnsim

Pro podporu kombinovaných simulací více nanoprocesorů a též pro prezentační účely byl program nsim doplněn o grafickou nadstavbu xnsim, viz obrázek. V tomto programu lze postupně simulovat jednotlivé kroky zpracování dat ve firmwaru karty COMBO6. V horní části okna se názorně zobrazuje výměna informací mezi komponentami firmwaru, zatímco ve spodní části vidíme prováděné instrukce nanoprocesoru a jejich výsledky. Vstupem programu xnsim je sada paketů zaznamenaných ve výstupním formátu programu tcpdump.

7.3   Systémový software

Komunikace mezi kartou COMBO6 a hostitelským operačním systémem má dvě hlavní podoby:

  1. Karta COMBO6 spolu s dceřinou kartou rozhraní se chová stejně jako standardní víceportový ethernetový adaptér.
  2. Pro některé účely (instalace firmwaru, ladění) je potřeba mít speciální mechanismy, které u běžných adaptérů neexistují.

Softwarovou podporu obou způsobů komunikace vyvíjíme zároveň pro operační systémy NetBSD a Linux.

První způsob komunikace je umožněn vytvořením tenké vrstvy ovladačů a dalšího systémového softwaru, který zakryje zvláštnosti karty COMBO6. Díky tomu lze pro konfiguraci, správu a monitorování našeho hardwaru použít běžné nástroje operačního systému, jako ifconfig, tcpdump apod.

Vyhledávací procesor LUP, který je implementován v hardwaru karty COMBO6, si udržuje vlastní datové struktury pro klasifikaci a rozhodování o dalším osudu přijatých paketů. Tyto struktury však musí být odrazem analogických informací, které udržuje a spravuje jádro operačního systému, především ve směrovací tabulce a strukturách paketového filtru. Pro správnou funkci karty COMBO6 je proto důležité, aby její vnitřní struktury byly pokud možno stále v souladu s tabulkami jádra. Tuto synchronizaci zajišťuje démon combod, který je jádrem informován o změnách sledovaných tabulek, například pomocí soketu typu netlink v Linuxu.

Přímý přístup ke kartě COMBO6 a dceřiné kartě rozhraní (především pro účely vývoje) zprostředkovává zvláštní ovladač, který je z operačního systému dostupný prostřednictvím dvou znakově orientovaných zařízení /dev/combosix0 a /dev/combosix1. Vyvinuli jsme nástroje pro inicializaci hlavní i dceřiné karty a zavedení firmwaru. Pro usnadnění jednodušších operací (čtení a zápis hodnot z/do specifických registrů a pamětí apod.) a testování byl rovněž vytvořen program comboctl, který poskytuje i možnost symbolické adresace a skriptovací jazyk založený na TCL.

7.4   Formální verifikace

Metody formálního dokazování správnosti, známé i z oblasti softwaru, jsou pro hardware o to potřebnější, že chyby odhalené až po realizaci návrhu mohou být velmi drahé a jejich náprava obtížná. Jak však ukazují všeobecně známé omyly i těch největších výrobců (například chyby v procesorech Intel Pentium), je celková formální verifikace návrhu velmi složitých součástek zatím v oblasti utopie.

V projektu Liberouter spolupracujeme se skupinou formální verifikace Fakulty informatiky MU v Brně. Snažíme se přitom využít formálních postupů pro ověření funkce některých dílčích modulů hardwaru a firmwaru, ale také pomocí metodiky formální verifikace zkvalitnit a objektivizovat práci programátorů, například povinným vkládáním výrokových formulí (assertions) do zdrojového kódu VHDL.

Pro formální verifikaci se používá metoda ověřování modelu (model checking), která se snaží dokázat platnost předepsané specifikace chování daného systému na určité úrovni abstrakce dané vytvořeným modelem tohoto systému. Platnost specifikace se ověřuje procházením celého stavového prostoru možných vstupů a porovnáním výstupu se specifikací. V případě nesouladu je pak okamžitě k dispozici protipříklad.

Pro automatizaci formální verifikace používáme program NuSMV. K popisu modelu využívá tento program speciálního jazyka SMV. Skupina formální verifikace vyvinula sadu skriptů, jimiž lze do tohoto jazyka automaticky transformovat zdrojový kód VHDL.

Formální verifikace byla v projektu Liberouter využita například pro ověření dílčí funkce vyhledávacího procesoru LUP, konkrétně korektního sdílení pamětí CAM a SRAM vyhledávacími procesory všech čtyř portů. Tyto a některé další zkušenosti jsou podrobněji popsány v technické zprávě 17/2003.

7.5   Konfigurační systém Netopeer

Jednou z vlastností, jíž se komerční směrovače na první pohled odlišují od PC s unixovým operačním systémem, je způsob konfigurace a správy. Směrovače nejdůležitějších výrobců, jakými jsou například Cisco Systems nebo Juniper Networks, nabízejí pro tyto účely komfortní a konzistentní řádkové rozhraní, pomocí něhož lze konfigurovat všechny hardwarové i softwarové subsystémy směrovače a monitorovat jejich stav. Konfigurace subsystémů souvisejících s činnostmi směrovače je naproti tomu v unixových operačních systémech rozptýlena do řady konfiguračních souborů a inicializačních skriptů.

Cílem softwaru Netopeer, vyvíjeného v rámci projektu Liberouter, je vytvořit jak konfigurační rozhraní pro PC směrovače srovnatelné s jejich komerčními protějšky, tak i obecně použitelný a na platformě nezávislý systém pro správu konfigurací směrovačů i celých sítí. Základní myšlenkou, ale také dost tvrdým oříškem, je přitom definování neutrálního konfiguračního formátu, do něhož a z něhož se převádějí konfigurace vytvořené pro konkrétní platformu směrovače. Jako jazyk popisu tohoto formátu jsme zvolili XML, především proto, že jeho stromová struktura dobře odpovídá charakteru konfiguračních dat a pro zpracování XML také existuje řada softwarových nástrojů.

Konfigurace zapsané v XML jsou uchovávány ve skladu konfigurací (repository), který mimo jiné podporuje správu verzí. Uživatelským rozhraním jsou tzv. vstupní moduly (front-endy), jejichž hlavním úkolem je transformace konfiguračních dat z uživatelem zadané podoby do XML. Rozeznáváme front-endy dávkové, které dělají pouze tuto transformaci, a interaktivní, které uživateli poskytují podporu při vytváření konfigurace a výstup ukládají do skladu. Rozhraní mezi systémem a cílovým směrovačem pak obstarávají výstupní moduly neboli back-endy. Jejich úkolem je naopak transformace konfigurace z XML do jazyka cílového směrovače, případně též instalace a aktivace této konfigurace.

Vzhledem k tomu, že podstatná část funkcí vstupních i výstupních modulů je jim společná, vytvořili jsme dvě specializované knihovny, které se podle potřeby k modulům připojují:

Obrázek znázorňuje vazbu back-endů i obou typů front-endů na tyto knihovny.

[Obrázek]

Obrázek 7.6: Využití knihoven moduly systému Netopeer

V následujících oddílech popíšeme aktuální stav jednotlivých softwarových komponent.

7.5.1   Schéma konfiguračních dat

Konfigurace směrovačů různých výrobců sice lze obvykle z valné části navzájem převádět, některé subsystémy (zejména paketové a směrovací filtry, které nemají oporu ve standardech IETF) jsou však převoditelné obtížně či neúplně a některé velmi specifické parametry pak mají dokonce význam jen na jediné platformě. Sestavení neutrálního konfiguračního jazyka, který by pokrýval alespoň všechny běžné platformy směrovačů, je tak úkolem značně obtížným až nereálným. Proto jsme se rozhodli vedle obecných částí konfigurace vyjádřených v XML ponechat prostor i pro doslovný zápis částí konfigurací závislých na platformě.

Úplné pokrytí "konvertibilní" podmnožiny konfiguračních dat představuje ale i tak velmi rozsáhlý problém. Proto jsme se rozhodli umožnit vývoj všech součástí systému Netopeer dočasnou definicí neúplného schématu konfiguračních dat, které pokrývá konfiguraci síťových rozhraní (včetně tunelů a VLAN), statického směrování a směrovacích protokolů RIP a RIPng, a konečně paketových a směrovacích filtrů. Toto schéma je popsáno v technické zprávě 2/2003.

7.5.2   Nástroje pro práci s XML

Jako parser XML jsme původně vybrali Xerces, verze pro C++, neboť v té době nejúplněji pokrýval standardy XML. Praktické zkušenosti však ukázaly, že Xerces je přebujelý a pomalý software s nepříjemnými nedostatky (například v zacházení s chybami) a nepřesnou dokumentací. Naštěstí v průběhu roku 2003 dosáhla potřebné úrovně jiná knihovna XML - libxml2, která je naopak velmi rychlá, modulární a dobře dokumentovaná. Z tohoto důvodu byla naše interní knihovna Netopeer-XML přepsána pro libxml2. Popis aktuální verze knihovny Netopeer-XML obsahuje technická zpráva 22/2003.

7.5.3   Sklad konfigurací

Systém pro správu verzí CVS, který všichni členové týmu aktivně používají pro svou práci, není jako základ pro sklad konfigurací příliš vhodný. Hlavním problémem je z našeho hlediska fakt, že neposkytuje aplikační programové rozhraní - je k dispozici pouze jako soubor samostatných programů. To by především komplikovalo zpracování chybových hlášení. Proto jsme se rozhodli použít srovnatelný systém Subversion, který takové API má. Nad ním jsme vybudovali knihovnu, která vytváří API vhodné pro naši aplikaci. Popis její instalace a funkcí lze najít v technické zprávě 21/2003.

7.5.4   Vstupní a výstupní moduly

Všechny vstupní i výstupní moduly, které jsou momentálně k dispozici v různém stadiu rozpracovanosti, se vztahují k výše zmíněnému dočasnému schématu. Ze vstupních modulů je zcela hotov dávkový front-end pro Cisco IOS. Obdobný dávkový front-end pro JUNOS je také funkční, i když zatím plně nepokrývá přechodné schéma. Interaktivní front-endy - řádkový a webový - jsou zatím ve vývoji.

Na straně výstupních modulů jsou z větší části hotovy back-endy pro Cisco IOS a směrovač PC.

Oproti původním plánům jsme opustili vývoj vstupního i výstupního modulu pro SNMP. Ukázalo se totiž, že z hlediska praxe má SNMP pouze okrajový význam a navíc nepokrývá všechny potřebné oblasti konfigurace směrovačů.

7.5.5   Metakonfigurace

Zajímavou aplikací, která má v budoucnu spolupracovat se systémem Netopeer, je metakonfigurace. Ta má umožnit konfigurovat celé sítě na vyšší úrovni abstrakce a přitom při návrhu asistovat jako jistý expertní systém. Metakonfigurace má též umožňovat typizovaná síťová uspořádání ve formě šablon, které lze opakovaně použít s různými parametry. Metakonfigurace bude používat k popisu sítě vlastního schématu XML, z něhož bude automaticky generovat konfigurace jednotlivých směrovačů ve schématu Netopeer.

Metakonfigurace je náplní doktorské práce našeho spolupracovníka Miroslava Matušky a je zatím ve stadiu návrhu architektury.

7.6   Testování

Nezávislé a systematické testování hardwaru i softwaru považujeme za velmi důležitou součást projektu Liberouter. Proto jsme ustavili dvě testovací laboratoře (v Praze na FEL ČVUT a v Brně na ÚVT MU) a v průběhu roku je postupně vybavovali potřebným zařízením - kromě osobních počítačů byl zakoupen také výkonný profesionální analyzátor Spirent AX4000.

Testovací tým podrobně rozpracoval metodologii testování konformance směrovačů IPv6 na základě TAHI Conformance Suite a také provedl rešerši dostupných softwarových prostředků pro testování výkonu směrovačů v technické zprávě 18/2003.

7.7   Řízení projektu, publikace a prezentace

Obtížným úkolem, s nímž navíc řešitelé neměli prakticky žádné zkušenosti, bylo řízení distribuovaného týmu čítajícího několik desítek spolupracovníků. Tento počet si již vynutil zavedení vnitřního hierarchického uspořádání týmu a delegování pravomocí. V roce 2003 jsme proto v rámci projektu utvořili tyto pracovní skupiny:

  1. VHDL - 17 členů, vedoucí Jan Kořenek (VUT Brno)
  2. Systémový software - 11 členů, vedoucí David Antoš (MU Brno)
  3. Formální verifikace - 5 členů, vedoucí David Šafránek (MU Brno)
  4. Testování - 4 členové, vedoucí David Rohleder (MU Brno)
  5. Netopeer - 10 členů, vedoucí Ladislav Lhotka (CESNET)

Hlavními nástroji koordinace týmu byly:

Důležitou roli při podpoře týmové spolupráce hrají různé technické nástroje a služby. Kromě výše zmíněných videokonferencí a poštovních konferencí se nám velmi osvědčilo používání softwaru pro správu verzí CVS, do něhož musí členové týmu ukládat všechny své výsledky včetně dokumentace. Obsah CVS je veřejně přístupný.

Další potřebnou službou, kterou plánujeme zprovoznit v nejbližší době, je systém pro registraci a sledování chyb a žádostí o nové funkce, postavený například na základě softwaru Bugzilla.

Hlavní projektový web se nachází na adrese www.liberouter.org. Z něho jsou dostupné ostatní výše zmíněné služby (CVS přes webové rozhraní, administrativní stránky a archivy poštovních konferencí aj.). Vzhledem k velkému rozsahu vývoje hardwaru a softwaru považujeme za velmi důležité, aby zároveň vznikala kvalitní dokumentace, kterou by bylo možné okamžitě prezentovat na webu a diskutovat v rámci projektového týmu i mimo něj. Přes poměrně velké úsilí a testy systémů CMS (Content Management System), například Plone, jsme zatím k žádnému uspokojivému řešení nedospěli.

Řešitelé projektu prezentovali své výsledky ve třech příspěvcích na mezinárodních konferencích (TNC 2003 v Záhřebu, FPL 2003 v Lisabonu a ICETA 2003 v Košicích) a dalších pět příspěvků na národních konferencích - projektu Liberouter byla věnována celá sekce na XXIII. konferenci EurOpen ve Strážnici. Aktivně jsme se také zúčastnili úspěšného semináře IPv6 - rozvoj a implementace, který uspořádal CESNET 22. 10. 2003. Řešitelé projektu Liberouter jsou autory 11 technických zpráv CESNETu vydaných v roce 2003.

V oblasti prezentace jsme rovněž nechali navrhnout projektové logo (viz obrázek) a vyrobit upomínkové předměty - polokošile, hrnky a skleničky.

[Obrázek]

Obrázek 7.7: Logo projektu Liberouter

7.8   Závěr

Přestože projekt Liberouter zatím není dokončen, některé jeho dílčí výstupy - především karta COMBO6 - již byly využity v jiných projektech, jako je SCAMPI (viz kapitolu 14) a CzechLight (kapitola) a plánuje se též jejich použití v projektech 6. rámcového programu, především GN2.

Projekt Liberouter ukazuje i obecněji na významný potenciál CESNETu v oblasti koordinace rozsáhlých výzkumných a vývojových projektů, na nichž participují pracoviště různých vysokých škol či Akademie věd ČR. Ukazuje se totiž, že pro mnohé podobné projekty se obtížně hledá jiná platforma pro spolupráci.

Samotný projekt Liberouter je vedle očekávaných konkrétních výsledků z odborného hlediska také evidentním přínosem pro většinu spoluřešitelů. Zejména studenti mají výbornou příležitost prohloubit si své vědomosti při praktickém řešení tohoto poměrně rozsáhlého úkolu a naučit se přitom i týmové spolupráci a prezentaci vlastních výsledků. Hodnocení dvou bakalářských a tří magisterských prací vzešlých z projektu bylo zatím vesměs výborné a magisterská práce Jana Kořenka byla navržena na cenu ministra školství.

předchozí
obsah 		následující
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz