hledat:

4   Programovatelný hardware

Tato aktivita vznikla jako rozšíření původního projektu Liberouter, jehož cílem je vývoj směrovače IPv6 a IPv4 založeného na platformě osobního počítače. Hardwarový akcelerátor COMBO6 se ukázal být díky svému modulárnímu návrhu a použitým integrovaným obvodům vhodným i pro jiné úlohy než je předávání a filtrování datagramů. Již v roce 2003 přijal projekt SCAMPI (viz kapitola 4.4) platformu COMBO6 za základ pro vývoj speciálního adaptéru pro monitorování síťového provozu. V roce 2003 jsme také zahájili vývoj dvoukanálového optického opakovače pro gigabitový Ethernet. K výše uvedeným dílčím projektům přibyl v roce 2004 nový úkol - vývoj samostatné monitorovací sondy, která bude generovat data ve formátu NetFlow verze 9.

Aktivita Programovatelný hardware byla ustavena na začátku roku 2004 s primárním cílem koordinovat výše uvedené vývojové práce a zároveň připravit nové vývojáře, především z řad studentů, pro případné nové úkoly. Počet členů řešitelského týmu vzrostl v roce 2004 na 69, přičemž rozhodující část tohoto nárůstu tvoří studenti čtyř vysokých škol (VUT v Brně, MU Brno, ČVUT Praha a VŠE Praha), jichž je celkem 53. Spolupráce se studenty má zajisté svá úskalí a rizika, je však zřejmě jedinou cestou k dokončení všech výše uvedených projektů. Zapojení do týmu a řešení reálných problémů je ovšem velkým přínosem i pro samotné studenty, což dokládá i převážně velmi dobré hodnocení bakalářských, magisterských i doktorských prací vznikajících z této spolupráce.

Ukázalo se však, že k efektivnímu zapojení studentů do vlastních vývojových prací je zapotřebí zhruba půlročního přípravného období, v němž nově příchozí studenti dostávají jen drobné konkrétní úkoly, avšak seznamují do hloubky s architekturou příslušného hardwarového či softwarového bloku a naučí se také správně používat všechny vývojové nástroje a týmově spolupracovat.

4.1   Organizace a řízení aktivity

Řízení takto rozsáhlého kolektivu je ovšem již docela náročné, a proto jsme v roce 2004 přikročili k reorganizaci řízení směrem k větší samostatnosti jednotlivých pracovních skupin a větší odpovědnosti jejich vedoucích. Nově byla také utvořena skupina systémové podpory. Vzhledem k této reorganizaci jsme také podstatně zkrátili pravidelné týdenní schůze celého týmu a naopak posílili úlohu komunikace uvnitř každé skupiny, k níž se využívá emailových konferencí, videokonferencí i dalších prostředků. V průběhu roku jsme také zorganizovali tři výjezdní semináře, na nichž měli řešitelé možnost setkat se osobně a informovat ostatní skupiny o své práci.

4.1.1   Skupina VHDL

Skupina VHDL, která se zabývá návrhem firmwaru, má celkem 29 aktivních členů, z nichž je 24 studentů všech typů studia. Rozsah této skupiny a struktura úkolů si vynutily její další hierarchické rozčlenění na čtyři části (Liberouter, SCAMPI, NetFlow, Testování). Každá z částí má svého vedoucího, který je zodpovědný za integraci a správnou funkci firmware daného projektu.

Ve druhé polovině roku 2004 bylo do skupiny VHDL zařazeno 11 nováčků. Pro jejich snazší začlenění do týmu jsme vytvořili sérii instruktivních prezentací seznamujících s týmovými nástroji a problematikou návrhu VHDL.

Potřeba efektivní spolupráce v rámci skupiny i s jinými skupinami si vynutila zavedení systému dokumentace vyvíjeného firmwaru. Využíváme přitom jazyka XML, který umožňuje různé způsoby využití stejných informací, mimo jiné ve formě technické dokumentace na projektovém webu.

Ve skupině VHDL je připravováno celkem šest bakalářských a šest doktorských prací.

4.1.2   Skupina systémového softwaru

Skupina systémového softwaru má 11 aktivních členů, z nichž 6 je studentů. Tři členové pracují na ovladačích, ostatní na různých úrovních systémového a aplikačního softwaru. Aplikační programátoři ze softwarové skupiny také integrují celý systém.

V rámci skupiny jsou připravovány tři diplomové a jedna doktorská práce.

Tři noví studenti, kteří zatím nejsou zařazeni do týmu, pracují na podpůrných úkolech, jako je například grafická reprezentace činnosti nanoprocesorů. Tato spolupráce má obvykle formu vedení bakalářských prací.

4.1.3   Skupina formální verifikace

Skupina formální verifikace v současné době sestává z osmi studentů FI MU a FIT VUT, z nichž tři byli nově přijati v roce 2004 s cílem aplikace dalších verifikačních metod, zejména vytvoření abstraktních formálních modelů programovatelného hardwaru se zaměřením na verifikaci časových vlastností.

Způsob práce skupiny je založen především na komunikaci s vývojáři hardware. Pro tyto účely jsme vytvořili rozhraní tzv. assertů, jimiž lze specifikovat (v přirozeném jazyce) požadované vlastnosti na chování VHDL návrhů přímo do VHDL kódu. Členové verifikačního týmu tyto vlastnosti následně formalizují pomocí temporálních logik a převádějí VHDL kódy do jazyka Cadence SMV, v němž posléze probíhá vlastní verifikace. Výsledky verifikace jsou prezentovány zpětně vývojářům prostřednictvím verifikačních zpráv vystavených přímo na projektovém webu. Pro proces překladu VHDL kódů do SMV vyvíjíme balík skriptů Verunka, popsaný v technické zprávě [TR05/04]. Proces vytváření verifikačních zpráv v konkrétních případech je detailně vysvětlen ve zprávě [TR03/04].

V současné době jsou v rámci skupiny formální verifikace zpracovávány dvě diplomové a jedna disertační práce.

4.1.4   Skupina Netopeer

Tato skupina se zabývá vývojem softwarového systému pro konfiguraci směrovačů a celých sítí v rámci projektu Liberouter. Skupina měla na konci roku 2004 šest aktivních členů, z nichž je pět studentů. Jeden z nich dokončil v roce 2004 svou bakalářskou práci, ve stadiu přípravy jsou dále dvě magisterské a jedna doktorská práce.

4.1.5   Skupina BIRD

Skupina BIRD je v současné době nejmenším týmem projektu. Má pouze dva aktivní členy. Jedním je zaměstnanec sdružení CESNET a druhý je studentem FJFI ČVUT a spolupracuje na projektu formou bakalářské práce.

Vzhledem k malému rozsahu skupiny je řízení méně formalizováno. Koordinace probíhá v pravidelných schůzkách jednou za 14 dnů a v mailové konferenci. V současné době probíhá zapojování dalšího nového člena.

4.1.6   Skupina testování

Úkolem této skupiny je nezávislé testování všech výstupů aktivity. Využívá se k tomu jednak specializovaný síťový analyzátor Spirent AX/4000 a dále též soubor volně dostupných programů.

Vzhledem k tomu, že studenti FEL ČVUT, kteří tvořili v předchozích letech jádro skupiny, odešli z projektového týmu, museli jsme skupinu doplnit o čtyři nové členy - tři z nich jsou studenty FI MU a jeden studuje FEL ČVUT.

4.1.7   Skupina systémové podpory

Systémová podpora řešitelů aktivity zahrnuje následující hlavní oblasti:

1. správa veřejných i interních webových stránek a serverů pro email, CVS, sledování chyb aj.
2. podpora dokumentačních a prezentačních činností
3. správa účtů, přístupových práv a s nimi spojená personální administrativa
4. správa projektových serverů a laboratorních počítačů.

Rozsah a váha těchto činností narostly natolik, že jsme v polovině roku 2004 přikročili k ustavení samostatné skupiny systémové podpory.

V oblasti prezentace na vlastním webovém serveru jsme zavedli systém pro správu obsahu (Content Management System, CMS) a celkově zkonsolidovali tento důležitý nástroj zveřejňování informací o výsledcích aktivity. Část WWW stránek je nyní vytvářena automaticky na základě dat spravovaných centrálně sdružením CESNET (LDAP, RIV databáze). Značných změn doznala také interní část webu, kde jsme zavedli aplikaci pro registraci účastníků seminářů a jiných akcí, databázi karet a jejich uživatelů aj. Vedoucí skupin pak mají přístup k dalším aplikacím, jako jsou výkazy činnosti řešitelů a časový plánovač.

Ve spolupráci se skupinou VHDL jsme vytvořili nástroje pro generování dokumentace firmwaru založené na XML.

Pro systematické sledování a odstraňování nalezených chyb a kontrolu úkolů jsme nově zavedli systém Mantis. Jeho prostřednictvím také skupina systémové podpory přijímá požadavky řešitelů.

Velmi důležitými nástroji týmové spolupráce zůstaly nadále mailové konference (celkově jich spravujeme devět) a systém pro distribuovaný vývoj softwaru CVS.

S rostoucím množstvím projektových počítačů vznikla otázka, jak tato zařízení efektivně spravovat. V průběhu roku proto byl vyvinut systém pro jednotnou a automatickou instalaci a správu softwaru a konfigurací těchto počítačů.

4.2   Základní řada karet COMBO

V roce 2004 pokračoval hardwarový vývoj komunikačních karet COMBO. Popis a vyobrazení všech karet lze najít na projektovém webu. Významným úspěchem je zejména oživení dvouportové karty desetigigabitového Ethernetu COMBO-2XFP (viz obrázek 4.1).

Tato karta je primárně určena pro projekt SCAMPI, ale bude nasazena i v dalších projektech, na nichž aktivita Programovatelný hardware spolupracuje.

Tím, jak se karty COMBO dostávají na samotnou hranu současných technologií, je pro nás stále obtížnější - i přes sliby dodavatelů - obstarávat potřebné součástky s požadovanými parametry. V druhé generaci karet COMBO, která je v současnosti ve výrobě, se proto snažíme minimalizovat počet použitých součástek a použit výhod nových generací FPGA (Rocket IO obvody, které jsou součástí VIRTEX II PRO), případně použít IP Core (PCI interface).

První kartou druhé generace je základní karta COMBO6X určená k náhradě karty COMBO6. Hlavní změnou je přechod na obvody VIRTEX II PRO, které umožní použít výhod sériové komunikace i mezi obvody na kartě a kartě rozhraní. PCI kontrolér PLX 9054 je nahrazen hradlovým polem VIRTEX II PRO spolu s PCI core, které implementuje sběrnici PCI-X na rychlosti 133 MHz. Obvody VIRTEX II PRO obsahují procesory Power PC (na kartě COMBO6X budou 3), pomocí nichž budeme moci zpracovávat části algoritmů běžících v software hostitelského počítače přímo na kartě.

Pro podporu nového standardu Express PCI založeného na sériové komunikaci jsme rozpracovali návrh karty COMBO6E. Ta má podobnou architekturu jako COMBO6X, liší se pouze připojením na sběrnici, kde u karty COMBO6E použijeme obvodů Rocket IO a příslušného IP core.

U stávající verze karty COMBO-2XFP jsme narazili během jejího vývoje na problémy s vysokou teplotou serial/deserial obvodů (TLK3114SC a LXT12101), které jsou navíc obtížně dostupné. Nová verze karty - COMBO-2XFPRO - je proto postavena na obvodu VIRTEX II PRO-X s Rocket IO-X, které navíc přímo podporují standardy 10GbE a SONET OC-192.

Koncem roku 2004 jsme také navrhli kartu COMBO-4SFPRO, která nahradí kartu COMBO-4SFP, u níž jsou opět serial/deserial obvody nahrazeny obvody Rocket IO. Při osazení obvodem VIRTEX II PRO bude karta podporovat gigabitový Ethernet, zatímco s obvodem VIRTEX II PRO-X bude možno kartu použít pro SONET OC-48.

Rodina COMBO tedy v současné době sestává z následujících karet:

1. COMBO6: Základní karta, je v produkční fázi, v roce 2005 bude nahrazena kartami COMBO6X a COMBO6E.
2. COMBO6X: Nová základní karta pro sběrnici PCI-X, návrh schématu a plošného spoje je hotov, karta je v továrně osazována.
3. COMBO6E: Nová základní karta pro sběrnici Express PCI, je ve stadiu návrhu plošných spojů.
4. COMBO-4MTX: Karta rozhraní 4×GE metalickými porty, je v produkční fázi.
5. COMBO-4SFP: Karta rozhraní 4×GE s transceivery SFP, je v produkční fázi.
6. COMBO-2XFP: Karta rozhraní 2×10GE s transceivery XFP, je v prototypové fázi a bude záhy nahrazena kartou COMBO-2XFPRO.
7. COMBO-2XFPRO: Nová verze karty rozhraní 2×10GE s transceivery XFP, návrh schématu a plošného spoje je hotov, deska plošného spoje je ve výrobě.
8. COMBO-4SFPRO: Nová verze karty rozhraní 4×GE s transceivery SFP, návrh schématu a plošného spoje je hotov, deska plošného spoje je ve výrobě.
9. COMBO-PTM: Karta přesných časových značek vzniklá v rámci projektu SCAMPI, je v produkční fázi.
10. COMBO-BOOT: Tuto kartu lze připojit ke kartě rozhraní namísto COMBO6, čímž je umožněn jejich autonomní provoz (bez PC). Tato kombinace je použita v optickém opakovači, viz oddíl 4.5. Karta je v produkční fázi.

4.3   Projekt Liberouter

Cílem projektu Liberouter, který je také zařazen do mezinárodního projektu 6NET, je zdokonalení směrovačů na bázi PC s unixovým operačním systémem v těch oblastech, kde PC směrovače zaostávají za svými komerčními protějšky:

• propustnost a výkon při směrování a filtrování datagramů
• konfigurační uživatelské rozhraní.

Vzhledem k pokračujícímu zastarávání obou nejběžnějších open-source směrovacích démonů GateD a Zebra/Quagga jsme se rozhodli podpořit vlastním vývojem softwarový projekt BIRD, který vznikl původně na MFF UK. Naším hlavním záměrem v tomto směru je vývoj implementace protokolu PIM-SM pro směrování multicastu.

V průběhu roku 2004 jsme se rozhodli zaměřit úsilí všech pracovních skupin k dokončení funkčního prototypu PC směrovače, který bude mít lepší parametry než čistě softwarový směrovač, byť v některých ohledech zatím nebude naplňovat původní cíle projektu. Demonstraci takového zařízení připravujeme pro schůzi konsorcia 6NET na konci ledna 2005.

Významným rysem směrovače Liberouter bude vedle podpory aktuálních standardů IPv6 i co nejúplnější a veřejně dostupná dokumentace firmwaru a softwaru, která umožní, jak doufáme, vývoj dalších funkcí směrovače i mimo původní projektový tým.

4.3.1   Firmware

Úlohou firmware v projektu Liberouter je zajistit rychlé směrování a filtrování paketů IPv6/IPv4 s využitím prostředků na kartě COMBO6. Tyto funkce jsou soustředěny do několika programovatelných hradlových polí (FPGA), 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. Architektura firmware je popsána v loňské zprávě a nedoznala žádných výraznějších změn.

V roce 2004 jsme největší úsilí zaměřili na dokončení a odladění jednotlivých komponent návrhu a jejich integraci do celku. Funkce komponent HFE (Header Field Extractor), LUP (Look-Up Processor) a PQ (Priority Queues) již byly ověřeny přímo v FPGA, ostatní komponenty byly prověřeny zatím pouze softwarovou simulací. Vytvořili jsme první verzi firmware, která umožňuje analyzovat hlavičky paketů a provádět filtrovaní na všech čtyřech vstupních rozhraních. Architektura je znázorněna na obrázku 4.2.

Zobrazené komponenty mají následující funkce:

IBUF (Input Buffer)

Zjišťuje, zda paket není porušen (správnost CRC) a přechodně uloží paket před zpracováním v HFE.

HFE (Header Field Extractor)

Analyzuje hlavičky paketů a vybírá z nich informace důležité pro směrování a filtrování. Výsledek uloží do pevné struktury, která se nazývá unifikovaná hlavička.

LUP (Look-Up Processor)

Na základě informací v Unifikované hlavičce provede klasifikaci paketu.

DISP (Dispatcher)

Přeposílá pakety k softwarovému zpracování anebo je zahazuje.

SWOBUF (SW Output Buffer)

Implementuje vyrovnávací paměť pro pakety a zajišťuje jejich přenos do softwaru.

OBUF (Output Buffer)

Realizuje vysílání paketů na síťové rozhraní.

Oproti očekávanému definitivnímu návrhu firmwaru je tato verze zjednodušena především v tom smyslu, že neumožňuje ukládat tělo paketu do dynamické paměti přímo na kartě COMBO6. Vstupní část (analýza hlaviček paketů a klasifikace paketů) se však již s definitivním návrhem plně shoduje. K cílové podobě firmwaru chceme dospět aplikací principu hardwarově-softwarového kodesignu: postupným přidáváním funkcí do již vytvořeného firmware a realizací zbylých komponent.

4.3.2   Systémový software

Softwarovou podporu karty COMBO6 v současné době vyvíjíme pro operační systémy NetBSD a Linux (v plánu je i verze FreeBSD).

Software pro COMBO6 lze rozdělit to dvou základních kategorií:

1. Ovladače COMBO6 zodpovídají za základní komunikaci s kartou (zavedení firmwaru, manipulaci s vnitřními pamětmi a registry, atd.)
2. Akcelerace přepínání paketů, démon combod.

Ovladače dovolují komunikaci s COMBO6 a kartou rozhraní. Ovladač je v systému dostupný jako znakové zařízení /dev/combo. Vytvořili jsme nástroje pro inicializaci karty a zavedení firmwaru. Pro zjednodušení testování a odstraňování chyb jsme připravili sadu řídicích nástrojů hfectl, lupctl a další. Tyto nástroje dovolují číst a nastavovat registry a paměti nanoprocesorů a také řídit jejich běh.

Ovladače také poskytují přístup k síťovým rozhraním COMBO6. Rozhraní se chovají jako běžná rozhraní síťových adaptérů a dovolují konfiguraci pomocí standardních nástrojů operačního systému, jako například ifconfig.

Podpora akcelerovaného přepínání paketů, démon combod, má za úkol skrýt přítomnost karty v systému. Operační systém udržuje informace o směrování, překladu adres (ARP), filtraci paketů (firewallu) a potažmo též nastavení programu tcpdump. Tyto informace jsou v jádře vyjádřeny jako sada tabulek a filtrů. Cílem je v hardwaru přepínat pakety stejně, jako by to dělal operační systém.

Look-Up Processor, vyhledávací nanoprocesor implementovaný v hardwaru COMBO6, používá pro klasifikaci paketů speciální datovou strukturu. Tato struktura je uložena v asociativní paměti (CAM) a statické paměti. Úkolem démona combod je udržovat tuto strukturu synchronní se směrováním a filtrací nastavenou v operačním systému.

V současné době je k dispozici software pro hardwarovou podporu směrování a filtrování. Chová se de facto jako síťový adaptér, který na vstupu, tedy ještě před předáním operačnímu systému, umožňuje filtrovat pakety podle posloupnosti zadaných pravidel zahrnujících zdrojové a cílové IP adresy a porty.

4.3.3   Formální verifikace

Verifikovali jsme programy VHDL pro modul editace paketů (EDIT ENGINE), se zaměřením na komunikaci tohoto modulu s plánovačem přístupu k DRAM paměti, a dále pak moduly UH_FIFO a ASYNCHRONOUS FIFO. Výsledky verifikace jsou dostupné prostřednictvím verifikačních zpráv v sekci formální verifikace na projektovém webu.

Klíčovým přínosem pro vývoj verifikačních technologií byla verifikace asynchronní fronty, u níž jsme vyřešili problém formalizace VHDL designu s více hodinami. Problematika a způsob řešení jsou popsány v technické zprávě [TR04/04].

4.3.4   Konfigurační systém Netopeer

Softwarový systém Netopeer je zaměřen na konfiguraci směrovačů IPv6 a IPv4 a celých sítí. Jeho základní uspořádání je naznačeno na obrázku 4.3: Konfigurace se vytvářejí na manažerské stanici, která je jednak ukládá ve formátu XML do datového skladu (repository) a podle potřeby též převádí do příslušného konfiguračního jazyka a instaluje do cílového směrovače.

Hlavní část softwarového vývoje je soustředěna do aplikací běžících na manažerské stanici. Jejich softwarová architektura je znázorněna na obrázku 4.4. V jeho horní polovině jsou aplikační programy (front-endy), které realizují uživatelské rozhraní, transformují vstup na dokument XML a ukládají jej do skladu konfigurací. Pro převod do jazyka cílového směrovače a instalaci této konfigurace front-endy využijí příslušný back-end, který je dostupný jako knihovní funkce.

Vývoj konfiguračního systému Netopeer byl v roce 2004 zaměřen na dokončení funkčního prototypu softwaru pro konfiguraci PC směrovačů v produkčních sítích. Naším cílem proto bylo dokončit především vstupní modul řádkového rozhraní (CLI), které považujeme za hlavní konfigurační nástroj, a dále výstupní modul Unix pro překlad konfigurací z XML a jejich instalaci v PC směrovači.

Podstatných změn doznalo schéma XML, jímž je definován datový obsah konfigurací. Především jsme přešli na jiný jazyk pro popis schématu - RELAX NG, který umožnil oproti dříve používanému DTD výrazně rozšířit informace zachycené ve schématu. Schéma nyní zahrnuje data pro konfiguraci síťových rozhraní (včetně tunelů a VLAN), základní nastavení systému (DNS, NTP apod.), paketové filtry, statické směrování a směrovací protokoly RIP, OSPF a BGP.

Vstupní modul CLI jsme dovedli do použitelné podoby. Jeho syntaxe je přímo odvozena ze schématu XML, což je sice velmi užitečné - změna schématu se ihned odrazí v syntaxi - v některých případech to ale činí syntaxi CLI těžkopádnou. Plánujeme proto jednak dílčí úpravy ve schématu XML a dále též do schématu zavést (v samostatném jmenném prostoru) pokyny pro vstupní moduly, které umožní efektivní a elegantní reprezentaci vstupních dat.

V roce 2004 též pokračoval vývoj webového vstupního modulu. Tento modul rovněž generuje své formuláře dynamicky ze schématu XML, což vede k podobným výhodám i nevýhodám jako v případě CLI. Architektura webového vstupního modulu je popsána v technické zprávě [TR06/04].

Výstupní modul Unix v současné době umožňuje konfigurovat PC směrovače s operačním systémem Linux a směrovacím démonem Zebra. Tuto platformu je tedy již možno konfigurovat pomocí řádkového rozhraní.

Velmi zajímavým rozšířením systému je modul netconf založený na stejnojmenném protokolu, jenž je vyvíjen v rámci IETF [Enn04]. Tento protokol je založen rovněž na XML, a proto do systému Netopeer velmi dobře zapadá. Implementace netconf nad transportním protokolem BEEP je tématem diplomové práce, která bude dokončena v lednu 2005.

Významného pokroku bylo také dosaženo ve vývoji metakonfigurační aplikace, která umožňuje konfigurovat celou síť na vyšší úrovni a automaticky pak generovat konfigurace jednotlivých směrovačů ve formátu Netopeer. Vytvořili jsme speciální schéma XML (rovněž v jazyku RELAX NG), které pokrývá všechny základní oblasti (adresování, směrování a filtrace paketů), a navrhli též uživatelské rozhraní. Výsledky jsou popsány v technické zprávě [TR27/04].

4.3.5   Směrovací démon BIRD

Směrovací démon BIRD je nejvyšší softwarovou vrstvou zastoupenou v projektu Liberouter. Hlavní úlohou démona je dynamické vytváření pravidel pro předávání datagramů (směrovacích tabulek), a to pro směrování unicastu a multicastu IPv4 i IPv6. Tyto tabulky pak v upravené formě předává nižším vrstvám operačního systému, popřípadě jeho prostřednictvím i kartě COMBO6.

Démon BIRD byl v roce 2004 portován pro operační systémy FreeBSD a NetBSD (původní verze běží na Linuxu). Unicastové jádro je zcela hotové a odladěné, stejně jako směrovací protokoly BGP, RIP a OSPF (posledně jmenovaný zatím pouze pro IPv4). Vývoj multicastového jádra je rovněž ukončen a rozpracovány jsou implementace směrovacích protokolů DVMRP a PIM. Student FJFI ČVUT zároveň v rámci své bakalářské práce vyvíjí modul pro konfiguraci síťových rozhraní.

4.4   Monitorovací adaptér SCAMPI

Monitorovací adaptér SCAMPI je založen na rodině karet COMBO - využívá se jejich modularity, umožňující libovolnou kombinace základní karty (COMBO6, později i COMBO6X nebo COMBO6E) s kartou rozhraní (COMBO-4MTX, COMBO-4SFP, COMBO-2XFP, COMBO-2XFPRO, COMBO-4SFPRO). Pro podporu projektu SCAMPI jsme vyvinuli a oživili kartu COMBO-PTM fungující jako zdroj přesných časových značek. Adaptéry SCAMPI jsou proto momentálně k dispozici v následujících třech variantách:

1. SCAMPI-4MTX - COMBO6, COMBO-4MTX, COMBO-PTM
2. SCAMPI-4SFP - COMBO6, COMBO-4SFP, COMBO-PTM
3. SCAMPI-2XFP - COMBO6, COMBO-2XFP, COMBO-PTM

Další varianty budou postupně testovány, jakmile budou připraveny nové verze základních karet (COMBO6X a COMBO6E) a karet rozhraní.

4.4.1   Firmware

Úlohou firmware v projektu SCAMPI je zajistit příjem paketu ze vstupních rozhraní, přiřadit paketu přesnou časovou značku a provést analýzu a klasifikaci paketu. Na základě výsledku klasifikace pak umožnit sběr statistik, filtrování, vzorkování paketů a detekci specifických posloupností bajtů v datovém obsahu paketu.

Je podporován sběr až 256 různých statistik délek a intervalů mezi pakety. V návrhu je také obsaženo 16 vzorkovacích jednotek, které je možné nakonfigurovat na různé režimy vzorkování:

• Deterministické - propustí každý n-tý paket
• Pravděpodobnostní - propouští náhodně pakety s předepsanou pravděpodobností
• Paket s n-tým bajtem - pro každý n-tý bajt v proudu dat propustí paket, který tento bajt obsahuje

Firmware je díky použité asociativní paměti schopen detekovat až 512 různých vzorků při rychlosti 3,2 Gb/s.

Součástí návrhu je i firmware pro kartu COMBO-PTM, zajišťující generování přesných časových značek a jejich přenos na kartu COMBO6.

Vývoj firmware jsme rozdělili do dvou fází. V první fázi jsme vytvořili implementaci monitorovacího adaptéru na rychlosti 1 Gb/s. Architektura firmware je znázorněna na obrázku 4.5.

Zobrazené komponenty mají následující funkce:

IBUF (Input Buffer)

Zjišťuje, zda paket není porušen (správnost CRC) a přechodně ukládá paket před zpracováním v HFE.

HFE (Header Field Extractor)

Analyzuje hlavičky paketů a vybírá z nich informace důležité pro směrování a filtrování. Výsledek uloží do pevné struktury, která se nazývá unifikovaná hlavička.

LUP (Look-Up Processor)

Na základě informací v unifikované hlavičce provede klasifikaci paketu.

FIFO (Packet FIFO)

Přechodné uložení paketů (realizace zpožďovací linky).

STU (Statistical Unit)

Zajišťuje sběr statistik.

SAU (Sampling Unit)

Provádí vzorkování paketů.

SWOBUF (SW Output Buffer)

Implementuje vyrovnávací paměť pro pakety a zajišťuje jejich přenos do softwaru.

Druhá fáze vývoje je zaměřena na monitorovací adaptér pro rychlost 10 Gb/s. Z důvodu vysoké propustnosti je návrh adaptéru mírně odlišný od výše popsané verze. Byly použity zcela jiné vstupní buffery a Dispatcher. Došlo k replikaci několika komponent (HFE, FIFO) a rozdělení návrhu mezi COMBO6 a přídavnou kartu. Architektura monitorovacího adaptéru pro 10 Gb/s je znázorněna na obrázku 4.6.

Firmware první fáze je hotový. Na vývoji druhé fáze se intenzivně pracuje. Pro její dokončení zbývá pouze integrovat jednotlivé komponenty, které již byly úspěšně softwarově simulovány a individuálně otestovány v hardwaru.

4.4.2   Systémový software

Systémový software pro projekt SCAMPI sestává z ovladačů COMBO6 a knihovny pro transformaci paketových filtrů do jejich hardwarové podpory.

Ovladače poskytují nízkoúrovňový přístup do interních registrů, pamětí a čítačů COMBO6. K nástrojům používaným pro projekt Liberouter přibyla podpora statistické (STU) a vzorkovací (SAU) jednotky.

Požadavky na zachytávání paketů jsou nastaveny pomocí aplikačního programového rozhraní MAPI vyvinutého v rámci projektu SCAMPI. MAPI používá knihovnu Scampidump k převedení a zavedení monitorovacích pravidel do adaptéru. Scampidump přijímá pravidla vyjádřená v podmnožině syntaxe Berkeley Packet Filter (BPF). Pravidla jsou analyzována, převedena do formy nanoprogramu LUP a nahrána do karty COMBO6.

V současnosti lze zpracovat jedno pravidlo. Verze Scampidump umožňující více monitorovacích pravidel a techniky kompilace pravidel intenzivně studujeme. Je nutno vyřešit zpracování překrývajících se pravidel. Studujeme přístup založený na reprezentaci pravidel jako SB+ stromů a jejich rozdělení do nepřekrývajících se segmentů.

4.4.3   Formální verifikace

Ve firmwarovém návrhu SCAMPI jsme verifikovali moduly DISPATCHER, FIFO BRAM, STATISTIC a SAMPLING UNIT.

Při verifikaci modulu FIFO_BRAM se podařilo odhalit odchylku v chování návrhu VHDL oproti zamýšlené specifikaci. Zjištěné výsledky budou použity k opravě specifikace, neboť diskusí se ukázalo, že implementace je za vhodných a v praxi splněných předpokladů korektní.

Dále se podařilo při diskusích upřesňujících požadavky na vytvoření abstraktního modelu SCAMPI odhalit problémové části designu s ohledem na splnění očekávaných časových vlastností. Zde se ukázal jako klíčový přínos komunikace členů týmu verifikace s vývojáři hardware.

4.5   Optický opakovač

Optický opakovač jsme navrhli jako jednoduchou aplikaci používající karet rozhraní rodiny COMBO. V roce 2004 jsme dokončili jeho vývoj včetně mechanického uložení do rackového šasi výšky 2U.

Pro vývoj optického opakovače jsme navrhli a oživili kartu COMBO-BOOT, která zabezpečuje napájení a nahrávaní mikroprogramu pro kartu rozhraní.

4.5.1   Firmware

Firmware opakovače je poměrně jednoduchý. Je umístěn v hradlovém poli na kartě COMBO-4SFP a sestává ze dvou procesů, které kopírují příchozí znaky z jednoho portu na druhý. Po dokončení karty COMBO-2XFPRO bude příslušný firmware portován i na tuto kartu.

4.5.2   Systémový software

Ovládací software pro kartu COMBO-BOOT jsme napsali v jazyce C. Vytvořili jsme jednoduchý monitor, který komunikuje pomocí RS-232C s řídícím počítačem a podporuje základní funkce karty, kterými je nahráváni firmware do karty rozhraní a hlídání napěťových zdrojů.

4.6   Sonda NetFlow

V mezinárodním projektu GN2 vyvíjí CESNET v rámci aktivity JRA2 (Security) zařízení pro generování a analýzu dat. V prvních dvou letech projektu bude hlavním úkolem vyvinout autonomní sondu NetFlow verze 9 založenou na kartách rodiny COMBO. Na rozdíl od běžných implementací NetFlow, které jsou umístěny ve směrovačích, bude tato sonda fungovat jako dělič datového provozu (Y-splitter) - vloží se do datového okruhu, přičemž jedna větev bude přenášet bez zásahu originální data, která se zároveň zkopírují do druhé větve a s touto kopií bude zařízení dále pracovat.

Verze 9 protokolu NetFlow umožňuje definovat datový obsah záznamů pomocí tzv. předloh (templates). Díky pružnosti programovatelného hardwaru hodláme implementovat možnost dynamické změny obsahu záznamů na základě uživatelova požadavku. Taková funkce není u existujících implementací NetFlow v9 k dispozici, neboť předlohy jsou u nich pevně zafixovány v obvodech ASIC.

Ve druhém pololetí roku 2004 jsme na základě rozsáhlé diskuse vytvořili návrh architektury sondy NetFlow, který byl také oponován zahraničními partnery v projektu GN2. Výsledky jsou zachyceny v technických zprávách [TR08/04], [TR14/04] a [TR15/04].

4.6.1   Návrh hardwarové architektury

Architektura hardwarové sondy vychází z možností karet COMBO. Snahou je využít prostředků na kartě pro udržení maximálního počtu NetFlow záznamů při zajištění úplného zpracování toku 1 Gb/s. Důležitým parametrem sondy je také bezpečnost. Informace o prošlých datových tocích by nemělo být možné podvrhnout ani náhodně ani cíleným útokem.

Navržená hardwarová sonda analyzuje přijaté pakety, vybírá důležité informace a ukládá je do NetFlow hlavičky. Z hlavičky se následně počítá 19bitová a 45bitová rozptylovací funkce (hash), které jsou využity při ukládání nebo aktualizaci záznamů. U COMBO karet jsou vhodným kandidátem pro uložení NetFlow záznamů paměti SSRAM. Pro uchování maximálního počtu záznamů je vhodné použít uspořádání pamětí podle obrázku 4.7.

První statická paměť slouží pro rozskok pomocí 19bitové rozptylovací funkce. V paměti je uložen pouze odkaz na informace o NetFlow záznamu a 45bitová hodnota rozptylovací funkce, která při využití konstantního dohledávání umožňuje omezit celkový počet konfliktů, kdy se dva různé toky zobrazí na stejný záznam. Se stupněm zaplnění paměti roste i pravděpodobnost těchto konfliktů. Paměť musí být z tohoto důvodu relativně řídce obsazena. Aby bylo maximálně využito paměťových zdrojů na kartě, jsou informace o záznamech uchovávány v oddělených SSRAM pamětech.

Architektura sondy NetFlow je znázorněna na obrázku 4.8. Paket je přijat ze vstupního rozhraní do vyrovnávací paměti IBUF, kde se mu přiřadí časová značka získaná z TSU (Time Stamp Unit). Paket dále pokračuje do HFE (Header Field Extractor), který analyzuje hlavičky paketů, vybírá důležité informace a ukládá je do záznamu NetFlow. Z něj se v HASH (Hash Block) vypočítá 19bitová a 45bitová hodnota rozptylovacích funkcí, které využívá HSRCH (Hash Search Component) pro rychlé vyhledání záznamu. Nalezený záznam je následně aktualizován v komponentě SCTRL (Storage Controller). Pokud nebyl v HSRCH záznam nalezen, je přidán jako nový. Komunikace mezi HSRCH a SCTRL je řízena prostřednictvím MAN (Manager), který zároveň zajišťuje přidávání a uvolňování záznamů.

Aktivní záznamy jsou seřazeny vzestupně v lineárním seznamu podle časové značky poslední aktualizace. Uvolňování neaktivních toků je zajištěno postupným odstraňováním položek ze začátku seznamu podle aktuální hodnoty času. Je také udržován seznam volných paměťových položek, ze kterého jsou přidělovány při zakládání nového záznamu. Oba seznamy jsou z kapacitních důvodů uchovávány v pamětech SSRAM.

předchozí

obsah

následující