Rekonfigurowany system ochrony transmisji danych typu Firewall dla sieci Ethernet o wielkich przepływnościach implementowany w układach FPGA

Transkrypt

1 WYDZIAŁ ELEKTROTECHNIKI, AUTOMATYKI, INFORMATYKI I ELEKTRONIKI KATEDRA ELEKTRONIKI Maciej Twardy Rekonfigurowany system ochrony transmisji danych typu Firewall dla sieci Ethernet o wielkich przepływnościach implementowany w układach FPGA Rozprawa doktorska Promotor: Prof. dr hab. inż. Kazimierz Wiatr Kraków 2010

2 Pragnę wyrazić serdeczne podziękowania Panu Profesorowi Kazimierzowi Wiatrowi za inspirację, mobilizację oraz nieocenioną pomoc w powstaniu tej rozprawy. 2

3 Spis treści Wykaz skrótów Wstęp Motywacja Cel i teza pracy Organizacja pracy Przegląd rozwiązań systemów ochrony danych przesyłanych w sieciach teleinformatycznych Wprowadzenie Klasyfikacja funkcjonalna Pasywne filtry pakietów Dynamiczne filtry pakietów Bramki typu Circuit-level Bramki aplikacyjne Filtry typu Stateful Inspection Proxy odcinające Rozwiązania typu Air Gap Filtry typu Deep Packet Inspection Zunifikowane zarządzanie zagrożeniami Klasyfikacja implementacyjna Firewalle programowe Firewalle sprzętowe Stanowisko badawcze Wprowadzenie Pakiet Active-HDL Płyta testowo-uruchomieniowa Digilab 2E firmy Digilent Płyta testowo-uruchomieniowa XUPV2 firmy Digilent Realizacja dostępowych interfejsów fizycznych dla sieci Fast i Gigabit Ethernet Karta Fast Ethernet Karta Gigabit Ethernet Sprzętowa implementacja kontrolerów MAC dla sieci Ethernet Wprowadzenie Struktura ramki Ethernet Charakterystyka pól składowych ramki podstawowej Format ramki znakowanej

4 4.3. Sprzętowy kontroler MAC - wersja Fast Ethernet Schemat blokowy Tor odbiorczy Rx Tor nadawczy TX Moduł kontrolny Wyniki implementacji Sprzętowy kontroler MAC - wersja Gigabit Ethernet Schemat blokowy Tor odbiorczy Rx Tor nadawczy Tx Moduł kontrolny Wyniki implementacji Sprzętowy system bezpieczeństwa typu Firewall Wprowadzenie Silnik sprzętowego systemu typu Firewall Schemat blokowy Kontroler pamięci ramkowej Moduł generujący deskryptor bezpieczeństwa Pamięć wspomagająca cache Moduł zarządzający Wyniki implementacji Sprzętowy klasyfikator pakietów Schemat blokowy Filtr adresów sieciowych Filtr portów sieciowych Moduł sterujący Wyniki implementacji oraz ocena wydajności sprzętowego klasyfikatora pakietów Blok ładowania polityki bezpieczeństwa Aplikacja zarządzająca Ocena wyników implementacji kompletnej zapory sieciowej Podsumowanie Bibliografia Dodatek A opis funkcji sygnałów poszczególnych modułów sprzętowego systemu Firewall Dodatek B - szczegółowe wyniki syntezy modułów sprzętowego Firewalla Dodatek C zawartość płyty CD

5 Wykaz skrótów 2sBFCE - sprzętowa wersja algorytmu klasyfikacji pakietów wykorzystującego wielopoziomowe filtry Bloom a (ang. Dual Stage Bloom Filter Classification Engine) ABV - algorytm klasyfikacji pakietów wykorzystujący zagregowane wektory bitowe (ang. Aggregated Bit Vector) ACE - opracowany przez firmę Xilinx system zarządzania konfiguracją wewnętrzną układów FPGA (ang. Advanced Configuration Environment) ACL - lista kontroli dostępu (ang. Access Control List) AQT - algorytm klasyfikacji dwuwymiarowej opracowany przez M. Buddhikot'a et al. (ang. Area-based Quad Tree) ARP - protokół odnajdywania adresu sprzętowego hosta na podstawie adresu warstwy sieciowej (ang. Address Resolution Protocol) ASIC - układy scalone projektowane do ściśle określonych zastosowań, zgodnie ze specyfikacją użytkownika (ang. Application Specific Integrated Circuits) B2PC - algorytm klasyfikacji pakietów bazujący na wielopoziomowych filtrach Bloom a (ang. Bloom Based Packet Classification) BRGC - binarny refleksyjny kod Gray a (ang. Binary-Reflected Gray Code) BVL - algorytm klasyfikowania pakietów wykorzystujący wektory bitowe (ang. Bit Vector Linear serach) BWL - typ kompresji zniekształceń sygnału w sieciach Ethernet (ang. Base Line Wander) CAM - pamięć adresowana zawartością (ang. Content Addressable Memory) CLB - konfigurowalny blok logiczny dostępny w zasobach układów FPGA Virtex firmy Xilinx (ang. Configurable Logic Blocks) CMOS - technologia wytwarzania układów scalonych wykorzystująca tranzystory MOS o przeciwnym typie przewodnictwa (ang. Complementary MOS) CRC - cykliczny kod nadmiarowy (ang. Cyclic Redundancy Check) CSMA/CD - protokół wielodostępu ze śledzeniem stanu medium transmisyjnego (ang. Carrier Sense Multiple Access with Collision Detect) DAC - model nieobowiązkowej kontroli dostępu do systemów komputerowych (ang. Discretionary Access Control) DCFL - metoda klasyfikacji pakietów bazująca na niezależnym przeszukiwaniu poszczególnych pól, połączonym z kodowaniem i agregacją pośrednich wyników 5

6 DCFLE DCM DDR DIRE DIRPE DoS DPI EDA EPP ERS E-TCAM FCS FIFO FIS-tree FPGA FSM FTP GMII GOT GPP GUI HiCuts kwerend (ang. Distributed Crossproducting Field Labels) - rozszerzona wersja algorytmu DCFL zaproponowana przez G. Jedhe et al. (ang. Distributed Crossproducting of Field Labels Extended) - blok zarządzania zegarem cyfrowym dostępny w zasobach układów FPGA Virtex firmy Xilinx (ang. Digital Clock Management) - podwójna szybkość przesyłu danych (ang. Double Data Rate) - metoda kodowania zakresów uzależniona od zawartości bazy reguł bezpieczeństwa (ang. Database Independent Range Encoding) - metoda kodowania zakresów niezależna od zawartości bazy reguł bezpieczeństwa (ang. Database Independent Range PreEncoding) - atak typu odmowa usługi (ang. Denial of Service) - metoda pełnej (głębokiej) analizy pakietów (ang. Deep Packet Inspection) - elektroniczne wspomaganie procesu projektowania (ang. Electronic Design Automation) - standard dwukierunkowego równoległego portu komunikacyjnego urządzeń komputerowych (ang. Enhanced Parallel Port), - metoda jawnego wyszukiwania zakresów zaproponowana przez Y. Lou et al. (ang. Explicite Range Serach) - zmodyfikowana trójwartościowa pamięć adresowana zawartością, pozwalająca na zapisywanie przedziałów (ang. Extended TCAM) - sekwencja kontrolna ramki Ethernet zawierająca 4-bajtowy kod CRC (ang. Frame Check Sequence) - kolejka, liniowy bufor danych (ang. First In, First Out) - algorytm klasyfikacji pakietów wykorzystujący zmodyfikowaną wersję drzewa odcinków (ang. Fat Inverted Segment tree) - układy programowalne o architekturze matrycowej (ang. Field Programmable Gate Array) - automat skończony (ang. Finite State Machine) - protokół transferu plików (ang. File Transfer Protocol) - gigabitowy interfejs komunikacyjny niezależny od typu medium fizycznego (ang. Gigabit Media Independent Interface) - algorytm klasyfikacji pakietów bazujący na strukturach typu trie opracowany przez V. Srinivasan a et al. (ang. Grid-Of-Tries) - procesor ogólnego przeznaczenia (ang. General Purpose Processor) - graficzny interfejs użytkownika (ang. Graphical User Interface) - heurystyczny algorytm klasyfikacji pakietów opracowany przez P. Gupta et al. (ang. Hierarchical Intelligent Cuttings) 6

7 http - protokół przesyłania dokumentów hipertekstowych (ang. Hypertext Transfer Protocol) ICMP - internetowy protokół komunikatów kontrolnych wykorzystywany w diagnostyce sieci oraz trasowaniu pakietów (ang. Internet Control Message Protocol) IDS - system wykrywania włamań (ang. Intrusion Detection System) IOS - system operacyjny urządzeń sieciowych firmy Cisco (ang. Internetwork Operating System) IP - protokół komunikacyjny warstwy sieciowej modelu OSI (ang. Internet Protocol) IP-Core - elementy biblioteczne o określonej funkcjonalności (ang. Intellectual Property Core) IPS - system zapobiegania włamaniom (ang. Intrusion Prevention System) ISO/OSI - model odniesienia przeznaczony do łączenia systemów otwartych (ang. International Organization for Standardization / Open System Interconnection Reference Model) ISP - dostawca usług internetowych (ang. Internet Service Provider) JTAG - nazwa standardu IEEE definiującego protokół używany do testowania połączeń na płytkach drukowanych oraz diagnostyki układów cyfrowych (ang. Joint Test Action Group) LAN - lokalna sieć komputerowa (ang. Local Area Network) LCA - najniższy wspólny przodek w strukturze danych typu drzewo (ang. Lowest Common Ancestor) LDPS - tryb pracy układu PHY redukujący pobieraną moc (ang. Link Down Power Saving) LED - dioda elektroluminescencyjna (ang. Light-Emitting Diode) LRU - najdawniej używane wpisy w tablicy połączeń Firewalla (ang. Last Recently Used) LSB - najmniej znaczący bit w słowie (ang. Least Significant Bit) LUT - tablica spełniająca rolę tablicy wartości funkcji logicznej (ang. Look-Up-Table) MAC - kontroler dostępu do sieci Ethernet (ang. Media Access Control) MAC - obligatoryjny model ochrony systemów komputerowych (ang. Mandatory Access Control) MAU - łącze interfejsu dopasowującego do typu medium fizycznego (ang. Media Attachment Unit) MDC - linia zegarowa interfejsu MDIO (ang. Management Data Clock) MDI - element MAU zapewniający właściwe połączenie fizyczne oraz elektryczne z medium transmisyjnym (ang. Medium Dependent Interface) MDIO - typ szeregowego interfejsu zarządzającego układami PHY (ang. Management Data Input/Output) MDIX - odmiana MDI z zamienionymi parami przewodów (ang. MDI crossover) MGT - standard gigabitowego portu komunikacyjnego (ang. Multi-Gigabit Transceiver) MII - w modelu ISO/OSI interfejs komunikacyjny niezależny od typu medium fizycznego 7

8 (ang. Media Independent Interface) MLS - wielopoziomowy model bezpieczeństwa systemów komputerowych (ang. Multi- Level Security) MLT-3 - standard kodowania sygnałów (ang. Multi-Level Transmit) Mpps - jednostka wydajności przetwarzania danych wyrażona w milionach pakietów na sekundę (ang. Mega packets per second) MSB - najbardziej znaczący bit w słowie (ang. Most Significant Bit) MTU - maksymalny rozmiar datagramu w protokole transportowym (ang. Maximum Transmission Unit) NIC - karta interfejsu sieciowego (ang. Network Interface Card) NRZ - standard kodowania sygnałów (ang. Non Return to Zero) NRZI - standard kodowania sygnałów (ang. Non Return to Zero Inverted) P 2 C - metoda równoległej klasyfikacji pakietów opracowana przez J. Lunteren'a et al. (ang. Parallel Packet Classification) PAD - sekwencja bitów uzupełniających ramkę Ethernet do minimalnej wymaganej standardem długości (ang. padding) PCS - podwarstwa fizycznego kodowania sygnału w modelu ISO/OSI (ang. Physical Coding Sublayer) PHY - urządzenie warstwy fizycznej w modelu ISO/OSI odpowiedzialne za obsługę połączenia z medium komunikacyjnym w sieci Ethernet (ang. Physical Layer Device) PLL - pętla sprzężenia fazowego (ang. Phase-Locked Loop) PMA - przyłącze medium fizycznego w modelu ISO/OSI (ang. Physical Medium Attachment) PMD - podwarstwa modelu ISO/OSI odpowiedzialna za transmisję oraz odbiór poszczególnych bitów z medium fizycznego (ang. Physical Medium Dependent) RAM - pamięć o dostępie swobodnym (ang. Random Access Memory) RARP - protokół odnajdywania adresu warstwy sieciowej hosta na podstawie adresu sprzętowego (ang. Reverse Address Resolution Protocol) RBAC - model bezpieczeństwa systemów komputerowych bazujący na rolach przydzielanych użytkownikom (ang. Role-Based Access Control) RFC - heurystyczny algorytm klasyfikacji pakietów opracowany przez P. Gupta et al. (ang. Recursive Flow Classification) RGMII - odmiana interfejsu GMII o zredukowanej liczbie linii sygnałowych (ang. Reduced GMII) SATA - szeregowa magistrala komputerowa służąca komunikacji z urządzeniami pamięci masowej (ang. Serial Advanced Technology Attachment) 8

9 SDRAM - synchroniczna dynamiczna pamięć RAM (ang. Synchronous Dynamic RAM) SFD - znacznik początku ramki Ethernet (ang. Start Frame Delimiter) SMA - typ złącza koncentrycznego (ang. SubMiniature version A) SMB - protokół współdzielenia plików w sieci Microsoft Network (ang. Server Message Block) SMD - element elektroniczny przystosowany do montażu powierzchniowego (ang. Surface Mount Device) SNI - szeregowy interfejs sieciowy (ang. Serial Network Interface) SOI - flaga zakończenia transmisji danych (ang. Start Of Idle) SRGE - algorytm niezależnego od kontekstu bazy reguł klasyfikowania pakietów wykorzystujący kod BRGC (ang. Short Range Gray Encoding) TCAM - trójwartościowa pamięć adresowana zawartością (ang. Ternary Content Addressable Memory) TCP - strumieniowy protokół komunikacyjny warstwy transportowej modelu OSI (ang. Transmission Control Protocol) TE - model bezpieczeństwa systemów komputerowych bazujący na kontroli typów obiektów(ang. Type Enforcement) TOE NIC - kontroler NIC wyposażony w sprzętowe wspomaganie obsługi protokołów TCP/IP (ang. TCP/IP Offload Engine Network Interface Card) TP-PMD - podwarstwa obsługi medium transmisyjnego typu skrętka miedziana w modelu ISO/OSI (ang. Twisted Pair Physical Medium Dependent Sublayer) UDP - bezpołączeniowy protokół komunikacyjny zlokalizowany w warstwie transportowej modelu ISO/OSI (ang. User Datagram Protocol) UTM - system zunifikowanego zarządzenia zagrożeniami (ang. Unified Threat Management) VBA - język programowania zaimplementowany w aplikacjach pakietu Microsoft Office (ang. Visual Basic for Applications) VHDL - język opisu sprzętu (ang. Very High Speed Integrated Circuits Hardware Description Language) VPN - wirtualna sieć prywatna (ang. Virtual Private Network) WAN - rozległa sieć komputerowa (ang. Wide Area Network) WSC4VB - biblioteka funkcji obsługi komunikacji szeregowej dla języka VBA (ang. Windows Standard Serial Communications Library for Visual Basic) 9

10 1. Wstęp 1.1. Motywacja Metody ochrony krytycznych danych w firmach i instytucjach podlegają ciągłej ewolucji, powodowanej zmianami wymogów formalnych oraz postępem technologicznym w obszarze przetwarzania i przechowywania informacji. Powszechne wykorzystanie systemów komputerowych, postępujący proces cyfryzacji treści wraz z popularyzacją technologii sieciowej transmisji danych, doprowadził do sytuacji, w której pierwotne mechanizmy bezpieczeństwa, oparte głównie o środki fizyczne i procedury administracyjne, przestały należycie spełniać swe zadanie. Ewolucyjne zmiany dotknęły także informacji samej w sobie stała się ona strategicznym dobrem wymagającym szczególnej ochrony. Nieuprawnione wykorzystywanie poufnych zasobów, ich niekontrolowane przecieki, mogłyby bowiem wywołać nieodwracalne szkody z punktu widzenia interesów organizacji zarówno naukowych, jak również publicznych i komercyjnych. Globalna sieć Internet jest z jednej strony nieocenionym narzędziem służącym wymianie myśli i wiedzy we współczesnym świecie. Dla organizacji komercyjnych stanowi ona platformę efektywnego prowadzenia działalności gospodarczej, umożliwiając wzajemną komunikację kluczowych aplikacji biznesowych, niezależnie od lokalizacji geograficznej poszczególnych jednostek. Z drugiej strony tak ogromny potencjał Internetu daje dużej liczbie użytkowników dostęp do współdzielonych zasobów komputerowych, wprowadzając nieznane wcześniej zagrożenia dla bezpieczeństwa systemów informatycznych: włamania, wirusy, spamming, blokowanie działania, itp. Wskutek lawinowej ekspansji nowoczesnych, mobilnych urządzeń wymiany danych (np. komputery przenośne, telefony komórkowe typu smartfon, etc.), zaciera się bardzo wyraźna kiedyś granica pomiędzy wewnętrzną siecią chronioną biura czy też centrum danych a zewnętrznym, niebezpiecznym środowiskiem publicznego Internetu. Działy bezpieczeństwa informacji firm i instytucji starają się nadążyć za postępującymi zmianami, wdrażając coraz bardziej wyrafinowane systemy ochrony, jednak liczba nowych zagrożeń czyni to zadanie niełatwym. Niejednokrotnie wysiłek oraz nakłady finansowe poniesionie na wdrożenie systemów bezpieczeństwa wewnętrznych sieci organizacji nie przynoszą należytych efektów. Całkowita efektywność kompleksowego łańcucha ochrony danych jest bowiem uzależniona od jego najsłabszego ogniwa często jeden nieodpowiedzialny pracownik wykonujący powierzone mu zadania, korzystając z domowej publicznej sieci Internet, stanowi lukę pozwalającą na obejście (tzw. tylne drzwi) nawet najbardziej zaawansowanych systemów zabezpieczających [66]. O skali prezentowanego problemu dobitnie świadczą statystyki występujących obecnie zagrożeń. Firma Google wylicza, że z przeanalizowanych 450 milionów stron WWW (ang. World Wide Web) 10

11 publikowanych w sieci Internet 450 tysięcy było zainfekowanych złośliwym oprogramowaniem typu malware (z ang. malicious software). Każdego dnia identyfikowano ponad 8 tysięcy nowych przypadków takich stron [54]. Z kolei raporty czołowego producenta systemów bezpieczeństwa - firmy McAfee ostrzegają przed drastycznym zwiększeniem się szybkości rozprzestrzeniania szkodliwych aplikacji komputerowych. Przykładowo, program Code Red v2 (robak internetowy) potrzebował 14 godzin do zarażenia 400 tysięcy komputerów, dzięki czemu zespoły programistów dysponowały czasem niezbędnym do opracowania skutecznych środków ochrony. Bardziej zaawansowany robak Warhol w ciągu 15 minut był w stanie zainfekować ponad milion komputerów, podczas gdy najnowszy kod Flash dokonuje tego w ciągu zaledwie 30 sekund [67]. Drogą propagacji robaków i wirusów bywa najczęściej poczta elektroniczna (ang. ). Pomiędzy styczniem a marcem roku 2009 wysłano 139 miliardów niepożądanych wiadomości (tzw. spam), co stanowi 89% ogólnej liczby wiadomości przesłanych w tym okresie [66]. Wymienione przykłady ukazują jedynie niewielką grupę występujących współcześnie zagrożeń. Co niezwykle istotne, w miarę upływu czasu zwiększa się nie tylko liczba wykrywanych zdarzeń danego typu, ale również poszerza się zbiór metod naruszania bezpieczeństwa danych oraz systemów informatycznych służących ich przetwarzaniu. Naturalną konsekwencją takiego stanu rzeczy jest poszukiwanie automatycznych narzędzi pozwalających na zabezpieczenie krytycznych zasobów organizacji. Muszą one sprostać wyzwaniom wydajnościowo-funkcjonalnym, wynikającym ze stale powiększającego się wolumenu oraz szybkości przesyłania danych w sieciach teleinformatycznych, jak również z wykazanej wcześniej eskalacji rodzajów zagrożeń. Od początku swego istnienia aż do chwili obecnej architektura powszechnie wykorzystywanych systemów zabezpieczających bazuje przede wszystkim na rozwiązaniach programowych. Wszelkie implementowane funkcje ochrony danych są efektem wykonywania poleceń kodu specjalizowanego oprogramowania, uruchamianego na platformach sprzętowych ogólnego przeznaczenia. Tylko w nielicznych wypadkach tworzone są rozwiązania dedykowane: odpowiednio zaprojektowany sprzęt wraz z niezbędnym oprogramowaniem, co jednak znacznie podnosi koszty całego urządzenia. Standardowe podejście do budowy systemów bezpieczeństwa w oparciu o oprogramowanie posiada jednak wiele wad. Do najistotniejszych należy niewątpliwie duża podatność na próby naruszenia bezpieczeństwa, związana m.in. z wykorzystywaniem błędów systemów operacyjnych, stanowiących platformę dla implementacji programowego mechanizmu zabezpieczającego. Opisana sytuacja dotyczy nie tylko popularnych rodzin systemów operacyjnych Windows czy też Linux, ale również rozwiązań przeznaczonych wyłącznie do zastosowania w infrastrukturze sieci komputerowych produkowanych przez czołowe firmy tego sektora, takie jak Cisco, Check Point czy Juniper Networks. Przykładowo, w ciągu ostatnich 7 lat w oprogramowaniu Cisco IOS (ang. Internetwork Operating System) w wersji 12.x wykryto 82 błędy [89] pozwalające na złamanie zabezpieczeń, przejęcie kontroli nad urządzeniem wykorzystującym ten system bądź nieuprawniony dostęp do chronionych danych. Podobnie w wypadku innych produktów: Cisco 11

12 Intrusion Prevention System (IPS) 5.x - 6 luk bezpieczeństwa od 2005 roku [88], Cisco PIX 6.x 10 luk od 2003 roku [90], itd. Również inni producenci nie wypadają na tym polu lepiej od firmy Cisco. Presja rynkowa jak najszybszego wprowadzania do sprzedaży kolejnych generacji urządzeń oraz minimalizacja kosztów ich wytworzenia wpływają negatywnie na jakość wytwarzanych produktów, szczególnie w kontekście oferowanej stabilności pracy, funkcjonalności, a przede wszystkim poziomu ochrony danych. Drugie istotne ograniczenie konwencjonalnych systemów bezpieczeństwa, zbudowanych w oparciu o procesory ogólnego przeznaczenia GPP (ang. General Purpose Processors), to niska wydajność przetwarzania danych. Coraz szybszy rozwój technologii komunikacji sieciowej stymulowany jest przede wszystkim ogromnym zapotrzebowaniem na pasmo transmisyjne, generowane przez współczesne aplikacje strumieniowe. Standard 10 Gb Ethernet staje się powoli powszechnym medium komunikacyjnym w większości centrów przetwarzania danych; w drugim kwartale 2010 roku sprzedano ponad milion portów tego rodzaju [17]. Tak duża przepustowość uniemożliwia wykorzystanie wyłącznie programowych metod analizy przesyłanych danych. Producenci posiłkują się w takich przypadkach akceleracją wybranych elementów funkcjonalnych kompletnego systemu (np. obsługa wirtualnych sieci prywatnych tzw. VPN), najczęściej przy wykorzystaniu specjalizowanych układów ASIC (ang. Application Specific Integrated Circuit), bądź stosują wydajniejsze wersje procesorów GPP. Oczywiście konsekwencją takich działań jest wzrost ceny urządzenia, często nieadekwatny do rzeczywistych kosztów poniesionych przez producentów. Na rynku produktów komputerowych jest bowiem bardzo wyraźnie zarysowana granica ekonomiczna pomiędzy tanim sprzętem popularnym, adresowanym do szerokiego grona odbiorców (ang. low level) a wielokrotnie droższymi, zaawansowanymi rozwiązaniami z grupy profesjonalnej (ang. high-end) Cel i teza pracy Ostatnie lata przyniosły również dynamiczny rozwój technologii cyfrowych układów programowalnych FPGA (ang. Field Programmable Gate Array). Nieustannie zwiększająca się szybkość oraz coraz większa ilość dostępnych zasobów sprzętowych, otwierają przed logiką reprogramowalną nowe obszary zastosowań. Oferowana przez układy FPGA elastyczność w zakresie zmian konfiguracji zasobów wewnętrznych, umożliwia budowę systemów uniwersalnych i parametryzowanych przy jednoczesnej dużej ekonomiczności takiego rozwiązania. Ma ona związek z możliwością zapamiętywania części map konfiguracji w pamięci RAM i dynamicznego rekonfigurowania struktury w zależności od aktualnych potrzeb. Nieograniczona liczba takich zmian, wynikająca z faktu zapisywania konfiguracji w pamięci RAM, pozwala na zastosowanie układów reprogramowalnych w projektach, w których sprzęt musi być ściśle dostosowany do wymagań aplikacji różnych użytkowników. Atrakcyjność technologii FPGA bierze się z połączenia jej naturalnych walorów, wpływających m.in. na skrócenie czasu opracowania prototypów oraz łatwości modyfikacji funkcjonalnej realizowanych systemów, ze stale polepszającymi się ich parametrami 12

13 użytkowymi, takimi jak: szybkość działania czy też wielkość dostępnych zasobów [122, 123]. Fakt ten został bardzo szybko dostrzeżony przez wiele zespołów badawczych, koncentrujących swą aktywność naukową na optymalizacji systemów zabezpieczających transmisję danych w sieciach teleinformatycznych [7, 31, 59, 61, 62, 81]. Wykorzystanie potencjału układów FPGA stwarza bowiem całkowicie nowe możliwości w dziedzinie zdominowanej dotychczas przez rozwiązania oparte o procesory GPP. W tym miejscu watro jednak podkreślić, że w zdecydowanej większości prowadzone w tym zakresie prace badawcze skupiają się przede wszystkim na ulepszaniu algorytmów klasyfikacji danych, pomijając lub marginalizując kwestie pozostałych elementów wchodzących w skład architektury Firewalla. Tylko niewielka grupa publikacji [43, 59] podejmuje temat kompleksowej sprzętowej implementacji zapory ogniowej z wykorzystaniem logiki reprogramowalnej. Jednak nawet w wypadku takich prac, stosowane wstępne założenia projektowe powodują ograniczenie funkcjonalności bądź elastyczności konfiguracji systemu, w sposób utrudniający jego praktyczną eksploatację. Obserwacje te legły u podstaw podjęcia przez autora niniejszej rozprawy badań w zakresie metod efektywnej realizacji sprzętowego Firewalla, przy uwzględnieniu realnych wymagań funkcjonalnych, stawianych przez współczesne, wysoko wydajne systemy komputerowe. Celem pracy była praktyczna realizacja w pełni funkcjonalnego, rekonfigurowanego systemu ochrony transmisji danych typu Firewall, zaimplementowanego w logice FPGA, pozbawionego wszelkich elementów programowych w procesie klasyfikacji przetwarzanych danych. Dzięki temu wyeliminowana została możliwość włamań poprzez uruchamianie obcego kodu, przejmowanie uprawnień, itp. Spodziewanym rezultatem zastosowania sprzętowego weryfikowania pakietów pod kątem zgodności z bazą reguł bezpieczeństwa miał być również znaczący wzrost wydajności przetwarzania danych. Rozprawa ta wpisuje się w nowy, dynamicznie rozwijający się nurt wykorzystywania technologii FPGA w obszarach zabezpieczania transmisji danych w szybkich sieciach teleinformatycznych. Większość z zaplanowanych prac badawczych prowadziło do opracowania elementów otwierających nowe możliwości dla zastosowania logiki reprogramowalnej. Wymienić tutaj można sprzętową implementację kontrolerów sieci Ethernet czy też mechanizmy analizy transmitowanego strumienia danych, stanowiących zasadniczy element projektowanego systemu bezpieczeństwa. Doświadczenia zdobyte w trakcie realizacji niniejszej rozprawy pozwolą kontynuować prace badawcze w opisanym powyżej zakresie. W wyniku przeprowadzonych badań, autor zamierza udowodnić następującą tezę pracy: Implementacja w układach FPGA rekonfigurowanego systemu ochrony transmisji danych typu Firewall dla sieci Ethernet o wielkich przepływnościach pozwala uzyskać wysoki poziom bezpieczeństwa, dużą szybkość przetwarzania danych oraz możliwość dynamicznej zmiany parametrów. 13

14 1.3. Organizacja pracy Niniejsza praca została podzielona na 6 rozdziałów obejmujących zagadnienia związane z przedmiotem prowadzonych badań, w szczególności: przegląd i analizę dostępnych metod i systemów klasyfikacji pakietów w systemach ochrony transmisji danych, prezentację niezbędnych składników środowiska testowo-uruchomieniowego oraz zasadniczy opis poszczególnych elementów zrealizowanej zapory ogniowej. Rozdział 1 zarysowuje w sposób ogólny genezę oraz problematykę przeprowadzonych badań. Na tym tle prezentuje również tezę pracy oraz jej główny cel. Rozdział 2 prezentuje przekrojową analizę dostępnych algorytmów oraz systemów zabezpieczania krytycznych zasobów informacyjnych ze szczególnym uwzględnieniem sposobów sprzętowej akceleracji procesu weryfikacji przetwarzanych pakietów. Autor w syntetyczny i czytelny sposób stara się podsumować wady i zalety poszczególnych rozwiązań, poszukując na tej podstawie dróg dalszej optymalizacji procesu klasyfikacji pakietów oraz architektury zapory ogniowej. Rozdział 3 zawiera dokładny opis elementów wchodzących w skład środowiska testowouruchomieniowego, niezbędnego do realizacji prac projektowych. W szczególności omawia parametry i konfiguracje wykorzystywanych płyt z układami FPGA oraz środowiska programistycznego Active-HDL. Rozdział 4 przedstawia budowę, funkcjonalność oraz uzyskane parametry wydajnościowe zrealizowanych w ramach prac badawczych sprzętowych wersji kontrolerów MAC dla sieci Ethernet. Stanowią one główny pomost komunikacyjny pomiędzy silnikiem klasyfikacji pakietów a urządzeniami przesyłającymi dane w infrastrukturze sieciowej. Rozdział 5 to kluczowa część rozprawy, zawierająca opis opracowanej architektury sprzętowej zapory ogniowej wraz z charakterystyką poszczególnych elementów wchodzących w jej skład. Dla każdego z modułów sprzętowego Firewalla szczegółowo omówiono realizowane przez nie funkcjonalności, jak również zaprezentowano uzyskane parametry implementacji w układach FPGA. Rozdział 6 zawiera wnioski końcowe, najistotniejsze osiągnięcia uzyskane w toku realizacji pracy oraz zarys przyszłych kierunków badań nad rozwojem opracowanego systemu. Dodatki prezentują pełne wyniki syntezy logicznej, jak również wyjaśniają funkcje linii sygnałowych poszczególnych modułów kompletnej sprzętowej zapory ogniowej. Do pracy załączono także płytę CD z dokumentacją techniczną oraz kodami źródłowymi w języku VHDL. 14

15 2. Przegląd rozwiązań systemów ochrony danych przesyłanych w sieciach teleinformatycznych 2.1. Wprowadzenie Wykazany we wstępie do niniejszej rozprawy ogromny wzrost liczby potencjalnych zagrożeń dla danych przetwarzanych w formie cyfrowej generuje potrzebę stosowania szeregu różnorodnych systemów zabezpieczających. Od wielu lat dominujące wśród nich są rozwiązania określane mianem ścian ogniowych (ang. Firewall). W miarę upływu czasu, w związku z dynamicznym postępem technologicznym, ta wąska początkowo grupa rozrosła się do wielkiej rodziny, składającej się obecnie z wielu odmiennych funkcjonalnie urządzeń. W tej sytuacji punktem wyjścia przy opracowywaniu ich klasyfikacji musi być próba sformułowania ogólnej definicji systemu bezpieczeństwa typu Firewall, obejmującej wszelkie formy jego implementacji. Optymalnym terminem wydaje się być generalne stwierdzenie opisujące Firewall jako systemem komputerowy, złożony z komponentów sprzętowych oraz/lub programowych, zabezpieczający wewnętrzną sieć teleinformatyczną organizacji w każdym z punktów styku z mniej zaufanymi sieciami zewnętrznymi (np. Internetem) [10, 70]. Zwykle, w warunkach rzeczywistych, administratorzy zapór ogniowych zdecydowanie bardziej rygorystycznie podchodzą do weryfikacji ruchu sieciowego pochodzącego spoza danej organizacji, niż w odniesieniu do informacji wysyłanych w kierunku przeciwnym. Wszystkie istniejące typy systemów Firewall analizują strumienie danych pod kątem zgodności z obowiązującym schematem polityki bezpieczeństwa. Ocena taka dokonywana jest na podstawie zawartości określonych pól w przetwarzanych pakietach, ulokowanych w różnych warstwach modelu referencyjnego OSI [42], w zależności od typu wykorzystywanej ściany ogniowej. To właśnie opisany czynnik funkcjonowanie w ściśle określonej warstwie modelu OSI jest podstawą do dokonania głównego podziału funkcjonalnego całej rodziny systemów Firewall, zaprezentowanego w dalszej części rozdziału. Drugi istotny czynnik wyróżniający poszczególne implementacje dotyczy platformy wykorzystanej do budowy systemu bezpieczeństwa. Do niedawna najbardziej rozpowszechnionymi w tym obszarze były rozwiązania wykorzystujące procesory ogólnego przeznaczenia GPP oraz dedykowane oprogramowanie filtrujące [36]. Obecnie wiele zespołów badawczych poszukuje alternatywnych metod weryfikacji danych przesyłanych w sieciach teleinformatycznych, opracowując nowe algorytmy klasyfikujące [5, 6, 33] bądź wykorzystując ogromny potencjał stricte sprzętowych realizacji, bazujących na logice reprogramowalnej FPGA [7, 31, 59, 61, 62, 81]. 15

16 2.2. Klasyfikacja funkcjonalna W początkowym okresie istnienia zapór ogniowych podział pomiędzy poszczególnymi ich rodzajami rysował się w sposób jasny i czytelny. Definiował go jedynie poziom w modelu OSI, do którego system analizował przetwarzane dane. W miarę rozwoju technik zabezpieczania transmisji sieciowej następowało coraz większe różnicowanie ścian ogniowych, któremu często towarzyszyło łączenie funkcjonalności odrębnych wcześniej rozwiązań. Powstawały więc swego rodzaju hybrydy nie wnoszące całkowicie nowych usług, lecz pozwalające na lepsze dostosowanie się do wymagań specyficznych użytkowników. Proces ten trwa nadal; co więcej w ostatnich latach przybrał on na sile, choć, obserwując jego kierunek, można wysnuć wniosek, że kolejne generacje wprowadzonych urządzeń w wielu przypadkach inicjowane są planami marketingowymi producentów, aniżeli racjonalnymi potrzebami klientów. W celu sformułowania pełnej klasyfikacji ścian ogniowych również i takie systemy zostały uwzględnione w zaprezentowanym dalej zestawieniu Pasywne filtry pakietów Pasywne filtry pakietów (ang. Static Packet Filters) są najstarszą i najprostszą z istniejących architektur systemów bezpieczeństwa typu Firewall [36]. Z tej przyczyny aktualnie stanowią najbardziej popularną metodę ochrony danych przesyłanych w sieciach komputerowych. Znajdują zastosowanie zarówno w komercyjnych rozwiązaniach, takich jak listy kontroli dostępu Cisco ACL (ang. Access Control List), czy też w otwartych rozwiązaniach typu IPChains (obecnie IPTables) wykorzystywanych w systemie operacyjnym Linux [76]. Statyczny filtr pakietów WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI PREZENTACJI SESJI TRANSPORTOWA SIECIOWA ŁĄCZA DANYCH FIZYCZNA Sieć zewnętrzna Interfejs sieciowy Interfejs sieciowy Sieć wewnętrzna Rys Poglądowy schemat strukturalny pasywnego filtru pakietów. Weryfikacja przetwarzanych pakietów dokonywana jest w filtrach statycznych na podstawie danych zawartych w nagłówkach warstwy sieciowej i transportowej (Rys.2.1), obejmujących: źródłowy adres IP, docelowy adres IP, 16

17 numer portu źródłowego, numer portu docelowego, typ protokołu. Podstawową zaletą statycznych filtrów pakietów jest ich duża wydajność [2] oraz niski koszt budowy wynikający z ograniczonej funkcjonalności. Negatywną konsekwencją tego jest podatność na ataki polegające na podszywaniu się pod zaufane adresy sieciowe (tzw. spoofing). Administrator systemu, tworząc schemat reguł odzwierciedlających obowiązującą politykę bezpieczeństwa, zmuszony jest do uwzględniania wszystkich możliwych przypadków komunikacji występującej w danej sieci komputerowej. Pasywne filtry pakietów nie analizują bowiem stanów połączeń [13], stąd każdemu otwartemu portowi aplikacji wysyłającej bądź odbierającej dane należy przyporządkować dedykowaną regułę zezwalającą albo zapobiegającą przepływowi strumienia informacji. Konieczne jest również zastosowanie domyślnej reguły blokującej ruch pakietów zawierających nagłówki wykraczające poza wcześniej zdefiniowany schemat polityki bezpieczeństwa Dynamiczne filtry pakietów Dynamiczne filtry pakietów stanowią modyfikację wersji pasywnej, polegającą na wprowadzeniu analizy stanów połączeń. Do weryfikacji przetwarzanych danych wykorzystują one dokładnie te same pola, jak w przypadku filtrów statycznych, stąd ulokowanie w modelu OSI jest analogiczne do przedstawionego na rysunku 2.1. Dane o połączeniach przechowywane są w specjalnej tablicy (ang. Connection Bypass table) [10], dzięki czemu filtr jest w stanie precyzyjnie śledzić poszczególne fazy nawiązywania komunikacji, a przez to określać ich zgodność z obowiązującymi standardami. Jeśli przetwarzany pakiet zostanie zidentyfikowany jako część już wcześniej zainicjowanego połączenia, nie jest konieczna jego dalsza weryfikacja [36]. Wpływa to na zwiększenie wydajności przetwarzania informacji w stosunku do klasycznych filtrów statycznych, które muszą analizować wszystkie pakiety. Najbardziej krytycznym elementem konstrukcji dynamicznego filtru pakietów jest tablica połączeń implementowana w pamięci RAM (ang. Random Access Memory). Pamięć taka dysponuje zwykle ograniczoną pojemnością, co ma związek z minimalizacją kosztów urządzeń. Dlatego filtry dynamiczne są podatne na ataki typu maksymalnego wykorzystania zasobów (ang. resource starvation attack) [10]. W takiej sytuacji Firewall może wykonać następujące akcje [30]: zablokować generowanie nowych wpisów do tablicy połączeń, a tym samym doprowadzić do paraliżu funkcjonalnego systemu odmowa usługi, czyli atak typu DoS (ang. Denial of Service), usunąć tylko najstarsze wpisy LRU (ang. Last Recently Used), upewniając się najpierw, czy połączenie nadal nie jest aktywne, zastosować mechanizm wczesnej detekcji losowej (ang. Random Early Detection), wybierający i usuwający pakiety w sytuacji przepełniania się tabeli połączeń, 17

18 usuwać po określonym czasie (ang. time out) poszczególne wpisy z tabeli połączeń Bramki typu Circuit-level Bramki typu Circuit-level, zwane również filtrami połączeń [10] lub bramkami na poziomie sesji [48], stanowią kolejny etap zwiększania funkcjonalności filtrów pakietów. Operując na piątej warstwie modelu OSI (Rys. 2.2), można pozyskać dodatkowe informacje pozwalające na dokładniejszą weryfikację strumieni danych. Pełna lista analizowanych pól obejmuje [36]: źródłowy adres IP, docelowy adres IP, numer portu źródłowego, numer portu docelowego, typ protokołu, potwierdzenia protokołu transmisyjnego oraz numery sekwencji. Bramka typu Circuit-level WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI PREZENTACJI SESJI TRANSPORTOWA SIECIOWA ŁĄCZA DANYCH FIZYCZNA Sieć zewnętrzna Interfejs sieciowy Interfejs sieciowy Sieć wewnętrzna Rys Poglądowy schemat strukturalny bramki typu Circuit-level. Pierwszym etapem weryfikacji pakietów jest sprawdzenie zgodności pól adresowych oraz portów z zapisami zdefiniowanymi w zestawie reguł bezpieczeństwa. Następnie filtr analizuje parametry sesji na podstawie flag SYN, ACK oraz numeru sekwencji potwierdzeń protokołu TCP (ang. Transmission Control Protocol) pod kątem zgodności z wymogami specyfikacji RFC 793 [16]. Do tego celu wykorzystuje on specjalną tabelę weryfikacji połączeń (ang. Connection Verification Table), w której każdy wpis zawiera informacje o stanie flag (m.in. SYN, ACK) oraz numer sekwencji ostatnio odebranego pakietu w danym strumieniu komunikacyjnym [10]. Bramki tego typu charakteryzują się dużą wydajnością przetwarzania danych, ponieważ operują na dolnych warstwach modelu OSI. Dzięki swej funkcjonalności umożliwiają zabezpieczenie istotnych segmentów sieci komputerowych przed atakami hakerów polegającymi na przejmowaniu sesji (tzw. hijack) i wprowadzaniu w strumienie połączeń nieautoryzowanych pakietów danych. 18

19 Bramki aplikacyjne Bramka aplikacyjna (ang. Application-level Gateway), określana także jako filtr aplikacyjny [10], analizuje szczegółowe dane zawarte w najwyższej warstwie modelu OSI (Rys. 2.3). Taka funkcjonalność wymusza pełną obsługę połączeń pomiędzy komputerami zlokalizowanymi w sieci zewnętrznej oraz w bezpiecznym segmencie wewnętrznym [76], stąd też konieczne jest zaimplementowanie w filtrze aplikacyjnym dedykowanego oprogramowania pośredniczącego (tzw. proxy). Zazwyczaj jest ono dedykowane do obsługi konkretnej usługi sieciowej (np. HTTP, FTP, itp.), stąd w przypadku wykrycia nieobsługiwanego serwisu proxy zablokuje takie pakiety [13, 30]. Co więcej, zastosowanie rozważań dedykowanych poszczególnym aplikacjom, pozwala na drobiazgową analizę przetwarzanych danych aż do poziomu poszczególnych poleceń danego protokołu. Dzięki temu administrator otrzymuje narzędzie umożliwiające bardzo precyzyjne przydzielanie uprawnień dostępowych do poszczególnych usług systemów informatycznych na etapie tworzenia polityki bezpieczeństwa organizacji. Bramka aplikacyjna WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI PREZENTACJI SESJI TRANSPORTOWA SIECIOWA ŁĄCZA DANYCH FIZYCZNA Sieć zewnętrzna Interfejs sieciowy Interfejs sieciowy Sieć wewnętrzna Rys Poglądowy schemat strukturalny bramki aplikacyjnej. Wysoki poziom ochrony oferowany przez bramki aplikacyjne wynika z weryfikowania przez nie wszystkich istotnych informacji zawartych w górnych poziomach modelu OSI, począwszy od warstwy sieciowej. Negatywną konsekwencją takiej funkcjonalności jest niewątpliwie duży narzut wydajnościowy, związany z koniecznością obsługi proxy. Producenci filtrów aplikacyjnych zmuszeni są do ciągłego śledzenia potrzeb odbiorców wykorzystujących coraz to nowe usługi sieciowe, bowiem dla każdej z nich trzeba tworzyć specyficzną aplikację pośredniczącą implementowaną w bramce. O ile rosnące w ten sposób zapotrzebowanie na moc obliczeniową można w stosunkowo łatwy sposób zaspokoić poprzez zastosowanie nowocześniejszych procesorów GPP, to w przypadku dodawania kolejnych elementów aplikacyjnych istnieje duże ryzyko niewykrycia na etapie testów luk w oprogramowaniu. Dlatego w wielu wypadkach nieostrożna implementacja oraz słaba jakość kodu źródłowego doprowadziły do złamania zabezpieczeń tego typu systemów (szczególnie poprzez ataki polegające na tzw. przepełnieniu bufora ang. buffer overrun) [36]. 19

20 Filtry typu Stateful Inspection Omówiona w punkcie bramka aplikacyjna jest ostatnim z wariantów rozbudowy funkcjonalnej filtru pakietów. Kolejno prezentowane systemy bezpieczeństwa stanowią złożenie kilku bloków filtrujących, pozwalających na uzyskanie dodatkowych mechanizmów ochrony przesyłanych informacji. Pierwszą tego rodzaju hybrydą jest filtr typu Stateful Inspection. W teorii analizuje on wszystkie 7 warstw modelu OSI (Rys. 2.4), łącząc w sobie cechy dynamicznego filtru pakietów, bramki Circuit-level oraz bramki aplikacyjnej. Każdy z analizowanych pakietów jest najpierw weryfikowany pod kątem zgodności z zakresami adresów i portów sieciowych, zdefiniowanych w regułach bezpieczeństwa. Kolejno weryfikowane są pod kątem logiczności flagi SYN, ACK oraz numery sekwencji, tak jak ma to miejsce w filtrach połączeń. Na koniec w ograniczonym zakresie możliwe jest przeprowadzenie oceny kontekstowej danych aplikacji. Filtr typu Stateful Inspection WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI PREZENTACJI PREZENTACJI PREZENTACJI SESJI SESJI SESJI TRANSPORTOWA TRANSPORTOWA TRANSPORTOWA SIECIOWA SIECIOWA SIECIOWA ŁĄCZA DANYCH ŁĄCZA DANYCH ŁĄCZA DANYCH FIZYCZNA FIZYCZNA FIZYCZNA Sieć zewnętrzna Interfejs sieciowy Dynamiczny filtr pakietów Ograniczone funkcje bramki typu Circuit-level Ograniczone funkcje bramki aplikacyjnej Interfejs sieciowy Sieć wewnętrzna Rys Poglądowy schemat strukturalny filtru typu Stateful inspection. Praktyczne implementacje, pomimo odmiennych twierdzeń producentów, często ograniczają się jednak wyłącznie do obsługi jedynie warstwy sieciowej, co ma związek z ogromnym obciążeniem generowanym przez pojedyncze wątki analizy stanu połączeń [36]. Wymusza to konieczność degradacji funkcjonalności urządzenia do poziomu odpowiadającego dynamicznemu filtrowi pakietów. Co bardziej istotne, duża część rozwiązań typu Stateful inspection wykorzystuje w swym działaniu jednowątkowe procesy obsługujące algorytmy weryfikujące, stąd brak jest możliwości kompensowania zapotrzebowania na moc obliczeniową poprzez wykorzystanie nowoczesnych procesorów wielordzeniowych GPP. Dodatkowym problemem są ograniczenia języka stosowanego do opisu reguł bezpieczeństwa dla silnika klasyfikującego, z tego też powodu zdecydowanie szybciej popularyzują się rozwiązania bramek aplikacyjnych [36, 100] Proxy odcinające Proxy odcinające (ang. Cutoff Proxy) stanowi złożenie dynamicznego filtru pakietów oraz części funkcjonalności bramki na poziomie sesji (Rys. 2.5). W pierwszej kolejności weryfikowane są 20

21 parametry sesji pod kątem zgodności z wymaganiami rekomendacji RFC [16], w szczególności trójetapowa wymiana komunikatów oraz niezbędna autentykacja. Po poprawnym zakończeniu analizy stanu sesji Proxy przełącza się w tryb dynamicznego filtru pakietów, weryfikującego parametry trzeciej warstwy modelu OSI [36]. Proxy odcinające WARSTWY MODELU REFERENCYJNEGO OSI WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI APLIKACJI PREZENTACJI PREZENTACJI SESJI SESJI TRANSPORTOWA TRANSPORTOWA SIECIOWA SIECIOWA ŁĄCZA DANYCH ŁĄCZA DANYCH FIZYCZNA FIZYCZNA Sieć zewnętrzna Interfejs sieciowy Ograniczone funkcje bramki typu Circuit-level Dynamiczny filtr pakietów Interfejs sieciowy Sieć wewnętrzna Rys Poglądowy schemat strukturalny filtru proxy odcinającego. W przeciwieństwie do standardowej bramki sesyjnej, omówionej w punkcie 2.2.3, proxy odcinające nie tworzy bariery w modelu klient-serwer w czasie nawiązywania połączenia. Stanowi ono bezpośrednie połączenie pomiędzy zdalnym klientem a serwerem usługowym zlokalizowanym za zabezpieczającą go ścianą ogniową [36]. Cecha ta lokuje proxy odcinające w grupie tzw. pośredników transparentnych (ang. Transparent Proxies), które mogą przesyłać otrzymywane pakiety bez konieczności ich modyfikowania [10]. Jest to oczywiste ograniczenie w stosunku do funkcjonalności typowych bram sesyjnych, powodujące zmniejszenie poziomu zabezpieczeń świadczonych przez zaporę. Z drugiej strony, z racji ogromnej różnorodności systemów sieciowych, a przez to i potrzeb w zakresie ich ochrony, proxy odcinające znajdują swoje miejsce w grupie systemów realizujących tego typu usługi Rozwiązania typu Air Gap System zabezpieczający typu Air Gap (szczelina powietrzna) jest dobrym przykładem obrazującym występujące obecnie zjawisko szybkiego wprowadzania do sprzedaży nowych rozwiązań systemów Firewall, których nowatorstwo sprowadza się jedynie do wdrożenia elementów pozwalających na odróżnianie się od produktów konkurencyjnych. Nie powoduje to istotnej zmiany funkcjonalnej. Co gorsze, często cechy użytkowe nowego produktu ulegają pogorszeniu. Tak jest właśnie w przypadku systemu Air Gap, w którym każde z połączeń pochodzących z zewnętrznej sieci przed przekazaniem do segmentu chronionego zostaje zapisane na wewnętrzny dysk twardy (Rys. 2.6). Utworzony w ten sposób bufor szczelina powietrzna, zdaniem producentów, zapewnia uzyskanie większego poziomu bezpieczeństwa chronionych danych [36]. 21

22 Air Gap Dysk twardy APLIKACJI PREZENTACJI SESJI TRANSPORTOWA SIECIOWA ŁĄCZA DANYCH FIZYCZNA Sieć zewnętrzna Interfejs sieciowy WARSTWY MODELU REFERENCYJNEGO OSI Interfejs sieciowy Sieć wewnętrzna Rys Poglądowy schemat strukturalny rozwiązania typu Air Gap. Weryfikacja danych dokonywana jest we wszystkich warstwach modelu OSI, stąd rozwiązanie Air Gap jest bliźniaczo podobne do bramki aplikacyjnej. Trudno jest doszukać się wyjątkowego zysku z wykorzystania dodatkowego mechanizmu buforująco-separującego w postaci dysku twardego. Element ten wpływa raczej na degradację zarówno wydajności systemu, jak również jego awaryjności. Typowa brama aplikacyjna wykorzystuje również buforowanie, tyle że zrealizowane za pomocą pamięci RAM, która jest zdecydowanie szybsza od dysku twardego oraz mniej zawodna, ze względu na brak jakichkolwiek elementów mechanicznych Filtry typu Deep Packet Inspection Mechanizm głębokiej analizy pakietów DPI (ang. Deep Packet Inspection) polega na szczegółowej analizie zawartości przetwarzanych pakietów w celu odnalezienia określonych wzorców bajtowych, zdefiniowanych w bazie sygnatur. W tradycyjnych implementacjach każda z reguł bezpieczeństwa zawiera ciąg znakowy identyfikujący konkretne zdarzenie bądź zagrożenie dla bezpieczeństwa danych [51]. Dzięki temu, że filtry DPI stanowią połączenie systemu detekcji intruzów IDS (ang. Intrusion Detection System) oraz ściany ogniowej [25], w przypadku wykrycia określonego wzorca automatycznie blokują niebezpieczne połączenia. Odmienne od konwencjonalnych systemów Firewall podejście do weryfikacji danych, polegające na monitorowaniu jedynie podejrzanego ruchu, niesie z sobą pewną słabość tego typu rozwiązań. Całkowita efektywność wykrywania zagrożeń sprowadza się bowiem do poziomu aktualności bazy sygnatur. Jest to zadanie niezwykle trudne wobec ogromnej liczby zagrożeń powstających co roku. Jeśli wziąć pod uwagę jedynie złośliwe oprogramowanie (tzw. malware), w każdym kwartale jest rejestrowanych klika milionów nowych przypadków (Rys. 2.7). Do tego należy uwzględnić jeszcze wszelkiego rodzaju luki w systemach i aplikacjach użytkowych oraz zagrożenia związane z ingerencją w protokoły komunikacyjne. 22

23 Liczba zarejestrowanych przypadków 4,500,000 4,000,000 3,500,000 3,000,000 2,500,000 2,000,000 1,500,000 1,000, ,000 0,000 Q Przyrost Malware (pierwsze kwartały lat ) Q Rys Porównanie liczby zarejestrowanych przypadków oprogramowania malware w pierwszych kwartałach lat [66]. Q Dodatkowym problemem jest zapewnienie odpowiednio skalowalnej bazy danych sygnatur, która zapewni możliwość przechowywania nowopowstających wzorców przez cały okres eksploatacji urządzania (zwykle 3-5 lat) Zunifikowane zarządzanie zagrożeniami Najnowszym produktem w dziedzinie ochrony danych jest system zunifikowanego zarządzenia zagrożeniami UTM (ang. Unified Threat Management). Według definicji IDC (ang. International Data Corporation) UTM to dedykowane urządzenie (tzw. appliance), które unifikuje i integruje wiele funkcjonalności bezpieczeństwa na pojedynczej platformie sprzętowej. Zaklasyfikowanie do tej kategorii wymaga zaimplementowania co najmniej podsystemu Firewalla, detekcji lub prewencji przed intruzami (IDS lub IPS) oraz skanera antywirusowego. Niekoniecznie trzeba ich używać równocześnie, ale muszą istnieć w danym produkcie [36, 41, 87]. Tak bogate wyposażenie bywa jednak w praktyce często ograniczane przez producentów redukujących koszty wytworzenia. Stosowanie typowych komercyjnych lub otwartych systemów operacyjnych, w których funkcjonują poszczególne usługi bezpieczeństwa, stwarza ogromne zagrożenie dla chronionych danych. W takiej sytuacji zdecydowanie łatwiej jest dokonać włamania do bazowego systemu operacyjnego niż bezpośrednio do poszczególnych usług bezpieczeństwa [36]. Podobne redukcje dotykają pozostałych podsystemów: IDS/IPS, antywirus czy też antyspam. Do poprawnej pracy wymagają one bieżącej aktualizacji baz sygnatur, co narzuca na producenta obowiązek utrzymania kosztownych laboratoriów gromadzących informacje o nowych przypadkach zagrożeń bądź zakupywania gotowych aktualizacji od zewnętrznych podmiotów prowadzących tego typu działalność. 23

24 2.3. Klasyfikacja implementacyjna Rozwój platform implementacyjnych systemów bezpieczeństwa typu Firewall jest ściśle powiązany z opisaną w rozdziale 2.2 klasyfikacją funkcjonalną. Wdrażanie nowych mechanizmów ochrony danych niesie z sobą konieczność poszukiwania coraz bardziej wydajnych algorytmów lub architektur sprzętowych. Trend ten utrzymuje się stale, choć obecnie jest bardziej uwarunkowany przez lawinowo rosnącą ilość informacji przetwarzanych w systemach zabezpieczających. Jego efektem jest powstanie rozwiązań wyraźnie wyróżniających w dotychczas jednorodnej grupie systemów stricte programowych, wykorzystujących aplikacje filtrujące oraz popularne procesory ogólnego przeznaczenia. Mowa tutaj o próbach zastosowania rozwiązań sprzętowych w postaci układów ASIC, FPGA bądź pamięci TCAM jako metody zwiększenia bezpieczeństwa oraz wydajności przetwarzania danych Firewalle programowe Historycznie najstarsza metoda implementacji ścian ogniowych wykorzystuje dedykowane aplikacje filtrujące działające w systemie komputerowym opartym na procesorach GPU. To rozwiązanie, choć niewątpliwie najprostsze i najtańsze z możliwych, niesie ze sobą wiele poważnych wad (Rys. 2.8). Przede wszystkim wykorzystanie typowego (powszechnie wykorzystywanego) systemu operacyjnego umożliwia hakerom podejmowanie prób włamań z wykorzystaniem znanych luk bezpieczeństwa. Atak Aplikacja usługowa Aplikacja usługowa Niemodyfikowany system operacyjny Moduły obsługi komunikacji sieciowej Platforma komputerowa ogólnego przeznaczenia Ograniczenia wydajnościowe Rys Poglądowy diagram wrażliwych punktów struktury programowego Firewalla. O skali tego problemu świadczy dobitnie liczba rejestrowanych co roku błędów w zabezpieczeniach oprogramowania. Przykładowe zestawienie za rok 2009 dla czterech wybranych wersji popularnych systemów operacyjnych zaprezentowano na rysunku

25 Liczba zarejestrowanych luk bezpieczeństwa Microsoft Windows Server 2008 SUSE Linux Enterprise Server (SLES) 11 Red Hat Enterprise Linux ES4 Debian GNU/Linux 5.0 Rys Liczba luk bezpieczeństwa wybranych systemów operacyjnych wykrytych w roku 2009 (na podstawie [102]). Producenci systemów operacyjnych starają się na bieżąco wydawać odpowiednie poprawki likwidujące wykryte zagrożenia. Jednak to na użytkownikach zapór ogniowych ciąży odpowiedzialność ciągłej aktualizacji oprogramowania wewnętrznego. Jakiekolwiek zaniedbania w tej kwestii mogą doprowadzić do przełamania zabezpieczeń i utraty istotnych danych. Drugi problemem dotyczy platformy sprzętowej wykorzystanej do budowy tego typu urządzeń. Z reguły minimalizacja kosztów produkcji zmusza producentów do stosowania uniwersalnych rozwiązań sprzętowych wyposażonych w popularne procesory ogólnego przeznaczenia. Nieoptymalizowana pod kątem realizowanych zadań architektura płyt głównych, w połączeniu z dużą ilością zbędnych usług działających w systemie operacyjnym, zmniejsza w sposób radykalny całkowitą wydajność zapory. Poszukiwania metod rozwiązania opisanych słabych stron zapór programowych obejmują kilka równolegle rozwijających się działań: tworzenie specjalnie zabezpieczonych wersji systemów operacyjnych, optymalizacja algorytmów klasyfikujących pakiety, akceleracja weryfikacji danych z wykorzystaniem rozwiązań sprzętowych. 25

26 Zabezpieczanie systemu operacyjnego, zwane również utwardzaniem (ang. hardening), polega na minimalizacji ekspozycji na aktualne oraz przyszłe zagrożenia poprzez przeprowadzenie pełnej konfiguracji systemu wraz z usunięciem zbędnych aplikacji i urządzeń [78]. Proces ten nie kończy się na jednorazowej aktywności, lecz powinien być kontynuowany przez administratorów w toku produkcyjnej eksploatacji poszczególnych urządzeń. W przypadku wykorzystywania systemu operacyjnego do budowy dedykowanych ścian ogniowych, utwardzanie powinno sięgać o wiele dalej. Konieczna jest ingerencja w kod źródłowy systemu, tak, aby wdrożyć mechanizmy rozgraniczające w wyraźny sposób obszary, w których funkcjonują aplikacje bezpieczne bądź narażone na złamanie (Rys. 2.10). Dopiero takie podejście daje gwarancję prawidłowej ochrony danych, eliminując możliwość włamania się hakera do systemu operacyjnego z wysokimi prawami użytkownika [36]. Atak Niezabezpieczona aplikacja usługowa Zabezpieczona aplikacja usługowa Bezpieczny system operacyjny Bezpieczne moduły obsługi komunikacji sieciowej Granica bezpieczeństwa Platforma komputerowa ogólnego przeznaczenia Ograniczenia wydajnościowe Rys Poglądowy diagram struktury programowego Firewalla z zabezpieczonym ( utwardzonym ) systemem operacyjnym (na podstawie [36]). Dla systemów z grupy Linux, często wykorzystywanych do budowy programowych ścian ogniowych, stosowane w praktyce mechanizmy ochrony można podzielić na cztery grupy [77]: ochrona pamięci w jądrze systemu, ochrona pamięci w kompilatorze, nadzór nad dostępem do systemu (kontrola dostępu), inne (stosujące randomizację, szczegółowe ograniczenia dostępu, zapis zdarzeń zachodzących w systemie itp.). Wpisują się one w szersze modele definiujące sposób przydzielania i kontroli uprawnień. W najbardziej powszechnym modelu nieobowiązkowej kontroli DAC (ang. Discretionary Access Control) zarówno użytkownicy, jak i procesy, dysponują możliwością pełnej kontroli nad posiadanymi obiektami (m.in. plikami, katalogami, urządzeniami, itp.) [60, 77]. Takie podejście nie nadaje się do budowy bezpiecznego środowiska dla funkcjonowania krytycznych aplikacji. Stąd też w roku 1985 Departament Obrony Stanów Zjednoczonych opracował standard wprowadzający 26

27 obligatoryjny mechanizm ochrony zwany MAC (ang. Mandatory Access Control) [19]. Model ten można podzielić na składowe polityki obejmujące m.in.: kontrolę dostępu podmiotów (użytkownicy i procesy) do obiektów, autentykację tożsamości a zarazem przywilejów poszczególnych użytkowników oraz metody szyfrowania istotnych danych [60]. W tym przypadku to administrator systemu decyduje o konfiguracji zabezpieczeń i praw dostępów. Użytkownicy nie są w stanie samodzielnie zmienić narzuconej im polityki bez wcześniejszej zgody administratora. Nieustanny rozwój systemów komputerowych oraz wzrost znaczenia informacji przetwarzanej w postaci cyfrowej spowodował konieczność modyfikowania ogólnych założeń modeli DAC i MDAC. W wyniku takich działań powstało szereg dodatkowych rozwinięć koncepcji ochrony systemów operacyjnych, dostosowanych do specyficznych potrzeb aplikacyjno-użytkowych. Do najważniejszych zaliczyć należy modele: wymuszania typów TE (ang. Type Enforcement), kontroli dostępu na podstawie ról RBAC (ang. Role-Based Access Control), wielopoziomowego bezpieczeństwa MLS (ang. Multi-Level Security). Model bezpieczeństwa TE, bazujący na kontroli typów obiektów, minimalizuje uprawnienia aplikacji do zakresu pozwalającego na ich poprawne funkcjonowanie oraz ogranicza potencjalne negatywne skutki nadużycia tychże przywilejów [60]. Stanowi on praktyczną implementację elastycznej architektury Flask [95], w której każdemu procesowi oraz obiektowi przypisany zostaje specjalny zestaw atrybutów bezpieczeństwa (ang. security attributes), określany jako tzw. kontekst bezpieczeństwa [124]. Dzięki temu funkcja kontrolująca uprawnienia, w momencie podejmowania decyzji o zezwoleniu danej operacji, dysponuje zbiorem niezbędnych informacji. Implementacja TE wprowadza pojęcie domeny jako atrybutu opisującego każdy proces oraz pojęcie typu klasyfikującego każdy obiekt. Wszystkie procesy będące w tej samej domenie, jak również wszystkie obiekty o konkretnym typie, podlegają takim samym zasadom bezpieczeństwa. Pojedynczy zestaw atrybutów, opisujący zarówno procesy jak i obiekty, pozwala wykorzystać jedną macierz specyfikującą warunki dostępu oraz wzajemnej interakcji pomiędzy typami i obiektami [124]. Kontrola dostępu na podstawie ról RBAC wykorzystuje do podejmowania decyzji informacje o funkcjach, jakie przydzielono użytkownikowi w danej organizacji. Użytkownik nie może według własnego uznania dokonywać operacji czy też uzyskiwać dostępu do danych innych użytkowników systemu. RBAC jest więc przeciwieństwem modelu DAC. Ze względu na brak wykorzystania wielopoziomowych mechanizmów zabezpieczających nie można go jednak zaliczyć wprost do grupy obligatoryjnych modeli MDAC [27]. Wprowadzenie klasyfikowania użytkowników według ról ułatwia proces zarządzania polityką bezpieczeństwa systemu. Wystarczy bowiem zdefiniować zestaw zasad i uprawnień odzwierciedlających strukturę organizacji, a później przyporządkować użytkowników według właściwej im lokalizacji. W przypadku zmiany stanowiska czy też przynależności działowej pracownikowi przydzielony zostaje nowy zestaw reguł. 27

28 System zabezpieczony zgodnie z wymogami modelu wielopoziomowego bezpieczeństwa MLS, powinien być wyposażony w następujące funkcjonalności [55]: możliwość tworzenia oraz izolowania równoważnych klas zasobów systemowych, przez co wszystkie aktywne elementy danej klasy są dostępne na takich samych zasadach bezpieczeństwa, zdefiniowane zasady interakcji pomiędzy poszczególnymi klasami, mechanizmy gwarantujące wdrożenie polityki MLS, metody kontroli zgodności działania mechanizmów zabezpieczających z obowiązującymi regułami, nadanie czytelnych, łatwo identyfikowalnych etykiet poszczególnym klasom zasobów systemowych. Dzięki takim cechom system MLS pozwala w praktyce precyzyjnie odseparować poszczególne klasy informacji oraz zarządzać użytkownikami o różnych poziomach uprawnień. Hierarchiczna struktura klasyfikująca dane oraz uprawnienia, w połączeniu z mechanizmami weryfikacji użytkowników, uniemożliwia nieautoryzowany dostęp do zasobów systemowych. Klasyczne rozwiązania MLS opierają się na modelu kontroli dostępu Bell-LaPadula [9], w którym użytkownik nie może odczytywać danych z wyższych poziomów uprawnień oraz nie może dokonywać zapisów na poziomach innych od przydzielonego użytkownikowi. Restrykcje takie odnoszą się również do programów uruchamianych przez użytkownika w danym systemie [86]. Zaprezentowanej aktywności w obszarze zwiększania bezpieczeństwa systemów operacyjnych towarzyszy poszukiwanie metod optymalizacji algorytmów klasyfikacji pakietów przetwarzanych przez zapory ogniowe. Pomimo tego, że parametry funkcjonalne poszczególnych rozwiązań są uwarunkowane docelowym obszarem zastosowań, można wyróżnić kilka uniwersalnych wymagań, stawianych wszystkim nowoczesnym algorytmom klasyfikującym. Należą do nich m.in. [26, 33, 34, 62]: duża prędkość wyszukiwania coraz szybsze łącza teleinformatyczne oraz rosnące wymagania co do akceptowalnych poziomów opóźnień przetwarzania danych wymuszają opracowywanie rozwiązań pozwalających na pracę z prędkościami medium komunikacyjnego (ang. wire-speed), minimalizacja ilości zasobów pamięciowych niezbędnych do implementacji algorytmu w zależności od przeznaczenia urządzenia zestaw reguł bezpieczeństwa może zawierać od kilkudziesięciu do kilkuset tysięcy elementów, skalowalność ilości pól wykorzystywanych do weryfikacji danych rozbudowa funkcjonalna systemów bezpieczeństwa wiąże się z koniecznością analizy dodatkowych informacji z nagłówków pakietów. Uniwersalny algorytm klasyfikujący powinien pozwalać na łatwe poszerzenie zakresu sprawdzanych pól, 28

29 elastyczność definiowania opisu reguł oprócz arbitralnego ustalania wartości poszczególnych pól składowych reguły, wymagana jest możliwość wykorzystywania masek, operatorów (mniejszy, większy, etc.) czy też zakresów, szybkość aktualizacji zestawu reguł praktyczna eksploatacja klasyfikatorów wiąże się z koniecznością wdrożenia mechanizmów umożliwiających aktualizację definicji polityki bezpieczeństwa. Szybkość realizacji tego procesu wpływa na efektywność całego urządzenia. Problem klasyfikacji pakietów w ujęciu ogólnym sprowadza się do porównywania określonych pól nagłówków przetwarzanych pakietów z bazą danych klasyfikatora, zawierającą skończoną sekwencję n reguł bezpieczeństwa: R 1, R 2 R n. Poszczególne reguły składają się z k-elementarnych wartości, odpowiadających analizowanym polom nagłówków pakietów. Każde pole może być porównane z k-tym elementem reguły na jeden z trzech sposobów: bezpośrednio, prefiksowo lub poprzez zakres. W przypadku porównywania bezpośredniego pole nagłówka musi jednoznacznie odpowiadać wartości k danej reguły. Sytuacja taka ma miejsce przy specyfikowaniu pojedynczego adresu IP, konkretnego numeru portu lub protokołu sieciowego. Dopasowywanie prefiksowe jest wykorzystywane do opisywania grup adresów tworzących podsieci. Ostatni sposób, polegający na porównywaniu zakresów, służy w praktyce określaniu przedziałów portów protokołów transportowych [6]. Niezależnie od zastosowanej metody weryfikowany pakiet jest zgodny z daną regułą R i jedynie wówczas, jeśli ściśle zdefiniowane pola nagłówka odpowiadają jednocześnie wszystkim k-elementarnym wartościom składowym reguły. Do wyrażenia funkcyjnej złożoności czasowej algorytmów klasyfikujących powszechnie używana jest w literaturze notacja dużego O [3]. W celu zapewnienia jak najlepszej czytelności prezentowanych w dalszej części rozdziału charakterystyk metod weryfikacji pakietów, w tabeli 2.1 przedstawiono listę zmiennych wykorzystywanych w funkcjach opisujących złożoność czasową poszczególnych algorytmów. Tab Opis zmiennych wykorzystywanych w funkcjach złożoności czasowej poszczególnych algorytmów. Zmienna N d W S Opis Liczba reguł Liczba wymiarów (analizowanych pól nagłówków) Długość (bitowa) prefiksu pojedynczego wymiaru Szerokość słowa danych pamięci A, α, l Parametry optymalizacyjne, specyficzne dla danego algorytmu 29

30 Wykorzystywane obecnie algorytmy klasyfikujące można podzielić na cztery główne grupy, wymienione w tabeli 2.2 (na podstawie [33, 50]). W dalszej części rozdziału zostaną omówione pokrótce najważniejsze cechy algorytmów wchodzących w skład pierwszych trzech grup, jako metod klasyfikacji pakietów stosowanych w programowych systemach typu Firewall. Ostatnia kategoria, wymieniona w tabeli 2.2 ze względu na konieczność całościowego przeglądu algorytmów klasyfikujących, stanowi odrębny rozdział, dedykowany sprzętowym rozwiązaniom zabezpieczającym transmisję danych w sieciach teleinformatycznych. Tab Podział algorytmów klasyfikujących (na podstawie [33, 50]). Kategoria Podstawowe struktury danych Geometryczne Przykłady algorytmów Przeszukiwanie liniowe, drzewa hierarchiczne, drzewa przycinane, wektory bitowe GOT, cross-producting, AQT, FIS-tree Heurystyczne RFC, HiCutts, HyperCuts, przestrzeń krotek Sprzętowe TCAM, bitmap intersection Najstarszy i zarazem najprostszy algorytm wyszukiwania liniowego polega na porównywaniu odpowiednich pól nagłówków przetwarzanych pakietów z listą reguł bezpieczeństwa. Analiza taka dokonywana jest sekwencyjnie, począwszy od reguły o najwyższym priorytecie, aż do momentu, w którym dopasowane zostaną wszystkie pola nagłówkowe. Pomimo swej prostoty i stosunkowo niewielkiego zapotrzebowania na zasoby pamięciowe O(N), algorytm przeszukiwania liniowego charakteryzuje się niewielką wydajnością oraz skalowalnością. Czas przeszukiwania listy reguł, wynoszący O(N), rośnie wprost proporcjonalnie do ich liczby [33, 50, 56, 119], co w praktyce dyskwalifikuje możliwość produkcyjnego wykorzystania tego typu rozwiązań w najbardziej wymagających obszarach zastosowań. Z tego względu rozpoczęto intensywne poszukiwania efektywniejszych form klasyfikacji pakietów, zwiększających szybkość dopasowywania pakietów do wzorców oraz zmniejszających zapotrzebowanie na zasoby pamięciowe. Początkowo prace te skoncentrowały się na wykorzystaniu podstawowych struktur danych, jakimi są prefiksowe drzewa wielokierunkowe trie (z ang. retrieval) przechowujące zbiory słów (łańcuchy znaków albo innych obiektów, np. liczb całkowitych) nad pewnym zdefiniowanym alfabetem [3]. W wypadku standardowych binarnych drzew przeszukiwań każdy z węzłów posiada maksymalnie dwa węzły-dzieci. Dodatkowo dla każdego węzła n takiego drzewa wszystkie wartości przechowywane w lewym poddrzewie (drzewie, którego korzeniem jest lewe dziecko korzenia głównego) są mniejsze od wartości v zapisanej w n, zaś wszystkie wartości z prawego poddrzewa są większe od v [24]. Struktury typu trie różnią się od binarnych drzew przeszukiwań sposobem przechowywania 30

31 wyszukiwanych słów są one zapisywane w liściach drzewa trie [8]. Węzły wewnętrzne drzewa zawierają jedynie tablice wskaźników do kolejnych poddrzew trie lub węzłów zewnętrznych [49, 91]. Przeszukiwanie drzewa polega na przemieszczaniu się po jego strukturze zgodnie z kolejno odczytywanymi bitami prefiksu, aż do osiągnięcia liścia zawierającego szukany klucz lub wskaźnika pustego, oznaczającego, że dane słowo w drzewie nie występuje. Cecha taka idealnie wpasowuje się w specyfikę wymagań związanych z klasyfikacją pakietów, gdzie weryfikowane ciągi informacji są zazwyczaj znacznej długości (minimalne dwuwymiarowe słowo wejściowe złożone z pola adresu źródłowego i docelowego IP posiada łączną długość 64 bitów). Najprostsza metoda klasyfikacji z wykorzystaniem struktur trie polega na utworzeniu d-wymiarowego hierarchicznego drzewa prefiksowego [82]. W wypadku, gdy d>1, procedura konstruowania drzewa rozpoczyna się od utworzenia drzewa przeszukiwania F1 złożonego ze zbioru prefiksów pierwszego wymiaru (np. adresu źródłowego IP). Dla każdego prefiksu p w drzewie F1, jednoznacznie zdefiniowanego w zestawie reguł, rekurencyjnie tworzone są drzewa przeszukiwań dla wymiarów d-1. Poszczególne prefiksy stanowią zarazem wskaźniki łączące drzewa kolejnych poziomów hierarchii. Zapotrzebowanie na zasoby pamięciowego algorytmu hierarchicznych drzew trie wynosi O(NdW), zaś maksymalny czas przeszukiwania jest równy O(W d ) [33, 50]. Możliwym jest również dokonywanie przyrostowych aktualizacji hierarchii drzew w czasie O(d 2 W). Główne wady omawianego algorytmu obejmują alokację dużych zasobów pamięciowych (większą niż w przypadku przeszukiwania liniowego) oraz konieczność wstecznych wyszukiwań (ang. backtracking search) w celu odnalezienia właściwej ścieżki do odpowiedniego prefiksu. Eliminacja wyszukiwań wstecznych możliwa jest dzięki modyfikacji struktury danych drzewa trie poprzez replikację odpowiednich reguł. Tak powstała nowa wersja drzewa, określana w literaturze jako Cecilia [98, 121] bądź set-pruning trie [33], redukuje czas weryfikacji dla najgorszego przypadku do wartości O(dW) kosztem zwiększenia zapotrzebowania na pamięć do poziomu O(N d dw). Złożoność czasowa aktualizacji, wynosząca O(N d ), ogranicza obszar wykorzystania algorytmu do relatywnie małych i statycznych klasyfikatorów. Alternatywną metodę wykorzystania struktur trie zaproponowano w algorytmie BVL (ang. Bit Vector Linear serach) [6]. Poszczególnym węzłom drzewa trie przyporządkowane są N-bitowe wektory sygnalizujące reguły odpowiadające danemu węzłowi. Dla każdego z wymiarów tworzone jest odrębne drzewo trie o takiej konstrukcji. Wyznaczenie zbioru reguł zgodnych z weryfikowanym słowem sprowadza się do określenia N-bitowych punktów przecięć pomiędzy d wektorami, stąd najmniej korzystny czas wyszukiwania wynosi przy wykorzystaniu pamięci równym [50]. Obserwacje praktyczne pozwoliły stwierdzić, że przetwarzane pakiety pasują równocześnie jedynie do niewielkiej liczby reguł, nawet w przypadku polityk bezpieczeństwa złożonych z około 1700 wpisów [6]. Definiowanie N-bitowych wektorów, dla każdego z wymiarów, prowadzi w tej sytuacji do zbędnego zwiększania złożoności obliczeniowej. Zaproponowana przez Baboescu et al. [6] zmodyfikowana wersja algorytmu ABV (ang. Aggregated Bit Vector), poprzez wykorzystanie 31

32 zagregowanego wektora bitowego o długości A, redukuje koszt operacji wstępnego przetwarzania bazy reguł do wartości O(N 2 d), zwiększając przy tym zapotrzebowanie na zasoby pamięciowe o dodatkowe bitów (w stosunku do klasycznego algorytmu BVL) [50]. Kolejnym algorytmem bazującym na strukturach typu trie jest siatka drzew GOT (ang. Grid- Of-Tries) [98]. Ze względu na swą specyfikę GOT jest przyporządkowywany w dostępnej literaturze do różnych grup funkcjonalnych: A. Kolehmainen zakwalifikowuje GOT do kategorii klasycznych metod weryfikacji pakietów [50], zaś P. Gupta do grupy algorytmów geometrycznych [33]. Siatka drzew tries została opracowana przez V. Srinivasana et al. [98] głównie z przeznaczeniem dla klasyfikacji dwuwymiarowej, obejmującej adresy źródłowe i docelowe protokołu IP. Algorytm GOT charakteryzuje się zapotrzebowaniem na zasoby pamięciowe rzędu O(NdW), osiągniętym poprzez umieszczanie reguł (kluczy) tylko w pojedynczych węzłach drzewa. Dodatkowo stosowane jest wstępne przetwarzanie bazy reguł w celu określenia pozycji wskaźników łączących drzewa poszczególnych wymiarów. Dzięki temu możliwe są bezpośrednie skoki pomiędzy poddrzewami prefiksów danego wymiaru bez konieczności wstecznego wyszukiwania, co zmniejsza czas klasyfikacji do wartości O(W d-1 ). Negatywną konsekwencją zastosowania takiej metody definiowania wskaźników jest utrudnienie procesu przyrostowych aktualizacji twórcy algorytmu sugerują przebudowywanie całej struktury drzewa. Proces taki posiada złożoność czasową równą O(NW) [33]. Praktyczne potrzeby weryfikacji wielu pól z możliwością definiowania reguł zawierających przedziały wyszukiwanych wartości doprowadziły do opracowania algorytmu cross-producting [98]. Pierwszy etap przetwarzania danych w tej metodzie polega na wydzieleniu z bazy reguł kolumn zawierających wszystkie różne zakresy prefiksów dla każdego z wymiarów d. Na podstawie tych informacji konstruowana jest tabela C T (ang. cross-product table) złożona ze zidentyfikowanych zakresów wraz z odpowiadającymi im numerami reguł, przechowywanych w postaci krotek, gdzie i oznacza kolejne zakresy dla wymiaru d (np. [, ], [, ].) [50]. Ponieważ dla N prefiksów istnieje najwyżej 2N-2 zakresów, maksymalny rozmiar tablicy C T, a zarazem zapotrzebowanie na zasoby pamięciowe algorytmu cross-producting, osiąga wartość O(N d ). Z tego względu nadaje się on jedynie dla bardzo małych klasyfikatorów [33]. Czas wyszukiwania wynosi w tym przypadku O(dW). Odmienną koncepcję dwuwymiarowego systemu klasyfikacji pakietów (ang. 2-dimensional classification scheme) zaproponował T. Lakshman et al. [52]. Algorytm ten nakłada restrykcje odnośnie specyfiki poszczególnych wymiarów: pierwszy wymiar F 1 jest ograniczony jedynie do formy prefiksowej, drugi zaś F 2 pozwala na definiowanie dowolnych przedziałów. Dzięki takim założeniom początkowym możliwe jest wykorzystanie drzewa trie jako struktury przechowującej prefiksy F 1. Węzłom zewnętrznym drzewa F 1 przyporządkowane zostają niezachodzące na siebie przedziały cząstkowe wymiaru F 2, reprezentujące poszczególne reguły, zgodne z prefiksem wymiaru F 1. Jako struktury danych przeznaczone do identyfikacji zakresów wykorzystywane są zwykle binarne drzewa wyszukiwań. Ponieważ każda z reguł zapisywana jest tylko raz w drzewie wyszukiwania, 32

33 zapotrzebowanie algorytmu na zasoby pamięciowe wynosi O(NW). Czas weryfikacji danych dla najbardziej niekorzystnego przypadku wynosi O(WlogN) [33]. Do grupy metod geometrycznych, dedykowanych klasyfikacji dwuwymiarowej, należy także algorytm AQT (ang. Area-based Quad Tree) [12]. Buddhikot et al. [24, 28] stosują dekompozycję każdego z wymiarów do drzewa ćwiartek (ang. quad tree), składającego się z czterech węzłów (tzw. kwadrantów) odpowiadających prefiksom 00, 01, 10 oraz 11. Proces dekompozycji realizowany jest rekurencyjnie aż do momentu, kiedy w każdym z kwadrantów drzewa ćwiartek pozostaje najwyżej jedna pasująca reguła. Dana reguła przecina kwadrant, jeżeli całościowo obejmuje przynajmniej jeden z jego wymiarów [33]. Algorytm AQT charakteryzuje się następującymi parametrami: zapotrzebowanie pamięciowe O(NW), złożoność operacji wyszukiwania O(αW), czas aktualizacji, gdzie α oznacza parametr optymalizacyjny, definiujący liczbę podziałów [50]. Ostatnim z omawianych w grupie metod geometrycznych jest algorytm FIS-tree (ang. Fat Inverted Segment tree), zaproponowany przez A. Feldmana et al. [26], wykorzystujący zmodyfikowaną wersję drzewa odcinków (ang. segment tree). Struktura taka jest zrównoważonym drzewem binarnym, w którym każdy z liści odpowiada przedziałom elementarnym, wyznaczonym przez uporządkowane końce poszczególnych przedziałów. Węzły wewnętrzne drzewa odcinków odpowiadają z kolei przedziałom, które są sumą odpowiednich przedziałów elementarnych poddrzewa zakorzenionego w danym węźle [18]. Algorytm FIS-tree wprowadza dwie istotne zmiany: po pierwsze kompresuje strukturę drzewa odcinków, redukując jego głębokość kosztem zwiększenia liczby wymiarów l, po drugie nie wykorzystuje wskaźników powrotnych od węzłów-dzieci do węzła-rodzica [33]. Dzięki takim zmianom uzyskano złożoność czasową wyszukiwania na poziomie O((l+1)W) oraz zapotrzebowanie na pamięć rzędu O(l N 1+1/l ) [50]. Zarówno w przypadku zaprezentowanych podstawowych metod wyszukiwania, jak i algorytmów geometrycznych, optymalizacja jednego z istotnych parametrów oceny jakościowej (czasu wyszukiwania bądź zapotrzebowania na pamięć) odbywa się często kosztem degradacji drugiego parametru. Spostrzeżenie to stało się przyczyną poszukiwań nowych sposobów klasyfikacji wielowymiarowej, opartych o heurystyki, uwzględniające specyfikę rzeczywistych baz reguł bezpieczeństwa, posiadających niejednokrotnie bardzo rozbudowaną strukturę z nadmiarowymi lub wykluczającymi się wpisami. Redukcja zbędnych informacji poprzez wstępne przetwarzanie bazy reguł jest podstawą działania algorytmu heurystycznego RFC (ang. Recursive Flow Classification) [34]. W pierwszym etapie weryfikacji, dane z nagłówków pakietów dzielone są na wiele mniejszych części, pozwalając na równoległe przeszukiwanie szeregu bloków pamięci, w których zapisano przetworzoną bazę reguł. Odczytane wartości tworzą indeksy dla kolejnej fazy wyszukiwania, przy czym łączny rozmiar bitowy wyniku operacji wyszukiwania jest mniejszy od długości wektora danych wejściowych. Proces jest powtarzany rekurencyjnie aż do momentu, w którym pozostaje tylko jeden indeks, kodujący informację o typie analizowanego pakietu (tzw. 33

34 classid). Efektywność czasowa weryfikacji dla algorytmu RFC wynosi O(d), zaś zapotrzebowanie pamięciowe O(N d ) [50]. Twórcy algorytmu RFC opracowali również alternatywną metodę heurystycznej weryfikacji pakietów, określaną jako HiCuts (ang. Hierarchical Intelligent Cuttings). W procesie wstępnego przetwarzania tabeli definicji reguł bezpieczeństwa zbudowana zostaje struktura drzewa decyzyjnego, w którego liściach przechowywane są niewielkie liczby reguł, przeszukiwane sekwencyjnie w procesie klasyfikacji [35, 119]. Korzeń drzewa reprezentuje pełną d-wymiarową przestrzeń wyszukiwania. W wyniku jej partycjonowania wzdłuż jednego z wymiarów, węzłom-dzieciom przypisane zostają mniejsze podprzestrzenie. Proces ten realizowany jest rekurencyjnie do momentu, kiedy w każdej z podprzestrzeni znajdzie się nie więcej niż B reguł, gdzie B oznacza zmienną optymalizacyjną algorytmu [33]. Koszt czasowy operacji wyszukiwania jest równy O(d) przy zapotrzebowaniu na zasoby pamięciowe wynoszącym O(N d ) [50]. Zmodyfikowana wersja algorytmu, określana jako HyperCuts [92], pozwala na partycjonowanie wzdłuż wielu wymiarów równocześnie. Dzięki temu, w stosunku do oryginalnej metody HiCuts, uzyskano redukcję zużycia zasobów pamięciowych od 2 do 10 razy oraz skrócenie czasu wyszukiwania do 5 razy [92]. Grupę metod heurystycznych zamyka algorytm przeszukiwania przestrzeni krotek (ang. Tuple Space Search) [99]. Poszczególnym regułom bezpieczeństwa przyporządkowywane zostają d-krotki, w których każdy i-ty element odpowiada długości prefiksu i-tego wymiaru. Powstała w ten sposób przestrzeń krotek odzwierciedla strukturę bazy reguł, pogrupowanej ze względu na długość prefiksów wymiarów składowych. Zbiór reguł o takim samym, stałym rozmiarze, identyfikowany daną krotką, jest przechowywany w tabeli funkcji skrótów [33]. W najgorszym przypadku każda reguła posiada odrębną funkcję skrótu, stąd zapotrzebowanie algorytmu na zasoby pamięciowe oraz efektywność czasowa operacji wyszukiwania wynoszą O(N). Algorytm umożliwia szybką aktualizację przyrostową w czasie O(1) [50] Firewalle sprzętowe Pojęcie sprzętowy Firewall w idealnym przypadku oznacza system realizujący funkcje zabezpieczania transmisji danych w sieciach teleinformatycznych przy wykorzystaniu wyłącznie dedykowanych układów elektronicznych, z pominięciem jakiegokolwiek kodu programu wykonywanego przez mikroprocesor. W praktyce wielu producentów posługuje się jednak tym terminem w odniesieniu do oferowanych produktów, będących tak naprawdę klasycznymi rozwiązaniami programowymi, uzupełnionymi jedynie o pewne funkcje wspomagające implementowane w sprzęcie. Przeważnie do takich celów używane są układy ASIC, obsługujące procesy szyfrowania i deszyfrowania pakietów w wirtualnych sieciach prywatnych VPN (ang. Virtual Private Network) bądź akcelerujące proces wyszukiwania ciągów w urządzeniach IDS/IPS oraz modułach antywirusowych [29, 36]. Nie sposób jest jednoznacznie stwierdzić, jak w rzeczywistości realizowana jest taka funkcjonalność, ponieważ producenci nie udostępniają szczegółowych 34

35 dokumentacji technicznych oferowanych urządzeń, zasłaniając się tajemnicą technologiczną i ochroną przed konkurencją. Użytkownikom pozostaje jedynie weryfikacja ogólnych parametrów technicznych w toku produkcyjnej eksploatacji. W niektórych przypadkach minimalizacja kosztów produkcji, w połączeniu z istniejącym zapotrzebowaniem w poszczególnych sektorach rynku, prowadzi do wycofywania się z wytwarzania zaawansowanych, a przez to drogich i adresowanych do wąskiego grona odbiorców, urządzeń. Przykładem opisanego zjawiska jest kampania marketingowa firmy Check Point Software Technologies Ltd. dyskredytująca korzyści płynące z zastosowania rozwiązań sprzętowych na rzecz nowych, wydajnych procesorów wielordzeniowych [14]. Pomimo tak silnego wpływu strategii biznesowych na kierunki rozwoju technologicznego wiele ośrodków badawczych prowadzi niezależne prace nad optymalizacją sprzętowych metod klasyfikacji pakietów. Historycznie początki aktywności badawczej w tym obszarze stymulowane były koniecznością przetwarzania coraz większych tabel trasowania pakietów w routerach brzegowych rozległych sieci WAN (ang. Wide Area Network). Stąd też wynika wczesna dominacja metod dwuwymiarowych w grupie algorytmów sprzętowej klasyfikacji danych (pierwotnie routery wykorzystywały do trasowania pakietów jedynie informacje o adresie źródłowym i docelowym protokołu IP). Pierwszy i zarazem najbardziej popularny sposób sprzętowej klasyfikacji pakietów opiera się na wykorzystaniu trójwartościowej pamięci TCAM (ang. Ternary Content Addressable Memory). Jest to zmodyfikowana wersja pamięci adresowanej zawartością (ang. Content Addressable Memory), umożliwiająca przechowywanie również wartości nieistotnych (ang. don t care). TCAM zapisuje pary wyszukiwanych ciągów skojarzonych z dedykowanymi im maskami. Dzięki temu idealnie wpasowuje się w prefiksowy schemat adresacji, obowiązujący w sieciach Ethernet. Przykładowo: zakres podsieci *, gdzie * oznacza pozycję nieistotną, będzie zapisany w pamięci TCAM jako wartość z maską Co najważniejsze, efektywność czasowa procesu wyszukiwania jest niezależna od liczby zapisanych wierszy i wynosi O(1), zatem już po jednym cyklu zegarowym pamięć zwraca wynik kwerendy [119, 139]. W zależności od potrzeb implementacyjnych może być on dostępny w postaci binarnej niekodowanej, w której każdemu wierszowi pamięci odpowiada dedykowana linia sygnałowa potwierdzająca trafienie albo w formie kodowanej, znacznie redukującej szerokość magistrali wyjściowej. Pomimo swych niewątpliwych zalet, praktyczne wykorzystanie pamięci TCAM w nowych obszarach zastosowań ogranicza kilka istotnych wad tej technologii [119, 137]: wysoki koszt produkcji, stosunkowo niska pojemność, niedostosowanie do przechowywania reguł zawierających przedziały wartości, duże zapotrzebowanie na energię, ograniczona skalowalność. Koszt pojedynczego bitu przechowywanego w pamięci TCAM może być nawet do 30 razy większy niż w przypadku pamięci DDR SRAM [119], co wynika z faktu, że komórka elementarna 35

36 TCAM wymaga użycia od 10 do 12 tranzystorów, podczas gdy konwencjonalne pamięci SRAM potrzebują do tego celu jedynie od 4 do 6 tranzystorów [5]. Stale rosnąca liczba urządzeń wyposażonych w tego typu pamięć pozwala przypuszczać, że jej cena będzie sukcesywnie maleć, choć prawdopodobnie nigdy nie osiągnie poziomu powszechnych rozwiązań SRAM. Jednak to nie kwestia ekonomiczna jest największym ograniczeniem pamięci TCAM główny problem wiąże się z brakiem bezpośredniej możliwości zapisywania reguł zawierających dowolne zakresy, szczególnie w odniesieniu do numerów portów [11]. Każdy zakres musi być najpierw poddany dekompozycji do postaci niezależnych prefiksów. W najgorszym przypadku dla W-bitowego numeru portu może istnieć (2W-2) d prefiksów, stąd definicja pojedynczej reguły składającej się z dwóch 16-bitowych portów będzie wymagała aż 900 wpisów do pamięci [33, 119]. Fakt ten wpływa także niekorzystnie na efektywnie dostępną pojemność TCAM, szczególnie w połączeniu z dużymi rozmiarami komórek, wynikającymi z konieczności zastosowania dodatkowych tranzystorów przechowujących informacje o wartościach *. Jednotaktowy czas wyszukiwania informacji w TCAM uzyskiwany jest dzięki zrównolegleniu architektury wewnętrznej pamięci. Każda komórka sygnalizuje specjalnym blokom logicznym, czy sygnał wejściowy jest zgodny z zapisaną w niej regułą. Duża liczba równocześnie aktywnych elementów powoduje jednak znaczne zużycie energii. Dostępne obecnie układy TCAM charakteryzują się poborem mocy rzędu 12-15W [64, 137, 138]. W przeliczeniu na pojedynczy bit jest to wartość 150 razy większa niż w wypadku klasycznych pamięci SRAM [119]. Atrakcyjność pamięci TCAM motywuje wiele zespołów naukowych na całym świecie do prowadzenia badań nad możliwymi sposobami redukcji zapotrzebowania energetycznego, jak również optymalnego implementowania obsługi wyszukiwania zakresów. Spitznagel et al. [97] proponują rozwiązanie E-TCAM (ang. Extended TCAM), modyfikujące konstrukcję elementarnych komórek pamięci, w sposób pozwalający na bezpośrednie wyszukiwanie zakresów na poziomie układu scalonego. Dodatkowa funkcjonalność zwiększa liczbę elementów wchodzących w skład pojedynczego wiersza pamięci o kolejne 32W tranzystorów. Pomimo tego E-TCAM ogranicza o ponad 90% pobór mocy układu poprzez redukcję ilości obszarów aktywowanych w trakcie trwania procesu wyszukiwania [11, 119]. Stało się to możliwe dzięki uzupełnieniu koncepcji partycjonowanej pamięci CoolCAM [138] dodatkowym blokiem indeksów, z którym skojarzone są segmenty przechowujące informacje. Na podstawie danych odczytanych z bloku indeksów realizowane jest równoległe wyszukiwanie w niewielkiej, ściśle określonej grupie bloków pamięciowych. Optymalizacja sprzętowej architektury TCAM jest zadaniem czasochłonnym i niezwykle kosztownym. Z tego powodu bardzo dynamicznie rozwija się alternatywny kierunek badań, koncentrujący się na opracowaniu efektywnych algorytmów kodowania zakresów. W nurcie tym możemy wyróżnić metody zależne od kontekstu bazy danych reguł bądź od niego niezależne, określane jako DIRE (ang. Database Independent Range Encoding) [11, 53]. Gupta oraz McKeown [34] przeanalizowali 793 rzeczywiste systemy klasyfikacji pakietów funkcjonujące u 101 różnych 36

37 dostawców usług internetowych ISP (ang. Internet Service Provider). W sumie zawierały ponad 41 tysięcy reguł, co pozwoliło na wyciągnięcie kilku istotnych wniosków dotyczących charakterystyk polityk bezpieczeństwa. Do najważniejszych wniosków należą [34]: średnia liczba reguł w badanych systemach wynosiła około 50 (jedynie 0,7% wszystkich klasyfikatorów posiadała bazy zawierające więcej niż 1000 wpisów), protokoły warstwy transportowej były ograniczone zwykle do niewielkiego zbioru konkretnych elementów, np.: TCP, UDP (ang. User Datagram Protocol), ICMP (ang. Internet Control Message Protocol), itp., tylko 10,2% klasyfikatorów wykorzystywało zakresy w definicji reguł dla warstwy transportowej, w tym 9% przypadków był to przedział od portu 1023 do 65535, wiele reguł w tych samych klasyfikatorach wykorzystywało jednakowe definicje poszczególnych pól, 8% reguł było nadmiarowych. Z kolei K. Lakshminarayanan et al. [53] wykazał, że w bazach danych list kontroli dostępu ACL, pochodzących z 2004 roku, na łączną liczbę około 215 tysięcy reguł, 25% procent wykorzystywało zakres w opisie jednego pola, zaś tylko 1,5% w dwóch polach. Dla pierwszego pola wyróżniono 270 unikalnych przedziałów, a dla drugiego jedynie 37. Na podstawie powyższych obserwacji H. Liu opracował metodę efektywnego mapowania przedziałów w pamięci TCAM [58]. Wykorzystuje ona translację klucza wyszukującego do wektora o zredukowanej długości, w którym każdy z bitów składowych v i przyjmuje wysoką wartość logiczną jedynie wówczas, kiedy klucz zawiera się w przedziale R i. Translacja taka może być realizowana w oparciu o bezpośrednie adresowanie pamięci konwencjonalnej (pojedyncze pole, zawierające 16-bitowy zakres, wymaga zarezerwowania około 64 tysięcy wpisów) [58]. Wektor wynikowy zapisywany jest do pamięci TCAM, zwracającej ostatecznie informację o regułach odpowiadających wyszukiwanemu kluczowi. Odmienny wariant hierarchicznej minimalizacji liczby przedziałów proponuje J. Lunteren et al. [62]. Schemat równoległej klasyfikacji pakietów P 2 C (ang. Parallel Packet Classification) pozwala na jednoczesne, niezależne wyszukiwanie informacji w wielu polach, ograniczając znacznie zapotrzebowanie na zasoby pamięciowe. Algorytm P 2 C występuje w trzech odmianach (stylach): wariant I charakteryzuje się najlepszym czasem aktualizacji, natomiast warianty II i III najmniejszymi rozmiarami wektorów pośrednich kodujących zakresy. Styl kodowania może być jednolity dla całej bazy, jak również wybierany indywidualnie dla poszczególnych reguł. Wektor kodujący wyszukiwany klucz jest przechowywany w pamięci TCAM, przy czym dla stylów I i II każda reguła alokuje dokładnie jedną pozycję w pamięci, natomiast styl III może wymagać większej ilości wpisów [62]. Zarówno algorytm P 2 C, jak i metoda H. Liu, wymagają użycia dedykowanych rozwiązań sprzętowych do wstępnego przetwarzania baz reguł, bądź dodatkowych zasobów pamięciowych przechowujących tablice kodujące zakresy, co znacznie ogranicza skalowalność tego typu rozwiązań [11]. 37

38 Próbę usunięcia głównych wad algorytmów hierarchicznych podejmują metody z grupy DIRE, w których sposób kodowania przedziałów nie jest powiązany z ich rozkładem w bazie danych reguł bezpieczeństwa. Lakshminarayanan et al. [53] opracowali algorytm DIRPE (ang. Database Independent Range PreEncoding), bazując na dwóch podstawowych zasadach: każdy przedział jest reprezentowany jako zbiór arbitralnych elementów trójwartościowych a nie prefiksów, dodatkowe, wolne bity pamięci TCAM są używane do kodowania ciągów trójwartościowych. Dzięki temu, w porównaniu do standardowej reprezentacji prefiksowej, udało się znacznie zredukować liczbę wpisów identyfikujących poszczególne przedziały, kosztem zwiększenia długości poszczególnych słów. Jednak efektywność DIRPE spada w miarę zmniejszania liczby nadmiarowych bitów dostępnych w pamięci TCAM. Alternatywną koncepcją algorytmu niezależnego od kontekstu bazy jest SRGE (ang. Short Range Gray Encoding) [11], którym reprezentację krótkich zakresów zrealizowano w oparciu o binarny refleksyjny kod Graya BRGC (ang. Binary-Reflected Gray Code). Granice poszczególnych przedziałów zostają zamienione z postaci binarnej na odpowiadające im kody Graya. Następnie dla każdego początku i końca danego zakresu obliczany jest najniższy wspólny przodek LCA (ang. Lowest Common Ancestor), czyli przodek najbardziej oddalony od korzenia drzewa. Stanowi on punkt podziału pierwotnego zakresu na dwie mniejsze części. Dla lewego poddrzewa generowane prefiksy pokrywają wszystkie wartości w nim zawarte. Dzięki własnościom kodu BRGC możliwa jest minimalizacja zbioru prefiksów poprzez zastąpienie wpisem nieistotnym * wszystkich pozycji odpowiadających krawędziom podziału LCA. Ciągi trójwartościowe wygenerowane przez algorytm SRGE mogą jednak w pewnych wypadkach zachodzić na siebie, powodując nieefektywne wykorzystanie zasobów pamięci TCAM. Z tego względu A. Bremler-Barr et al. [11] opracowali zmodyfikowaną wersję hybrydowego algorytmu H-SRGE (ang. Hybrid-SRGE), w którym do każdego przedziału kodowanego metodą SRGE, alokującego największą pojemność TCAM, przyporządkowywany zostaje jeden dodatkowy bit identyfikujący. Wstępny etap przetwarzania, zależny od kontekstu bazy danych reguł bezpieczeństwa, polega na utworzeniu hierarchicznej listy przedziałów nadmiarowych posegregowanej według częstości występowania. Dzięki takiemu podejściu współczynnik rozwinięcia liczby zakresów hybrydowego algorytmu H-SRGE dla referencyjnej bazy reguł wyniósł 1,03. Dla porównania algorytm DIRPE osiągnął wynik 1,12 przy większej o 40% liczbie wymaganych bitów dodatkowych, dostępnych w pamięci TCAM [11]. Lakshman i Stiliadis [52] zaproponowali algorytm Bitmap-intersection, wykorzystujący do procesu klasyfikacji pakietów standardowe pamięci SRAM. W metodzie tej zestaw reguł odpowiadający analizowanemu pakietowi stanowi część wspólną d-podzbiorów trafionych reguł, określanych dla każdego z wymiarów indywidualnie. Obliczanie części wspólnych zbiorów jest realizowane metodami sprzętowymi. W tym celu jednowymiarowe wynikowe zbiory są kodowane do 38

39 postaci N-bitowego wektora (bitmapy), w którym wysoki stan logiczny na danej pozycji odpowiada trafieniu w odpowiednią regułę. Iloczyn logiczny poszczególnych wektorów zwraca ostatecznie rezultat klasyfikacji. Ponieważ każda z map bitowych jest długości N oraz istnieje O(N) przedziałów w każdym z d wymiarów, zapotrzebowanie na zasoby pamięciowe algorytmu wynosi O(dN 2 ). Złożoność czasowa operacji wyszukiwania uzależniona jest od szerokości słowa pamięci i wynosi [33]. Tab Porównanie złożoności obliczeniowej oraz zapotrzebowania na zasoby pamięciowe Algorytm algorytmów klasyfikujących (na podstawie [33, 50]). Złożoność obliczeniowa dla najgorszego przypadku Alokowane zasoby pamięciowe dla najgorszego przypadku Wyszukiwanie liniowe O(N) O(N) Przestrzeń krotek O(N) O(N) Hierarchiczne drzewa trie O(W d ) O(NdW) GOT O(W d-1 ) O(NdW) Cecilia (Set-pruning tries) O(dW) O(N d dw) Cross-producing O(dW) O(N d ) BVL Klasyfikacja 2D O(W log N) O(NW) AQT O(αW) O(NW) FIS-tree O((l+ 1)W) O(l N 1+1/l ) RFC O(d) O(N d ) HiCuts O(d) O(N d ) Bitmap-intersection O(dN 2 ) Ternary CAM O(1) O(N) Zbiorcze zestawienie parametrów czasowo-pamięciowych omawianych algorytmów przedstawiono w tabeli 2.3. Część z przedstawionych algorytmów można bezpośrednio implementować w układach programowalnych FPGA (np. P 2 C [62] bądź Bitmap-intersection [52]), przy czym w grupie tej dominują metody oparte o dekompozycję oraz drzewa decyzyjne [44]. W niektórych przypadkach pierwotne algorytmy zostały wzbogacane o pewne funkcjonalności, polepszające własności klasyfikatorów. Takie podejście zastosował Song oraz Lockwood [93] w rozwiązaniu BV-TCAM, łączącym metodę równoległych wektorów bitowych BV (ang. Bit Vector) z pamięcią TCAM. Dzięki temu możliwym stało się sygnalizowanie wielu równoczesnych trafień. 39

40 Praktyczna implementacja algorytmu BV-TCAM w układzie FPGA Xilinx XCV2000E dla 222 reguł alokowała około 10% dostępnych zasobów sprzętowych oraz 20% pamięci BlockRAM [93]. Taylor i Turner [118] przedstawili algorytm DCFL (ang. Distributed Crossproducting Field Labels) redukujący wykładniczą złożoność czasową, jak również zapotrzebowanie pamięciowe występujące w oryginalnych metodach Cross-producing i RFC. Algorytm ten, bardzo podobny do równoległej klasyfikacji pakietów P 2 C, należy do grupy metod bazujących na niezależnym przeszukiwaniu poszczególnych pól, połączonym z kodowaniem i agregacją pośrednich wyników kwerend. DCFL składa się z trzech głównych elementów: zestawu równoległych bloków wyszukujących, sieci agregującej oraz dekodera priorytetu reguł. Poszczególne bloki wyszukujące stosują odmienne metody analizy, dostosowane do konkretnych typów pól nagłówków. I tak do weryfikacji adresów źródłowych i docelowych wykorzystano zmodyfikowaną wersję kompresowanych wielobitowych drzew typy trie (w algorytmie DCFL określanych jako Tree Bitmap). Każde wyszukiwanie dla takiej struktury danych wiąże się z koniecznością 6 odwołań do pamięci, zaś pojedynczy prefiks alokuje średnio 6 bajtów [118]. W przypadku portów sieciowych autorzy algorytmu przeprowadzili początkowo szereg analiz rzeczywistych systemów klasyfikatorów, na podstawie których zdecydowali się na wyodrębnienie pięciu typów zakresów: WC - dowolne, HI - porty wysokie od 1024 do 65535, LO - porty niskie od 0 do 1023, AR - zakresy arbitralne, EM - pojedyncze porty. Dla pierwszych trzech typów (WC, HI i LO) układy wyszukujące zawierają jedynie flagi informujące o istnieniu filtrów, mieszczących się w tych zakresach portów oraz rejestry etykiet przedziałów, uzupełnione logiką wykrywającą, czy analizowane pole jest większe od wartości 1023 czy też nie. Pojedynczym portom EM dedykowano tablice funkcji skrótów, zaś do przeszukiwania zakresów arbitralnych AR wykorzystano algorytm FIS-tree. Sieci agregujące wyniki pośrednie uzyskiwane z opisanych bloków wyszukujących zbudowane zostały w oparciu o filtry Blooma, dzięki czemu, zdaniem twórców DCFL, jest on w stanie osiągnąć wydajność klasyfikacji na poziomie 100 Mpps (ang. Mega packets per second) [118]. Jednak takie podejście nie jest całkowicie optymalne przy implementacji w układach FPGA, głównie ze względu na opóźnienia wnoszone przez długie ścieżki logiczne [44]. Dyskusyjną kwestią pozostaje również efektywność zastosowanej metody wyszukiwania zakresu portów, bazującej na statystycznych własnościach niewielkiej grupy produkcyjnych klasyfikatorów. Wielopoziomowe filtry Blooma zostały także wykorzystane w algorytmie B2PC (ang. Bloom Based Packet Classification), opracowanym przez I. Papaefstathiou et al. [75] oraz jego sprzętowej odmianie 2sBFCE (ang. Dual Stage Bloom Filter Classification Engine), zrealizowanej przez A. Nikitakis a et al. [71]. Obydwie wersje algorytmów posługują się generalnymi charakterystykami 40

41 baz danych reguł bezpieczeństwa, dostępnymi w publikacji P. Gupta et al. [33]. Dzięki dekompozycji wielowymiarowych danych wejściowych poszczególne pola nagłówków są przetwarzane równolegle w niezależnych blokach klasyfikujących, bazujących na filtrach Blooma. Wynikiem pierwszej fazy weryfikacji jest 120-bitowy wektor, generowany przez blok permutacji, który trafia w kolejnym etapie do drugiego filtru Blooma, indeksującego tablice identyfikatorów trafionych reguł. Algorytm 2sBFCE pozwala na zapisanie bazy złożonej z 4 tysięcy definicji przy wykorzystaniu 178 kb pamięci SRAM. Złożoność czasowa operacji wyszukiwania wynosi 26 taktów zegara systemowego, stąd maksymalna przepustowość algorytmu osiąga wartość 5,86 Mpps [71]. Warto w tym miejscu zauważyć, że wszystkie omawiane metody wykorzystujące filtry Blooma, mogą w niektórych przypadkach zwracać niepoprawne wyniki klasyfikacji, tzw. false positive. Dyskwalifikuje to możliwość ich praktycznego zastosowania w obszarach wymagających zapewnienia całkowitej wiarygodności i autentyczności przesyłanych danych. Odrębna grupa rozwijanych obecnie sprzętowych algorytmów klasyfikujących wykorzystuje struktury drzew decyzyjnych. Są to drzewa binarne, których łukom przyporządkowano etykiety T (tak) lub N (nie). Wewnętrzne węzły drzewa zawierają warunki bądź zapytania związane z etykietami łuków, natomiast liście reprezentują wszystkie możliwe uporządkowania sortowanej tablicy [24]. Lou et al. [63] zaproponowali metodę jawnego wyszukiwania zakresów ERS (ang. Explicite Range Serach), bazującą na wyżej wymienionych strukturach danych, redukującą w znaczny sposób (w porównaniu do standardowego algorytmu HiCuts) rozmiar drzewa przeszukiwań. Dla najgorszego przypadku w każdym liściu drzewa HiCuts znajdują się maksymalnie 4 reguły. Ostatecznie są one przeszukiwane liniowo w celu odnalezienia właściwej, odpowiadającej analizowanemu pakietowi. Algorytm ERS zmniejsza liczbę reguł w obszarach przeszukiwań liniowych do maksymalnie 3, kosztem zwiększonego zapotrzebowania na zasoby pamięciowe. Ze względu na zmienną liczbę odwołań do pamięci, niezbędnych do ustalenia ścieżki przeszukiwania drzewa dla każdego z jego węzłów wewnętrznych, algorytm ERS, zdaniem W. Jianga et al. [44], nie pozwala na zastosowanie potokowego przetwarzania danych. Co więcej, nie przeprowadzono praktycznej implementacji algorytmu w układach FPGA, więc nie ma możliwości oceny jego rzeczywistej wydajności i efektywności wykorzystania zasobów sprzętowych. Próbę optymalizacji algorytmów HiCuts oraz HyperCuts podjął również Kennedy et al. [46, 47]. W celu lepszego dopasowania do specyfiki układów FPGA, a zarazem ograniczenia mocy pobieranej przez klasyfikator, w opracowanej modyfikacji Kennedy zrezygnował z implementacji dwóch elementów zawartych w pierwotnych wersjach algorytmów: zagęszczania regionów oraz przesuwania w górę podzbiorów wspólnych reguł. Pierwszy z nich, redukujący do niezbędnego minimum obszary skojarzone z poszczególnymi węzłami drzewa decyzyjnego, a dla realizacji sprzętowej wymagałby wykorzystania bardzo dużej ilości zasobów logiki reprogramowalnej, głównie ze względu na konieczność dokonywania operacji dzielenia zmiennoprzecinkowego. Przesuwanie do wyższych węzłów podzbiorów wspólnych reguł wiąże się z kolei z koniecznością przeszukiwania 41

42 węzłów pośrednich w trakcie przemieszczania się w strukturze drzewa, co wpłynęłoby negatywnie na wydajność sprzętowego akceleratora [46]. Praktyczna implementacja klasyfikatora w układzie Xilinx Virtex5SX95T alokowała 22% dostępnych bloków slice oraz 54% pojemności pamięci BlockRAM. Przy maksymalnej częstotliwość zegara wynoszącej 77 MHz klasyfikator pozwalał na przetwarzanie danych z wydajnością 77 Mpps (dla bazy złożonej z 60 reguł). Przy zwiększeniu liczby reguł do 1000 wydajność spadła do wartości około 46 Mpps dla algorytmu HiCuts oraz 53 Mpps dla algorytmu HyperCuts [46]. Dalsze prace optymalizacyjne, ukierunkowane na minimalizację pobieranej mocy oraz wzrost szybkości przetwarzania danych, doprowadziły do powstania kolejnej wersji algorytmu, wykorzystującej wiele równolegle pracujących bloków klasyfikujących. Zastosowanie 4 silników weryfikujących oraz układu FPGA Stratix3 firmy Altera pozwoliło uzyskać całkowitą przepustowość rzędu 169 Mpps [47] (pojedynczy silnik w tym wypadku osiągał efektywność około 42,25 Mpps). Jiang i Prasanna [45] zaproponowali alternatywną metodę klasyfikacji wielowymiarowej, bazującą na zmodyfikowanej wersji algorytmu HyperCuts. W swej pracy zidentyfikowali dwa główne źródła duplikacji reguł w oryginalnym algorytmie HyperCuts, wpływające na wzrost wykorzystywanych zasobów pamięciowych: pokrywanie się obszarów wyznaczanych przez poszczególne reguły, dokonywanie równomiernych cięć przedziałów (bez analizy rozmieszczenia poszczególnych reguł). Redukcję pokrywania się obszarów osiągnięto dzięki zapisywaniu zestawu replikowanych reguł w dedykowanych tabelach, tzw. wewnętrznych listach reguł (ang. internal rule lists), przyporządkowanych wewnętrznym węzłom drzewa decyzyjnego. Z kolei równomierne cięcia przedziałów w odniesieniu do portów źródłowych i docelowych zastąpione zostały przez precyzyjne wyszukiwanie optymalnych punktów przecięć, minimalizujących liczbę wielokrotnych wystąpień reguł [45]. Testową implementację klasyfikatora przeprowadzono przy wykorzystaniu układu Xilinx Virtex-5 XC5VFX200T, osiągając alokację zasobów sprzętowych na poziomie 33%. Teoretyczna maksymalna częstotliwość pracy wynosząca 125,4 MHz, zdaniem autorów, pozwala na przetwarzanie danych z szybkością 80 Gb/s, przy czym brak jest informacji dla jakich rozmiarów pakietów wartość taką wyliczono. Z tego względu nie można jednoznacznie ocenić wydajności pracy klasyfikatora, wyrażonej liczbą pakietów przetwarzanych w ciągu pojedynczej sekundy. Niekorzystną cechą omawianego algorytmu jest także uzależnienie długości potoku analizy danych rzutującego na całkowitą efektywność czasową metody, od rozmiaru drzewa decyzyjnego, warunkowanego heurystyką bazy danych reguł bezpieczeństwa (algorytm nie będzie optymalny dla drzew decyzyjnych o różnych wysokościach) [44]. Wszystkie przedstawione metody weryfikacji pakietów skupiają się na optymalizacji parametrów głównego elementu zapory ogniowej, jakim jest niewątpliwie moduł klasyfikatora. Niezwykle istotne z punktu widzenia wydajności przetwarzania danych oraz skalowalności jest jednak spojrzenie całościowe na tak złożony system bezpieczeństwa. Pominięcie kwestii odpowiedniej 42

43 organizacji architektury wewnętrznej, ścieżek przepływu danych, mechanizmów wspomagających proces klasyfikacji czy też pracy wielointerfejsowej, może w konsekwencji doprowadzić do degradacji szybkości pracy oraz stabilności zapory bądź też ograniczenia jej funkcjonalności w sposób niepozwalający na praktyczną eksploatację. Jedną z pierwszych prób implementacji w układzie FPGA kompletnego rozwiązania systemu Firewall podjął Loinig i Wolkerstorfer [59]. Zaproponowana koncepcja pozwala na zabezpieczenie wydzielonego segmentu sieci przy pomocy dwóch modułów filtrujących ruch przychodzący i wychodzący. Współpracują one z kolejkami buforującymi przepływ pakietów pomiędzy klasyfikatorem a kontrolerami interfejsów sieciowych Gigabit Ethernet. Proces weryfikacji pakietów zrealizowano przy wykorzystaniu prostego mechanizmu wyszukiwania liniowego, przy czym baza reguł bezpieczeństwa została podzielona na szesnastoelementowe, przetwarzane równolegle bloki. Skraca to czas analizy pojedynczego pakietu do 17 cykli zegara, aczkolwiek całkowite opóźnienie, uwzględniające przejście przez wszystkie elementy potoku filtracji danych, wynosi 283 cykle (niezależnie od liczby i konfiguracji reguł) [59]. Omawiany Firewall pracuje w trybie bezpośredniej retransmisji pakietów (tzw. cut-through). Dzięki temu znacznie zredukowano zapotrzebowanie na zasoby pamięciowe, kosztem zaakceptowania propagacji uszkodzonych ramek pomiędzy separowanymi segmentami sieci. Jedynie część z zaproponowanych przez Loiniga funkcjonalności Firewalla została zaimplementowana w prototypowym układzie (zrezygnowano m.in. z modułu obsługującego ruch szyfrowany oraz modułu zarządzającego). Co więcej, testowa wersja zapory wykorzystywała tylko jeden fizyczny interfejs sieciowy, jej twórcy nie byli więc w stanie w pełni zweryfikować parametrów pracy systemu w warunkach produkcyjnej infrastruktury sieci teleinformatycznych. Zdecydowanie bardziej przemyślaną i zaawansowaną konstrukcję sprzętowego Firewalla zaprezentował Jedhe et al. [43]. Klasyfikator w wersji obsługującej dwa interfejsy sieciowe wykorzystuje metodę niezależnej analizy poszczególnych pól nagłówków pakietów. Do weryfikacji adresów sieciowych zastosowano pamięć TCAM, zaś dla portów sieciowych jej wersję rozszerzoną ETCAM, umożliwiającą wyszukiwanie zakresów. Optymalizując wydajność opracowanego przez Taylor a i Turner a [118] algorytmu DCFL, Jedhe et al. [43] zaproponowali jego wersję ulepszoną - DCFLE (ang. Distributed Crossproducting of Field Labels Extended) z przeznaczeniem do agregacji pośrednich wyników przetwarzania pojedynczych pól. Tym sposobem osiągnięto ograniczenie zapotrzebowania na zasoby logiki reprogramowalnej. Zarówno przy implementacji pamięci TCAM, jak i kontrolerów Gigabit Ethernet, użyto gotowych modułów IP core (ang. Intellectual Property) firmy Xilinx. Pamięci ETCAM zbudowano w oparciu o łańcuchy elementów SRL16E (ang. Shift Register Look-Up Table), dostępne w układach FPGA Virtex. Podczas operacji zapisu konfiguracji filtrów są one wykorzystywane jako typowe 16-bitowe rejestry przesuwne, zaś podczas odczytywania informacji (klasyfikacji pakietów) pracują jako 4-wejściowe bloki LUT (ang. Look-Up Table). Ze względu na konieczność przechowywania wartości górnej i dolnej granicy wyszukiwanego przedziału pojedynczy wiersz pamięci ETCAM wymaga zastosowania 16 bloków LUT4. 43

44 Implementacja pełnego klasyfikatora dla bazy złożonej z 32 reguł bezpieczeństwa alokowała 24% dostępnych bloków LUT oraz 36% pojemności pamięci BRAM układu Virtex II Pro XC2VP30. W przeciwieństwie do rozwiązania Loiniga i Wolkerstorfera, omawiany system buforuje poszczególne pakiety, rozpoczynając ich analizę dopiero po zakończeniu odbierania danych (tzw. tryb store and forward). Maksymalna wydajność klasyfikacji osiąga w tym przypadku 50 Mpps (dla pakietów o długości 40 bajtów) [43]. Pomimo podkreślanej przez Jedhe et al. dużej skalowalności i efektywności pracy zapory, przy jej opracowywaniu powzięto szereg arbitralnych ustaleń, narzucających optymalną charakterystykę bazy danych reguł bezpieczeństwa bądź ograniczających funkcjonalność systemu, w szczególności założono, że: maksymalna liczba unikalnych wartości pól jest relatywnie mała w porównaniu z rozmiarem bazy danych reguł, maksymalna liczba unikalnych wartości pól zgodnych z analizowanym pakietem jest relatywnie bardzo mała w odniesieniu do liczby wszystkich reguł i jest z reguły mniejsza od pięciu, maksymalna liczba reguł odpowiadających danemu pakietowi jest typowo mniejsza od pięciu, ramki typu ARP (ang. Address Resolution Protocol) bądź RARP (ang. Reverse Address Resolution Protocol) są przesyłane pomiędzy separowanymi segmentami sieci bez filtracji (nie istnieje możliwość zablokowania tego typu komunikacji), typy wykrywanych protokołów transportowych ograniczono do: TCP, UDP oraz ICMP [43]. Zaprezentowany przegląd protokołów oraz metod implementacji systemów filtrujących pakiety przesyłane w sieciach teleinformatycznych obrazuje ogromną dynamikę rozwoju tego obszaru badawczego. Prowadzone prace badawcze koncentrują się przede wszystkim na optymalizacji algorytmów klasyfikacji danych, pomijając lub marginalizując kwestie pozostałych elementów wchodzących w skład architektury Firewalla. Tylko bardzo niewielka grupa publikacji podejmuje temat kompleksowej sprzętowej implementacji kompletnej zapory ogniowej z wykorzystaniem logiki reprogramowalnej. Jednak nawet w takich wypadkach stosowane wstępne złożenia projektowe powodują ograniczenie funkcjonalności lub elastyczności konfiguracji systemu w sposób utrudniający jego praktyczną eksploatację. Obserwacje te potwierdzają zasadność i celowość podjęcia przez autora niniejszej rozprawy prac badawczych w zakresie metody efektywnej realizacji sprzętowego Firewalla, przy uwzględnieniu realnych wymagań funkcjonalnych, stawianych przez współczesne, wysoko wydajne systemy komputerowe. 44

45 3. Stanowisko badawcze 3.1. Wprowadzenie Pierwszy etap realizacji pracy badawczej dotyczył przygotowania odpowiedniego środowiska testowo-uruchomieniowego, obejmującego dedykowane narzędzia programistyczne EDA (ang. Electronic Design Automation) oraz infrastrukturę sprzętową umożliwiającą weryfikację opracowanych rozwiązań w warunkach rzeczywistych. Poszczególne moduły opracowywanego sprzętowego systemu bezpieczeństwa typu Firewall musiały najpierw zostać opisane z wykorzystaniem języka VHDL (ang. Very High Speed Integrated Circuits Hardware Description Language) a następnie poddane symulacji i testom z wykorzystaniem odpowiednich narzędzi projektowych. Otrzymane w efekcie tych prac wyniki porównywano z założeniami projektowymi. Jeżeli uzyskana funkcjonalność bądź parametry wydajnościowe odbiegały od przyjętych wartości, konieczne było przeprowadzenie niezbędnych korekt w opisie i ponowne przetestowanie całego modułu Pakiet Active-HDL Kolejne generacje układów FPGA umożliwiają implementację coraz bardziej rozbudowanych systemów cyfrowych. Presja, wywoływana rynkową konkurencją wśród producentów sektora elektronicznego, znacznie skraca czas dostępny na zaprojektowanie i właściwe przetestowanie opracowywanych urządzeń. Czynniki te przekładają się na wysokie wymagania funkcjonalne oraz wydajnościowe stawiane narzędziom programistycznym EDA wspomagającym proces projektowania. Jednym z wiodących producentów oprogramowania EDA dla inżynierów zajmujących się układami reprogramowalnymi jest firma Aldec-ADT. Jej flagowy produkt, pakiet Active-HDL, stanowi zintegrowane środowisko dostarczające pełnego zestawu narzędzi niezbędnych do projektowania i weryfikacji układów cyfrowych wykorzystujących technologie FPGA oraz ASIC. Kluczowe elementy oraz cechy funkcjonalne pakietu Active-HDL obejmują m.in. [4]: narzędzia projektowe Design Entry, szybki symulator, zestaw narzędzia do analizy i weryfikacji funkcjonalnej (debugowanie oraz profiler), automatyczną generację modułów testujących, zaawansowane zarządzanie projektem oraz pełne dokumentowanie prac projektowych, wsparcie dla narzędzi producentów układów. 45

46 W skład grupy Design Entry wchodzą podstawowe narzędzia służące do opisu poszczególnych modułów realizowanego projektu, zarówno w formie tekstowej, jak i graficznej. Obecnie większość projektantów systemów cyfrowych wykorzystuje języki opisu sprzętu, a ze względu na wysoki stopień złożoności bardzo często łączone są ze sobą elementy zapisane w postaci kodu VHDL, Verilog, SystemVerilog, jak również SystemC. Użytkownicy w ramach jednego środowiska mogą korzystać ze wszystkich wyżej wymienionych modułów. Dodatkowo Active-HDL pozwala na konwersję kodu zapisanego w formie tekstowej do postaci graficznej [4]. Symulator wbudowany w pakiet Active-HDL charakteryzuje się wydajnym, uniwersalnym jądrem obsługującym wszystkie wspierane języki opisu sprzętu. Projektant ma możliwość symulowania funkcjonowania fragmentów kodu zapisanych w językach VHDL, Verilog oraz SystemC. Proces oceny poprawności funkcjonowania kodu ułatwia szereg narzędzi do debugowania, m.in.: edytor przebiegów (ang. Waveform Editor) - moduł umożliwiający edytowanie symulowanych przebiegów, okno podglądu (ang. Watch Window) - umożliwia przeglądanie wartości symulowanych obiektów, takich jak sygnały, zmienne, rejestry, podgląd pamięci (ang. Memory View) - umożliwia obserwację zawartości komórek pamięci symulowanego modułu, stos wywołań (ang. Call Stack) - umożliwia śledzenie ścieżki wywołania kolejnych funkcji testowanego modułu oraz śledzenie wartości parametrów na jakich operują funkcje. Dokładne sterowanie procesem symulacji, a tym samym obserwowanie poszczególnych etapów działania testowanego modułu, możliwe jest dzięki śledzeniu wykonania kodu z wykorzystaniem modułów Watch Window, Memory View, Call Stack oraz dzięki punktom przerwań (ang. break point). Szybkie weryfikowanie skomplikowanych projektów ułatwiają automatyczne generatory modułów testujących (ang. testbench) bazujących zarówno na wykresach utworzonych za pomocą edytora przebiegów czasowych, jak również wygenerowanych bezpośrednio w trakcie trwania symulacji. Podobnie dla automatów stanów istnieje możliwość automatycznego wygenerowania modułów testbench pokrywających wszystkie zdefiniowane na diagramie przejścia. Active-HDL nie jest dedykowany jednej konkretnej grupie układów FPGA jego uniwersalna architektura pozwala na wykorzystanie tego pakietu przez inżynierów pracujących z układami FPGA różnych producentów. Projektant za pomocą funkcjonalności Design Flow Manager może bezpośrednio w programie uruchomić dowolne narzędzie syntezy i implementacji, zarówno w trybie interaktywnym GUI (ang. Graphical User Interface), jak również w trybie wsadowym (ang. Batch mode). Active-HDL zawiera przekompilowane i gotowe do użycia biblioteki symulacyjne (VHDL oraz Verilog) udostępniane przez wszystkich producentów układów programowalnych. Dodatkowo pakiet wyposażony został w bogaty zestaw bibliotek schematów dla układów firmy Xilinx [4]. 46

47 3.3. Płyta testowo-uruchomieniowa Digilab 2E firmy Digilent Płyta FPGA Digilab 2E (D2E) firmy Digilent [21], przedstawiona na rysunku 3.1, jest ekonomiczną platformą testowo-uruchomieniową, wyposażoną w dużą liczbę złącz zewnętrznych interfejsów wejścia-wyjścia, niezbędnych do opracowywania różnorodnych układów cyfrowych. Rys Umiejscowienie kluczowych komponentów na płycie FPGA Digilab D2E. Charakteryzuje się ona następującymi parametrami: układ FPGA Spartan 2E XC2S200E firmy Xilinx [132], jeden port równoległy EPP (ang. Enhanced Parallel Port) oraz jeden szeregowy RS-232, sześć 40-nóżkowych złączy rozszerzeń wejścia-wyjścia ogólnego przeznaczenia (ang. general puropse I/O expansion connectors). Schemat blokowy płyty D2E przedstawiono na rysunku 3.2. Większość dostępnych wyprowadzeń układu FPGA podłączonych zostało do portów rozszerzeń. Takie podejście z jednej strony zapewnia dużą elastyczność oraz zmniejsza cenę urządzenia, które w swej podstawowej konfiguracji zawiera jedynie elementy niezbędne do poprawnego funkcjonowania układu FPGA (zasilanie, układ programowania JTAG, rezonator kwarcowy, itp.). Z drugiej zaś strony użytkownik 47

48 zmuszony jest zakupić bądź zbudować we własnym zakresie niezbędne karty rozszerzeń, realizujące określone specyfiką danego projektu funkcje (porty komunikacyjne, sygnalizacja, sterowanie). Rezonator 50 MHz Przycisk kontrolny Gniazdo zasilające 5-9V DC Stabilizator 2.5 V Dioda sygnalizacyjna LED Stabilizator 3.3 V Port szeregowy Port RS-232 Port równoległy Konwerter RS-232 Port równoległy EPP lub SPP Xilinx Spartan2E XC2S200E-PQ208 Port rozszerzeń D Przełącznik trybu programowania Bufor Port JTAG Port rozszerzeń C Port rozszerzeń A Port rozszerzeń E Port rozszerzeń B Port rozszerzeń F Rys Schemat blokowy płyty FPGA Digilab 2E (na podstawie [21]). Płyta Digilab D2E wyposażona jest w jedno złącze DB-25 poru równoległego EPP współdzielone z portem programowania układu Spartan2E JTAG współpracującym z narzędziami firmy Xilinx (np. Xilinx Parallel III cable oraz ISE WebPack). Złącze zgodne ze standardem IEEE 1284 jest podłączone bezpośrednio do układu FPGA. Do przełączania trybu pracy złącza z EPP do JTAG służy dwupozycyjny przełącznik SW-1, sterujący dodatkowym układem buforów trójstanowych. Dołączony kabel programowania JTAG wymaga posiadania w komputerze jednego wolnego portu równoległego. Na płycie zamontowano 8-nóżkowy 50 MHz rezonator kwarcowy. Dzięki łatwej wymianie elementu oscylatora płyta zapewnia szeroki zakres częstotliwości pracy zegara systemowego: od około 30 khz do 100 MHz. Wykorzystując bloki funkcjonalne DLL układu Spartan2E, możliwe jest doprowadzenie do implementowanych układów sygnału zegarowego o częstotliwości do 200 MHz. Dla kart rozszerzeń użytkownika na platformie D2E dostępnych jest 6 portów wejścia-wyjścia ogólnego przeznaczenia w standardowych 40-nóżkowych obudowach rozmieszczonych na krawędziach płyty, zgodnie ze schematem zamieszczonym na rysunku 3.3. Złącza zorganizowane są parami: A & B, C & D, E & F. Linie sygnałowe dla portów A & B oraz E & F są podłączone do układu FPGA w sposób symetryczny tak, że pary A & E oraz B & F współdzielą te same linie 48

49 sygnałowe. Porty C oraz D podłączone są do układu FPGA w sposób niezależny. W każdym z portów, oprócz linii sygnałowych, udostępnione zostały napięcie zasilające 3,3 V oraz masa płyty GND. A B C DB Xilinx Spartan2E XC2S200E -PQ208 DB D F E Rys Schemat rozmieszczenia oraz struktura połączeń wewnętrznych złączy rozszerzeń na płycie FPGA Digilab 2E (na podstawie [21]). Płyta D2E pozwala na wykorzystanie 122 linii sygnałowych układu Spartan2E, z czego 74 linie podłączone do złącz C & D umożliwiają pracę z częstotliwością do 100 MHz. Szczegółowy opis poszczególnych linii sygnałowych złącz rozszerzeń można odnaleźć w dokumentacji technicznej płyty [21] Płyta testowo-uruchomieniowa XUPV2 firmy Digilent Płyta testowo-uruchomieniowa XUPV2 firmy Digilent (Rys. 3.4) jest zaawansowanym środowiskiem wdrożeniowym przeznaczonym do realizacji projektów systemów cyfrowych implementowanych na platformie FPGA. Płyta bazuje na układzie FPGA Virtex II Pro XC2VP30 firmy Xilinx, uzupełnionym bogatym zestawem urządzeń peryferyjnych oraz funkcjonalności obejmujących [23]: układ FPGA Virtex II Pro [135] wyposażony w dwa rdzenie procesora PowerPC 405, możliwość zainstalowania do 2 GB pamięci DDR (ang. Double Data Rate) SDRAM, wbudowany kontroler System ACE, pamięć PROM oraz złącze CompactFlash Type II do przechowywania wielu obrazów konfiguracji układu FPGA, port USB 2.0 do konfiguracji układu FPGA, konfigurację z wykorzystaniem SelectMAP Platform Flash, wbudowany układ PHY 10/100 Mb/s Ethernet, szybkie złącza zewnętrzne MGT, 49

50 Rys Wygląd płyty FPGA XUP Virtex II Pro. dostępne dwa porty szeregowe PS-2, jeden port szeregowy RS-232 DB9 oraz trzy porty Serial ATA, sześć standardowych złączy rozszerzeń podłączonych do 80 wyprowadzeń I/O układu Virtex II Pro z zabezpieczeniem przeciążeniowym, jeden szybki port rozszerzeń alokujący 40 wyprowadzeń I/O układu Virtex II Pro możliwość pracy w trybie różnicowym bądź standardowym, wbudowany CODEC AC-97 wyposażony w dodatkowy wzmacniacz oraz panel wejść/wyjść audio, wbudowany port wideo XSGA wspierający rozdzielczości do 1200x1600 przy odświeżaniu 70 Hz, zegar systemowy 100 MHz oraz zegar SATA o częstotliwości 75 MHz, możliwość wykorzystywania zegarów użytkownika, specjalizowany układ resetu komponentów płyty po włączeniu zasilania. Dostępny na płycie układ FPGA typu Virtex II Pro XC2VP30 FF896BGA firmy Xilinx [135] charakteryzuje się następującymi parametrami: bloków Slice, 428 Kb pamięci Distributed RAM oraz 2448 Kb pamięci Block RAM, 50

51 136 bloków mnożących, 8 bloków DCM, 2 rdzenie procesora PowerPC, 8 transceiver ów Multi-Gigabit. Płyta posiada jedno 184-wyprowadzeniowe złącze zgodne z modułami pamięci DIMM DDR SDRAM (ang. Dual In-line Memory Module Double Data Rate Synchronous Dynamic RAM) o maksymalnej pojemności do 2GB w wersji zarówno buforowanej, jak i niebuforowanej. W przypadku korzystania z pamięci o organizacji 72-bitowej, moduły takiej pamięci powinny posiadać korekcję błędów ECC. AC97 Audio SXGA port 10/100 Ethernet Złącza rozszerzeń (zabezpieczenia przeciążeniowe) Pamięć 256M x 64/72 DDR SDRAM DIMM Diody LED, Przełączniki, przyciski, porty PS/2 Oraz RS-232 System ACE port 3.3V IO 2.5V IO Rys Schemat połączeń banków I/O do urządzeń zewnętrznych płyty XUP Virtex II Pro (na podstawie [23]). Układ XC2VP30 komunikuje się z urządzeniami zewnętrznymi poprzez 8 banków sygnałów wejścia-wyjścia. Przyporządkowanie poszczególnych banków do konkretnych urządzeń peryferyjnych zaprezentowano na rysunku 3.5. Projektant ma do dyspozycji 6 zewnętrznych interfejsów wejścia-wyjścia ogólnego przeznaczenia (ang. general puropse I/O expansion connectors) oraz jedno bardzo szybkie zewnętrzne złącze przystosowane do pracy w trybie różnicowym z możliwością obsługi do trzech niezależnych sygnałów zegarowych. Cztery z sześciu dostępnych złączy dostępne są w konfiguracji 60 linii sygnałowych, a dwa w konfiguracji 40 linii sygnałowych. W każdym z wariantów połowa dostępnych wyprowadzeń jest połączona z masą płyty (GND). Sumarycznie wszystkie złącza pozwalają wykorzystać do 80 wyprowadzeń układu Virtex II Pro. Szczegółowy opis poszczególnych sygnałów portów rozszerzeń można odnaleźć w dokumentacji technicznej płyty [135]. 51

52 Układ XC2VP30 zawiera w sumie osiem portów MGT (ang. Multi-Gigabit Transceiver), cztery z nich udostępniono użytkownikom w postaci złączy zewnętrznych. Kolejne trzy interfejsy MGT zostały podłączone do gniazd SATA, a ostatni do gniazda w standardzie Sub-Miniature A (SMA). Wszystkie interfejsy MGT wykorzystują niezależny sygnał zegarowy o częstotliwości pracy 75MHz. Dodatkowo złącze SMA przystosowane jest do pracy z różnicowym zegarem zewnętrznym. Uzupełnieniem zestawu portów komunikacyjnych dostępnych na płycie XUPV2P jest jeden interfejs Fast Ethernet zgodny ze specyfikacjami 100BASE-TX oraz 10BASE-T. Pozwala on na dwukierunkową transmisję danych (tzw. tryb Full Duplex) z szybkościami 10 Mb/s i 100 Mb/s. Wspiera również funkcje autonegocjacji oraz detekcji kolizji. Programowanie układu XC2VP30 ułatwia wbudowany kontroler System ACE (ang. Advanced Configuration Environment), pozwalający na zarządzanie łańcuchem konfiguracyjnym złożonym z następujących elementów: portu Compact Flash, portu konfiguracyjnego JTAG, portu MPU, portu testowego JTAG Realizacja dostępowych interfejsów fizycznych dla sieci Fast i Gigabit Ethernet Ogromne możliwości oferowane przez technologię układów reprogramowalnych FPGA zostały szybko zauważone przez firmy komercyjne zajmujące się produkcją gotowych systemów testowo-uruchomieniowych. Spośród dużego zbioru różnorodnych płyt producentów, takich jak: Digilent [22], HiTech Global Design & Distribution [37], Terasic Technologies [120] i wielu innych, zespoły badawcze mogą wybrać platformę najlepiej odpowiadającą swoim wyposażeniem potrzebom funkcjonalnym realizowanych urządzeń. Większość dostępnych rozwiązań płyt uruchomieniowych wyposażana jest dodatkowo w złącza rozszerzeń, zwiększające elastyczność całej platformy, poprzez umożliwienie dołączania specjalizowanych kart dostosowanych do potrzeb konkretnych użytkowników. W efekcie tego znikają praktycznie wszystkie ograniczenia implementacyjne związane z nietypowymi wymaganiami odnośnie liczby bądź standardu portów komunikacyjnych, interfejsów sterujących oraz sygnalizacyjnych, itp. Taka sytuacja miała miejsce przy realizacji zadania badawczego związanego z opracowaniem sprzętowej wersji systemu bezpieczeństwa typu Firewall, filtrującego ruch w szybkich sieciach opartych o standard Ethernet. Z racji sposobu działania wymaga on dostępności minimum dwóch portów komunikacyjnych (z możliwością dalszego zwiększania ich liczby), pomiędzy którymi odbywa się transmisja danych. Ponieważ na etapie prowadzenia prac projektowych autor dysponował płytami testowymi firmy Digilent, wyposażonymi maksymalnie w jeden port sieciowy obsługujący 52

53 tylko standard Fast Ethernet (transmisja do 100 Mb/s), koniecznym stało się opracowanie prototypów zewnętrznych kart sieciowych dołączanych do portów rozszerzeń. Początkowe prace badawcze realizowano z wykorzystaniem platformy Digilent Digilab D2E [21], bazującej na układzie FPGA Spartan 2E XC2S200 firmy Xilinx [132]. Ze względu na stosunkowo niewielką liczbę zasobów sprzętowych oraz maksymalną szybkość pracy tego układu, dla tak skonfigurowanego środowiska testowego zdecydowano się na opracowanie jedynie kart Fast Ethernet. Pomimo oczywistych ograniczeń umożliwiły one weryfikację funkcjonowania kluczowych modułów sprzętowych opracowywanego systemu, takich jak: kontroler sieciowy MAC (ang. Media Access Control) [108] oraz blok pamięci ramkowych [115]. Kolejne etapy realizacji sprzętowej zapory ogniowej wymagały zmiany platformy testowej na bardziej wydajną. Ostatecznie wybrano płytę Digilent XUPV2 [23] z układem Virtex II Pro XC2VP30 FPGA [135], dla której opracowano nową wersję interfejsów NIC (ang. Network Interface Card) pozwalających na pracę w sieciach opartych o Gigabit Ethernet z przepustowością do 1000 Mb/s Karta Fast Ethernet Kluczowym elementem karty sieciowej jest układ PHY (ang. Physical Layer Device), odpowiedzialny za realizację operacji przynależnych najniższej warstwie modelu odniesienia łączenia systemów otwartych ISO/OSI (ang. ISO OSI Reference Model) [42], związanych z kodowaniem, dekodowaniem oraz synchronizacją wysyłanych bądź odbieranych danych (zależnie do typu zastosowanego nośnika fizycznego [40]). Położenie funkcjonalne układu PHY w modelu ISO/OSI pokazano na rysunku 3.6. Dla układów PHY, obsługujących jedynie standard Fast Ethernet, dopuszczone są prędkości pracy do 100 Mb/s, zaś dla standardu Gigabit Ethernet do 1000 Mb/s. WARSTWY MODELU REFERENCYJNEGO OSI WARSTWY WYŻSZE APLIKACJI LLC LOGICAL LINK CONTROL PREZENTACJI MAC CONTROL (opcjonalnie) SESJI MAC MEDIA ACCESS CONTROL TRANSPORTOWA SIECIOWA ŁĄCZA DANYCH FIZYCZNA MAU MDI AUI PLS PMA DOPASOWANIE MDI AUI MII PLS PMA DOPASOWANIE MDI MII PCS PMA PMD DOPASOWANIE MDI GMII PCS PMA PMD PHY MEDIUM MEDIUM MEDIUM MEDIUM 1 Mb/s, 10Mb/s 10Mb/s 100Mb/s 1000Mb/s AUI = ATTACHMENT UNIT INTERFACE MDI = MEDIUM DEPENDENT INTERFACE MII = MEDIA INDEPENDENT INTERFACE GMII = GIGABIT MEDIA INDEPENDENT INTERFACE MAU = MEDIUM ATTACHMENT UNIT PLS = PHYSICAL LAYER SIGNALING PCS = PHYSICAL CODING SUBLAYER PMA = PHYSICAL MEDIUM ATTACHMENT PHY = PHYSICAL LAYER DEVICE PMD = PHYSICAL MEDIUM DEPENDENT Rys Model warstwowy ISO/OSI z uwidocznionym położeniem układu PHY. 53

54 Spośród wielu dostępnych na rynku rozwiązań do opracowania karty Fast Ethernet wybrano układ PHY RTL8201BL, oferowany przez firmę Realtek [84]. Jest to jednoportowy układ typu Fast Ethernet Phyciever, wyposażonym w selektywnie wybierany interfejs MII (ang. Media Independent Interface) lub SNI (ang. Serial Network Interface) do warstwy MAC. Posiada on następujące cechy funkcjonalne [83]: zgodność ze standardami IEEE 802.3/802.u, w tym wsparcie dla interfejsu MII/7-wire SNI, możliwość pracy w trybie 10/100 Mb/s Half/Full Duplex z autonegocjacją parametrów, możliwość pracy z okablowaniem miedzianym lub światłowodami, niski pobór mocy, tryb oszczędny (ang. Power Down Mode), wsparcie dla kompensacji BLW (ang. Base Line Wander) oraz kontroli przepływu, konfigurowalne prędkości oraz tryb transmisji (Duplex, autonegocjacja), możliwość ustawiania parametrów pracy zarówno poprzez dedykowane wyprowadzenia zewnętrzne, jak również przy pomocy linii MDC/MDIO, sygnalizowanie przy pomocy diod LED nawiązania poprawnego połączenia, transmisji danych, prędkości oraz wystąpienia kolizji. BLOK 100 Mbps Korekcja BLW Detektor szczytowy MLT-3 NRZI Komparator Korektor adaptacyjny RXIN + RXIN - Interfejs MII Interfejs SNI 10/100 Mbps, Half/Full Duplex Logika sterująca Dekoder 5B/4B Dekoder 4B/5B BLOK 10 Mbps Blok formowania danych Scrambler Autonegocjacja 10/100 Mbps Logika kontrolna TXD10 TXC10 Kodowanie Menchester Descrambler Formowanie sygnału wyjściowego RXD RXC 25MHz TXD TXC 25MHz Deserializacja Serializacja 25MHz clk data Slave PLL 3-stanowy bufor wyjsciowy Główna PLL TXO + TXO - RXD10 RXC10 Odtwarzanie danych Filtr dolnoprzepustowy Rys Schemat blokowy układu RTL8201BL (na podstawie [83]). Strukturę wewnętrzną układu RTL8201BL przedstawiono na rysunku 3.7. W układzie zaimplementowane zostały wszystkie funkcje niezbędne do obsługi warstwy fizycznej (ang. Physical Layer) dla standardu Ethernetu 10/100 Mb/s, m.in.: podwarstwa kodowania PCS (ang. Physical Coding Sublayer), 54

55 przyłącze medium fizycznego PMA (ang. Physical Medium Attachment), podwarstwa obsługi medium transmisyjnego typu skrętka miedziana TP-PMD (ang. Twisted Pair Physical Medium Dependent Sublayer), blok kodowania/dekowania dla standardu 10Base-Tx, jednostka dostępu do medium typu skrętka miedziana TPMAU (ang. Twisted Pair Media Access Unit). W zależności od aktualnie skonfigurowanej szybkości pracy przetwarzanie danych odbywa się w dedykowanych blokach: 10 Mb/s lub 100 Mb/s. Architektura toru obsługującego standard Fast Ethernet jest zdecydowanie bardziej zaawansowana w porównaniu do wersji 10 Mb/s. Nad poprawnością funkcjonowania całego układu PHY czuwa specjalny blok sterujący. Na podstawie zadanych parametrów konfiguracyjnych komunikacja z kontrolerem MAC realizowana jest poprzez interfejs MII lub SNI. Dzięki bogatej funkcjonalności układ może być wykorzystywany nie tylko do budowy kart interfejsów sieciowych, lecz również w koncentratorach i przełącznikach Ethernetowych czy też w interfejsach przyłączeniowych MAU (ang. Media Attachment Unit). Manualna konfiguracja parametrów pracy układu idealnie odpowiada potrzebom środowiska testowo-uruchomieniowego. Oznaczenia oraz funkcje poszczególnych sygnałów układu RTL8201BL zostały zamieszczone w pliku fast_ethernet_phy.pdf, znajdującym się na załączonej płycie CD w katalogu \fast_ethernet_doc. Opisany w standardzie IEEE [40] 18-sygnałowy interfejs komunikacyjny MII ma za zadanie zapewnić poprawną wymianę informacji pomiędzy układem PHY a kontrolerem MAC. W celu skonfigurowania układu RTL8201BL w tryb pracy z obsługą interfejsu MII należy ustawić wysoki poziom logiczny na wejściu MII/SNIB, jak również właściwie wysterować linie ANE, SPEED oraz DUPLEX. Częstotliwość pracy interfejsu uzależniona jest od trybu pracy i wynosi odpowiednio: 2,5 MHz dla szybkości 10 Mb/s oraz 25 MHz dla szybkości 100 Mb/s. Proces transmisji danych inicjowany jest przez kontroler MAC wystawieniem wysokiego stanu logicznego na wejście TXEN oraz odpowiednią relokacją danych przeznaczonych do wysłania. Ponieważ magistrala danych TXD układu PHY ma szerokość jednego nibla (połowy bajtu), kontroler MAC dokonuje wstępnego formowania wysyłanych danych. Stan linii TXD jest zatrzaskiwany dla każdego narastającego zbocza sygnału zegarowego przez cały czas aktywności sygnału TXEN. Sygnał zegarowy TXC dla toru transmisyjnego generowany jest przez PHY, wykorzystując do tego zewnętrzny oscylator kwarcowy o częstotliwości znamionowej 25 MHz. Dla pracy z prędkością 10 Mb/s częstotliwość zegara TXC wynosi 2,5 MHz. Poszczególne czterobitowe słowa wejściowe TXD[3:0] w tym trybie pracy podlegają na początku konwersji z postaci równoległej na szeregową. Tak otrzymany strumień danych NRZ (ang. Non Return to Zero) o przepływności 10 Mb/s jest następnie poddawany kodowaniu Manchester i przesyłany do bloku transmitera, który zgodnie ze standardem IEEE dołącza na końcu pakietu komunikat sygnalizacyjny SOI (ang. Start Of Idle). Ostatnim elementem całego procesu jest dodatkowa filtracja strumienia transmitowanych danych, mająca na celu dopasowanie parametrów sygnału do wymagań medium transmisyjnego. W trybie Fast 55

56 Ethernet (prędkość 100 Mb/s) poszczególne nible na wejściach TXD podawane są przez kontroler MAC synchronizowany zegarem TXC o częstotliwości 25 MHz. Dla tej prędkości transmisji każde czterobitowe słowo danych podlega wpierw kodowaniu 4B/5B. Następnie dokonywana jest randomizacja danych (blok scramblera), konwersja do postaci szeregowej NRZ 125 MHz oraz zmiana kodowania na format NRZI (ang. Non Return to Zero Inverted). W kolejnym kroku strumień danych podlega kodowaniu MLT-3 (ang. Multi-Level Transmit) i w tej postaci trafi do stopnia wyjściowego. Blok transmitera przed wysłaniem właściwych danych aktywuje najpierw sygnał TXEN oraz nadaje grupę kodową początku ramki /J/K/ (ang. start-of-frame delimiter). Po zakończeniu transmisji danych wysyłana jest sekwencja /T/R/ (ang. end-of-frame delimiter). Aby zminimalizować powstawanie zakłóceń elektromagnetycznych EMI (ang. Electromagnetic Interference) zastosowano powiązanie parametru ziarna (ang. seed) skramblera z adresem fizycznym układu PHY. Układ RTL8201BL nie wykorzystuje sygnału błędu nadawania TXER. Proces odbierania danych sygnalizowany jest obecnością wysokiego stanu logicznego na wyjściu RXEN. Odebrane dane RXD[3:0] zmieniają się w takt zegara RXC odtworzonego z sygnału przesyłanego w medium transmisyjnym. Stan sygnału CRS uzależniony jest od aktualnego trybu pracy. Dla szybkości 100 Mb/s jest on aktywny, jeżeli odebrany symbol w kodowaniu 5B jest różny od wartości IDLE. W przeciwnym przypadku CRS pozostaje w niskim stanie logicznym. Dla szybkości 10 Mb/s CRS aktywuje się po odebraniu poprawnej sekwencji preambuły, zaś dezaktywuje po wystąpieniu sekwencji IDLE. Sygnał RXDV, walidujący słowo na szynie danych RXD, osiąga wysoki stan logiczny dla szybkości 100 Mb/s, jeżeli odebrano symbol /J/K/. W przypadku odebrania symboli /T/R/ lub IDLE pozostaje on na poziomie niskim. Przy pracy z szybkością 10 Mb/s stan sygnału RXDV odpowiada wartości sygnału CRS. Sygnał błędu odbioru RXER jest aktywny w momencie odebrania niepoprawnego symbolu w kodowaniu 5B. Przepływ danych w torze odbiorczym dla szybkości 10 Mb/s jest odwrotny do opisanego wcześniej dla części nadawczej. Sygnał odebrany z medium fizycznego po wstępnym filtrowaniu podlega dekodowaniu Menchester, w efekcie czego uzyskujemy szeregowy strumień informacji kodowany NRZ. Jest on ostatecznie konwertowany do postaci równoległych słów czterobitowych (szyna RXD[3:0]). Przy szybkości 100 Mb/s sygnał ulega na wstępie kompensacji w adaptacyjnym korektorze, minimalizując w ten sposób negatywne zjawiska związane z tłumieniem medium fizycznego. Korektor BLW monitoruje nieustannie ten proces, dynamicznie reagując na zmiany sygnału wejściowego. Pętla fazowa PLL (ang. Phase-Locked Loop) odtwarza sygnał zegarowy, niezbędny do odzyskania strumienia danych w kodowaniu NRZI. W kolejnych krokach następuje zmiana formatu NRZI na NRZ, proces deskramblowania, a na koniec konwersja postaci szeregowej 5B na równoległą 4B. W efekcie końcowym odebrane nible danych wystawiane są do interfejsu MII poprzez szynę RXD[3:0]. 56

57 32 cykle zegara Preambuła A4 A3 A2 A1 A0 R4 R3 R2 R1 R0 1 0 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 ST OP PHYAD[4:0] REGAD[4:0] TA DANE Linia MDIO sterowana przez kontroler MAC; dane zapisywane do układu PHY przy narastającym zboczy zegara MDC cykl zapisu IDLE 32 cykle zegara Preambuła Z A4 A3 A2 A1 A0 R4 R3 R2 R1 R0 0 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 ST OP PHYAD[4:0] REGAD[4:0] TA DANE IDLE Linia MDIO sterowana przez kontroler MAC; dane zapisywane do układu PHY przy narastającym zboczy zegara MDC cykl odczytu Linia MDIO sterowana przez PHY; dane wystawiane przez PHY przy narastającym zboczy zegara MDC Rys Cykle zapisu i odczytu magistrali MDIO układu RTL8201BL (na podstawie [83]). Szeregowa magistrala zarządzająca MDIO pozwala kontrolerowi MAC na bieżącą zmianę oraz odczyt parametrów pracy maksymalnie 32 układów RTL8201BL, z których każdy posiada inny adres PHY, definiowany w zakresie od do (wartość jest zarezerwowana do przejścia w tryb oszczędzania energii). Wyprowadzenia służące konfiguracji adresu stanowią zarazem podłączenia diod sygnalizacyjnych, stąd też konfiguracja adresu jest zatrzaskiwana podczas włączenia napięcia zasilającego bądź resetu układu. Proces odczytu i zapisu konfiguracji z wykorzystaniem magistrali MDIO został przedstawiony na rysunku 3.8. Opis poszczególnych pól ramki zarządzającej zaprezentowano w tabeli 3.1. Tab Opis poszczególnych pól ramki zarządzającej układu RTL8201BL (na podstawie [83]). Nazwa Opis Preambuła '1' logiczna wysyłana przez MAC podczas 32 pierwszych cykli zegara MDC od momentu rozpoczęcia nadawania ramki sterującej. Preambuła jest niezbędna do poprawnej synchronizacji układu PHY. ST Początek ramki (ang. Start of Frame) wyróżniany sekwencją 01. OP Kod operacji (ang. Operation code). Odczyt = 10. Zapis = 01. PHYAD Adres układu PHY (ang. PHY Address). Pojedynczy kontroler MAC może zarządzać maksymalnie 31 układami PHY. Pięciobitowa sekwencja adresu wskazuje na konkretny PHY, którego dotyczy dana ramka. REGAD TA DANE IDLE Adres rejestru (ang. Register Address). Pięciobitowy adres wewnętrznego rejestru układu PHY, którego dotyczy aktualnie wykonywana operacja zapisu bądź odczytu Pole zmiany urządzenia sterującego linią MDIO (ang. Turnaround). Dwubitowy odstęp pomiędzy polami rejestru i danych pozwala na poprawne przejęcie sterowania linią MDIO przez układ PHY w czasie operacji odczytu. Podczas trwania pierwszego bitu pola TA, zarówno kontroler MAC, jak i układ PHY powinny pozostawać w stanie wysokiej impedancji. Dopiero w drugim bicie PHY może zmienić stan MDIO na logiczne '0'. Dane (ang. Data). 16-bitowa wartość odczytanych bądź zapisywanych danych. Tryb bezczynności (ang. Idle). Schemat ideowy opracowanej karty sieciowej Fast Ethernet, bazującej na układzie PHY RTL8201BL firmy Realtek, zawarto w pliku fast_ethernet_nic.pdf, znajdującym się na załączonej płycie CD w katalogu \fast_ethernet_doc. Uwzględniając zasygnalizowane już wcześniej specyficzne wymagania środowiska testowo-uruchomieniowego, koniecznym stało się uzupełnienie typowej implementacji układu RTL8201, zamieszczonej w nocie aplikacyjnej [85], o blok manualnej 57

58 konfiguracji parametrów pracy, pełną sygnalizację stanu układu oraz panel konfiguracji adresu PHY. Dodatkowo, w stosunku do pierwotnego rozwiązania, zmieniono niezależne elementy U2 (transformator separujący H1251) oraz U3 (gniazdo RJ-45) na zintegrowany moduł Pulse J0026D21B [79], oznaczony na schemacie ideowym symbolem J1. Zastosowany w prototypie blok manualnej konfiguracji wykorzystuje 8-sekcyjny przełącznik typu DIP-switch (symbol SW1) oraz zestaw rezystorów pull-up R11-17 i R28. Funkcje poszczególnych sekcji przełącznika SW1 przedstawiono w tabeli 3.2. Manualny reset karty realizowano za pomocą dodatkowego przełącznika S2. Reset automatyczny następuje po włączeniu zasilania dzięki elementom R13 i C20. Tab Opis funkcji poszczególnych sekcji przełącznika SW1 w karcie Fast Ethernet. Numer Funkcja Pozycja przełącznika ON ('0' logiczne) OFF ('1' logiczna) 1 Wybór interfejsu MII/SNI Interfejs SNI aktywny Interfejs MII aktywny 2 Włączenie trybu ISOLATE Tryb ISOLATE wyłączony Tryb ISOLATE włączony Włączenie trybu LDPS Tryb LDPS wyłączony Tryb LDPS włączony 5 Włączenie trybu repeater'a Tryb repeater'a wyłączony Tryb repeater'a wyłączony 6 Ustawienie szybkości pracy na 100 Mb/s Szybkość pracy 10 Mb/s Szybkość pracy 100 Mb/s 7 Włączenie trybu Full Duplex Praca w trybie Half Duplex Praca w trybie Full Duplex 8 Włączenie trybu autonegocjacji Autonegocjacja wyłączona Autonegocjacja włączona Konfiguracji adresu PHY dokonuje się przy montażu płytki drukowanej za pomocą zwor JP1- JP10. Istotne jest zachowanie właściwej polaryzacji diod LED w zależności od ustawienia zwor w każdej z sekcji. Funkcje poszczególnych diod sygnalizacyjnych opisano w tabeli 3.3, natomiast ich lokalizację fizyczną na karcie interfejsu sieciowego Fast Ethernet zaprezentowano w pliku fast_ethernet_cfg.pdf, znajdującym się na załączonej płycie CD w katalogu \fast_ethernet_doc. Tab Opis funkcji poszczególnych diod sygnalizacyjnych karty Fast Ethernet. Nazwa LED 0 LED 1 LED 2 LED 3 LED 4 Funkcja Link: aktywna w momencie zestawienia poprawnego połączenia do medium. Full Duplex: aktywna w trybie Full Duplex. Link 10 Mb/Active: tryb 10Base-T; pulsuje w momencie transmisji bądź odbioru danych. Link 100 Mb/Active: tryb 100Base-TX; pulsuje w momencie transmisji bądź odbioru danych. Collision: aktywna w momencie wystąpienia kolizji. W ramach przeprowadzonych prac zaprojektowano i wykonano dwuwarstwowy obwód drukowany interfejsu sieciowego Fast Ethernet. Matryce poszczególnych warstw zamieszczono w pliku fast_ethernet_pcb.pdf (katalog \fast_ethernet_doc na płycie CD). Zmontowany prototyp karty sieciowej Fast Ethernet przedstawiono na rysunku

59 Rys Prototyp zmontowanej karty Fast Ethernet skala 1:1. Zdecydowana większość wykorzystanych do budowy karty elementów składowych była przeznaczona do montażu powierzchniowego SMD. Zostały one ulokowane na górnej warstwie obwodu drukowanego (ang. top layer). Jedynie gniazdo RJ-45, złącze interfejsu MII oraz przełącznik DIP-switch wymagały montażu przewlekanego. Rozmieszczenie linii zasilających oraz poszczególnych sygnałów interfejsu MII w złączu komunikacyjnym karty Fast Ethernet pokazano na rysunku GND VDD 3.3V TXEN TXD2 TXD0 RXCLK RXD2 RXD0 CRS MDC COL TXD3 TXD1 TXCLK RXD3 RXD1 RXDV RXER MDIO Rys Numeracja wyprowadzeń złącza interfejsu MII karty Fast Ethernet Karta Gigabit Ethernet Karta sieciowa obsługująca standard Gigabit Ethernet została zrealizowana w oparciu o układ DP83865 [68] firmy National Semiconductor. Jest on w pełni funkcjonalnym urządzeniem warstwy fizycznej typu PHY, wyposażonym w wewnętrzne bloki funkcjonalne obsługujące podwarstwę PMD (lokalizacja PHY w modelu ISO-OSI przedstawiona została na rysunku 3.6) dla standardów sieci: 10BASE-T, 100BASE-TX oraz 1000BASE-T Ethernet. Jego zaawansowana struktura wewnętrzna oraz proces technologiczny CMOS 0.18 µm (zasilanie 1,8 V) gwarantują niewielki pobór mocy, jak również wysoką wydajność i stabilność pracy. Typowe aplikacje układu wymagają stosunkowo niedużej liczby elementów zewnętrznych (głównie kondensatorów odprzęgających), pozwalając na szybką realizację kart interfejsów sieciowych, przełączników Ethernetowych, bądź portów 59

60 agregujących. Interfejs komunikacyjny MAC obsługuje standardy: IEEE 802.3u MII, IEEE 802.3z GMII (ang. Gigabit Media Independent Interface) oraz RGMII (ang. Reduced GMII). Główne cechy funkcjonalne układu DP83865 [68]: bardzo niski pobór mocy typowo 1,1 W, pełna zgodność ze specyfikacjami IEEE BASE-T, 100BASETX oraz 1000BASE-T, wbudowane bloki PMD wyposażone w korekcję adaptacyjną oraz BWL zgodnie z wymaganiami standardu ANSI X3.T12, interfejs komunikacyjny MAC 3,3 V lub 2,5 V wspierający tryby: o IEEE 802.3u MII, o IEEE 802.3z GMII, o RGMII wersja 1.3, możliwość ustalania przez użytkownika kolejności sygnałów w interfejsie GMII, pełna automatyczna negocjacja pomiędzy urządzeniami 1000 Mb/s, 100 Mb/s, 10 Mb/s, Full Duplex oraz Half Duplex, dostosowywanie prędkości pracy do jakości połączenia (ang. Speed Fallback), wbudowany moduł pomiaru długości kabla, sygnalizacja połączenia, trybu oraz prędkości transmisji danych z wykorzystaniem diod LED (istnieje możliwość konfiguracji opcji sygnalizacji przez użytkownika), wymagane jedynie dwa napięcia zasilające: 1,8 V (rdzeń i część analogowa) oraz 2,5 V (część analogowa i blok I/O) - istnieje możliwość wykorzystania alternatywnego napięcia 3,3 V do zasilania bloku I/O, przerwania definiowane przez użytkownika, wsparcie dla automatycznego wykrywania rodzaju kabla (prosty, skrosowany) Auto-MDIX dla wszystkich szybkości pracy 10, 100 oraz 1000 Mb/s. Bogata funkcjonalność układu DP83865, a przede wszystkim wsparcie dla standardu Gigabit Ethernet, czynią jego wewnętrzną architekturę zdecydowanie bardziej skomplikowaną, niż to miało miejsce w przypadku omawianego wcześniej układu RTL8201BL. Schemat blokowy układu DP83865 przedstawiono na rysunku Odrębne tory przetwarzania danych dla każdej z szybkości pracy formują w odpowiedni sposób strumienie bitowe. Podsystem przetworników analogowo-cyfrowych i cyfrowo-analogowych współpracuje z blokiem analogowych nadajników i odbiorników sygnału z medium fizycznego. Układ DP83865 wymaga zastosowania zewnętrznego transformatora separującego. Blok 10 Mb/s oraz 100 Mb/s komunikuje się z kontrolerem MAC za pomocą interfejsu MII, natomiast blok 1000 Mb/s za pomocą interfejsu GMII. Za właściwą obsługę poszczególnych trybów pracy interfejsu komunikacyjnego odpowiedzialny jest blok multipleksera/demultipleksera. Nad całością pracy układu czuwa dedykowany mikrokontroler, realizujący również funkcje zarządzania PHY z wykorzystaniem linii MDIO oraz generowania przerwań dla układów 60

61 zewnętrznych użytkownika. Dokładny opis działania poszczególnych bloków układu DP83865 odnaleźć można w dokumentacji technicznej [68]. Oznaczenia i funkcje poszczególnych sygnałów wchodzących w skład interfejsu MAC oraz panelu sygnalizacyjno-konfiguracyjnego opracowanej karty sieciowej wraz z odpowiadającymi im numerami wyprowadzeń układu DP83865 zamieszczono w pliku gigabit_ethernet_phy.pdf, znajdującym się na załączonej płycie CD w katalogu \gigabit_ethernet_doc. Interfejs zarządzający Wspólny interfejs MII/GMII/RGMII MDIO MDC Interrupt GTX_CLK TX_ER TX_EN TXD[7:0] TX_CLK RX_CLK COL CRS RX_ER RX_DV RXD[7:0] Mikrokontroler zarządzający oraz blok kontroli PHY Blok multipleksera/ demultipleksera MII MII GMII 10BASE-T PLS 100BASE-TX PCS 1000BASE-T PCS 10BASE-T PMA 100BASE-TX PMA 1000BASE-T PMA Blok 10BASE-T Blok 100BASE-TX 100BASE-TX PMD Blok 1000BASE-T Manchester 10 Mb/s MLT Mb/s PAM-5 17 poziomów Kształtowanie PR Podsystem DAC/ADC Blok DAC/ADC oraz generator zegara Odbiorniki/ nadajniki Generator zegara Transformator 4-parowa skrętka CAT-5 Rys Schemat blokowy układu DP83865 (na podstawie [68]). 61

62 Schemat ideowy karty sieciowej Gigabit Ethernet, bazującej na układzie PHY DP83865 firmy National Semiconductor, opracowano na podstawie standardowej noty aplikacyjnej [69]. Wersję elektroniczną schematu zawarto w pliku gigabit_ethernet_nic.pdf, znajdującym się na płycie CD w katalogu \gigabit_ethernet_doc. Ze względu na przyjęte założenia konieczne było wprowadzenie szeregu modyfikacji dostosowujących funkcjonalność gigabitowego interfejsu sieciowego do potrzeb środowiska testowo-uruchomieniowego. Do najistotniejszych należały: dodanie bloku manualnej konfiguracji umożliwiającego pełne sterowanie układem PHY, w tym jego adresu, dodanie panelu sygnalizującego stan pracy, złożonego z pięciu diod LED. Oprócz zwiększenia funkcjonalności karty Gigabit Ethernet niezbędne były również korekty związane z zamianą niektórych podzespołów elektronicznych wykorzystanych do jej budowy oraz zapewnieniem poprawnej współpracy interfejsu sieciowego z płytami FPGA firmy Digilent. W tej grupie najważniejsze zmiany obejmowały: wydzielenie bloku zasilającego układ DP83865, obejmującego elementy LT1963EST-1.8 oraz LT1963EST-2.5 [57], zastosowanie zintegrowanego modułu transformatora separującego z gniazdem RJ-45 typu Pulse JK0-0036NL [80], spełniającego wymagania standardu 1000BASE-T, wykorzystanie układu generatora resetu z opcją manualną typu TS825CX5E [117]. Ustalanie oraz weryfikacja bieżących parametrów pracy interfejsu sieciowego dokonywana jest w bloku sygnalizacyjno-konfiguracyjnym, złożonym z 19 przełączników suwakowych oraz 5 diod LED. Wykorzystanie przełączników dwusekcyjnych pozwoliło wyeliminować konieczność jednorazowego definiowania adresu PHY przy montażu interfejsu sieciowego, jak to miało miejsce w przypadku wersji Fast Ethernet. W karcie gigabitowej istnieje możliwość dowolnej konfiguracji adresu przy jednoczesnej automatycznej zmianie polaryzacji diod sygnalizacyjnych LED. Opis funkcji poszczególnych diod sygnalizacyjnych oraz przełączników konfiguracyjnych przedstawiono odpowiednio w tabelach 3.4 i 3.5. Tab Opis funkcji diod sygnalizacyjnych karty Fast Ethernet. Nazwa D1 D2 D3 D4 D5 Funkcja ACTIVITY_LED: sygnalizacja błędu w stanie bezczynności (ang. Idle error) lub transferu pakietu. LINK10_LED: sygnalizacja poprawnego połączenia 10 Mb/s. LINK100_LED: sygnalizacja poprawnego połączenia 100 Mb/s. LINK1000_LED: sygnalizacja poprawnego połączenia 1000 Mb/s. DUPLEX_LED: sygnalizacja zestawienia poprawnego połączenia w trybie Full Duplex. 62

63 Tab Opis funkcji przełączników konfiguracyjnych w karcie Gigabit Ethernet. Numer Funkcja A Pozycja przełącznika B 1 Reset manualny Wybór napięcia zasilania stopnia I/O (sygnał VDD_SEL_STRAP ) Włączenie zegara interfejsu MAC (sygnał MAC_CLK_EN_STRAP) Włączenie automatycznej konfiguracji par interfejsu MDI (sygnał MDIX_EN_STRAP) Zezwolenie trybu wielowęzłowego (sygnał MULTI_EN_STRAP) Adres PHY bit 4 (sygnał PHYADDR4_STRAP) Typ interfejsu MAC (sygnał RGMII_SEL1) Typ interfejsu MAC (sygnał RGMII_SEL0) Częstotliwość zegara kontrolera MAC (sygnał CLK_MAC_FREQ) Adres PHY bit 3 (sygnał PHYADDR3_STRAP) Adres PHY bit 2 (sygnał PHYADDR2_STRAP) Adres PHY bit 1 (sygnał PHYADDR1_STRAP) Ręczna konfiguracja krosowania interfejsu MDI (sygnał MAN_MDIX_STRAP) Włączenie trybu niekompatybilnego z IEEE (sygnał NON_IEEE_STRAP) 2,5V 3,3V Wyjście CLK_TO_MAC nieaktywne Auto-MDIX wyłączone aktywne manualne ustawienia (sygnał MAN_MDIX_STRAP) Tryb jednowęzłowy (karta sieciowa - NIC) 0 1 Interfejs GMII Dla RGMII_SEL1 = 1 Interfejs RGMII HP CLOCK TO MAC = 25 MHz Tryb prosty (straight mode MDI) Zezwolenie na operacje kompatybilne z równoczesną blokadą operacji niekompatybilnych z IEEE Wyjście CLK_TO_MAC aktywne Automatyczna konfiguracja Auto-MDIX aktywna Tryb wielowęzłowy (przełącznik lub koncentrator) Interfejs RGMII o typie zależnym od wartości sygnału RGMII_SEL0 Dla RGMII_SEL1 = 1 Interfejs RGMII 3COM CLOCK TO MAC = 125 MHz Tryb skrosowany (crossover mode MDIX) Zezwolenie na operacje kompatybilne i niekompatybilne z IEEE 15 Adres PHY bit 0 (sygnał PHYADDR0_STRAP) Włączenie autonegocjacji (sygnał AN_EN_STRAP ) Autonegocjacja wyłączona Autonegocjacja włączona 17 Tryb komunikacji dupleksowej (sygnał DUPLEX_STRAP) Half Duplex Full Duplex 18 Ustawienie prędkości pracy (sygnał SPEED1_STRAP) Ustawienie prędkości pracy (sygnał SPEED0_STRAP) 0 1 Autonegocjacja wyłączona (AN_EN_STRAP = 0 ): Autonegocjacja włączona (AN_EN_STRAP = 1 ): Speed[1] Speed[0] Dozwolona prędkość Speed[1] Speed[0] Dozwolona prędkość 1 1 opcja zarezerwowana BASE-T, 10BASE-T BASE-T BASE-T BASE-TX BASE-T, 100BASE-TX BASE-T BASE-T, 100BASE-TX, 10BASE-T Generator resetu, wykorzystujący układ scalony TS825CX5E [117], odpowiada za wytworzenie impulsu o właściwej charakterystyce czasowo-napięciowej resetującego układ PHY. Pozwala on na wygenerowanie impulsu automatycznie po włączeniu zasilania, jak również poprzez manualną inicjalizację. Opracowana karta sieciowa Gigabit Ethernet została wyposażona 63

64 w 40-wyprowadzeniowy interfejs MII/GMII oraz 6-wyprowadzeniowy interfejs diagnostyczny. Rozmieszczenie sygnałów w złączu interfejsu MII/GMII pokazano na rysunku GND VDD 3.3V INT_N COL RX_ER RXD7 RXD5 RXD3 RXD1 RX_CLK TX_ER TXD7 TXD5 TXD3 TXD1 GTX_CLK MDC MAC_CLK_EN RESET_N TX_TCLK CRS RX_DV RXD6 RXD4 RXD2 RXD0 TX_CLK TX_EN TXD6 TXD4 TXD2 TXD0 MDIO CLK_TO_MAC Rys Numeracja wyprowadzeń złącza interfejsu MII/GMII karty Gigabit Ethernet. Na podstawie schematu ideowego zaprojektowano obwód drukowany interfejsu sieciowego Gigabit Ethernet. Ze względu na znaczny stopień skomplikowania układu oraz wysokie wymagania częstotliwościowe-funkcjonalne, niezbędne było użycie druku czterowarstwowego. Matryce poszczególnych warstw zawarto w pliku gigabit_ethernet_pcb.pdf, znajdującym się na załączonej płycie CD w katalogu \gigabit_ethernet_doc. Rys Prototyp zmontowanej karty Gigabit Ethernet (widok od góry) skala 1:1. Zdjęcie prototypu zmontowanej karty Gigabit Ethernet przedstawia rysunek Duża ilość elementów SMD użytych do budowy interfejsu sieciowego oraz wymagania funkcjonalne nie pozwoliły na zlokalizowanie podzespołów elektronicznych tylko po jednej stronie płytki drukowanej. Górna strona zawierała wszystkie elementy przewlekane (przełączniki konfiguracyjne i interfejsy komunikacyjne) oraz część elementów SMD, m.in.: układ PHY, jak również diody sygnalizacyjne LED. Na spodniej stronie płytki drukowanej zamontowane zostały przede wszystkim elementy związane z rozprowadzeniem i filtrowaniem zasilania układu PHY. Szczegółowe rozlokowanie elementów sygnalizacyjno-konfiguracyjnych karty zaprezentowano w pliku gigabit_ethernet_cfg.pdf, dostępnym na załączonej płycie CD. 64

65 4. Sprzętowa implementacja kontrolerów MAC dla sieci Ethernet 4.1. Wprowadzenie Spośród wielu istniejących obecnie technologii realizacji sieci lokalnych LAN (ang. Local Area Network) zdecydowanie najbardziej popularną jest Ethernet. Historycznie termin ten pojawił się już w latach 70-tych ubiegłego wieku w rozwiązaniu sieci LAN opracowanym przez laboratorium badawcze firmy Xerox. To właśnie on stał się pierwowzorem dla pierwszej wersji specyfikacji IEEE [40], wydanej w roku Od tego czasu standard przeszedł dynamiczny rozwój, opracowano szereg jego modyfikacji, wprowadzających coraz większe prędkości transmisji, jak również obsługę nowych mediów komunikacyjnych. Gwałtowne rozpowszechnienie standardu Ethernet i jego niewątpliwy sukces rynkowy wyniknęły głównie z właściwego doboru stosunku parametrów technicznych do kosztu zakupu wszystkich elementów wchodzących w skład infrastruktury sieci bazującej na tym standardzie [20]. Ethernet oferuje bowiem w atrakcyjnej cenie (w porównaniu do innych standardów sieciowych, takich jak np. Infiniband, czy też Fibre Channel) bardzo dobre przepustowości, a także odpowiednie dopasowanie do obsługi ruchu opartego o dominujący obecnie protokół IP (ang. Internet Protocol) [72]. Negatywnym skutkiem poszukiwania kompromisu ekonomicznego jest zredukowanie do niezbędnego minimum funkcjonalności układów PHY, szerzej opisanych w rozdziale 3.5. W zdecydowanej większości przypadków odpowiadają one jedynie za dopasowanie do standardu warstwy fizycznej kanału transmisyjnego, począwszy od interfejsu MII lub GMII. Całość zadań, związanych z przygotowaniem pakietów i ramek do transmisji oraz analizą ich zawartości po odebraniu danych przez interfejs sieciowy, jest realizowana przez procesor ogólnego przeznaczenia. Przekłada się to na znaczny wzrost obciążenia, a tym samym na spadek efektywności całego systemu komputerowego. Zjawisko takie możemy zaobserwować szczególnie w przypadku standardowych komputerów osobistych. O ile trudno jest dostrzec wpływ obsługi komunikacji sieciowej na obciążenie przy komunikacji z prędkością 100Mb/s (co ma związek z bardzo dużą wydajnością dostępnych obecnie procesorów), to przy szybkości 1Gb/s jest on już wyraźnie dostrzegalny. Ponadto degradacja wydajności obliczeniowej, związana z koniecznością programowej obsługi stosu protokołów TCP/IP, wzrasta nie tylko ze zmianą szybkości przesyłu danych, lecz również w wypadku zmniejszania się rozmiaru oraz przerw pomiędzy pojedynczymi pakietami [38]. W konsekwencji, nawet przy wykorzystaniu bardzo wydajnych procesorów, może dojść do przypadków blokady obsługi sieci i utraty danych. Przykładowe statystyki obciążenia procesora w zależności od rozmiaru i odstępu pomiędzy pakietami zaprezentowano na rysunku 4.1 [39]. 65

66 Obciążenie procesora CPU1 stacji odbierającej [%] Utracone pakiety [%] 100 S yskonnect P4DP6 64 bit 66 MHz Odstęp pomiędzy kolejnymi pakietami [μs] S yskonnect P4DP6 64 bit 66 MHz Rozmiar pakietu 50 bajtów 100 bajtów 200 bajtów 400 bajtów 600 bajtów 800 bajtów 1000 bajtów 1200 bajtów 1400 bajtów 1472 bajty Odstęp pomiędzy kolejnymi pakietami [μs] Rys Procentowa utrata pakietów wraz z utylizacją procesora w funkcji rozmiaru oraz odstępu pomiędzy poszczególnymi pakietami przy wykorzystaniu karty SysKonnect NIC 64 bit 66 MHz PCI współpracującej z płytą główną SuperMicro P4DP6 [39]. W krytycznym przypadku, kiedy badany serwer odbierał bardzo małe ramki nadawane w krótkich odstępach czasu, obciążenie procesora CPU1 osiągało wartość 100%. W efekcie tego ponad 60% ramek nie zostało prawidłowo przetworzonych. Jest to sytuacja niedopuszczalna dla systemów komputerowych świadczących usługi o wysokim poziomie dostępności bądź też zapewniających bezpieczeństwo i integralność danych przesyłanych w sieciach teleinformatycznych. Dla takich właśnie zastosowań niezbędnym okazało się poszukiwanie rozwiązań pozwalających na odciążenie procesorów ogólnego przeznaczenia z konieczności obsługi komunikacji sieciowej poprzez implementację stosu protokołów TCP/IP oraz funkcjonalności kontrolerów MAC w dedykowanych układach sprzętowych ASIC. W przypadku seryjnie produkowanych serwerów karty NIC wyposażone w sprzętowe wspomaganie obsługi sieci określa się jako TOE NIC (ang. TCP/IP Offload Engine Network Interface Card) [106]. Ze względu na swą wysoką cenę nie stały się one rozwiązaniem powszechnym i w zdecydowanej większości sytuacji problemy z przeciążaniem jednostek obliczeniowych niweluje się poprzez zastosowanie nowych, bardziej wydajnych procesorów ogólnego przeznaczenia. Analogiczny problem sposobu obsługi komunikacji sieciowej stanowił punkt wyjścia do opracowania koncepcji implementacji systemu bezpieczeństwa Firewall w układach logiki reprogramowalnej FPGA. Z jednej strony możliwym byłoby wykorzystanie rozwiązań programowych, tak, aby skrócić czas realizacji całego projektu i skoncentrować się na jego zasadniczym elemencie sprzętowym klasyfikatorze pakietów. Z drugiej strony należałoby wziąć pod 66

67 uwagę wpływ wszystkich komponentów tak złożonego systemu, jakim jest zapora ogniowa, na globalną wydajność przetwarzania danych. Ogromny potencjał i elastyczność układów FPGA dawały szansę na opracowanie kompleksowej sprzętowej implementacji pełnego systemu Firewall w jednym układzie reprogramowalnym, począwszy od kontrolerów MAC, a skończywszy na modułach przetwarzających politykę bezpieczeństwa. Droga ta, choć bardziej pracochłonna, pozwalała na realizację urządzenia, w którym każdy z najdrobniejszych elementów mógł być zoptymalizowany zarówno pod kątem wydajności i stabilności działania, jak również ilości zasobów niezbędnych do jego realizacji. Co więcej, proporcje pomiędzy tymi czynnikami, mogły być na bieżąco kształtowane w zależności od wymagań stawianych przez potencjalny obszar zastosowań. Biorąc pod uwagę powyższe przesłanki, autor niniejszej rozprawy zdecydował się na kompleksową implementację komponentów odpowiedzialnych za obsługę komunikacji sieciowej, przy zachowaniu pełnej zgodności z zaleceniami specyfikacji IEEE Założono, że przeniesienie warstwy 2 i 3 modelu ISO/OSI do układu FPGA stwarza realne szanse na przyspieszenie procesu weryfikacji danych poprzez zaporę ogniową. WARSTWY WYŻSZE WARSTWY MODELU REFERENCYJNEGO OSI APLIKACJI PREZENTACJI SESJI WARSTWA TRANSPORTOWA WARSTWA SIECIOWA LLC LOGICAL LINK CONTROL MAC CONTROL (opcjonalnie) MAC MEDIA ACCESS CONTROL Sprzętowy kontroler MAC TRANSPORTOWA SIECIOWA ŁĄCZA DANYCH FIZYCZNA MAU MDI AUI PLS PMA DOPASOWANIE MDI AUI MII PLS PMA DOPASOWANIE MDI MII PCS PMA PMD DOPASOWANIE MDI GMII PCS PMA PMD MEDIUM MEDIUM MEDIUM MEDIUM 1 Mb/s, 10Mb/s 10Mb/s 100Mb/s 1000Mb/s AUI = ATTACHMENT UNIT INTERFACE MDI = MEDIUM DEPENDENT INTERFACE MII = MEDIA INDEPENDENT INTERFACE GMII = GIGABIT MEDIA INDEPENDENT INTERFACE MAU = MEDIUM ATTACHMENT UNIT PLS = PHYSICAL LAYER SIGNALING PCS = PHYSICAL CODING SUBLAYER PMA = PHYSICAL MEDIUM ATTACHMENT PHY = PHYSICAL LAYER DEVICE PMD = PHYSICAL MEDIUM DEPENDENT Rys Lokalizacja sprzętowego kontrolera MAC w warstwowym modelu ISO/OSI sieci Ethernet (na podstawie [40]). Implementacja sprzętowa standardu sieci Ethernet sprowadza się do wdrożenia funkcjonalności opisanych specyfikacją IEEE 802.3, począwszy od podwarstwy dostępu do medium MAC, a skończywszy na wybranych elementach warstwy sieciowej i transportowej. Graficzną ilustrację umiejscowienia sprzętowego kontrolera MAC w warstwowym schemacie ISO/OSI przedstawiono na rysunku

68 4.2. Struktura ramki Ethernet Standard IEEE definiuje dwa główne formaty ramek w sieciach Ethernet: ramki podstawowe oraz ramki znakowane (ang. Tagged Frame). Podstawowa ramka Ethernet (Rys. 4.3) złożona jest z dziewięciu pól: preambuły, znacznika początku ramki SFD (ang. Start Frame Delimiter), adresu docelowego i źródłowego (ang. Destination and Source Address), pola długości lub typu protokołu ramki (ang. Length/Type), danych klienta MAC, opcjonalnego pola dopełnienia (ang. Pad), sekwencji kontrolnej FCS (ang. Frame Check Sequence) oraz pola rozszerzenia (tylko dla trybu 1000 Mb/s Half Duplex). 7 Oktetów 1 Oktet 6 Oktetów 6 Oktetów 2 Oktety Oktetów 4 Oktety PREAMBUŁA POLE STARTU RAMKI (SFD) ADRES DOCELOWY ADRES ŹRÓDŁOWY DŁUGOŚĆ/TYP DANE KLIENTA MAC DOPEŁNIENIE (PAD) SUMA KONTROLNA (FCS) ROZSZERZENIE (EXTENTION) Porządek nadawania bajtów ramki: od góry do dołu LSB b 0 b 7 MSB Porządek wysyłania poszczególnych bitów: od LSB do MSB Rys Struktura podstawowej ramki Ethernet. Wszystkie pola, za wyjątkiem danych klienta, PAD oraz EXTENTION, mają ściśle ustaloną, niezmienną długość. Poszczególne pola ramki przesyłane są w porządku od góry do dołu, czyli od preambuły do FCS (ewentualnie EXTENTION). Pojedyncze bity w każdym z pól są natomiast transmitowane, począwszy od najmniej znaczącego bitu LSB (ang. Least Significant Bit), aż do najbardziej znaczącego MSB (ang. Most Significant Bit). Wartości graniczne parametrów w zależności od szybkości pracy, zebrane w tabeli 4.1, dotyczą ramki Ethernet, złożonej ze wszystkich pól z pominięciem preambuły (od adresu docelowego do sekwencji kontrolnej FCS włącznie). 68

69 Tab Graniczne wartości parametrów ramki Ethernet w zależności od szybkości pracy [40]. Parametr (nazwa używana w standardzie) Szybkość 10 Mb/s Szybkość 100 Mb/s Szybkość 1000 Mb/s Okno czasowe (slottime) 512 okresów bitowych 512 okresów bitowych 4096 okresów bitowych Odstęp międzyramkowy (interframegap) 9,6 μs 0,96 μs 0,096 μs Limit prób dostępu (attemptlimit) Limit ponowień algorytmu Backoff (backofflimit) Długość sygnału rozgłaszającego kolizję (jamsize) 32 bity 32 bity 32 bity Maksymalna długość ramki podstawowej (maxuntaggedframesize) Minimalna długość ramki (minframesize) 1518 oktetów 1518 oktetów 1518 oktety 512 bitów (64 oktety) 512 bitów (64 oktety) 512 bitów (64 oktety) Limit nadawania w trybie burst (burstlimit) nie używane nie używane bitów Charakterystyka pól składowych ramki podstawowej Z punktu widzenia funkcjonowania sieci opartej o standard specyfikacji IEEE każde z dziewięciu pół składowych ramki Ethernet pełni istotną rolę: a) preambuła - pole to o długości 7 bajtów wykorzystywane jest do stabilizacji warunków w medium transmisyjnym oraz zapewnienia poprawnej synchronizacji układu PHY z odbieranymi danymi. Preambuła składa się z następującej sekwencji bitów: Są one nadawane w kolejności od lewej do prawej. Jeżeli w trakcie nadawania pola zostanie wykryta kolizja, proces transmisji powinien być kontynuowany aż do momentu wysłania ostatniego bitu sekwencji preambuły; b) pole SFD - składa się z sekwencji bitów Jest ono nadawane niezwłocznie po zakończeniu transmisji preambuły, sygnalizując początek ramki Ethernet. Jeżeli w trakcie nadawania pola zostanie wykryta kolizja, proces transmisji powinien być kontynuowany do momentu wysłania ostatniego bitu sekwencji SFD; c) pola adresów źródłowego i docelowego - adres docelowy zawiera informację o miejscu dokąd powinna dotrzeć dana ramka, zaś adres źródłowy o stacji, która ramkę wysłała. Strukturę wewnętrzną pól adresowych przedstawiono na rysunku 4.4. I/G U/L 46-bitowy adres I/G typ adresu ( 0 - indywidualny, 1 - grupowy) U/L typ zarządzania ( 0 - administrowany globalnie, 1 - administrowany lokalnie) Rys Struktura pól adresowych ramki Ethernet. 69

70 Pole każdego z adresów o długości 48 bitów podzielone jest na następujące części: typ adresu (I/G) najmniej znaczący bit pola adresu docelowego informuje, czy dany adres należy do puli indywidualnej czy też grupowej. Dla adresu źródłowego bit ten jest zarezerwowany, a jego wartość wynosi 0. Adres typu indywidualnego dotyczy zawsze pojedynczej stacji, adres grupowy natomiast określa zbiór stacji w danej sieci. Istnieją trzy jego rodzaje: o Multicast-Group Address określa podgrupę logicznie powiązanych ze sobą stacji w danej sieci LAN, o Broadcast Address definiuje zbiór wszystkich stacji w danej sieci LAN. Pole adresu docelowego dla tego typu składa się z samych jedynek; typ zarządzania (U/L) jeżeli bit ten ma wartość 0, wówczas adres należy do grupy globalnie (bądź też uniwersalnie) administrowanej. W przypadku, gdy wartość bitu wynosi 1, adres należy do puli administrowanej lokalnie; d) pole długości/typu protokołu (L/T) - pole L/T może mieć dwa znaczenia w zależności od wartości, jaka w nim występuje: jeżeli jest ona mniejsza bądź równa parametrowi maxuntaggedframesize pomniejszonemu o 18 bajtów (suma długości pól adresowych, L/T oraz CRC), wówczas pole L/T zawiera informację o długości ramki wyrażoną w bajtach, jeżeli jest większa lub równa 1536 (x0600 hexadecymalnie), wówczas pole L/T opisuje typ protokołu klienta MAC. W tej interpretacji klient MAC odpowiada za właściwe określenie rozmiaru ramki oraz obsługę procedury użycia pola PAD; e) pole danych oraz PAD - pole danych użytkownika MAC zawiera dowolną sekwencję bajtów o maksymalnej długości równej maxuntaggedframesize 18 bajtów (suma długości pól adresowych, L/T oraz CRC). Z kolei minimalny rozmiar tego pola jest wymagany dla poprawnego funkcjonowania protokołu wielodostępu ze śledzeniem stanu dostępności medium transmisyjnego CSMA/CD (ang. Carrier Sense Multiple Access with Collision Detect). W razie potrzeby (dla danych krótszych od 46 bajtów) stosowane jest uzupełnianie pola do minimalnego wymaganego standardem rozmiaru. Do tego celu wykorzystuje się dodatkowy element ramki Ethernet sekwencję PAD; f) sekwencja kontrolna FCS - zawiera 4-bajtowy wynik obliczenia cyklicznego kodu nadmiarowego CRC (ang. Cyclic Redundancy Check) dla każdej z transmitowanych ramek w celu zweryfikowania poprawności danych na etapie odbioru. Do wyliczania wartości CRC używane są pola: adres źródłowy i docelowy, L/T, dane oraz PAD. Wielomian generacyjny ma następującą postać:. (4.1) 70

71 Wynik obliczenia 32-bitowego kodu CRC zawartego w polu FCS jest transmitowany w porządku od bitu x 31 do bitu x 0, g) pole EXTENTION - sekwencja bitów rozszerzenia nadawana po polu FCS w trybie 1000 Mb/s Half Duplex. Jej długość jest zmienna i zawiera się w granicach od 0 do slottime-minframesize. Zawartość pola EXTENTION nie jest uwzględniana do obliczania wartości FCS Format ramki znakowanej W stosunku do ramki podstawowej, opisanej w rozdziale 4.2.1, ramka znakowana (Rys. 4.5) zawiera dodatkowy 4-bajtowy blok, definiowany jako QTag Prefix, wstawiony pomiędzy pola adresu źródłowego oraz L/T klienta MAC. Złożony jest on z dwóch elementów: 2-bajtowego pola o stałej wartości identyfikującej protokół 802.1Q, 2-bajtowego pola informacji kontrolnej. 7 Oktetów 1 Oktet 6 Oktetów PREAMBUŁA POLE STARTU RAMKI (SFD) ADRES DOCELOWY Pierwszy oktet Drugi oktet QTag Prefix 6 Oktetów 2 Oktety 2 Oktety ADRES ŹRÓDŁOWY DŁUGOŚĆ/TYP= 802.1QTagType INFORM. KONTROLNE ZNACZNIKA user priority CFI VLAN IDENTIFIER (VID, 12 bitów) Pierwszy oktet Drugi oktet Porządek nadawania bajtów ramki: od góry do dołu 2 Oktety Oktetów 4 Oktety DŁUGOŚĆ/TYP KLIENTA MAC DANE KLIENTA MAC DOPEŁNIENIE (PAD) SUMA KONTROLNA (FCS) ROZSZERZENIE (EXTENTION) Informacja kontrolne znacznika (ang. Tag Control Information) LSB b 0 b 7 MSB Porządek wysyłania poszczególnych bitów: od LSB do MSB Rys Struktura znakowanej ramki Ethernet. Za polem QTag Prefix, wprowadzającym przesunięcie o 4 bajty, wysyłane są pozostałe pola ramki analogicznie jak w wersji podstawowej. Całkowita długość ramki w związku z dodaniem prefiksu wzrasta zatem o 4 bajty. 71

72 4.3. Sprzętowy kontroler MAC - wersja Fast Ethernet W związku z wykorzystywaniem do prac badawczych różnych konfiguracji platform badawczych z układami FPGA oraz różnych wersji kart sieciowych, szerzej opisanych w rozdziale 3.5, zdecydowano o zrealizowaniu dwóch wersji sprzętowych kontrolerów MAC, przeznaczonych do obsługi standardów Fast oraz Gigabit Ethernet, przy czym wersja Gigabit Ethernet wpiera również niższe prędkości przesyłu danych. Takie podejście uniezależniło ciągłość procesu projektowego od typu płyty testowo-uruchomieniowej. Co więcej, dysponując dwoma implementacjami kontrolera, możliwym stał się ich precyzyjny dobór do aktualnych potrzeb narzucanych przez docelowy obszar zastosowań systemu zabezpieczającego (wersja Fast Ethernet alokuje kilkukrotnie mniejszą ilość zasobów sprzętowych układu FPGA) Schemat blokowy Sprzętowy kontroler MAC w wersji Fast Ethernet, którego poglądowy schemat zaprezentowano na rysunku 4.6, składa się z trzech podstawowych bloków: toru odbiorczego RX, toru transmisyjnego TX oraz modułu kontrolnego [108]. Kontroler MAC Karta sieciowa Interfejs MII Tor odbiorczy RX (moduł eth_rx) Tor nadawczy TX (moduł eth_tx) Blok kontrolny (moduł eth_control) Interfejs Firewalla Rys Schemat blokowy sprzętowego kontrolera MAC w wersji Fast Ethernet. Zadaniem kontrolera jest przede wszystkim zapewnienie poprawnej komunikacji Firewalla w sieci zgodnej ze standardem Fast Ethernet. W zależności od aktualnego trybu pracy, kontroler inicjuje poszczególne fazy nawiązywania połączenia bądź też odbierania danych, obsługując niezbędne mechanizmy metody dostępowej typu CSMA/CD. Funkcjonalność każdego z elementów kontrolera MAC została zdefiniowana za pomocą języka opisu sprzętu VHDL. Szczegółowa struktura kontrolera MAC, uwzględniająca wewnętrzne linie sygnałowe oraz wyprowadzenia poszczególnych interfejsów została przedstawiona na rysunku 4.7. W wersji Fast Ethernet posiada on trzy grupy połączeń z modułami zewnętrznymi: interfejs MII układu PHY, interfejs komunikacyjny Firewalla oraz interfejs konfiguracyjny. Dokładny opis funkcji poszczególnych sygnałów kontrolera zawarto w dodatku A, punkt

73 INTERFEJS PHY MII KONFIGURACJA phy_rx_clk phy_rx_dv phy_rx_error phy_rx_data(3:0) phy_tx_clk phy_tx_en phy_tx_data(3:0) phy_col phy_crs phy_int_n phy_mdc phy_mdio phy_reset_n r_rx_mac_address(47:0) r_rx_multicast_en r_rx_promiscous_en r_tx_crc_en r_tx_padding_en r_mii_config(15:0) moduł eth_mac.vhd phy_rx_clk phy_rx_dv phy_rx_error phy_rx_data(3:0) eth_rx r_rx_mac_address(47:0) r_rx_multicast_en r_rx_promiscous_en rx_enable rx_pause rx_data_valid rx_data(7:0) rx_active rx_ok rx_error rx_frame_size(10:0) reset eth_tx phy_tx_clk half_duplex phy_tx_en tx_enable phy_tx_data(3:0) tx_running phy_col tx_retransmit phy_crs tx_data(7:0) tx_data_ack r_tx_crc_en tx_ok r_tx_padding_en tx_error tx_frame_size(10:0) reset eth_control phy_int_n eth_control_link phy_mdc eth_control_speed phy_mdio eth_control_half_duplex sys_clk r_mii_config(15:0) reset eth_mac_rx_enable eth_mac_rx_pause eth_mac_rx_data(7:0) eth_mac_rx_data_valid eth_mac_rx_active eth_mac_rx_ok eth_mac_rx_error eth_mac_rx_frame_size(10:0) eth_mac_tx_enable eth_mac_tx_active eth_mac_tx_retransmit eth_mac_tx_data(7:0) eth_mac_tx_data_ack eth_mac_tx_ok eth_mac_tx_error eth_mac_tx_frame_size(10:0) eth_mac_ready sys_clk reset INTERFEJS FIREWALLA <= '0' when reset = reset_level else '1'; Rys Struktura wewnętrzna modułu eth_mac w wersji Fast Ethernet Tor odbiorczy Rx W skład toru odbiorczego w wersji Fast Ethernet, którego schemat blokowy zaprezentowano na rysunku 4.8, wchodzi pięć modułów: eth_rx_bitreceiver, eth_rx_datadecap, eth_rx_recaddress, eth_rx_crc i eth_rx_tlm. Realizują one wspólnie procedurę odczytu danych z interfejsu sieciowego zgodnie z algorytmem wyspecyfikowanym w standardzie IEEE [40]. Funkcje oraz sposób działania poszczególnych modułów zostaną szerzej opisane w dalszej części niniejszego rozdziału. Tor odbiorczy RX Karta sieciowa Interfejs MII eth_rx_bitreceiver eth_rx_datadecap eth_rx_recaddress eth_rx_tlm Dane Konfiguracja Interfejs Firewalla Sygnały kontrolne eth_rx_crc Rys Schemat blokowy toru odbiorczego RX. 73

74 Szczegółowy schemat strukturalny toru RX (moduł eth_rx) w wersji Fast Ethernet, uwzględniający wewnętrzne linie sygnałowe oraz wyprowadzenia poszczególnych interfejsów, przedstawiono na rysunku 4.9. Posiada on trzy grupy połączeń z blokami zewnętrznymi: interfejs MII układu PHY (część odbiorcza), interfejs komunikacyjny Firewalla oraz interfejs konfiguracyjny. Opis funkcji poszczególnych sygnałów modułu eth_rx zamieszczono w dodatku A, punkt 8.2. moduł eth_rx.vhd Konwersja nible->bajty Proces 4-bajtowego opóźniania danych (usuwanie CRC) eth_rx_bitreceiver eth_rx_datadecap phy_rx_clk phy_rx_dv phy_rx_error phy_rx_data(3:0) rx_enable rx_pause reset r_rx_promiscous_en r_rx_multicast_en r_rx_mac_address(47:0) phy_rx_clk phy_rx_dv phy_rx_error phy_rx_data(3:0) rx_enable rx_pause reset rx_fsm_idle rx_fsm_start_data rx_fsm_data rx_fsm_finished rx_frame_finished rx_data_out_valid rx_data_out(7:0) rx_nible_counter(11:0) rx_nible_frame_size(11:0) phy_rx_clk rx_len_or_type rx_fsm_idle rx_len_or_type_field(15:0) rx_fsm_data rx_fsm_finished rx_frame_finished rx_data_out_valid rx_data_out(7:0) rx_nible_counter(11:0) reset rx_frame_size(10:0) rx_data(7:0) rx_data_valid rx_active rx_ok rx_error eth_rx_crc phy_rx_clk rx_fsm_idle rx_fsm_start_data rx_fsm_data rx_fsm_finished rx_frame_finished rx_data_out(7:0) rx_nible_counter(11:0) reset rx_crc_ok eth_rx_recaddress phy_rx_clk rx_fsm_idle rx_fsm_data rx_data_out_valid rx_data_out(7:0) rx_nible_counter(11:0) r_rx_promiscous_en r_rx_multicast_en r_rx_mac_address(47:0) reset rx_address_ok eth_rx_tlm phy_rx_clk rx_fsm_idle rx_fsm_start_data rx_fsm_data rx_fsm_finished rx_frame_finished rx_nible_counter(11:0) rx_address_ok rx_crc_ok rx_len_or_type rx_len_or_type_field(15:0) reset rx_active rx_ok rx_error Rys Struktura wewnętrzna modułu eth_rx.vhd w wersji Fast Ethernet. Pierwszy etap procedury odbioru realizowany jest przez moduł eth_rx_bitreceiver, którego zadaniem jest przetwarzanie informacji otrzymywanych z układu PHY w celu wykrycia poszczególnych pól ramki Ethernet oraz konwersji odbieranych danych z postaci nibli do pojedynczych bajtów. Wewnętrzny automat stanów generuje dla pozostałych modułów toru RX sygnały o wykryciu znacznika SFD, zakończenia ramki oraz walidacji odbieranych danych. Dodatkową funkcją zaimplementowaną w module jest pomiar długości ramek przeprowadzany w celu weryfikowania ich poprawności. Rysunek 4.10 przedstawia przebiegi czasowe sygnałów modułu eth_rx_bitreceiver w trakcie odbierania testowej ramki Ethernet. 74

75 Dane z układu PHY Sygnalizacja początku ramki Sygnalizacja kooca ramki Dane wyjściowe Długośd ramki Rys Przebiegi czasowe sygnałów modułu eth_rx_bitreceiver dla testowej ramki Ethernet. Odbierane dane, przetworzone do postaci bajtowej, trafiają do modułu eth_rx_datadecap, odpowiadającego za detekcję zawartości pola L/T, zarówno dla ramek w formacie podstawowym, jak również dla ramek znakowanych. Jeżeli wartość pola L/T niesie ze sobą informację o długości ramki, sygnał rx_len_or_type przyjmuje wartość 0. W przeciwnym wypadku pozostaje on w wysokim stanie logicznym. Odczytana zawartość pola L/T jest dla każdego z tych przypadków odzwierciedlona stanem sygnału rx_len_or_type_field. Kontekst pola L/T Wartośd pola L/T Rys Przebiegi czasowe sygnałów modułu eth_rx_datadecap dla przykładowej ramki Ethernet. W zaprezentowanym na rysunku 4.11 przykładzie sygnał rx_len_or_type jest w stanie wysokim, zatem oznacza to, że pole L/T określa typ protokołu ramki Ethernet. Wartość sygnału rx_len_or_type_field wynosi x 0806, czyli odebrano ramkę ARP. Tor odbiorczy został zaprojektowany w sposób pozwalający na manualną konfigurację obsługi ramek rozgłoszeniowych oraz ramek o adresie docelowym MAC różnym od przypisanego do danego kontrolera. Funkcje te realizuje moduł eth_rx_recaddress. Przetwarzanie wszystkich przychodzących ramek, z pominięciem analizy zgodności adresów MAC (tzw. tryb promiscous), aktywowane jest ustawieniem wysokiego stanu logicznego na linii r_rx_promiscous_en. Z kolei akceptacja ramek rozgłoszeniowych (tzw. tryb multicast) włączana jest sygnałem r_rx_multicast_en. W wypadku wyłączenia obu trybów dodatkowych, tor RX odbiera jedynie ramki o adresie MAC zgodnym z wartością sygnału konfiguracyjnego r_rx_mac_address. Jeżeli wykryta zostanie ramka o poprawnym adresie moduł aktywuje linię rx_address_ok. Rysunek 4.12 przedstawia przykładowe przebiegi czasowe sygnałów modułu eth_rx_recaddress w trakcie odbierania ramki Ethernet. 75

76 Konfiguracji typów obsługiwanych ramek Sygnał detekcji poprawnie zaadresowanej ramki Rys Przebiegi czasowe sygnałów modułu eth_rx_recaddress dla przykładowej ramki Ethernet. Ponieważ sygnały r_rx_promiscous_en oraz r_rx_multicast_en są w stanie wysokim, tor odbiorczy RX akceptuje wszystkie nadchodzące ramki. Stąd też wynika fakt aktywowania sygnału rx_address_ok niezwłocznie po rozpoczęciu odbierania ramki. Do jednoznacznego zweryfikowania poprawności każdej z odebranych ramek niezbędne jest wyliczenie cyklicznego kodu namiarowego CRC. Operacje takie wykonuje moduł eth_rx_crc. Jego funkcjonowanie opiera się na nocie aplikacyjnej [129]. Jeżeli wartość kodu CRC, obliczona dla pól - począwszy od adresu docelowego, a skończywszy na sekwencji kontrolnej FCS (włącznie) - jest równa residuum x C704DD7B heksadecymalnie, odebraną ramkę należy uznać za poprawną [129]. Stan taki sygnalizowany jest wysokim poziomem logicznym na wyjściu rx_crc_ok. Przykładowe przebiegi czasowe sygnałów modułu eth_rx_crc w trakcie obliczania kodu CRC dla odbieranej ramki Ethernet zaprezentowano na rysunku Odbierane bajty danych analizowanej ramki Potwierdzenie poprawności kodu CRC Rys Przebiegi czasowe sygnałów modułu eth_rx_crc dla przykładowej ramki Ethernet. Moduł eth_rx_tlm analizuje poszczególne sygnały kontrolne z bloków funkcjonalnych toru RX i na ich podstawie generuje ostateczną informację o poprawności odbieranych ramek. Pod uwagę brane są następujące czynniki: poprawność adresu MAC, zgodność długości ramki z wymaganiami definiowanymi przez standard IEEE 802.3, zgodność kodu CRC odebranych danych z sekwencją FCS. Jeżeli wszystkie powyższe punkty są spełnione, moduł eth_rx_tlm po zakończeniu procesu odbierania ramki (wyjście rx_active w stanie niskim) aktywuje sygnał rx_ok. W przeciwnym wypadku linia rx_error sygnalizuje błąd odbioru, przyjmując wartość logiczną 1. Rysunek 4.14 przedstawia przebiegi czasowe sygnałów modułu eth_rx_tlm w trakcie odbierania testowej ramki Ethernet. 76

77 Adres Mac zgodny Sekwencja CRC zgodna z FCS Długośd poprawna Informacja o poprawnym zweryfikowaniu ramki Rys Przebiegi czasowe sygnałów modułu eth_rx_tlm dla przykładowej ramki Ethernet Tor nadawczy TX Zadaniem toru nadawczego, którego schemat blokowy zaprezentowano na rysunku 4.15, jest odpowiednie przygotowanie ramki Ethernetowej na podstawie danych przekazanych przez klienta warstwy MAC [108]. Tor nadawczy TX Karta sieciowa Interfejs MII eth_tx_bittran eth_tx_crc eth_tx_defer eth_rx_tlm Dane Konfiguracja Interfejs Firewalla Sygnały kontrolne eth_tx_backoff Rys Schemat blokowy toru odbiorczego TX. Proces ten obejmuje dołożenie niezbędnych pól, takich jak: preambuła, pole startu ramki SFD, w razie konieczności rozszerzenie ramki do minimalnej dopuszczalnej długości (ang. padding), a na koniec obliczenie sumy kontrolnej CRC w celu zabezpieczenia danych przed przekłamaniem. Specyfikacja IEEE [40] określa precyzyjnie algorytm funkcjonowania toru nadawania (Rys. 4.16), który stał się punktem wyjścia do opracowania implementacji sprzętowej. W realizacji praktycznej modelowi proceduralnemu odpowiada zestaw pięciu modułów opisanych za pomocą języka VHDL: eth_tx_bittran, eth_tx_crc, eth_tx_defer, eth_tx_backoff oraz eth_tx_tlm. Funkcjonują one zgodnie z algorytmem CSMA/CD, realizując dwie podstawowe grupy zadań [111] zdefiniowanych w standardzie: enkapsulację danych klienta MAC, obejmującą dołożenie niezbędnych pól, obliczenie sumy kontrolnej CRC moduły eth_tx_bittran oraz eth_tx_crc, 77

78 zarządzanie transmisją, obejmujące zachowywanie niezbędnych opóźnień czasowych, wykrywanie i obsługiwanie kolizji, ponawianie transmisji z wykorzystaniem mechanizmów backoff, rozszerzenia ramek oraz obsługę trybu burst mode - moduły eth_tx_tlm, eth_tx_backoff oraz eth_tx_defer. TransmitFrame Nie Transmisja możliwa? Tak Składanie ramki Tak Kontynuacja syg. burst Nie Tak Opóźnianie ramki (deffering) Nie Wysłanie syg. jam Start transmisji Inkrementacja licznika prób transmisji Czy halfduplex i collisiondetect? Tak Nie Tak Późna kolizja i prędkość > 100Mb/s Nie Transmisja zakończona? Nie Tak Za dużo prób transmisji? Nie Obliczanie backoff Oczekiwanie przez czas równy backoff Zakończono: transmitdisabled Zakończono: transmitok Zakończono: excessivecollisionerror Zakończono: excessivecollisionerror tylko dla trybu half duplex > 100Mb/s Rys Algorytm funkcjonowania toru nadawczego TX (na podstawie [40]). Szczegółowy schemat strukturalny toru TX w wersji Fast Ethernet, uwzględniający wewnętrzne linie sygnałowe oraz wyprowadzenia poszczególnych interfejsów, przedstawiono na rysunku Moduł eth_tx posiada trzy grupy połączeń z blokami zewnętrznymi: interfejs MII układu PHY (część nadawcza), interfejs komunikacyjny Firewalla oraz interfejs konfiguracyjny. Szczegółowy opis funkcji poszczególnych linii interfejsów modułu zamieszczono w dodatku A, punkt

79 tx_data_ack_process moduł eth_rx.vhd tx_retransmit_process eth_tx_tlm tx_active tx_ok tx_fsm_start_backoff tx_fsm_start_crc tx_fsm_start_jam phy_tx_en_process tx_data_ack tx_retransmit tx_ok tx_running tx_enable tx_frame_size(10:0) tx_error tx_data(7:0) reset half_duplex Interfejs Firewall a tx_fsm_start_padding tx_fsm_start_data reset tx_fsm_start_sfd tx_igp_cnt_eq_ifs2 tx_fsm_start_preamble tx_igp_cnt_eq_ifs1 tx_fsm_start_ifs2 tx_igp_cnt_eq_ifs tx_fsm_start_ifs1 tx_eq_in_frame tx_fsm_start_ifs tx_eq_min_frame tx_fsm_start_set_defer tx_eq_crc tx_fsm_start_idle tx_eq_jam tx_fsm_backoff tx_eq_sfd tx_fsm_crc tx_eq_preamble tx_fsm_jam tx_attempt_cnt_eqlimit tx_fsm_padding tx_attempt_cnt_eq0 tx_fsm_data tx_backoff_cnt_eq0 tx_fsm_sfd r_tx_padding_en tx_fsm_preamble r_tx_crc_en tx_fsm_ifs2 tx_enable tx_fsm_ifs1 phy_tx_col tx_fsm_ifs phy_tx_crs tx_fsm_set_defer half_duplex tx_fsm_idle phy_tx_clk phy_tx_clk phy_tx_en phy_col phy_crs phy_tx_data(3:0) r_tx_crc_en r_tx_padding_en Interfejs MII PHY Interfejs konfiguracyjny eth_tx_bittran phy_tx_clk phy_tx_data(3:0) half_duplex tx_eq_preamble tx_fsm_idle tx_eq_sfd tx_fsm_preamble tx_eq_jam tx_fsm_sfd tx_eq_crc tx_fsm_data tx_eq_min_frame tx_fsm_padding tx_eq_in_frame tx_fsm_jam tx_nible_counter(11:0) tx_fsm_crc tx_fsm_start_preamble tx_fsm_start_data tx_fsm_start_jam tx_fsm_start_crc tx_data(7:0) tx_crc_data(3:0) tx_nible_frame_size(11:0) reset Konwersja nible->bajty eth_tx_crc phy_tx_clk tx_fsm_preamble tx_fsm_data tx_fsm_padding tx_nible_counter(11:0) tx_crc_data(3:0) tx_data(7:0) reset eth_tx_defer phy_tx_clk half_duplex phy_tx_crs tx_fsm_ifs tx_fsm_ifs1 tx_fsm_ifs2 tx_igp_cnt_eq_ifs tx_igp_cnt_eq_ifs1 tx_igp_cnt_eq_ifs2 tx_fsm_start_idle tx_fsm_start_backoff tx_fsm_start_ifs tx_fsm_start_ifs1 tx_fsm_start_ifs2 reset eth_tx_backoff phy_tx_clk tx_fsm_idle tx_fsm_start_jam tx_fsm_jam reset tx_backoff_cnt_eq0 tx_attempt_cnt_eq0 tx_attempt_cnt_eqlimit Rys Struktura wewnętrzna modułu eth_tx w wersji Fast Ethernet. 79

80 Pierwszą grupę zadań związanych z enkapsulacją danych klienta MAC realizuje moduł eth_tx_bittran. Na podstawie informacji sterujących, pochodzących z bloku zarządzającego eth_tx_tlm, generuje on poszczególne pola ramki Ethernet, takie jak: sekwencja preambuły, SFD oraz JAM. Moduł dokonuje również niezbędnej konwersji danych klienta MAC z postaci słowa ośmiobitowego do pojedynczych nibli (kod CRC nie wymaga konwersji, bowiem przesyłany jest od razu w postaci czterobitowej). Dodatkową funkcjonalnością, zaimplementowaną w omawianym module, jest główny licznik wysłanych nibli - tx_nible_counter. Jego wartość wykorzystują bloki wchodzące w skład toru TX do synchronizacji aktualnego położenia w przetwarzanej ramce. Rysunek 4.18 przedstawia przebiegi czasowe sygnałów modułu eth_tx_bittran w trakcie transmisji przykładowej ramki Ethernet. Preambuła Pole SFD Pole FCS Dane klienta MAC Licznik wysłanych nibli Rys Przebiegi czasowe sygnałów modułu eth_tx_bittran dla transmisji przykładowej ramki Ethernet. Moduł eth_tx_crc wylicza cykliczny kod namiarowy CRC transmitowanych danych w sposób analogiczny do przypadku omawianego przy okazji analizy funkcjonowania toru RX. Jedyna różnica sprowadza się do pominięcia etapu porównywania wartości kodu z residuum. Wynik obliczeń jest wysyłany bezpośrednio do modułu eth_tx_bittran w postaci słów 4-bitowych, począwszy od najstarszego bitu MSB, tak, aby wypełnić cały obszar sekwencji kontrolnej FCS. Przykładowe przebiegi czasowe sygnałów modułu eth_rx_crc przedstawiono na rysunku Początek pola danych klienta MAC Koniec pola danych klienta MAC Transmisja wyliczonego kodu CRC Rys Przebiegi czasowe sygnałów modułu eth_tx_crc dla transmisji przykładowej ramki Ethernet. 80

81 Moduł eth_tx_defer odpowiada funkcjonalnie procesowi Deference w modelu IEEE [40] (Rys. 4.20), zarządzającemu opóźnianiem ramki według poniższych reguł: tryb Half Duplex - moduł nieustająco monitoruje stan medium (nawet wtedy, gdy ramki nie są transmitowane), śledząc sygnał obecności nośnej eth_tx_crs (ang. carrier sense) z układu PHY. Kiedy tylko stwierdzi, że medium jest zajęte, rozpoczyna opóźnienie rozpoczęcia ewentualnej transmisji. W momencie, kiedy medium staje się wolne (sygnał eth_tx_crs zmienia wartość na 0 logiczne), moduł kontynuuje opóźnienie przez wymagany standardem okres równy wartości minimalnej szczeliny czasowej, oddzielającej kolejno transmitowane ramki (ang. interframespacing). Po tym czasie transmisja jest rozpoczynana niezależnie od stanu sygnału eth_tx_crs, a po jej zakończeniu (lub w wypadku, gdy nie ma żadnych ramek do wysłania) moduł rozpoczyna ponowne monitorowanie stanu medium, tryb Full Duplex - moduł nie monitoruje stanu sygnału eth_tx_crs. Po zakończeniu transmisji ramki odmierza jedynie wymagane opóźnienie równe interframespacing. Nie Kanał zajęty? Tak Włącz opóźnianie Kanał wolny? Tak Odczekaj czas równy interframe delay Wyłącz opóźnianie Czy ramka jest wysyłana (aktywny syg. framewaiting)? Nie Nie Tak Rys Algorytm opóźniania transmisji ramki (ang. deffering) [40]. Na rysunku 4.21 przedstawiono przykładowe przebiegi czasowe dla modułu eth_tx_defer przy transmisji ramki z szybkością 100 Mb/s w trybie Full Duplex. Dla takich warunków pracy po zakończeniu transmisji moduł odmierza jedynie czas równy szczelinie interframespacing (0,96 µs). Start transmisji Koniec transmisji Początek opóźniania Koniec opóźniania Rys Przebiegi czasowe sygnałów modułu eth_tx_defer dla transmisji przykładowej ramki Ethernet. 81

82 W module eth_tx_backoff zaimplementowano niezwykle ważny, z punktu widzenia funkcjonowania sieci opartej o protokół rywalizacyjny CSMA/CD, algorytm z binarno-wykładniczym rozszerzaniem czasu [72] (ang. binary-expotential backoff), randomizującym czas rozpoczęcia retransmisji ramki po wystąpieniu kolizji. Ponowienie transmisji opóźnia się o całkowitą wielokrotność r szczeliny czasowej, równej oknu kolizyjnemu (ang. collision window), definiowanej jako parametr slottime. Wartość zwielokrotnienia r stanowi liczbę losową z przedziału: 0 r 2 k, (4.2) gdzie k = min(n, 10). Przy pracy w trybie Full Duplex mechanizm backoff jest nieaktywny. Wówczas sygnał tx_attempt_cnt_eq_0, informujący o zerowej wartości licznika prób transmisji, pozostaje w wysokim stanie logicznym a sygnał przekroczenia liczby dopuszczalnych ponowień transmisji (tx_attempt_cnt_eq_limit) w stanie niskim. Dopiero dla trybu Half Duplex, w przypadku występowania kolizji, moduł eth_tx_backoff zapewnia właściwe rozłożenie dostępu do medium fizycznego. Randomizacja momentu wznowienia nadawania daje możliwość wykorzystania wolnego kanału przez inne stacje, równolegle funkcjonujące w sieci Ethernet. Rysunek 4.22 pokazuje reakcję modułu eth_tx_backoff na zgłoszenie wystąpienia kolizji w medium. Kolizja wysyłany sygnał JAM Inkrementacja licznika czasu slottime Przepisanie losowej ilości okresów slottime do odmierzenia Rys Przebiegi czasowe sygnałów modułu eth_tx_backoff w momencie wystąpienia kolizji w trybie Half Duplex. Aktywowanie sygnału phy_tx_crs powoduje przejście głównego automatu w module eth_tx_tlm w stan tx_fsm_jam, który inicjuje wysyłanie przez PHY sekwencji JAM. Równocześnie w module eth_tx_backoff następuje przepisanie pseudolosowej wartości liczby przedziałów czasowych slottime z sygnału back_random do licznika back_backoff_cnt oraz rozpoczęcie inkrementowania licznika 82

83 back_slot_cnt, odmierzającego czas 512 okresów bitowych (czyli 128 taktów zegara phy_tx_clk o częstotliwości 25 MHz dla szybkości 100Mb/s lub 2,5 MHz dla szybkości 10 Mb/s). Zakooczenie odmierzania pojedynczego okresu slottime Dekrementacja licznika back_backoff_cnt Rys Dekrementacja licznika back_backoff_cnt po odmierzeniu czasu slottime. W momencie zakończenia odmierzania pojedynczego okresu slottime (stan licznika back_slot_cnt wynosi 7F heksadecymalnie, czyli 128 dziesiętnie), w przypadku, gdy wartość licznika back_backoff_cnt jest większa od zera, nastąpi jej dekrementacja (Rys. 4.23). Cały proces trwa aż do momentu, kiedy licznik back_backoff_cnt osiągnie wartość zero. Wówczas aktywuje się sygnał tx_backoff_cnt_eq_cnt, co oznacza koniec procedury losowego opóźnienia ponowienia transmisji (Rys. 4.24). Wyzerowanie licznika back_backoff_cnt aktywuje sygnał tx_backoff_cnt_eq_0 Rys Zakończenie procedury opóźniania backoff. 83

84 Proces ponawiania transmisji może być wykonany ściśle określoną liczbę razy. Definiuje ją parametr attemptlimit (tabela 4.1), który dla wszystkich szybkości pracy wynosi 16. Po wystąpieniu kolizji w trakcie ostatniej próby nadania ramki aktywowany jest sygnał tx_attemp_eq_limit, a tym samym tor TX zgłasza błąd transmisji tx_error. Sytuacja taka zaprezentowana została na rysunku 4.25, gdzie wyraźnie widoczne jest zwiększanie czasu pomiędzy kolejnymi próbami retransmisji ramki zgodnie z algorytmem binarno-wykładniczym. Kolejne próby ponowienia transmisji Inkrementacja licznika prób dostępu back_attempt_cnt Kolizja w trakcie 16 próby aktywuje sygnał tx_attempt_cnt_eq_limit Rys Przekroczenie dopuszczalnej liczby prób ponowienia transmisji. Kluczowy moduł toru transmisyjnego eth_tx_tlm realizuje mechanizmy zarządzania dostępem do medium transmisyjnego, zgodnie z funkcjonalnością protokołu rywalizacyjnego CSMA/CD, w szczególności obsługę kolizji. W trybie Half Duplex, w obrębie okna kolizyjnego moduł monitoruje stan sygnału wystąpienia kolizji, pochodzącego z warstwy fizycznej. Rozmiar okna kolizyjnego jest uzależniony od parametrów medium transmisyjnego i musi być większy od sumy podwojonego czasu maksymalnego opóźnienia propagacyjnego oraz maksymalnego czasu trwania sygnału zakłócającego JAM, wysyłanego w momencie wykrycia kolizji. Takie przedłużanie transmisji ma na celu zapewnienie właściwej propagacji informacji o wystąpieniu kolizji do wszystkich stacji współdzielących medium fizyczne. Oprócz opisanej powyżej funkcjonalności w module eth_tx_tlm zaimplementowano główny automat stanów FSM (ang. Finite State Machine) synchronizujący pracę wszystkich elementów toru nadawczego. Graf przejść automatu przedstawiono na rysunku

85 TxTransmitEnabled = '1' and ((HalfDuplex = '1' and PHYTxCarrier = '0') or HalfDuplex = '0') TxTransmitEnabled = '0' IGPCounterEqIFS2 = '1' and PHYTxCarrier = '1' TxTransmitEnabled = '1' and HalfDuplex = '1' and PHYTxCarrier = '1' AttemptCntEq0 = '1' and PHYTxCarrier = '0' SetDefer IDLE IGPCounterEqIFS = '1' and ((HalfDuplex = '0') or (HalfDuplex = '1' and (AttemptCntEqLimit = '1' or TxOK = '1')) BackOffCntEq0 = '1' and AttemptCntEqLimit = '1' BackOffCntEq0 = '1' and AttemptCntEqLimit = '0' and PHYTxCarrier = '1' WaitIFS1 IGPCounterEqIFS1 = '1' AttemptCntEq0 = '0' and PHYTxCarrier = '0' WaitIFS PHYTxCarrier = '1' and AttemptCntEq0 = '0' and IGPCounterEqIFS = '1' and AttemptCntEqLimit = '0' WaitIFS2 BackOffCntEq0 = '1' and PHYTxCarrier = '0' and AttemptCntEqLimit = '0' IGPCounterEqIFS2 = '1' and PHYTxCarrier = '0' IGPCounterEqIFS = '1' and PHYTxCarrier = '0' and HalfDuplex = '1' and AttemptCntEqLimit = '0' and TxOK = '0' Preamble collisiondetect = '1' EqJamLenght = '1' and BackOffCntEq0 = '1' EqJamLenght = '1' and BackOffCntEq0 = '0' BackOff EqPreambleLenght = '1' and collisiondetect = '0' SFD EqSFDLenght = '1' and collisiondetect = '0' Jam EqDataLenght = '1' and PaddingNeeded = '0' and collisiondetect = '0' Data collisiondetect = '1' Padding CRC EqCRCLenght = '1' EqDataLenght = '1' and PaddingNeeded = '1' and collisiondetect = '0' EqPadLenght = '1' and collisiondetect = '0' Rys Graf przejść automatu FSM sterującego torem TX Moduł kontrolny Moduł kontrolny eth_tx_control dostarcza informacji o aktualnych parametrach warstwy fizycznej medium transmisyjnego pochodzących z PHY, niezbędnych do poprawnej konfiguracji pracy torów RX i TX. Pozwala również zmieniać ustawienia wewnętrznych rejestrów układu PHY, a tym samym modyfikować tryb funkcjonowania kontrolera MAC. Na etapie projektowym przyjęto 85

86 założenie, aby implementacja omawianego modułu była możliwie zwarta i jednocześnie nie zajmowała dużej liczby zasobów układowych [109]. Ze względu na opracowanie dwóch różnych wersji kart interfejsów sieciowych, opisanych szczegółowo w rozdziale 3.5, zrealizowana praktycznie implementacja sprzętowa modułu kontrolnego może pracować w dwóch trybach, dostosowanych do funkcjonalności układów PHY, z którymi współpracuje: tryb cyklicznego odświeżania starszy typ układów PHY, np. RTL8201BL wykorzystany do budowy kart Fast Ethernet, pozwala odczytywać konfigurację rejestrów wewnętrznych, lecz nie informuje kontrolera MAC o zmianie parametrów w nich zapisanych. Z tego powodu moduł kontrolny musi cyklicznie analizować konieczne w danym przypadku rejestry układu PHY, tak, aby nieustannie aktualizować informacje o stanie medium fizycznego; tryb z obsługą przerwań nowoczesne układy PHY, np. DP83865 wykorzystany do opracowania kart Gigabit Ethernet, umożliwiają powiadamianie kontrolera MAC o zmianach wybranych rejestrów poprzez konfigurowalne przerwania. W tym przypadku kontroler w trakcie procedur startowych przeprowadza konfigurację przerwań układu PHY, a następnie oczekuje jedynie na zgłoszenie wystąpienia zmian w warunkach pracy medium. Wybór odpowiedniego trybu działania modułu kontrolnego dokonywany jest przez odpowiednie ustawienie sygnału r_mii_config. Opis funkcji poszczególnych sekcji konfiguracyjnych przedstawiono na rysunku Sygnał r_mii_config MSB b 15 b 14 b 13 b 12 b 11 b 10 b 9 b 8 b 7 b 6 b 5 b 4 b 3 b 2 b 1 b 0 LSB Adres PHY Współczynnik podziału zegara zmiana okresu odświeżania stanu rejestrów PHY Tryb pracy modułu kontrolnego Zarezerwowane Rys Funkcje poszczególnych sekcji sygnału r_mii_config. Bity od 15 do 11 określają adres PHY, z którym będzie się komunikował moduł kontrolny (funkcjonowanie szeregowej magistrali MDIO zostało szerzej omówione w rozdziale 3.5.1). Bity od 10 do 3 definiują współczynnik podziału d zegara systemowego f sys, wyznaczając tym samym częstotliwość odświeżania rejestrów PHY w trybie cyklicznym. Dopuszczalne współczynniki podziału zawierają się w zakresie od 1 do 255. Częstotliwość odświeżania f r określa wówczas zależność: f sys r 20. f d 2 (4.3) 86

87 Wartość bitu 2 definiuje tryb pracy modułu: 0 obsługa przerwań, 1 cykliczne odświeżanie. Do obsługi szeregowej magistrali MDIO wykorzystano moduł eth_mii, opracowany przez G. Sułkowskiego [108]. Przykład przebiegów czasowych w trakcie sekwencji startowej kontrolera MAC (tryb z obsługą przerwań) zaprezentowano na rysunku Maskowanie przerwao Zerowanie przerwao Odczyt rejestrów PHY Oczekiwanie na przerwanie PHY Komunikacja poprzez linię MDIO Tryb połączenia Prędkośd połączenia Stan połączenia Rys Przykład przebiegów czasowych modułu eth_control Wyniki implementacji Opracowany sprzętowy kontroler MAC w wersji Fast Ethernet został zaimplementowany na dwóch platformach testowych FPGA z układem Xilinx Spartan 2E XC2S200 oraz Xilinx Virtex II Pro XC2VP30, zaprezentowanych w rozdziałach 3.3 oraz 3.4. Wyniki sumarycznego wykorzystania zasobów sprzętowych logiki reprogramowalnej oraz uzyskanych parametrów czasowych kompletnego kontrolera MAC w wersji Fast Ethernet przedstawiono w tabeli 4.2. Pełne wyniki implementacji poszczególnych modułów składowych kontrolera zamieszczono w dodatku B, punkty 9.1 do 9.4. Tab Podsumowanie wykorzystania zasobów sprzętowych układów FPGA oraz uzyskane parametry czasowe kontrolera MAC w wersji Fast Ethernet. Rodzaj zasobów Typ układu Spartan 2s200epq208-7 Virtex 2vp30ff896-7 Liczba bloków Slice Liczba 4-wejściowych LUT użytych jako logika użytych jako rejestry przesuwne 8 8 Parametry czasowe Maks. częstotliwość 74,705 MHz 191,953 MHz Maks. opóźnienie ścieżki kombinacyjnej 17,511 ns 6,864 ns 87

88 Zapotrzebowanie na zasoby sprzętowe logiki reprogramowalnej różni się nieznacznie pomiędzy układem Spartan a Virtex. Natomiast uzyskana maksymalna częstotliwość pracy jest zdecydowanie większa w wypadku bardziej zaawansowanego technicznie układu Virtex. Jednak należy podkreślić, że zarówno jedna, jak i druga implementacja spełnia z nadmiarem wymagania wydajnościowe standardu Fast Ethernet wykorzystującego zegar o maksymalnej częstotliwości 25 MHz Sprzętowy kontroler MAC - wersja Gigabit Ethernet Główne różnice funkcjonalne pomiędzy sprzętowymi implementacjami kontrolerów MAC w wersjach Fast Ethernet oraz Gigabit Ethernet obejmują: wykorzystywanie pełnego 8-bitowego interfejsu GMII, zwiększenie maksymalnej częstotliwości sygnału zegarowego do 125 MHz, możliwość pracy w seryjnym trybie transmisji (ang. burst mode), zaimplementowanie mechanizmów rozszerzenia nośnej (ang. carrier extension). Konieczność tak znacznego zwiększenia częstotliwości zegara (z 25 MHz w wersji Fast Ethernet aż do 125 MHz w wersji Gigabit) oraz zastosowania 8-bitowego interfejsu PHY GMII (w porównaniu do 4-bitowego MII) wyniknęły z 10-krotnego zwiększenia przepustowości kanału komunikacyjnego. Nową funkcjonalnością jest również tryb burst mode, który przy szybkości 1000 Mb/s Half Duplex pozwala na opcjonalną transmisję serii ramek bez kontrolowania stanu medium fizycznego (Rys. 4.29). Po zakończeniu transmisji jednej ramki stacja nadawcza może rozpocząć wysyłanie kolejnej, nie rywalizując o dostęp do medium. Jest to możliwe, ponieważ pozostałe stacje kontynuują proces opóźniania (ang. defer), oczywiście, o ile pierwsza stacja nie dopuści do powstania przerw między ramkami (medium nie może być w stanie idle). Aby taka sytuacja nie wystąpiła, stacja wypełnia odstępy międzyramkowe specjalnymi bitami rozszerzeń (ang. extention bits), które są przez stację odbiorczą w łatwy sposób odróżniane od właściwych danych. Maksymalna długość sekwencji burst definiowana jest przez parametr burstlimit (Tab. 4.1). Pierwsza ramka w trybie burst może być w razie konieczności uzupełniona bitami rozszerzeń, natomiast kolejno nadawane ramki nie wymagają ich dodawania. W poprawnie działającej sieci kolizja nie może wystąpić po zakończeniu transmisji pierwszej ramki wraz z rozszerzeniem. Z tego powodu kontroler MAC potraktuje każde kolizje występujące po wysłaniu pierwszej ramki sekwencji lub po osiągnięciu okresu slottime w trakcie transmisji pierwszej ramki jako tzw. późne kolizje (ang. late collisions). Ramka MAC z rozszerzeniem InterFrame Ramka MAC InterFrame Ramka MAC burstlimit okres zajętości medium Rys Tryb transmisji seryjnej burst mode [40]. 88

89 Dodatkową funkcjonalnością, nie występującą w kontrolerze Fast Ethernet, jest tzw. rozszerzanie nośnej (ang. carrier extention) dla trybu pracy 1000 Mb/s Half Duplex (Rys. 4.30), wynikające z niedostosowania okresu slottime do wymagań topologii sieci Gigabit Ethernet. Używając rozszerzeń nośnej, możliwym staje się zwiększenie tego przedziału czasu bez zmian minimalnej długości ramki minframesize. Jeżeli długość wysyłanej ramki jest mniejsza od okresu slot time, dodawane są do niej specjalne bity rozszerzeń, tak, aby sumarycznie osiągnąć wymagany standardem rozmiar. Rozszerzanie nośnej realizowane jest jedynie wówczas, gdy układ PHY wspiera taką funkcjonalność. Maksymalna długość rozszerzenia wynosi: slottime minframesize. Preambuła SFD DA SA L/T Dane/PAD FCS Rozszerzenie minframesize okres zajętości medium slottime okres obliczania FCS próg występowania późnych kolizji (slottime) Rys Mechanizm rozszerzania nośnej [40] Schemat blokowy Znaczne zwiększenie przepustowości kanału komunikacyjnego dla trybu Gigabit Ethernet oraz implementacja opisanych powyżej dodatkowych funkcjonalności wymusiły konieczność reorganizacji i optymalizacji wydajnościowej wszystkich modułów wchodzących w skład kontrolera MAC w stosunku do opracowanej pierwotnie wersji Fast Ethernet. Z tego powodu zmianie uległ również typ zewnętrznego interfejsu komunikacyjnego Firewalla, którego koncepcja działania oparta została o magistralę LocalLink [130]. Na najwyższym poziomie organizacji kontrolera (Rys. 4.31) zachowano podział na trzy główne bloki: tor odbiorczy RX, tor transmisyjny TX, moduł kontrolny. Układ PHY Kontroler MAC Karta sieciowa Interfejs GMII Tor odbiorczy RX (moduł eth_rx) Tor nadawczy TX (moduł eth_tx) Blok kontrolny (moduł eth_control) Interfejs Local Link Konfiguracja Rys Schemat blokowy sprzętowego kontrolera MAC w wersji Gigabit Ethernet. 89

90 Szczegółowa struktura kontrolera MAC uwzględniająca wewnętrzne linie sygnałowe oraz wyprowadzenia poszczególnych interfejsów została przedstawiona na rysunku W wersji Gigabit Ethernet kontroler posiada trzy grupy połączeń z modułami zewnętrznymi: interfejs GMII układu PHY, interfejs komunikacyjny Firewalla oraz interfejs konfiguracyjny. Dokładny opis funkcji poszczególnych sygnałów kontrolera MAC zawarto w dodatku A, punkt 8.4. moduł eth_mac.vhd INTERFEJS PHY GMII phy_rx_clk phy_crs phy_rx_error phy_rx_dv phy_rx_data(7:0) phy_tx_clk phy_gtx_clk phy_col phy_tx_en phy_tx_error phy_tx_data(7:0) phy_int_n phy_mdc phy_mdio phy_reset_n phy_rx_clk phy_crs phy_rx_error phy_rx_dv phy_rx_data(7:0) eth_rx sys_clk reset rx_data_out(31:0) rx_rem_out(3:0) rx_sof_out rx_eof_out rx_ce_in rx_rd_en_in rx_rdy_out rx_ok_out rx_err_out rx_tag_out rx_lenght_out(10:0) rx_pause_cnt_eq0 cfg_rx_mac_addr(47:0) cfg_rx_prmsc_en cfg_rx_mltc_en cfg_speed(1:0) cfg_link mac_ce_in sys_clk reset rx_data_out(31:0) rx_rem_out(3:0) rx_sof_out rx_eof_out rx_rd_en_in rx_rdy_out rx_ok_out rx_err_out rx_tag_out rx_lenght_out(10:0) tx_data_in(31:0) tx_rem_in(3:0) tx_sof_in tx_eof_in tx_wr_en_in tx_rdy_out tx_ok_out tx_err_out tx_lenght_in INTERFEJS LOCAL LINK phy_tx_clk phy_gtx_clk phy_crs phy_col phy_tx_en phy_tx_error phy_tx_data(7:0) eth_tx sys_clk reset tx_data_in(31:0) tx_rem_in(3:0) tx_sof_in tx_eof_in tx_ce_in tx_wr_en_in tx_rdy_out tx_ok_out tx_err_out tx_lenght_in tx_pause_cnt_eq0 cfg_rx_mac_addr(47:0) cfg_rx_prmsc_en cfg_rx_mltc_en cfg_tx_pause_en cfg_mii(15:0) stat_speed(1:0) stat_link stat_duplex KONFIGURACJA cfg_tx_pause_en cfg_speed(1:0) cfg_link cfg_duplex phy_int_n phy_mdc phy_mdio eth_control sys_clk reset mii_en_in cfg_mii(15:0) cfg_link cfg_speed(1:0) cfg_duplex <= '0' when reset = reset_level else '1'; Rys Struktura wewnętrzna modułu eth_mac.vhd w wersji Gigabit Ethernet Tor odbiorczy Rx W skład toru odczytu RX Gigabit Ethernet, którego schemat blokowy przedstawiono na rysunku 4.33, wchodzi siedem modułów: eth_rx_bitreceive, eth_rx_pattern_detect, eth_rx_crc, eth_rx_frame_control, eth_rx_fsm, eth_rx_pause_control, eth_rx_fifo_control realizujących wspólnie proces odczytu danych z interfejsu sieciowego zgodnie z modelem proceduralnym wyspecyfikowanym w standardzie IEEE [40]. 90

91 Tor odbiorczy RX Karta sieciowa Interfejs GMII eth_rx_bitreceiver eth_rx_pattern_detect eth_rx_frame_control eth_rx_fifo_control Interfejs LocalLink eth_rx_crc eth_rx_fsm eth_rx_pause_control Konfiguracja Rys Schemat blokowy toru odbiorczego RX w wersji Gigabit Ethernet. Część funkcjonalności realizowanych przez elementy składowe toru RX jest tożsama z odpowiednikami wersji Fast Ethernet, omówionymi szczegółowo w rozdziale Jednakże ze względu na zdecydowanie większe wymagania wydajnościowe standardu Gigabit Ethernet, a co za tym idzie, większą częstotliwość pracy poszczególnych modułów, już na etapie tworzenia koncepcji budowy kontrolera koniecznym okazało się zrewidowanie wcześniej przyjętych rozwiązań. Celem tych zabiegów było przede wszystkim zoptymalizowanie szybkości oraz stabilności działania modułów przy jednoczesnej minimalizacji ilości zasobów sprzętowych układów reprogramowalnych FPGA, niezbędnych do ich implementacji. Wykorzystanie zegara o częstotliwości 125 MHz zwiększa istotnie znaczenie opóźnień wnoszonych przez logikę kombinacyjną, szczególnie w sytuacji synchronizacji działania wielu bloków funkcjonalnych przetwarzających potokowo odbierane dane. Warto przy tej okazji zwrócić uwagę na fakt, że optymalizacja sprzętowej implementacji kontrolerów MAC jest zagadnieniem bardzo szerokim, wykraczającym poza ramy niniejszej rozprawy. W wypadku systemu bezpieczeństwa Firewall kontroler jest jedynie niewielkim fragmentem złożonej architektury, w której wiele elementów decyduje o całkowitej efektywności przetwarzania danych. Z tego powodu w toku prac badawczych większy nacisk położono na kwestie realizacji szybkiego sprzętowego klasyfikatora pakietów. Natomiast doświadczenia zebrane podczas opracowywania kontrolerów MAC są niezwykle cenne, pozwalają bowiem w perspektywie na dalsze udoskonalanie projektu i dostosowywanie go do dynamiczne rozwijającego się standardu Ethernet (od roku 2007 trwają prace nad wersją standardu IEEE P802.3ba, który będzie pozwalał na transmisję danych z prędkościami rzędu 100 Gb/s [105]). Szczegółowy schemat blokowy toru RX w wersji Gigabit Ethernet, uwzględniający wewnętrzne linie sygnałowe oraz wyprowadzenia poszczególnych interfejsów, przedstawiono na rysunku Moduł eth_rx posiada trzy grupy połączeń z blokami zewnętrznymi: interfejs GMII układu PHY (część odbiorcza), interfejs komunikacyjny Firewalla oraz interfejs konfiguracyjny. Funkcje poszczególnych sygnałów modułu zawarto w dodatku A, punkt

92 INTERFEJS PHY GMII phy_rx_clk phy_rx_dv phy_rx_error phy_crs phy_rx_data(7:0) phy_rx_clk phy_rx_dv phy_rx_data(7:0) rx_read_enable rx_state rx_next_state rx_sfd_detect cfg_speed(1:0) reset eth_rx_bitreceiver rx_data_8_val rx_data_8(7:0) rx_data_32_val rx_data_32(31:0) rx_data_32_rem(1:0) rx_byte_counter(10:0) rx_data_32_val_d rx_data_32_d(31:0) rx_data_32_rem_d(1:0) rx_byte_counter_d(10:0) phy_rx_clk eth_rx_pattern_detect rx_sfd_detect rx_src_detect rx_lt_detect rx_data_detect rx_tag_detect rx_mac_detect rx_bcast_detect rx_pause_detect rx_under_len rx_over_len rx_state rx_next_state rx_byte_counter(10:0) rx_data_8_val rx_data_8(7:0) cfg_rx_mac_addr(47:0) reset phy_rx_clk eth_rx_crc rx_crc_ok rx_state rx_next_state rx_data_8_val rx_data_8(7:0) reset moduł eth_rx.vhd eth_rx_frame_control rx_crc_ok rx_frame_ok rx_mac_detect rx_frame_err rx_bcast_detect rx_pause_detect rx_under_len rx_over_len cfg_rx_prmsc_en cfg_rx_mltc_en reset phy_rx_clk phy_rx_dv eth_rx_fsm rx_state rx_next_state rx_sfd_detect rx_src_detect rx_lt_detect rx_data_detect rx_read_enable cfg_speed(1:0) cfg_link reset phy_rx_clk phy_rx_dv phy_rx_error phy_crs eth_rx_fifo_control rx_read_enable rx_data_out(31:0) rx_rem_out(3:0) rx_sof_out rx_eof_out rx_rdy_out rx_ok_out rx_err_out rx_tag_out rx_lenght_out(10:0) rx_state rx_next_state rx_tag_detect rx_frame_ok rx_frame_err rx_data_32_val_d rx_data_32_d(31:0) rx_data_32_rem_d(1:0) rx_byte_counter_d(10:0) rx_ce_in rx_rd_en_in cfg_link sys_clk reset eth_rx_pause_control phy_rx_clk rx_pause_cnt_eq0 rx_state rx_next_state rx_pause_detect rx_frame_ok rx_frame_err rx_data_32_val rx_data_32(31:0) rx_byte_counter(10:0) cfg_link cfg_speed(1:0) reset cfg_link cfg_rx_mltc_en cfg_rx_prmsc_en cfg_rx_mac_addr(47:0) cfg_speed(1:0) KONFIGURACJA rx_data_out(31:0) rx_rem_out(3:0) rx_sof_out rx_eof_out rx_ok_out rx_rdy_out rx_err_out rx_tag_out rx_lenght_out(10:0) sys_clk reset rx_rd_en_in rx_ce_in rx_pause_cnt_eq0 INTERFEJS LOCAL LINK Rys Struktura wewnętrzna modułu eth_rx w wersji Gigabit Ethernet. 92

93 Proces przetwarzania danych odbieranych z układu PHY rozpoczyna się w module eth_rx_bitreceiver. Jego podstawowym zadaniem jest konwersja 4-bitowych nibli (dla szybkości 10/100 Mb/s) lub pełnych bajtów (dla szybkości 1000 Mb/s) do 32-bitowego słowa wyjściowego nieopóźnionego rx_data_32 oraz opóźnionego o cztery bajty rx_data_32_d. Takie rozwiązanie wynika z konieczności dostarczenia do modułu eth_rx_fifo_control informacji walidującej odebraną ramkę wraz z odebraniem ostatniego bitu danych klienta MAC. Ponieważ ramkę kończy 4-bajtowa sekwencja FCE (pozwalająca na ostateczną weryfikację poprawności), niezbędne jest wprowadzenie odpowiedniego opóźnienia względem pierwotnego strumienia danych. Przełączanie trybu pracy pomiędzy Fast a Gigabit Ethernetem dokonywane jest na podstawie informacji pochodzących z układu PHY przekazywanych do modułu sygnałem cfg_speed. Dodatkowo w module zaimplementowano główne liczniki odbieranych bajtów: rx_byte_counter (nieopóźniony) i rx_byte_counter_d (opóźniony), pozwalające na synchronizację poszczególnych bloków toru RX. Rysunek 4.35 przedstawia przykładowe przebiegi czasowe sygnałów modułu eth_rx_bitreceiver w trakcie odbierania ramki Ethernet. Sygnał sterujące z głównego FSM kontrolującego odbiór poszczególnych pól ramki 32-bitowe dane nieopóźnione Sygnały walidacji danych 32-bitowe dane opóźnione Rys Przebiegi czasowe sygnałów modułu eth_rx_bitreceiver w trakcie odbierania przykładowej ramki Ethernet. W wersji Gigabit Ethernet funkcje detekcji poszczególnych pól oraz typów odbieranych ramek zgrupowano w module eth_rx_pattern_detect. Sygnalizuje on następujące zdarzenia: detekcję sekwencji SFD aktywny sygnał rx_sfd_detect, detekcję pola adresu źródłowego MAC aktywny sygnał rx_src_detect, wykrycie pola Lenght/Type aktywny sygnał rx_lt_detect, osiągnięcie początku pola danych aktywny sygnał rx_data_detect, detekcję ramki znakowanej aktywny sygnał rx_tag_detect, detekcję ramki z polem adresu docelowego MAC odpowiadającym danemu kontrolerowi (zgodnym ze stanem linii cfg_rx_mac_add) aktywny sygnał rx_mac_detect, 93

94 wykrycie adresu rozgłoszeniowego typu broadcast aktywny sygnał rx_bcast_detect, wykrycie ramki kontroli przepływu typu PAUSE aktywny sygnał rx_pause_detect, nieosiągnięcie minimalnej wymaganej standardem długości ramki aktywny sygnał rx_under_len, przekroczenie dopuszczalnej długości ramki aktywny sygnał rx_over_len. Rysunek 4.36 przedstawia przykładowe przebiegi czasowe sygnałów modułu eth_rx_pattern_detect w trakcie odbierania ramki Ethernet. Detekcja pola SFD Detekcja pola adresu MAC Detekcja pola L/T Detekcja pola danych Odebrano ramkę typu broadcast Osiągnięto minimalną długośd Rys Przebiegi czasowe sygnałów modułu eth_rx_pattern_detect w trakcie odbierania przykładowej ramki Ethernet. Weryfikacja poprawności odbieranych ramek, w stosunku do wymagań narzucanych przez standard oraz aktualnie obowiązujące parametry konfiguracyjne realizowana jest przez moduł eth_rx_frame_control. Do tego celu wykorzystywane są sygnały: rx_mac_detect, rx_bcast_detect, rx_pause_detect, rx_under_len, rx_over_len, pochodzące z opisanego wcześniej bloku eth_rx_pattern_detect oraz sygnał eth_crc_ok generowany w module eth_rx_crc, funkcjonującym identycznie jak w kontrolerze typu Fast Ethernet (patrz rozdział 4.3.2). Jeżeli dla zadanej konfiguracji toru RX wszystkie wymagane standardem parametry są spełnione, aktywowany jest sygnał rx_frame_ok (Rys. 4.37). W przeciwnym wypadku zgłoszony zostaje błąd rx_frame_error, niezbędny do powiadomienia pozostałych bloków przetwarzających odbierane dane o konieczności zignorowania danej ramki Ethernet. Potwierdzenie poprawności odebranej ramki Rys Przebiegi czasowe sygnałów modułu eth_rx_frame_control w trakcie odbierania przykładowej ramki Ethernet. 94

95 Działaniem toru RX steruje główny automat stanów FSM zaimplementowany w module eth_rx_fsm. Na podstawie informacji o detekcji poszczególnych pól odbieranej ramki, pochodzących z bloku eth_rx_pattern_detect, generuje on sygnały kontrolne synchronizujące proces przetwarzania danych przez wszystkie elementy toru odbiorczego. Rysunek 4.38 przedstawia przebiegi czasowe sygnałów modułu eth_rx_fsm w trakcie odbierania przykładowej ramki Ethernet. Sygnalizacja detekcji poszczególnych pól ramki Sygnał kodujący stan automatu, sterujący poszczególnymi modułami toru RX Rys Przebiegi czasowe sygnałów modułu eth_rx_fsm w trakcie odbierania przykładowej ramki Ethernet. Standard IEEE [40] definiuje w Aneksie 31B specjalny typ ramek kontrolnych, zwanych PAUSE Frame. Ich zadaniem jest przesyłanie do stacji nadającej w trybie Full Duplex żądania wstrzymania transmisji na określony przedział czasu, zdefiniowany zawartością specjalnego pola informacyjnego ramki. Ramka PAUSE posiada zawsze stały, multicastowy adres wynoszący heksadecymalnie C Pole określające czas wstrzymania transmisji złożone jest z dwóch bajtów danych i może przyjmować wartości od 0 do kwantów, tzw. pause_quanta, czyli przedziałów czasu niezbędnego do wysłania porcji 512 bitów (specyficzny dla każdej z dopuszczalnych szybkości pracy). W opracowanym rozwiązaniu funkcjonalność obsługi ramek typu PAUSE zaimplementowano w module eth_rx_pause_control. Po odebraniu żądania wstrzymania transmisji moduł rozpoczyna odliczanie kwantów czasu, przepisując wartość pause_quanta do specjalnego licznika. Zakończenie odmierzania opóźnienia sygnalizowane jest przez wysoki poziom logiczny na wyjściu rx_pause_cnt_eq_0. Informacja ta przekazywana jest dalej do toru nadawczego, umożliwiając kontynuowanie transmisji danych. Ostatnim z elementów składowych toru odbiorczego jest moduł eth_rx_fifo_control odpowiadający za właściwą synchronizację dwóch domen zegarowych, obejmujących zegar układu PHY rx_clk taktujący cały blok RX (125MHz dla trybu 1 Gb/s, 25 MHz dla trybu 100 Mb/s lub 2,5 MHz dla szybkości 10 Mb/s) oraz zegar sys_clk (100 MHz), taktujący blok sprzętowego klasyfikatora pakietów. Do tego celu wykorzystano kolejkę buforującą FIFO (ang. First In, First Out), opartą na pamięci BRAM dostępnej w zasobach układu Xilinx Virtex II Pro [126, 134, 135]. Oprócz odbieranych danych synchronizacji podlegają również pozostałe sygnały kontrolne toru RX, dlatego w module zastosowano dwie odrębne kolejki FIFO: 512 słów 32-bitowych dla danych oraz 512 słów 95

96 16-bitowych dla sygnałów kontrolnych. Każdemu 32-bitowemu słowu odbieranych danych rx_data_out odpowiada 4-bitowa linia rx_rem_out walidująca poszczególne bajty (długość ramek nie jest wyrównywana do wielokrotności 4 bajtów, stąd konieczność dodatkowego potwierdzania ważności). Przebiegi czasowe dla modułu eth_rx_fifo_control podczas odbierania przykładowej ramki Ethernet przedstawiono na rysunku Zegar rx_clk 125 MHz Zegar sys_clk 100 MHz Walidacja słowa wyjściowego 32-bitowe słowo wyjściowe Sygnał walidujący bajty w 32- bitowym słowie wyjściowym Rys Przebiegi czasowe sygnałów modułu eth_rx_fifo_control w trakcie odbierania przykładowej ramki w trybie Gigabit Ethernet Tor nadawczy Tx rysunku Schemat blokowy toru transmisyjnego TX w wersji Gigabit Ethernet przedstawiono na Tor nadawczy TX Karta sieciowa Interfejs GMII eth_tx_bittransmiter eth_tx_crc eth_tx_counters eth_tx_fifo_control Interfejs LocalLink eth_tx_clk_mgmt eth_tx_fsm Konfiguracja Rys Schemat blokowy toru transmisyjnego TX w wersji Gigabit Ethernet. 96

97 W skład toru TX w wersji Gigabit Ethernet wchodzi sześć modułów: eth_tx_bittransmiter, eth_tx_clk_mgmt, eth_tx_crc, eth_tx_fsm, eth_tx_counters, eth_tx_fifo_control, realizujących proces transmisji danych do interfejsu sieciowego zgodnie z modelem proceduralnym wyspecyfikowanym w standardzie IEEE [40] (Rys. 4.41). Proces transmisji ramki (FrameTransmitter) KLIENT WARSTWY MAC (ang. MAC CLIENT) Transmisja ramki (TransmitFrame) Enkapsulacja transmitowanej ramki (TransmitDataEncap) Zarządzanie procesem transmisji (TransmitLinkMgmt) Dodawanie uzupełnienia (ComputePad) Obliczanie CRC (CRC32) Monitorowanie kolizji (WatchForCollision) Rozpoczęcie transmisji (StartTransmit) Ponawianie transmisji (BackOff) Randomizacja (Random) Proces transmisji danych (BitTransmitter) Obsługa trybu burst (BurstTimer) Rozszerzanie ramki (InterFrameSignal) Opóźnienie transmisji (Deference) Sterowanie transmisją pól ramki (PhisicalSignalEncap) Opóźnienie czasu rzeczywistego (RealTimeDelay) Transmisja sygnału jam (StartJam) Transmisja kolejnego bitu (NextBit) PODWARSTWA DOSTĘPU DO MEDIUM (ang. MEDIA ACCESS SUBLAYER) Transmisja bitu danych (TransmitBit) Oczekiwanie na transmisję (Wait) WARSTWA FIZYCZNA (ang. PHYSICAL LAYER) tylko dla trybu half duplex tylko dla trybu half duplex > 100Mb/s Rys Model proceduralny toru odbiorczego TX w wersji Gigabit Ethernet (na podstawie [40]). Blok transmisyjny eth_tx, podobnie jak w wersji Fast Ethernet, posiada trzy grupy połączeń z modułami zewnętrznymi: interfejs GMII układu PHY (część nadawcza), interfejs komunikacyjny Firewalla oraz interfejs konfiguracyjny. Funkcje poszczególnych sygnałów toru TX w wersji Gigabit Ethernet opisano szczegółowo w dodatku A, punkt 8.6, zaś wewnętrzny schemat strukturalny, 97

98 uwzględniający linie oraz wyprowadzenia interfejsów komunikacyjnych, przedstawiono na rysunku eth_tx_clk_mgmt moduł eth_tx.vhd phy_tx_clk phy_gtx_clk tx_clk cfg_speed(1:0) sys_clk reset eth_tx_crc tx_clk eth_tx_bittransmiter tx_clk phy_tx_en tx_state phy_tx_error tx_next_state phy_tx_data(7:0) tx_word_ptr(2:0) tx_fifo_data(31:0) tx_fifo_rem(3:0) tx_crc_ptr(2:0) phy_tx_clk phy_gtx_clk phy_col phy_crs phy_tx_en phy_tx_error phy_tx_data(7:0) INTERFEJS PHY GMII tx_state tx_crc(31:0) tx_crc(31:0) tx_next_state tx_fifo_data(31:0) cfg_duplex tx_word_ptr(2:0) cfg_link cfg_speed(1:0) cfg_speed(1:0) sys_clk reset reset phy_crs phy_col eth_tx_fsm tx_state tx_next_state eth_tx_counters phy_crs tx_ok phy_col tx_err preamble_done tx_clk sfd_done tx_state data_done tx_next_state crc_done tx_eof tx_done tx_lenght(10:0) jam_done tx_empty extent_done tx_fifo_rem(3:0) burst_done defer_cnt_eqifg cfg_duplex defer_cnt_eqifg1 cfg_speed(1:0) attmp_cnt_eq0 reset attmp_cnt_eqmax backoff_cnt_eq0 tx_rd_word_en tx_word_ptr(2:0) tx_crc_ptr(2:0) tx_byte_counter(10:0) tx_clk tx_ok tx_err preamble_done sfd_done data_done crc_done tx_done jam_done extent_done burst_done defer_cnt_eqifg defer_cnt_eqifg1 attmp_cnt_eq0 attmp_cnt_eqmax backoff_cnt_eq0 tx_pause_sync tx_ce_sync tx_sof tx_eof tx_lenght(10:0) tx_empty cfg_tx_pause_en cfg_duplex cfg_link cfg_speed(1:0) sys_clk reset eth_tx_fifo_control tx_clk tx_ce_sync tx_state tx_sof tx_next_state tx_eof tx_rd_word_en tx_lenght(10:0) tx_ok tx_empty tx_err tx_fifo_data(31:0) tx_byte_counter(10:0) tx_fifo_rem(3:0) attmp_cnt_eqmax tx_pause_sync tx_pause_cnt_eq0 tx_rdy_out tx_data_in(31:0) tx_ok_out tx_rem_in(3:0) tx_err_out tx_sof_in tx_eof_in tx_ce_in tx_wr_en_in tx_lenght_in(10:0) cfg_duplex cfg_link cfg_speed(1:0) sys_clk reset tx_rdy_out tx_ok_out tx_err_out tx_lenght_in tx_wr_en_in tx_ce_in tx_eof_in tx_sof_in tx_rem_in(3:0) tx_data_in(31:0) tx_pause_cnt_eq0 INTERFEJS LOCAL LINK reset sys_clk cfg_speed(1:0) cfg_link cfg_duplex cfg_tx_pause_en KONFIGURACJA Rys Struktura wewnętrzna modułu eth_tx w wersji Gigabit Ethernet. 98

99 Za poprawne generowanie i zarządzanie sygnałami zegarowymi toru transmisyjnego odpowiada moduł eth_tx_clk_mgmt. W zależności od aktualnych warunków pracy układu PHY częstotliwość zegara przyjmuje różne wartości: dla szybkości 10 Mb/s tor TX wykorzystuje zegar phy_tx_clk o częstotliwości 2,5 MHz generowany przez układ PHY, dla szybkości 100 Mb/s tor TX wykorzystuje zegar phy_tx_clk o częstotliwości 25 MHz generowany przez układ PHY, dla szybkości 1000 Mb/s tor TX generuje dla układu PHY sygnał zegarowy phy_gtx_clk o częstotliwości 125 MHz (Rys. 4.43). Proces wytwarzania sygnału zegarowego 125 MHz na bazie zegara systemowego sys_clk, o częstotliwości 100 MHz, realizowany jest w oparciu o blok DCM (ang. Digital Clock Management), wchodzący w skład zasobów sprzętowych układu Virtex II Pro [128, 133]. Sygnał cfg_speed równy 10 Zegar sys_clk 100 MHz Zegar z bloku DCM 125 MHz Rys Przebiegi czasowe sygnałów modułu eth_tx_clk_mgmt dla transmisji z szybkością 1000 Mb/s. Takie duże zróżnicowanie sygnałów taktujących w torze TX prowadzi do powstania dwóch niezależnych domen zegarowych: systemowej o stałej częstotliwości zegara wynoszącej 100 MHz oraz wewnętrznej o częstotliwości warunkowanej aktualnym trybem pracy układu PHY (od 2,5 MHz do 125 MHz). Z tej przyczyny, podobnie jak to miało miejsce w wypadku toru RX, konieczne jest zastosowanie specjalnego modułu eth_rx_fifo_control, odpowiadającego przede wszystkim za zapewnienie właściwej synchronizacji domen zegarowych, wykorzystując do tego celu kolejki buforujące FIFO, oparte o pamięci BRAM. Analogicznie do toru odbiorczego, oprócz wysyłanych danych, synchronizacji podlegają również pozostałe sygnały kontrolne toru TX, dlatego moduł wykorzystuje dwie kolejki FIFO: 512 słów 32-bitowych dla danych oraz 512 słów 16-bitowych dla sygnałów kontrolnych. Każdemu 32-bitowemu transmitowanemu słowu tx_data_in odpowiada 4-bitowa linia tx_rem_in walidująca poszczególne bajty. Gotowość toru transmisyjnego do rozpoczęcia nadawania sygnalizowana jest wysokim poziomem logicznym na wyjściu tx_rdy_out (Rys. 4.44). W takim stanie tor TX oczekuje na przyjęcie danych pochodzących od klienta MAC (bloku Firewalla). Uruchomienie procedury transmisji następuje po wystawieniu wysokiego poziomu na linię tx_sof. Wówczas do układu PHY przekazana zostaje sekwencja preambuły, a równocześnie rozpoczyna się buforowanie 32-bitowych słów danych klienta MAC (linia tx_data_in) walidowanych sygnałem tx_wr_en_in. Jeżeli w trakcie nadawania, w związku z występowaniem kolizji 99

100 i koniecznością obsługi mechanizmu backoff, nastąpi chwilowe przepełnienie kolejki FIFO, sygnał tx_rdy_out zmienia wartość na niski poziom logiczny. Buforowanie danych wejściowych trwa do momentu aktywowania sygnału tx_eof_in. Długość transmitowanej ramki podawana jest na wejście tx_lenght_in. Poprawne zakończenie przesyłania danych do układu PHY sygnalizuje wysoki poziom logiczny na linii tx_ok_out, zaś niepowodzenie tego procesu wysoki poziom logiczny na linii tx_err_out. Sygnał sterujący z FSM Rozpoczęcia buforowania danych klienta MAC Dane klienta MAC Walidacja danych klienta MAC Zakooczenie buforowania danych klienta MAC Poprawne zakooczenie transmisji Rys Przebiegi czasowe sygnałów modułu eth_tx_fifo_control w trakcie transmisji przykładowej ramki Ethernet. Zbuforowane dane przeznaczone do wysłania trafiają do modułu eth_tx_bittransmiter, który na podstawie informacji sterujących pochodzących z bloku zarządzającego eth_tx_tlm generuje poszczególne pola ramki Ethernet (Rys. 4.45) oraz konwertuje transmitowane informacje z postaci 32-bitowych słów do formatu określanego aktualnymi warunkami pracy układu PHY (nible dla prędkości 10/100 Mb/s lub bajty dla prędkości 1000 Mb/s). Sposób konwersji ustalany jest na podstawie stanu sygnału cfg_speed, kodującego informację o szybkości transmisji medium fizycznego. Po zakończeniu wysyłania danych klienta MAC moduł rozpoczyna przetwarzanie 32-bitowej sekwencji FCS, generowanej przez blok eth_tx_crc. Funkcjonuje on w sposób analogiczny do wersji Fast Ethernet, opisanej w rozdziale

101 Pole preambuły Pole SFD Dane klienta MAC razem z polami adresowymi Pole FCS Rys Przebiegi czasowe sygnałów modułu eth_tx_bittransmiter w trakcie transmisji przykładowej ramki Ethernet. Nowym rozwiązaniem w stosunku do wcześniejszej implementacji kontrolera MAC jest zgrupowanie w jednym module eth_tx_clk_counters kluczowych liczników (Rys. 4.46), niezbędnych do poprawnego działania wszystkich mechanizmów toru transmisyjnego, m.in.: opóźniania transmisji (ang. defer), algorytmu z binarno-wykładniczym rozszerzaniem czasu (ang. back-off), zliczania prób ponowienia transmisji (ang. attempt limit), zliczania liczby wysłanych bajtów. Sygnalizacja kooca pola preambuły Sygnalizacja kooca pola SFD Sygnalizacja kooca pola danych Sygnalizacja kooca pola FCS Sygnał osiągnięcia limitu ponowieo transmisji Sygnał zakooczenia odmierzania back-off Rys Przebiegi czasowe sygnałów modułu eth_tx_counters w trakcie transmisji przykładowej ramki Ethernet. Poszczególne sygnały informacyjne generowane w torze TX przekazywane są ostatecznie do modułu eth_tx_fsm. Zaimplementowano w nim główny automat sterujący przebiegiem transmisji danych. Trzynaście stanów pracy: IDLE, pause, flush, defer, ifs, ifs1, preamble, sfd, data, crc, jam, 101

102 extent oraz backoff realizuje wszelkie wymagane standardem operacje, w tym obsługę ramek kontroli przepływu typu PAUSE oraz wysyłanie ramek w trybie BURST. Przed przystąpieniem do nadawania konieczne jest wyzerowanie kolejki FIFO z ewentualnych niepożądanych informacji, pozostałych po zakończonym niepowodzeniem lub arbitralnie przerwanym procesie wysyłania wcześniejszych ramek. Aktywna linia zezwolenia nadawania tx_en wraz ze zgłoszeniem obecności danych klienta MAC w buforze FIFO, sygnalizowanym niskim stanem logicznym linii tx_empty oraz flagą początku ramki (wysoki stan na linii tx_sof), inicjuje rozpoczęcie procedury transmisji (Rys. 4.47). Przejścia pomiędzy poszczególnymi stanami pracy automatu, wyzwalane zmianami stanów liczników w opisywanym wcześniej module eth_tx_clk_counters, realizowane są według schematu zaprezentowanego na rysunku W przypadku braku zewnętrznych czynników zaburzających transmisję (np. kolizja w medium fizycznym, przepełnienie kolejki FIFO, itp.) zmiany stanów automatu tożsame są z przemieszczaniem się pomiędzy poszczególnymi polami ramki Ethernet. Jeżeli pojawi się konieczność obsługi któregokolwiek ze wspieranych wyjątków, automat natychmiast przechodzi we właściwą zaistniałej sytuacji sekwencję sterującą. Zakończenie procedury transmisji danych klienta MAC wyzwalane jest aktywacją flagi końca ramki (wysoki poziom linii tx_eof). Wówczas rozpoczyna się wysyłanie obliczanej na bieżąco sekwencji kontrolnej CRC (pole FCS w ramce Ethernet). Zezwolenia na transmisję Transmisja sekwencji FCS Konfiguracja toru TX Sygnalizacja aktualnego stanu automatu FSM Sygnał początku ramki Dane do wysłania obecne w FIFO Sygnał kooca ramki Rys Przebiegi czasowe sygnałów modułu eth_tx_fsm w trakcie transmisji ramki Ethernet. 102

103 tx_en = '1' and tx_empty = '0' and cfg_tx_pause_en = '1' and tx_pause_sync = '1' tx_en = '0' or tx_empty = '1' tx_en = '1' and tx_empty = '0' and (cfg_tx_pause_en = '0' or tx_pause_sync = '0') and tx_sof = '0' tx_en = '1' and cfg_tx_pause_en = '1' and tx_pause_sync = '1' tx_en = '1' and tx_empty = '0' and tx_sof = '0' pause flush tx_en = '1' and (cfg_tx_pause_en = 0' or tx_pause_sync = '0') or tx_en = '0' tx_en = '1' and tx_empty = '0' and (cfg_tx_pause_en = '0' or tx_pause_sync = '0') and tx_sof = '1' and ((cfg_duplex = '1' or phy_crs = '1') and cfg_duplex = '0') tx_en = '1' and phy_crs = '1' IDLE tx_en = '0' or (tx_en = '1' and (tx_empty = '1' or tx_sof = '1')) tx_en = '1' and tx_empty = '0' and (cfg_tx_pause_en = '0' or tx_pause_sync = '0') and tx_sof = '1' and ((cfg_duplex = '0' and phy_crs = '0') or cfg_duplex = '1') tx_en = '1' and colision = '0' and preamble_done = '0' tx_en = '1' and phy_crs = '0' and attmp_cnt_eq0 = '1' defer preamble tx_en = '1' and colision = '0' and preamble_done = '1' tx_en = '1' and phy_crs = '0' and attmp_cnt_eq0 = 0' tx_en = '1' and defer_cnt_eqifg1 = '0' tx_en = '1' and defer_cnt_eqifg = '1' and tx_done = '0' and ((cfg_duplex = '1' or phy_crs = '1') and cfg_duplex = '0') ifs ifs1 tx_en = '0' tx_en = '1' and colision = 0' and sfd_done = '1' sfd jam tx_en = '1' and colision = '1' tx_en = '1' and colision = 0' and sfd_done = '0' tx_en = '1' and colision = '1' tx_en = '1' and colision = '0' and crc_done = '1' and cfg_speed = "10" and cfg_duplex = '0' and extent_done = '1' and burst_done = '0' and tx_sof = '1' tx_en = '1' and defer_cnt_eqifg = '0' tx_en = '1' and defer_cnt_eqifg1 = 1' tx_en = '1' and defer_cnt_eqifg = '1' and tx_done = '0' and ((cfg_duplex = '0' and phy_crs = '0') or cfg_duplex = '1') tx_en = '0' tx_en = '0' or tx_empty = '1' tx_en = '1' and tx_empty = '0' colision = '0' and data_done = '1' tx_en = '0' data crc tx_en = '1' and tx_empty = '0' colision = '1' tx_en = '1' and colision = '1' tx_en = '1' and tx_empty = '0' colision = '0' and data_done = '0' tx_en = '0' or (tx_en = '1' and defer_cnt_eqifg = '1' and tx_done = '1' tx_en = '0' tx_en = '1' and colision = '0' and crc_done = '0' tx_en = '1' and colision = '0' and crc_done = '1' and (cfg_speed = "10" and cfg_duplex = '0' and (extent_done = '1' or burst_done = '1' or tx_sof = '0') or (cfg_speed = "00" or cfg_speed = "01" or cfg_duplex = '0'))) tx_en = '1' and colision = '0' and extent_done = '1' and (burst_done = '1' or tx_sof = '0') extent tx_en = '1' and colision = '1' tx_en = '1' and colision = '0' and extent_done = '1' and burst_done = '0' and tx_sof = '1' tx_en = '1' and colision = '0' and extent_done = '0' tx_en = '1' and colision = '0' and crc_done = '1' and cfg_speed = "10" and cfg_duplex = '0' and extent_done = '0' tx_en = '1' and backoff_cnt_eq0 = '1' and attmp_cnt_eqmax = '0' and phy_crs = '1' tx_en = '0' or (tx_en = '1' and backoff_cnt_eq0 = '1' and attmp_cnt_eqmax = '1') backoff tx_en = '1' and jam_done = '1' tx_en = '1' and backoff_cnt_eq0 = '1' and attmp_cnt_eqmax = '0' and phy_crs = '0' tx_en = '1' and backoff_cnt_eq0 = '0' Rys Graf przejść automatu FSM sterującego torem TX. 103

104 Moduł kontrolny Sposób funkcjonowania oraz implementacji sprzętowej modułu kontrolnego w wersji Gigabit Ethernet jest identyczny z opisanym w rozdziale Większa o około 27% wielkość alokowanych zasobów układu reprogramowalnego FPGA w omawianej wersji modułu kontrolnego (dodatek B, punkt 9.5) w porównaniu do wersji Fast Ethernet (dodatek B, punkt 9.1), wynika z wykorzystania pełnej dwubitowej linii cfg_speed, kodującej bieżącą szybkość pracy układu PHY Wyniki implementacji Opracowany sprzętowy kontroler MAC w wersji Gigabit Ethernet został zaimplementowany jedynie na platformie testowej FPGA z układem Xilinx Virtex II Pro XC2VP30. Wykorzystanie płyty Digilent D2E z układem Spartan 2E XC2S200 do weryfikacji funkcjonowania było niemożliwe ze względu na wysoką częstotliwość pracy modułu w trybie 1000 Mb/s. Wyniki sumarycznego wykorzystania zasobów sprzętowych logiki reprogramowalnej oraz uzyskanych parametrów czasowych kompletnego kontrolera MAC w wersji Fast Ethernet przedstawiono w tabeli 4.3. Pełne wyniki implementacji poszczególnych modułów składowych kontrolera zamieszczono w dodatku B, punkty 9.5 do 9.8. Tab Podsumowanie wykorzystania zasobów sprzętowych układów FPGA oraz parametry czasowe kontrolera MAC w wersji Gigabit Ethernet. Rodzaj zasobów Typ układu Virtex 2vp30ff896-7 Liczba bloków Slice 812 Liczba 4-wejściowych LUT 1502 Parametry czasowe Maks. częstotliwość 146,342 MHz Maks. opóźnienie ścieżki kombinacyjnej 6,783 ns Teoretyczna maksymalna częstotliwość pracy kontrolera MAC w wersji Gigabit Ethernet, raportowana przez narzędzia do syntezy logicznej (około 146 MHz), pozwala na jego poprawne funkcjonowanie przy maksymalnej szybkości transmisji danych 1000 Mb/s (częstotliwość sygnału zegarowego układu PHY dla tego przypadku jest równa 125 MHz). 104

105 5. Sprzętowy system bezpieczeństwa typu Firewall 5.1. Wprowadzenie W pierwszym etapie prac badawczych autor skoncentrował się na przygotowaniu odpowiedniej platformy testowo-uruchomieniowej oraz opracowaniu niezbędnych elementów warstwy komunikacyjnej, pozwalających na eksploatację systemu bezpieczeństwa w infrastrukturze sieci Ethernet [108, 109]. Kwestie te, jakkolwiek bardzo istotne z punktu widzenia kompleksowej realizacji założonego celu, stanowiły jedynie wstęp do właściwego obszaru badawczego, obejmującego klasyfikację pakietów z wykorzystaniem układów FPGA, a w szczególności praktyczną realizację w pełni funkcjonalnego sprzętowego systemu Firewall implementowanego w logice reprogramowalnej. Podstawowymi założeniami, przyjętymi przy tworzeniu koncepcji architektury sprzętowego Firewalla, było przede wszystkim zachowanie dużego bezpieczeństwa systemu oraz zmaksymalizowanie jego wydajności. O ile spełnienie pierwszego z założeń jest już osiągalne poprzez przeniesie funkcjonalności Firewalla do logiki reprogramowalnej, eliminując tym samym oprogramowanie posiadające luki wewnętrzne, to w przypadku optymalizacji wydajności konieczne jest szczegółowe przeanalizowanie słabych stron konwencjonalnych rozwiązań po to, aby móc je wyeliminować dodatkowymi mechanizmami, jakie zyskujemy po przejściu w implementację sprzętową. Powszechnie eksploatowane programowe systemy bezpieczeństwa wykorzystują w swym działaniu procesory ogólnego przeznaczenia, które stanowią główny punkt ograniczający efektywność. Procesor w takim przypadku jest wykorzystywany nie tylko do realizacji algorytmów analizy pakietów, ale również przez system operacyjny zapory ogniowej, aplikacje zarządzające, obsługę komunikacji sieciowej, itp. Tak znaczne obciążenie procesora zadaniami pobocznymi w stosunku do zasadniczego celu działania urządzenia skutkuje jego przeciążeniami i ograniczeniem maksymalnej przepustowości transmisji. Co więcej, możemy obserwować eskalację tego problemu przy dodawaniu kolejnych interfejsów sieciowych, generujących dodatkowe obciążenie związane z trasowaniem pakietów (ang. routing). Taka sytuacja sprowokowała autora do poszukiwań sprzętowych rozwiązań eliminujących opisane problemy. Opracowana koncepcja architektury Firewalla opiera się na założeniu tworzenia dedykowanych kanałów komunikacyjnych [115], tak jak ma to miejsce w przypadku mechanizmu mikrosegmentacji, wykorzystywanego praktycznie we wszystkich obecnych na rynku przełącznikach sieci Ethernet [15]. Każdy taki kanał zawiera w sobie pełny tor przetwarzania i analizy bezpieczeństwa danych. Poszczególne moduły elementarnych zapór ogniowych dla wszystkich istniejących ścieżek komunikacyjnych bazują w takim przypadku na jednym, globalnym zestawie reguł bezpieczeństwa. W momencie ich modyfikacji, wszelkie zmiany 105

106 propagowane są do każdego modułu weryfikującego przetwarzane dane. Jeżeli w systemie bezpieczeństwa zainstalowane zostaną więcej niż dwa interfejsy sieciowe NIC, konieczne jest zaimplementowanie dodatkowego bloku, realizującego trasowanie pakietów. Optymalnym rozwiązaniem byłby w tej sytuacji oczywiście router w pełni sprzętowy, natomiast zagadnienie to wykracza poza tematykę niniejszej rozprawy i z racji swej obszerności może stać się celem oddzielnych badań. W związku z prototypowym charakterem realizowanego sytemu autor założył, iż minimalna funkcjonalnie wersja konfiguracji zapory ogniowej, zawierająca dwa interfejsy sieciowe, pozwoli w pełni na zweryfikowanie poprawności działania opracowanej koncepcji architektury sprzętowego Firewalla, umożliwiając zarazem jego dalszą rozbudowę o moduł trasujący [110]. Ogólny schemat koncepcji architektury Firewalla z równoległym przetwarzaniem wielościeżkowym przedstawiono na rysunku 5.1. Pamięć reguł Kontroler pamięci NIC eth2 MAC 2 FW 2 NIC eth1 MAC 1 FW 1 NIC eth0 MAC 0 FW 0 Router Rys Schemat koncepcyjny architektury sprzętowego Firewalla. Poszczególne karty interfejsów sieciowych obsługiwane są przez opisane w rozdziale 4 sprzętowe bloki MAC, realizujące funkcjonalności wymagane przez standard opisujący sieć Ethernet Dane z odbieranych ramek trafiają następnie do dedykowanych modułów weryfikacji reguł bezpieczeństwa (bloki FW). Ramki, które zostały zaakceptowane, przekazywane są w kolejności do modułu trasującego, przełączającego strumień danych do toru transmisyjnego odpowiedniej karty sieciowej. W przypadku dwóch kart sieciowych moduł trasujący nie występuje. Bloki FW poszczególnych torów komunikacyjnych pobierają reguły bezpieczeństwa z głównej pamięci reguł 106

107 poprzez specjalny kontroler pamięci. Taka komunikacja ma miejsce tylko w momencie pierwszego uruchomienia systemu lub po każdorazowej zmianie polityki bezpieczeństwa. Zmiany takie nie występują jednak w praktyce na tyle często, aby opisana koncepcja dystrybucji reguł rzutowała na spadek wydajności przetwarzania danych. Przepływ danych w systemie z dwoma interfejsami sieciowymi przedstawiono na rysunku 5.2. FW 0 NIC eth0 MAC 0 RX TX MAC 1 NIC eth1 TX RX FW 1 Rys Przepływ danych w sprzętowym Firewallu z dwoma interfejsami sieciowymi. Podobnie jak to miało miejsce w przypadku kontrolerów MAC, analiza funkcjonowania części weryfikującej przetwarzane pakiety przeprowadzona zostanie począwszy od najwyższego poziomu hierarchii projektu, obejmującej strukturę blokową kompletnego systemu bezpieczeństwa typu Firewall, zaimplementowanego w logice reprogramowalnej FPGA (Rys. 5.3), a skończywszy na omówieniu budowy wewnętrznej najmniejszych elementów składowych. W stosunku do nakreślonej wcześniej koncepcji wykorzystania dedykowanych modułów weryfikujących pakiety dla każdej ze ścieżek komunikacyjnych pewnym odstępstwem wydawać się może zastosowanie w klasyfikatorze wewnętrznego mechanizmu kolejkowania typu Round-Robin. Jednakże, jak to zostanie wykazane, uzyskane w praktyce bardzo duże przepustowości prototypowych wersji filtrów adresów i portów sieciowych pozwoliły zastosować pojedynczy klasyfikator do równoczesnej analizy danych pochodzących z wielu ścieżek. Wpłynęło to na znaczne ograniczenie ilości alokowanych zasobów sprzętowych logiki reprogramowalnej FPGA przy jednoczesnym zapewnieniu niezbędnej wydajności przetwarzania informacji. Co więcej, ogromna elastyczność opracowanego rozwiązania pozwala w łatwy sposób dostosować system bezpieczeństwa do realnych wymagań użytkownika, wyłączając, w razie potrzeby, mechanizm kolejkowania i dedykując każdemu kanałowi transmisyjnemu oddzielny blok klasyfikujący. Na rysunku 5.3 linią przerywaną zaznaczono docelową lokalizację modułu trasującego. Jego implementacja, jak to zostało zasygnalizowane już wcześniej, jest niezbędna w sytuacji zwiększenia liczby obsługiwanych interfejsów sieciowych. Istotnym jest fakt przygotowania koncepcji architektury sprzętowego Firewalla do wdrożenia w przyszłości takiego rozszerzenia funkcjonalnego. 107

108 pin_phy_0_reset_n pin_phy_0_col pin_phy_0_crs pin_phy_0_rx_clk pin_phy_0_rx_dv pin_phy_0_rx_error pin_phy_0_rx_data(3:0) pin_phy_0_tx_clk pin_phy_0_tx_en pin_phy_0_tx_data(3:0) pin_phy_0_int_n pin_phy_0_mdc pin_phy_0_mdio pin_phy_1_reset_n pin_phy_1_col pin_phy_1_crs pin_phy_1_rx_clk pin_phy_1_rx_dv pin_phy_1_rx_error pin_phy_1_rx_data(3:0) pin_phy_1_tx_clk pin_phy_1_tx_en pin_phy_1_tx_data(3:0) pin_phy_1_int_n pin_phy_1_mdc pin_phy_1_mdio eth_0_config eth_mac_0_mii_config(15:0) eth_mac_0_mac_address(47:0) eth_mac_0_multicast_en eth_mac_0_promiscous_en eth_mac_0_crc_en eth_mac_0_padding_en eth_1_config eth_mac_1_mii_config(15:0) eth_mac_1_mac_address(47:0) eth_mac_1_multicast_en eth_mac_1_promiscous_en eth_mac_1_crc_en eth_mac_1_padding_en moduł fw_top.vhd r_mii_config(15:0) r_rx_mac_address(47:0) r_rx_multicast_en r_rx_promiscous_en r_tx_crc_en r_tx_padding_en reset sys_clk reset sys_clk phy_tx_clk eth_mac_tx_frame_size(10:0) eth_mac_tx_frame_size(10:0) eth_mac_tx_data_ack eth_mac_tx_ok eth_mac_tx_error eth_mac_tx_data_ack eth_mac_tx_ok eth_mac_tx_error eth_mac_tx_data(7:0) eth_mac_tx_retransmit phy_mdc phy_mdio eth_mac_tx_data(7:0) eth_mac_tx_active eth_mac_tx_retransmit eth_mac_tx_enable phy_int_n eth_mac_tx_active eth_mac_ready_tx phy_tx_clk phy_tx_en phy_tx_data(3:0) eth_mac_tx_enable phy_rx_data(3:0) eth_mac_rx_ok eth_mac_rx_error eth_mac_rx_frame_size(10:0) phy_rx_error phy_rx_dv eth_mac_rx_active eth_mac_rx_data(7:0) eth_mac_rx_data_valid eth_mac_rx_active eth_mac_rx_data(7:0) eth_mac_rx_data_valid eth_mac_rx_ok eth_mac_rx_error eth_mac_rx_frame_size(10:0) phy_rx_clk phy_col phy_crs phy_rx_clk eth_mac_rx_enable eth_mac_rx_pause eth_mac_rx_pause eth_mac_rx_enable phy_reset_n eth_mac_ready eth_mac_ready_rx eth_mac fw_engine eth_1 : fw_engine_1 : Router r_mii_config(15:0) r_rx_mac_address(47:0) r_rx_multicast_en r_rx_promiscous_en r_tx_crc_en r_tx_padding_en reset sys_clk reset sys_clk phy_tx_clk eth_mac_tx_frame_size(10:0) eth_mac_tx_frame_size(10:0) eth_mac_tx_data_ack eth_mac_tx_ok eth_mac_tx_error eth_mac_tx_data_ack eth_mac_tx_ok eth_mac_tx_error eth_mac_tx_data(7:0) eth_mac_tx_retransmit phy_mdc phy_mdio eth_mac_tx_data(7:0) eth_mac_tx_active eth_mac_tx_retransmit eth_mac_tx_enable phy_int_n eth_mac_tx_active eth_mac_ready_tx phy_tx_clk phy_tx_en phy_tx_data(3:0) eth_mac_tx_enable phy_rx_data(3:0) eth_mac_rx_ok eth_mac_rx_error eth_mac_rx_frame_size(10:0) phy_rx_error phy_rx_dv eth_mac_rx_active eth_mac_rx_data(7:0) eth_mac_rx_data_valid eth_mac_rx_active eth_mac_rx_data(7:0) eth_mac_rx_data_valid eth_mac_rx_ok eth_mac_rx_error eth_mac_rx_frame_size(10:0) phy_rx_clk phy_col phy_crs phy_rx_clk eth_mac_rx_enable eth_mac_rx_pause eth_mac_rx_pause eth_mac_rx_enable phy_reset_n eth_mac_ready eth_mac_ready_rx eth_mac fw_engine eth_0 : fw_engine_0 : clas_eth_frame_type(15:0) clas_ip_protocol(7:0) clas_ip_sa(31:0) clas_ip_da(31:0) clas_s_port(15:0) clas_d_port(15:0) clas_desc_ready clas_ready clas_result(7:0) clas_eth_frame_type(15:0) clas_ip_protocol(7:0) clas_ip_sa(31:0) clas_ip_da(31:0) clas_s_port(15:0) clas_d_port(15:0) clas_desc_ready clas_ready clas_result(7:0) Classifier : clas_0_eth_frame_type(15:0) classifier_main policy_we clas_0_ip_protocol(7:0) clas_0_ip_sa(31:0) clas_0_ip_da(31:0) address_we address_wr_data((tcam_width/4)-1:0) address_wr_addr(log2_ceil(number_of_rules-1)+3:0) clas_0_s_port(15:0) clas_0_d_port(15:0) clas_0_desc_ready clas_0_ready clas_0_result(7:0) clas_1_eth_frame_type(15:0) clas_1_ip_protocol(7:0) clas_1_ip_sa(31:0) clas_1_ip_da(31:0) port_we port_wr_data(27:0) port_wr_addr(log2_ceil(number_of_rules-1)+3:0) action_we action_ram_data(7:0) action_wr_addr(log2_ceil(number_of_rules-1)-1:0) clas_1_s_port(15:0) clas_1_d_port(15:0) clas_1_desc_ready clas_1_ready clas_1_result(7:0) reset sys_clk PolicyLoader : reset sys_clk rs232_active fw_policy_loader action_wr_addr(log2_ceil(number_of_rules-1)-1:0) action_ram_data(7:0) action_we port_wr_addr(log2_ceil(number_of_rules-1)+3:0) port_wr_data(27:0) port_we address_wr_addr(log2_ceil(number_of_rules-1)+3:0) address_wr_data((tcam_width/4)-1:0) address_we policy_we RS232_TxD RS232_RxD monitoring eth_mac_0_ready led_0 eth_mac_1_ready led_1 rs232_active led_2 led_3 sw_0 sw_1 sw_2 sw_3 pin_sys_clk pin_reset pin_rs232_tx pin_rs232_rx pin_led_0 pin_led_1 pin_led_2 pin_led_3 pin_sw_0 pin_sw_1 pin_sw_2 pin_sw_3 Rys Struktura wewnętrzna kompletnego systemu zabezpieczania transmisji danych typu Firewall 108

109 5.2. Silnik sprzętowego systemu typu Firewall Mianem silnika systemu Firewall określono w niniejszej rozprawie zbiór modułów, które funkcjonalnie odpowiadają za wszelkie operacje związane z odpowiednim przygotowaniem analizowanych danych do procesu ich weryfikacji w sprzętowym klasyfikatorze pakietów. Do operacji tych zaliczamy przede wszystkim wygenerowanie deskryptorów bezpieczeństwa oraz wspomaganie klasyfikacji poprzez mechanizmy pamięci podręcznej (ang. cache memory) Schemat blokowy Silnik sprzętowego Firewalla, którego poglądowy schemat blokowy zaprezentowano na rysunku 5.4, składa się z czterech podstawowych elementów: kontrolera pamięci ramkowej moduł fw_page_mgr, bloku generującego deskryptor bezpieczeństwa moduł fw_parser, pamięci podręcznej cache wspomagającej klasyfikację moduł fw_cache, modułu kontrolnego fw_control. Silnik Firewalla MAC 0 RX fw_parser Deskryptor MAC 1 TX fw_page_mgr fw_cache Klasyfikator fw_control Akcja Rys Schemat blokowy silnika Firewalla. Dane odbierane z kontrolera MAC trafiają do specjalnie zorganizowanej pamięci ramkowej, w której każdej ramce odpowiada dedykowana strona pamięci. Zarówno klasyfikator pakietów, jak i tor transmisyjny TX kontrolera MAC dysponuje własną kopią zawartości ramek, stąd możliwa jest ich niezależna praca. W efekcie uzyskiwany jest znaczny wzrost wydajności przetwarzania danych proces klasyfikacji informacji nie wpływa na transmisję ramek wcześniej zweryfikowanych. Do przeprowadzenia oceny zgodności ramki z definicjami reguł bezpieczeństwa niezbędny jest jedynie niewielki fragment jej zawartości. Moduł fw_parser generuje z odpowiednich pól odbieranych ramek specjalny deskryptor bezpieczeństwa, używany do dalszego procesu klasyfikacji informacji. 109

110 Dodatkowym elementem optymalizującym szybkość pracy silnika Firewalla jest pamięć podręczna cache. Trafiają do niej dane z deskryptorów bezpieczeństwa wraz z informacją o akcji, jaką zgodnie z obowiązującym schematem reguł bezpieczeństwa należy wykonać z przetwarzaną ramką. W przypadku trafienia w pamięć cache, czyli odebrania tego samego deskryptora bezpieczeństwa, który został już wcześniej w pamięci zapisany, wynik klasyfikacji dostępny jest w ciągu jednego taktu zegara. Jest to możliwe dzięki wykorzystaniu do budowy pamięci wspomagającej architektury typu CAM (ang. Content Addressable Memory). Pełny schemat strukturalny silnika zapory ogniowej, uwzględniający wewnętrzne linie sygnałowe oraz wyprowadzenia poszczególnych interfejsów, przedstawiono na rysunku 5.5. Szczegółowy opis funkcji poszczególnych sygnałów zawarto w dodatku A, punkt 8.7. moduł fw_engine.vhd Interfejs kontrolerów MAC eth_mac_ready_rx phy_rx_clk eth_mac_rx_enable eth_mac_rx_pause eth_mac_rx_active eth_mac_rx_data(7:0) eth_mac_rx_data_valid eth_mac_rx_ok eth_mac_rx_error eth_mac_rx_frame_size(10:0) eth_mac_ready_tx phy_tx_clk eth_mac_tx_enable eth_mac_tx_active eth_mac_tx_retransmit eth_mac_tx_data(7:0) eth_mac_tx_data_ack eth_mac_tx_ok eth_mac_tx_error eth_mac_tx_frame_size(10:0) eth_mac_ready_rx phy_rx_clk eth_mac_rx_enable eth_mac_rx_pause eth_mac_rx_active eth_mac_rx_data(7:0) eth_mac_rx_data_valid eth_mac_rx_ok eth_mac_rx_error eth_mac_rx_frame_size(10:0) eth_mac_ready_tx phy_tx_clk eth_mac_tx_enable eth_mac_tx_active eth_mac_tx_retransmit eth_mac_tx_data(7:0) eth_mac_tx_data_ack eth_mac_tx_ok eth_mac_tx_error eth_mac_tx_frame_size(10:0) fw_page_mgr sys_clk reset fw_fifo_tx_wr_en fw_fifo_tx_descr_wr(15:0) fw_fifo_tx_full fw_fifo_rx_rd_en fw_fifo_rx_descr_rd(15:0) fw_fifo_rx_empty fw_frame_mem_page(3:0) fw_frame_mem_data(31:0) fw_frame_mem_addr(8:0) fw_frame_mem_rd_en fw_drop_page fw_drop_page_ack sys_clk reset Zegar i reset systemowy Interfejs klasyfikatora pakietów clas_eth_frame_type(15:0) clas_ip_header_leght(3:0) clas_ip_protocol(7:0) clas_ip_sa(31:0) clas_ip_da(31:0) clas_s_port(15:0) clas_d_port(15:0) clas_ready clas_result clas_desc_ready fw_parser fw_tagged_frame fw_eth_frame_type(15:0) fw_ip_header_leght(3:0) fw_ip_protocol(7:0) fw_ip_sa(31:0) fw_ip_da(31:0) fw_s_port(15:0) fw_d_port(15:0) sys_clk reset fw_drop_page_ack fw_drop_page fw_frame_mem_rd_en fw_frame_mem_addr(8:0) fw_frame_mem_data(31:0) fw_frame_mem_page(3:0) fw_fifo_rx_empty fw_fifo_rx_descr_rd(15:0) fw_fifo_rx_rd_en fw_fifo_tx_full fw_fifo_tx_descr_wr(15:0) fw_fifo_tx_wr_en fw_sec_check_ack fw_sec_action fw_desc_ready fw_cache fw_d_port(15:0) fw_s_port(15:0) fw_ip_da(31:0) fw_ip_sa(31:0) fw_ip_protocol(7:0) fw_ip_header_leght(3:0) fw_eth_frame_type(15:0) sys_clk reset fw_cache_ready fw_cache_clr fw_cache_wr_en fw_cache_wr_action fw_cache_hit fw_cache_action fw_classify_ready fw_classify_result fw_control sys_clk reset fw_cache_action fw_cache_hit fw_cache_wr_action fw_cache_wr_en fw_cache_clr fw_cache_ready fw_desc_ready fw_sec_action fw_sec_check_ack Rys Struktura wewnętrzna modułu fw_engine. 110

111 Kontroler pamięci ramkowej Pamięć ramkowa (Rys. 5.6) zbudowana w oparciu o wewnętrzne zasoby pamięci blokowej Block SelectRAM+ układu Virtex II Pro firmy Xilinx [134], podzielona jest na strony. Każdej stronie odpowiada dedykowany blok pamięci BRAM o pojemności 2304 bajtów. Rozmiar taki pozwala na zapisanie do pojedynczej strony ramki Ethernetowej o maksymalnej dopuszczonej standardem długości wynoszącej 1518 bajtów [40]. Liczba stron pamięci ramek dla danego bloku FW jest parametryzowana i zależy od typu zastosowanego układu FPGA. Opracowana koncepcja organizacji pamięci ramkowej oraz modułu zarządzającego zwiększa wydajność pracy Firewalla poprzez umożliwienie transmisji ramek zweryfikowanych pod kątem zgodności z regułami bezpieczeństwa, niezależnie od analizowania bieżąco napływających danych. Taką funkcjonalność osiągnięto dzięki wykorzystaniu dwóch niezależnych pamięci ramkowych: jednej dla modułu analizującego ramki, a drugiej dla toru transmisyjnego TX właściwej karty sieciowej. Kontroler pamięci ramkowej MAC 0 RX FSM sterujący toru RX FIFO deskryptorów RX Pamięć ramek Firewall a Pamięć ramek toru TX FSM zarządzający pustymi stronami FIFO pustych stron Moduł weryfikujący reguły bezpieczeństwa MAC 1 TX FSM sterujący toru TX FIFO deskryptorów TX Rys Schemat blokowy modułu pamięci ramkowej fw_page_mgr. Dane każdej odebranej ramki trafiają z modułu MAC - kontrolera sieci Ethernet jednocześnie do obydwu pamięci pod ten sam adres strony. W tym samym momencie utworzony zostaje deskryptor parametryczny ramki, zawierający informację o jej długości i numerze strony, pod jaką została ona zapisana. Deskryptor ten zapisywany jest następnie do kolejki FIFO toru RX, z której zostanie pobierany przez moduł analizy bezpieczeństwa. Silnik Firewalla posiada w tej sytuacji niezbędny zestaw informacji, aby rozpocząć pobieranie nagłówka ramki Ethernetowej, na podstawie którego dokona weryfikacji jej zgodności ze schematem reguł bezpieczeństwa. Taka analiza, w zależności od liczby reguł wprowadzonych do Firewalla oraz od zastosowanych algorytmów wyszukujących, może trwać przez czas przekraczający odbiór ramki Ethernetowej o minimalnej 111

112 długości (60 bajtów). W najbardziej niekorzystnym przypadku, kiedy w trakcie weryfikacji bezpieczeństwa odbieramy ciąg krótkich następujących po sobie ramek, pamięć może ulec przepełnieniu (zabraknie wolnych stron), co może skutkować utratą części przesyłanych danych. Aby temu zapobiec, można w trakcie analizowania ramek transmitować równolegle wszystkie te, które zostały już zaakceptowane przez moduł weryfikujący, zwalniając tym samym strony w pamięci ramkowej (Rys. 5.7). Odczyt pierwszej ramki Odczyt drugiej ramki oraz równoległa transmisja pierwszej, która została już wcześniej zweryfikowana Rys Przebiegi czasowe sygnałów modułu fw_page_mgr w trakcie pracy Firewalla. Po zakończeniu analizy ramki w klasyfikatorze moduł weryfikujący generuje deskryptor, który zapisany zostaje do kolejki FIFO TX. Tor nadawczy kontrolera MAC sięga do niej, pobierając dane o kolejnych ramkach wymagających przesłania, niezależnie od zadań wykonywanych przez moduł weryfikujący. Zakończenie transmisji danej ramki przez tor TX kończy się zwolnieniem odpowiedniej strony w pamięci ramkowej i próbą pobrania kolejnego deskryptora z FIFO TX, o ile istnieją jakiekolwiek dane do przesłania. Zwalnianie stron następuje nie tylko po zakończeniu transmisji ramki przez tor TX kontrolera MAC, lecz również w momencie odrzucenia danej ramki w module weryfikującym reguły bezpieczeństwa. Lista pustych stron pamięci ramkowej przechowywana jest w specjalnej kolejce FIFO, zarządzanej przez dedykowany automat stanów FSM. Moduł został zaprojektowany w sposób umożliwiający łatwe zwiększenie liczby dostępnych stron w przypadku wykorzystania nowszych technologicznie układów FPGA. 112

113 Moduł generujący deskryptor bezpieczeństwa Zadaniem modułu fw_parser jest generowanie dla każdej przetwarzanej ramki deskryptora bezpieczeństwa złożonego z następujących pól: fw_eth_frame_type (15:0) typ ramki Ethernet, fw_ip_header_legth (3:0) długość nagłówka IP, fw_ip_protocol (7:0) typ protokołu IP, fw_ip_sa (31:0) adres źródłowy nagłówka IP, fw_ip_da (31:0) adres docelowy nagłówka IP, fw_s_port (15:0) port źródłowy nagłówka TCP/UDP, fw_d_port (15:0) port docelowy nagłówka TCP/UDP. Moduł parsujący odczytuje z kolejki FIFO RX kontrolera pamięci ramkowej fw_page_mgr kolejne 16-bitowe deskryptory parametryczne, zawierające 5-bitowy numer strony pamięci oraz 11-bitowe pole długości danej ramki. Po zakończeniu procesu weryfikacji danych, sygnalizowanego wysokim stanem linii fw_sec_check_ack (Rys. 5.8), moduł fw_parser przesyła deskryptor parametryczny dla toru TX (sygnał fw_fifo_tx_descr_wr) wraz z informacją o akceptacji bądź odrzuceniu analizowanej ramki (sygnał fw_sec_action). Zgłoszenie gotowości deskryptora bezpieczeostwa Potwierdzenie zakooczenia weryfikacji ramki Rys Przebiegi czasowe sygnałów modułu fw_parser w trakcie pracy Firewalla Pamięć wspomagająca cache Poszukując różnorodnych dróg zwiększenia maksymalnej wydajności przetwarzania danych [114] autor opracował dodatkowy moduł pamięci podręcznej cache (Rys. 5.9), wspomagającej proces weryfikacji pakietów. 113

114 sys_clk fw_eth_frame_type (15:0) fw_ip_header_leght (3:0) fw_ip_protocol (7: 0) fw_ip_sa (31:0) fw_ip_da (31:0) fw_s_portin (15:0) fw_d_port (15:0) din - typ ramki ethernetowej - długość nagłówka IP - typ protokołu IP - adres źródłowy nagłówka IP - adres docelowy nagłówka IP - port źródłowy nagłówka TCP/UDP - port docelowy nagłówka TCP/UDP reset sys_clk reset fw_desc_ready fw_sec_check_ack fw_sec_drop_page fw_classify_ready fw_classify_result CAM_A : pamięć CAM na ramki zaakceptowane Cache Memory Cache Control clk din (123:0) we wr_addr (4:0) mycam 124 x 32 busy match match_addr (31:0) rst clk Cache Memory FSM Cache Control FSM sys_clk cam_a_busy fw_cache_ready fw_cache_ready reset cam_a_wr_addr (4:0) cam_a_wr_en cam_d_wr_addr (4:0) fw_cache_clr fw_cache_wr_en fw_cache_wr_drop CACHE CONTROL fw_cache_clr fw_cache_wr_en fw_cache_wr_drop fw_desc_ready fw_sec_check_ack fw_sec_drop_page CAM_D : pamięć CAM na ramki odrzucane cam_d_wr_en cam_d_busy fw_cache_hit fw_cache_drop_page fw_classify_ready fw_classify_result clk din (123:0) we wr_addr (4:0) mycam 124 x 32 busy match match_addr (31:0) CacheHit cam_a_match fw_cache_hit cam_d_match fw_cache_hit fw_cache_drop_page Rys Poglądowy schemat blokowy pamięci wspomagającej cache. Koncepcja funkcjonowania pamięci wspomagającej opiera się na zapamiętywaniu deskryptorów bezpieczeństwa wraz z odpowiadającą im akcją (odrzucenie lub zaakceptowanie) w specjalnie do tego celu zaprojektowanym module. Idealnie w ten typ zastosowań wpasowują się pamięci adresowane zawartością typu CAM, w których informację wyjściową stanowi potwierdzenie obecności w pamięci danych podanych na jej wejście. W przypadku opracowanego rozwiązania sygnał wejściowy o szerokości 124 bitów stanowi złożenie wszystkich pól deskryptora bezpieczeństwa. Aby zapisać w pamięci informację o odrzuceniu ramki bądź jej akceptacji, wykorzystano dwa niezależne bloki CAM, każdy o pojemności 32 słów, umożliwiające zapamiętanie łącznie do 32 ramek. Wartość ta jest w pełni parametryzowana, co pozwala na łatwe skalowanie rozmiaru pamięci podręcznej w przypadku wykorzystywania nowszych układów FPGA dysponujących zdecydowanie większą ilością zasobów wewnętrznych. W przypadku stwierdzenia obecności analizowanego deskryptora w którejkolwiek z komórek pamięci ramek zaakceptowanych (oznaczonych na rysunku 5.9 jako CAM_A) lub ramek odrzuconych (oznaczonych na rysunku 5.9 jako CAM_D), sygnał fw_cache_hit przyjmuje wysoki poziom logiczny. Informacja o akcji, jaka powinna być wykonana w odniesieniu do analizowanej ramki, przenoszona jest przez sygnały cam_a_match oraz cam_d_match. Ich aktywacja oznacza odpowiednio konieczność przesłania danych z pamięci ramkowej do toru TX (Rys. 5.10) albo skasowania danej strony pamięci (dla ramek odrzuconych). W sytuacji niestwierdzenia obecności deskryptora w pamięci wspomagającej cache, sygnał fw_cache_hit pozostaje na niskim poziomie logicznym, co jest równoznaczne z wymogiem weryfikacji danej ramki w klasyfikatorze. Wówczas moduł zarządzający 114

115 fw_control, omówiony szerzej w rozdziale 5.2.5, zgłasza konieczność zapisu nowego deskryptora bezpieczeństwa pod kolejną dostępną lokalizację w pamięci cache. Jeżeli pamięć wspomagająca zostanie wypełniona w całości, zapis kolejnych deskryptorów rozpoczyna się ponownie od pierwszego adresu, tym samym wcześniejsze dane zostają nadpisane. Sygnalizacja trafienia w pamięd ramek zaakceptowanych Sygnalizacja trafienia w cache Rys Przebiegi czasowe sygnałów modułu fw_cache w trakcie pracy Firewalla. W pierwszym etapie prac badawczych wykorzystywano pamięci CAM wygenerowane przy użyciu komercyjnego oprogramowania COREGenerator firmy Xilinx [136]. Jednak ze względu na brak możliwości zmiany wewnętrznej struktury otrzymanego w ten sposób modułu, autor opracował alternatywną koncepcję realizacji pamięci CAM, pozwalającą zarówno na optymalizację wydajnościową, jak również minimalizację ilości niezbędnych zasobów sprzętowych. Bazuje ona na referencyjnych dokumentacjach pamięci CAM firmy Xilinx [127, 131], wykorzystujących generatory funkcji z konfigurowalnych bloków logicznych CLB (ang. Configurable Logic Blocks) układów Virtex II Pro firmy Xilinx, pracujące jako rejestry przesuwne typu SRL16E. Każdy z wierszy matrycy komórek pamięci CAM (Rys. 5.11) złożony jest z kaskady elementarnych rejestrów SRL16E włączonych do łańcucha przeniesień (ang. Carry Chain) zbudowanego przy pomocy multiplekserów MUXCY. Blok kontrolera CAM odpowiada za buforowanie danych wejściowych, a także generowanie i dekodowanie sygnału trafienia oraz obsługę procesu zapisu danych do pamięci. Spośród tych trzech funkcjonalności najbardziej złożoną, a zarazem czasochłonną jest zapis danych. Adres, pod który ma zostać zapisana ramka, odzwierciedla stan sygnału wr_addr. Po konwersji w dekoderze gorącej jedynki (ang. hot one) aktywuje on właściwy wiersz matrycy komórek CAM. Zapis pojedynczego słowa wejściowego zajmuje 16 cykli sygnału zegarowego. Wynika to z konieczności wprowadzenia do rejestrów SRL16E 16-bitowych wektorów kodujących części słowa 115

116 wejściowego. Wewnętrzny licznik zapisu wr_cnt porównywany jest w sekcji komparatorów z 4-bitowymi fragmentami sygnału wejściowego d in. Dzięki temu, dla adresów składowych zgodnych z danymi wejściowymi, w słowach wpisywanych do poszczególnych rejestrów ustawione zostają jedynki logiczne. clk wr_addr busy wr_en din... match match_addr(0) match_addr(1)... match_addr(n) out(n) in Binary to Hot One out(1) out(0) en D D... D Q Q Q... Q CLK Latches CLK Latches wr_busy wr_latch wr_counter INIT X 1111" wr_en clk wr_cnt(3:0) wr_cnt CE Q Q... Q... wr_cnt CE match D D D D Comparator Comparator Comparator out In(n) In_A(3:0) In_B(3:0) In_A(3:0) In_B(3:0)... In_A(3:0) In_B(3:0) Match Decoder In(1)... out out out In(0) CLK CE(0) CE(1) CE(n)... D(0) din(0)(3:0) D(1) din(1)(3:0) CAM Controller D(n) din(n)(3:0) match_addr(0) match_addr(1)... match_addr(n) COLUMN 0 COLUMN 1 COLUMN <m> MUXCY MUXCY MUXCY 0 1 CI O DI S 0 CI O DI S... 0 CI O DI S ROW 0... A(3:0) D SRL16E Q CE INIT X"0000" A(3:0) D SRL16E Q CE INIT X"0000" A(3:0) D SRL16E Q CE INIT X"0000" CLK CLK CLK MUXCY MUXCY MUXCY 0 1 CI O DI S 0 CI O DI S... 0 CI O DI S... A(3:0) A(3:0) A(3:0) ROW 1 D SRL16E Q CE INIT X"0000" CLK D SRL16E Q CE INIT X"0000" CLK D SRL16E Q CE INIT X"0000" CLK MUXCY MUXCY MUXCY 0 1 CI O DI S 0 CI O DI S... 0 CI O DI S A(3:0) A(3:0) A(3:0) ROW <n> D SRL16E Q CE INIT X"0000" CLK D SRL16E Q CE INIT X"0000" CLK D SRL16E Q CE INIT X"0000" CLK CAM Storage Elements Rys Schemat blokowy implementacji pamięci CAM opartej o rejestry przesuwne SRL16E. 116

117 Po przejściu pamięci CAM w tryb odczytu podane słowo wejściowe adresuje kolumny rejestrów wewnętrznych we wszystkich wierszach matrycy. Jeżeli wyjście Q każdego z rejestrów w danym wierszu jest w wysokim stanie logicznym, kontroler pamięci CAM sygnalizuje trafienie (wysoki poziom logiczny na wyjściu match). Kodowanie wierszy, które zawierają dane zgodne ze słowem wejściowym, realizowane jest w formie binarnej poprzez sygnał match_addr. Opracowane rozwiązanie pamięci CAM, w porównaniu do wersji uzyskanej za pomocą oprogramowania COREGenerator, charakteryzuje się nieznacznie mniejszym zapotrzebowaniem na zasoby sprzętowe (rzędu kilku procent). Jego główną zaletą jest natomiast możliwość parametryzowania, pozwalająca na elastyczne dostosowywanie do konfiguracji całego systemu Firewall, jak również możliwość dalszego rozwoju podnoszącego maksymalną wydajność czy też redukującego ilość zasobów logicznych niezbędnych do realizacji pamięci. Porównanie wyników syntezy obu wersji pamięci CAM przedstawia tabela 5.1. Pełny raport syntezy uwzględniający szczegółową informację o wszystkich rodzajach wykorzystanych zasobów sprzętowych zamieszczono w dodatku A, punkt 9.9. Tab Porównanie wykorzystania zasobów sprzętowych komercyjnej wersji pamięci CAM z opracowaniem własnym autora dla układu Xilinx 2vp30ff Wersja pamięci CAM 124 bity CAM CoreGen 6 Opracowanie własne autora Liczba wierszy pamięci Liczba bloków Slice Liczba 4-wejściowych LUT Maksymalna częstotliwość pracy [MHz] , , , , , , , , , , Moduł zarządzający Funkcjonowaniem bloku silnika systemu Firewall steruje moduł zarządzający fw_control. Monitoruje on nieustająco kolejkę deskryptorów bezpieczeństwa, tak, aby po pojawieniu się nowych danych niezwłocznie rozpocząć procedurę ich analizy, według algorytmu zaprezentowanego na rysunku Wpierw sprawdzana jest obecność danego deskryptora w pamięci wspomagającej cache. Jeżeli taka sytuacja ma miejsce, w ciągu jednego cyklu zegara systemowego odczytywana jest akcja, jaką należy dokonać wobec analizowanej ramki. Proces przetwarzania ramki od momentu otrzymania nowego deskryptora bezpieczeństwa do wysłania potwierdzenia zakończenia weryfikacji zajmuje w tym wypadku trzy pełne cykle zegarowe (Rys. 5.13). Przy braku obecności danego deskryptora w pamięci wspomagającej cache moduł fw_control oczekuje na zakończenie weryfikacji danych w klasyfikatorze sprzętowym, sygnalizowane wysokim 117

118 poziomem logicznym na linii fw_classify_ready. Klasyfikator przekazuje do modułu zarządzającego, za pomocą sygnału fw_classify_result, informację o akcji niezbędnej do wykonania wobec przetwarzanej ramki (odrzucenie bądź transmisja do stacji docelowej). Sprawdź deskryptor Czy jest nowy deskryptor? Nie Tak Sprawdź cache Czy deskryptor jest w cache u? Nie Oczekuj na weryfikację Tak Wyślij potwierdzenie weryfikacji Ramka zweryfikowana? Nie Tak Zapisz deskryptor do pamięci cache Rys Algorytm funkcjonowania modułu zarządzającego fw_control. Wówczas moduł zarządzający inicjuje zapis nowego deskryptora bezpieczeństwa do pamięci cache, a następnie wysyła potwierdzenie zakończenia weryfikacji danych (wysoki poziom logiczny na linii fw_sec_check_ack). Otrzymanie deskryptora Wysłanie potwierdzenia weryfikacji Oczekiwanie na deskryptor Trafienie w cache Informacja o akcji Rys Przebiegi czasowe sygnałów modułu fw_control w trakcie pracy Firewalla. 118

119 Wyniki implementacji Opracowany moduł silnika Firewalla został zaimplementowany na platformie testowej FPGA z układem Xilinx Virtex II Pro XC2VP30. Wyniki wykorzystania zasobów sprzętowych logiki reprogramowalnej oraz uzyskane parametry czasowe bloku silnika przedstawiono w tabeli 5.2. Pełne wyniki implementacji poszczególnych modułów składowych zamieszczono w dodatku B, punkt Tab Podsumowanie wykorzystania zasobów sprzętowych układów FPGA przez silnik Firewalla. Rodzaj zasobów Typ układu Virtex 2vp30ff896-7 Liczba bloków Slice 2492 Liczba 4-wejściowych LUT 2527 Parametry czasowe Maks. częstotliwość 190,422 MHz Maks. opóźnienie ścieżki kombinacyjnej 3,867 ns Maksymalna częstotliwość pracy układu raportowana przez narzędzia do syntezy logicznej, wynosi około 190 MHz. Jest ona limitowana głównie wydajnością zastosowanej pamięci CAM. Warto w tym miejscu zwrócić uwagę na fakt, że częstotliwość uzyskana przy analizie całego bloku silnika jest większa o około 50 MHz (dla pamięci CAM o pojemności 32 słów) od wskazanej w tabeli 5.1, zawierającej dane dotyczące syntezy różnych wariantów pamięci CAM. Wynika to z rezygnacji z implementacji bloku dekodera adresu trafienia wewnątrz struktury kontrolera CAM w finalnej wersji silnika. Usunięcie zbędnej logiki kombinacyjnej zwiększa w tym wypadku efektywność pracy układu o ponad 35% Sprzętowy klasyfikator pakietów Zadaniem klasyfikatora pakietów w sprzętowym systemie bezpieczeństwa typu Firewall jest weryfikacja zgodności przetwarzanych danych z obowiązującym schematem polityki bezpieczeństwa. Dokonuje się ona poprzez przyporządkowanie analizowanych pakietów do zestawu odpowiadających im reguł bezpieczeństwa na podstawie informacji zawartych w nagłówkach protokołu IP. Ze względu na uwarunkowania implementacyjne proces klasyfikacji podzielony jest na dwa odrębne obszary: adresację sieciową wraz z informacją o typie protokołu oraz porty sieciowe. Najbardziej popularną metodą sprzętowego klasyfikowania adresów jest wykorzystanie pamięci trójwartościowych TCAM [31, 32, 33, 81, 94, 97]. Wynika to ze specyficznych własności tego typu pamięci, a przede wszystkim z ich zdolności do przechowywania informacji o wartościach nieistotnych, oznaczanych w opisach znakiem gwiazdki *. Taka funkcjonalność idealnie odpowiada 119

120 potrzebom klasyfikatora adresów sieciowych. Definicje reguł bezpieczeństwa w części dotyczącej adresacji pakietów złożone są z dwóch elementów: 32-bitowego adresu sieciowego protokołu IP oraz 32-bitowej maski podsieci (ang. Subnetwork Mask), wyodrębniającej z adresu IP część sieciową oraz część hosta. Pamięć TCAM umożliwia zapisanie tych dwóch wartości dla poszczególnych reguł bezpieczeństwa i bardzo szybkie uzyskanie informacji o trafieniu (w przeciągu jednego cyklu zegarowego). Pomimo wielu zalet pamięci TCAM nie są optymalnym rozwiązaniem dla celów klasyfikacji portów, w szczególności dla reguł zawierających ich zakresy [5, 58, 62, 97]. Niestety, takie przypadki są powszechne w produkcyjnych systemach Firewall, gdzie dla uzyskania zamierzonego kształtu polityki bezpieczeństwa administratorzy wielokrotnie posługują się definicjami zawierającymi szerokie przedziały portów. Aktualnie wiele zespołów badawczych na całym świecie koncentruje się na poszukiwaniu szybkich oraz efektywnych (od strony zapotrzebowania na zasoby pamięciowe) rozwiązań analizowania zakresów portów [1, 5, 58, 62, 93, 97] Schemat blokowy Poglądowy schemat blokowy modułu klasyfikatora pakietów został przedstawiony na rysunku 5.14, a opis funkcji poszczególnych sygnałów zamieszczono w dodatku A, punkt 8.8. Niezbędne do przeprowadzenia weryfikacji przetwarzanych pakietów informacje wejściowe przekazywane są do modułu ze specjalnego bloku pamięci ramkowej, szerzej omawianego w rozdziale Opracowane przez autora rozwiązanie pozwala na równoczesną analizę danych pochodzących z wielu interfejsów sieciowych, przy wykorzystaniu algorytmu karuzelowego (ang. Round-Robin), sprawdzającego cyklicznie dostępność nowych deskryptorów. Jeżeli dla aktualnie monitorowanego wejścia zgłoszony zostanie sygnał obecności deskryptora, główny automat sterujący rozpoczyna procedurę weryfikacji pakietu, blokując proces kolejkowania na czas niezbędny do jej przeprowadzenia. Odczytywane deskryptory bezpieczeństwa składają się z następujących pól nagłówków przetwarzanych pakietów: typu protokołu sieciowego (16 bitów), typu protokołu transportowego (8 bitów), adresu źródłowego (32 bity), adresu docelowego (32 bity), numeru portu źródłowego (16 bitów), numeru portu docelowego (16 bitów). Pierwsze cztery pola o łącznej długości 88 bitów trafiają do modułu filtrującego adresy oraz typ protokołu. Dwa ostatnie, o łącznej długości 32 bitów, kierowane są do modułu filtrującego porty. Ponieważ wynikowa informacja o trafionych regułach generowana jest na podstawie iloczynu wektorów pochodzących z dwóch niezależnych bloków filtrujących, niezbędne jest, aby każdy z nich dostarczał informację wyjściową w formie binarnej niekodowanej (poszczególnym regułom 120

121 odpowiadają dedykowane wyjścia sygnałowe). Wynik iloczynu logicznego jest następnie zamieniany w priorytetowym dekoderze gorącej jedynki (ang. hot one) na adres binarny trafionej reguły, znajdującej się najwyżej w hierarchii. Na jego podstawie z pamięci akcji odczytywana jest informacja o dalszym postępowaniu z analizowanym pakietem. Ilość obsługiwanych interfejsów zależy od ich szybkości pracy (suma przepustowości nie powinna przekraczać maksymalnej wydajności klasyfikatora) Sygnalizacja trafienia w jakąkolwiek regułę typ protokołu Nagłówek IP eth0 adr. docelowy adr. źródłowy trafione reguły adresów i protokołu Nagłówek IP eth1... konfiguracja Filtracja adresów i typu protokołu Detektor trafienia Informacja o akcji dla analizowanego pakietu Nagłówek IP eth<n> FSM sterujący Round-Robin... reguły którym odpowiada analizowany pakiet port docelowy Adres najwyższej w hierarchii trafionej reguły Zakończenie analizy port źródłowy Akcja dla pakietu Filtracja portów trafione reguły portów Inicjalizacja polityki konfiguracja Priorytetowy dekoder Hot-One Pamięć akcji Konfiguracja filtra adresów Konfiguracja filtra portów Konfiguracja pamięci akcji konfiguracja Rys Schemat blokowy sprzętowego klasyfikatora pakietów. W obecnej implementacji możliwe są dwa scenariusze: odrzucenie bądź akceptacja i w jej efekcie - retransmisja pakietu. Równocześnie w bloku detektora trafienia generowany jest sygnał potwierdzający wystąpienie przynajmniej jednej reguły, której odpowiada analizowany pakiet. W wypadku, gdyby taka reguła nie istniała, pakiet domyślnie ulega odrzuceniu. Ostatecznie informacja o zakończeniu analizy wraz z potwierdzeniem akcji trafia z modułu klasyfikatora do bloku pamięci ramkowej. Dla pakietów zaakceptowanych rozpoczyna się wówczas procedura przesyłania danych z pamięci do interfejsu nadawczego, zaś w przypadku odrzucenia pakietu - odpowiadająca mu strona pamięci zostaje zwolniona. Szczegółowa struktura sprzętowego klasyfikatora pakietów, uwzględniająca wewnętrzne linie sygnałowe oraz wyprowadzenia poszczególnych interfejsów została przedstawiona na rysunku

122 port_wr_addr port_wr_data port_we address_wr_addr address_wr_data address_we clk rst policy_we clas_1_result clas_1_ready clas_1_desc_ready clas_1_d_port clas_1_s_port clas_1_ip_da clas_1_ip_sa clas_1_ip_protocol clas_1_eth_frame_type clas_0_result clas_0_ready clas_0_desc_ready clas_0_d_port clas_0_s_port clas_0_ip_da clas_0_ip_sa clas_0_ip_protocol clas_0_eth_frame_type action_we action_ram_data action_wr_addr rst clk policy_we clas_1_result clas_1_ready clas_1_desc_ready address_data_in clas_1_d_port(15:0) clas_1_s_port(15:0) clas_1_ip_da(31:0) clas_1_ip_sa(31:0) clas_1_ip_protocol(7:0) clas_1_eth_frame_type(15:0) clas_0_result clas_0_ready clas_0_desc_ready clas_0_d_port(15:0) clas_0_s_port(15:0) clas_0_ip_da(31:0) clas_0_ip_sa(31:0) clas_0_ip_protocol(7:0) clas_0_eth_frame_type(15:0) source_port_in dest_port_in action is_matched Main FSM Round-Robin rst clk Action RAM Address Filter clk address_filter we port_match wr_data(21:0) (nr_rules-1:0) wr_addr(8:0) din_in(87:0) Port Filter port_filter clk we wr_data(27:0) match in(n) in(1) in(0) in(n) Hot One to binary out(3:0) in(1) in(0) Match detector out matched_addr matched_addr " " "0" '0' '1' "0" '1' RAMB16_S9_S9 ADDRA(10:0) DIA(7:0) DIPA WEA CLKA DOA(7:0) SSRA ENA DOPA DOB(7:0) ADDRB(10:0) DOPB DIB(7:0) DIPB WEB CLKB SSRB ENB open open open wr_addr(8:0) (nr_rules-1:0) rule_match(nr_rules-1:0) source_port_in(15:0) destination_port_in(15:0) Rys Struktura wewnętrzna sprzętowego klasyfikatora pakietów Filtr adresów sieciowych Moduł address_filter filtrujący adresy sieciowe oraz typ protokołu został zrealizowany w oparciu o pamięci trójwartościowe TCAM [107]. Jego schemat blokowy przedstawiono na rysunku Zasadniczym elementem filtru jest matryca komórek pamięci TCAM (opisana szerzej w dalszej części rozdziału) uzupełniona niezbędnymi elementami sterującymi. Część deskryptora bezpieczeństwa o długości 88 bitów, zawierająca informację o adresach sieciowych oraz typie protokołu, zostaje podana na wejście multipleksera bloku sterującego. Jeżeli sygnał inicjalizacji polityki bezpieczeństwa (address_we) jest w niskim stanie logicznym, matryca pamięci TCAM pracuje w trybie odczytu. Na jej wejście poprzez multiplekser trafiają dane deskryptora. Z kolei na wyjściu pamięci pojawia się informacja o regułach, którym odpowiada weryfikowany pakiet. Czas trwania procesu odczytu jest typowy dla TCAM i wynosi jeden cykl zegara. Natomiast, gdy sygnał inicjalizacji jest w stanie wysokim, pamięć przechodzi do trybu zapisu. Wówczas na wejścia matrycy komórek podawane są z multipleksera adresy inkrementowane w zakresie od 0 do 15, służące zapisaniu wewnętrznych wartości poszczególnych komórek pamięci TCAM danymi konfiguracji odpowiadającymi definicjom poszczególnych reguł bezpieczeństwa. Na podstawie numeru reguły 122

123 podawanego na wejście bloku sterującego, dekoder gorącej jedynki generuje sygnał zezwalający na zapis odpowiedniego wiersza. Proces zapisu definicji pojedynczej reguły zajmuje 16 cykli zegarowych. Dane konfiguracji Inicjalizacja Sygnał zezwolenia zapisu dla poszczególnych reguł Dekoder Hot-One Multiplekser Numer reguły Adres pamięci RAM16X1S Weryfikowany adres wraz z typem protokołu Weryfikowany adres wraz z typem protokołu lub dla aktywnej inicjalizacji adresacja pamięci RAM16X1S Sterowanie filtra adresów i typu protokołu Dane wejściowe/ adres dla danych konfiguracji Dane konfiguracji Zapis konfiguracji Dane wejściowe/ adres dla danych konfiguracji Dane konfiguracji Zapis konfiguracji Dane wejściowe/ adres dla danych konfiguracji Dane konfiguracji Zapis konfiguracji Wiersz 0 (dane reguły 0) Wiersz 1 (dane reguły 1)... Wiersz <n> (dane reguły <n>) Reguła 0 Reguła 1... Reguła <n> Reguły, którym odpowiada analizowany pakiet Matryca komórek pamięci TCAM Rys Schemat blokowy filtru adresów. Ponieważ wynikowa informacja o trafionych regułach generowana jest na podstawie iloczynu wektorów pochodzących z dwóch niezależnych bloków filtrujących, niezbędne jest, aby każdy z nich dostarczał informację wyjściową w formie binarnej niekodowanej (każdej regule odpowiada dedykowane wyjście sygnałowe). Ten wymóg funkcjonalny narzuca duże ograniczenia odnośnie sposobu realizacji matrycy komórek TCAM, uniemożliwiając wykorzystanie algorytmów grupowania filtrów [97] bądź złożonych kaskad bloków LUT [81]. Na początku realizacji projektu, jako referencyjną metodę implementacji pamięci TCAM, wybrano rozwiązanie wykorzystujące komercyjne oprogramowanie COREGenerator firmy Xilinx. Jednak, ze względu na brak możliwości zmiany wewnętrznej struktury otrzymanego w ten sposób modułu pamięci, autor opracował alternatywną koncepcję realizacji TCAM, pozwalającą zarówno na optymalizację wydajnościową, jak również minimalizację ilości niezbędnych zasobów sprzętowych. Opiera się ona na wykorzystaniu generatorów funkcji z konfigurowalnych bloków logicznych CLB układów Virtex II Pro firmy Xilinx, pracujących jako pamięci RAM16X1S (jednowejściowa pamięć 123

124 RAM przechowująca 16 wartości jednobitowych). Każdy z wierszy TCAM zbudowany jest z kaskady elementarnych pamięci RAM16X1S włączonych do łańcucha przeniesień (ang. Carry Chain), zbudowanego przy pomocy multiplekserów MUXCY, wchodzących w skład bloków CLB. Strukturę opisywanej pamięci TCAM przedstawiono na rysunku clk we <rule_nr>&<3:0 ram addr> wr_addr din(tcam_width-1:0) wr_data(tcam_width/4) 1:0) match_addr(0) match_addr(1)... match_addr(n)... WE(0:n). out(n) Binary to Hot One out(1) out(0) en in <rule_nr> <3:0 ram addr> in_a in_b Data Multiplexer en out Address Filter A(0:(m*4)-1)... match_addr(0) match_addr(1)... match_addr(n) WE(n) WE(1) WE(0) D(0) A(0)(3:0) COLUMN 0 COLUMN 1 COLUMN <m> D(1) A(1)(3:0) D(m) A(m)(3:0) MUXCY MUXCY MUXCY 0 1 CI O DI S 0 CI O DI S... 0 CI O DI S ROW 0... A(3:0) D WE WCLK RAM16X1S INIT X"0000" O A(3:0) D WE WCLK RAM16X1S INIT X"0000" O A(3:0) D WE WCLK RAM16X1S INIT X"0000" O MUXCY MUXCY MUXCY 0 1 CI O DI S 0 CI O DI S... 0 CI O DI S... ROW 1 A(3:0) D WE WCLK RAM16X1S INIT X"0000" O A(3:0) D WE WCLK RAM16X1S INIT X"0000" O A(3:0) D WE WCLK RAM16X1S INIT X"0000" O MUXCY MUXCY MUXCY 0 1 CI O DI S 0 CI O DI S... 0 CI O DI S ROW <n> A(3:0) D WE WCLK RAM16X1S INIT X"0000" O A(3:0) D WE WCLK RAM16X1S INIT X"0000" O A(3:0) D WE WCLK RAM16X1S INIT X"0000" O TCAM Storage Elements Rys Struktura wewnętrzna opracowanej pamięci TCAM opartej o elementy RAM16X1S. Do poszczególnych komórek pamięci filtru adresów zapisane zostają odpowiednio przygotowane definicje reguł bezpieczeństwa. Przykładowa konfiguracja wewnętrzna pojedynczej 124

125 czterowejściowej komórki pamięci TCAM, wykrywającej adres 10** (gdzie * oznacza wartość nieistotną), została przedstawiona w tabeli 5.3. Tab Przykładowa konfiguracja pojedynczej pamięci RAM16X1S. Adres Wartość Adres Wartość Dla wszystkich kombinacji danych wejściowych rozpoczynających się wartością 10 (zaciemniona część tabeli 5.3) pamięć zwraca jedynkę logiczną. Chcąc uzyskać większą szerokość szyny wejściowej, konieczne jest połączenie niezbędnej ilości elementów RAM16X1S w łańcuch przeniesień (wymagana szerokość wejścia podzielona przez 4). Każde z wyjść pojedynczych pamięci steruje multiplekserem MUXCY. Jeżeli pamięć zwraca wartość 1, jest ona propagowana przez MUXCY do kolejnej pozycji w łańcuchu, pod warunkiem, że na wyjściu poprzedzającego multipleksera również występowała jedynka logiczna. Sygnał trafienia w regułę jest aktywny jedynie wówczas, kiedy wyjścia wszystkich pamięci RAM16X1S w łańcuchu przeniesień są w stanie wysokim. Ponieważ szerokość szyny danych modułu filtrującego adresy i typ protokołu wynosi 88 bitów, pojedynczy wiersz pamięci TCAM musi zawierać 22 elementy RAM16X1S. Zgodnie z przyjętymi założeniami poszczególnym regułom odpowiadają dedykowane linie sygnalizujące trafienie (Rys. 5.18) wchodzące w skład wektora match. Kompletna informacja o regułach, którym odpowiada analizowany pakiet, dostępna jest już po jednym takcie zegara systemowego. Trafienie w reguły nr 0 oraz 6 Rys Przebiegi czasowe sygnałów modułu filtrującego adresy w trakcie pracy Firewalla. Opisane rozwiązanie zostało zaimplementowane i przetestowane praktycznie przy pomocy płyty uruchomieniowej Digilent XUP z układem Virtex II Pro XC2VP30. W tabeli 5.4 przedstawiono 125

126 porównanie wykorzystania zasobów przez różne warianty realizacji pamięci TCAM o szerokości 88 bitów zawierającej 32 wiersze danych. Pełny raport syntezy, uwzględniający szczegółową informację o wszystkich rodzajach wykorzystanych zasobów sprzętowych, zamieszczono w dodatku B, punkt Tab Porównanie wykorzystania zasobów sprzętowych komercyjnej wersji pamięci TCAM z koncepcją autorską dla układu Xilinx 2vp30ff Wersja pamięci CAM 124 bity CAM CoreGen 6 Opracowanie własne autora Liczba wierszy pamięci Liczba bloków Slice Liczba 4-wejściowych LUT Maksymalna częstotliwość pracy 130,416 MHz 257,732 MHz Opracowana przez autora metoda implementacji pamięci TCAM bazująca na elementach RAM16X1S jest ponad dwukrotnie bardziej efektywna od strony zapotrzebowania na zasoby sprzętowe w porównaniu do wersji modułu pamięci wygenerowanego za pomocą oprogramowania Xilinx COREGenerator. Współczynnik liczby bloków Slice na pojedynczy wiersz TCAM wynosi [112]: 25,3 dla wersji z pamięciami RAM16X1S, 56,1 dla pamięci TCAM wygenerowanej za pomocą oprogramowania CoreGen 6 firmy Xilinx. Dodatkową korzyścią płynącą ze zredukowania niezbędnych zasobów logiki reprogramowalnej jest uzyskanie lepszych parametrów czasowych. W związku ze sposobem funkcjonowania filtru o ostatecznej wydajności przetwarzania danych decyduje minimalny czas ustalenia poziomu sygnału wejściowego przed zmianą zbocza zegara. Teoretycznie wyliczona maksymalna częstotliwość pracy modułu filtrującego wynosi na tej podstawie około: 257 MHz dla wersji TCAM z pamięciami RAM16X1S, 130 MHz dla modułu TCAM wygenerowanego za pomocą oprogramowania CoreGen 6 firmy Xilinx [112] Filtr portów sieciowych Koncepcja realizacji szybkiego i skalowalnego filtru portów opiera się na zastosowaniu równoległego przetwarzania bazy reguł bezpieczeństwa. Kluczowym elementem opracowanego rozwiązania, przedstawionego schematycznie na rysunku 5.19, jest matryca bloków filtrujących. 126

127 Konfiguracja Dane wejściowe Filtry portów docelowych Filtry portów źródłowych Adresacja Numer reguły Inicjalizacja Sygnał zezwolenia zapisu dla poszczególnych reguł Dekoder Hot-One Filtry portów źródłowych Filtry portów docelowych Sterowanie filtra portów Adres dla danych konfiguracji Dane wejściowe Reguła 0 Reguła <n> Dane konfiguracji Zapis konfiguracji Adres dla danych konfiguracji Dane konfiguracji Zapis konfiguracji... Adres dla danych konfiguracji Dane konfiguracji Zapis konfiguracji Adres dla danych konfiguracji Dane konfiguracji Zapis konfiguracji Filtr portu źródłowego Filtr portu docelowego... Filtr portu źródłowego Filtr portu docelowego Dane wejściowe Dane wejściowe Dane wejściowe... Reguły, którym odpowiada analizowany pakiet Matryca elementów filtrujących Rys Schemat blokowy filtru portów. Każdy wiersz odpowiadający pojedynczej regule zawiera po dwa takie elementy: jeden weryfikujący porty źródłowe, drugi - porty docelowe [113]. Końcowy rezultat klasyfikacji jest wynikiem iloczynu logicznego wyjść bloków filtrujących. Jeżeli sygnał inicjalizacji polityki bezpieczeństwa config_wr jest w niskim stanie logicznym, filtr portów pracuje w trybie odczytu. Wówczas część deskryptora bezpieczeństwa o długości 32 bitów, zawierająca informację o portach źródłowych i docelowych, zostaje podana na wejście matrycy elementów filtrujących. Na jej wyjściu pojawia się informacja o regułach, którym odpowiada weryfikowany pakiet (Rys. 5.20). Czas trwania procesu odczytu wynosi jeden cykl zegara. Jest on niezależny od liczby reguł, jak również od ilości i szerokości zakresów portów w nich zdefiniowanych. Dla aktywnego sygnału inicjalizacji filtr przechodzi do trybu zapisu konfiguracji wewnętrznej. Wówczas na wejścia matrycy elementów filtrujących podawane są z bloku sterującego adresy inkrementowane w zakresie od 0 do 15. Służą one wpisaniu do poszczególnych komórek pamięci filtru danych konfiguracji odzwierciedlającej obowiązujący schemat polityki bezpieczeństwa. Na podstawie numeru reguły obecnego na wejściu bloku sterującego, dekoder gorącej jedynki generuje sygnał zezwolenia na zapis odpowiedniego wiersza. Proces zapisu definicji pojedynczej reguły zajmuje 16 cykli zegarowych. 127

128 128 Rys Przebiegi czasowe sygnałów modułu filtrującego porty w trakcie pracy Firewalla. Element filtrujący, którego schemat wewnętrzny przedstawiono na rysunku 5.20, wykorzystuje ideę łańcucha komparatorów zaprezentowaną w [97]. Wariant opracowany przez autora nie bazuje jednak na zmodyfikowanej pamięci TCAM, lecz opiera się na zastosowaniu kaskad dwuportowych pamięci RAM16X1D, wchodzących w skład zasobów sprzętowych układów reprogramowalnych FPGA produkcji firmy Xilinx [125]. Poszczególne pamięci pracują jako elementarne komparatory zakresów cząstkowych. Działanie czterobitowego komparatora 0, złożonego z pary pamięci RAM_A_0 oraz RAM_B_0 (Rys. 5.21), można przedstawić za pomocą następującej zależności: ),, ( H L D f Q BA, (5.1) gdzie: Q BA0 stan wyjścia komparatora 0, , 10, 01, ) ( ) ( 00, ),, ( H D L D L H H D H D L H L D L H L D H L D f, (5.2) D 0 dane wejściowe komparatora 0, L 0 dolna granica zakresu cząstkowego komparatora 0, H 0 górna granica zakresu cząstkowego komparatora 0. Szerokość analizowanego zakresu dla komparatora 0, oznaczona jako W 0, wynosi: 2 ) ( 2, 2 ) (, L H L H L H W, (5.3) Pozostałe komparatory, oprócz dwubitowych danych wejściowych, wykorzystują również informację o stanie wyjść komparatora poprzedzającego Q BA i-1 oraz o szerokości poprzedzającego zakresu cząstkowego W i-1. Do opisu sposobu ich działania zdefiniujmy następujące funkcje: i i i i i i i i i i i i i i i i i i i i i H D L D L H H D H D L H L D L H L D H L D f 11, 10, 01, ) ( ) ( 00, ),, 1 (, (5.4) Trafione reguły portów źródłowych Trafione reguły portów docelowych Wynikowy zestaw trafionych reguł

129 WCLK DPO WE RAM16X1D INIT X"0000" SPO D DPRA3 A3 DPRA2 A2 DPRA1 A1 DPRA0 A0 RAM_B_0 WCLK DPO WE D DPRA3 DPRA2 DPRA1 RAM16X1D INIT X"0000" SPO A3 A2 A1 DPRA0 A0 RAM_A_0 clk config_wr wr_data_b(0) wr_data_a(0) port_in(15) port_in(14) port_in(13) port_in(12) config_addr(3) config_addr(2) config_addr(1) config_addr(0) clk config_wr config_data(13:0) config_addr(3:0) port_in(15:0) Conf_address: Config_data(13:0) 0: <RAM_B_00> & <RAM_A_00>, 1: <RAM_B_01> & <RAM_A_01>,... F: <RAM_B_15> & <RAM_A_15>, wr_data_b(1) wr_data_a(1) port_in(11) port_in(10) WCLK DPO WE D DPRA3 DPRA2 DPRA1 RAM16X1D INIT X"0000" SPO A3 A2 A1 DPRA0 A0 RAM_B_1 WCLK DPO WE D DPRA3 DPRA2 DPRA1 RAM16X1D INIT X"0000" SPO A3 A2 A1 DPRA0 A0 RAM_A_1 port_in(15:0) wr_data_b(0:7) wr_data_a(0:7) wr_data_b(2) wr_data_a(2) port_in(9) port_in(8) WCLK WE D DPRA3 DPRA2 DPRA1 RAM16X1D INIT X"0000" DPRA0 RAM_B_2 WCLK WE D DPRA3 DPRA2 DPRA1 RAM16X1D INIT X"0000" DPRA0 RAM_A_2 A0 A1 A2 A3 SPO DPO A0 A1 A2 A3 SPO DPO wr_data_b(6) wr_data_a(6) port_in(1) port_in(0) WCLK WE D DPRA3 DPRA2 DPRA1 RAM16X1D INIT X"0000" DPRA0 RAM_B_6 WCLK WE D DPRA3 DPRA2 DPRA1 RAM16X1D INIT X"0000" DPRA0 RAM_A_6 A0 A1 A2 A3 SPO DPO A0 A1 A2 A3 SPO DPO match Rys Schemat wewnętrzny pojedynczego elementu filtrującego. 129

130 00, Di Li f ( Di, Li, H i ) 01, Di Li 11, Di Li 2, (5.5) 01, Di H i f ( Di, Li, H i ) 10, Di H i 11, Di H i 3, (5.6) i H i Li, Wi 1, 2, Li H i ( H i Li ) 2 ( H i Li ) Wi 1 Li H i ( H i Li ) 2 Wi 1 ( H i Li ) L H ( H L ) 2 W, (5.7) i i i i gdzie: W i szerokość przedziału cząstkowego dla i-tego komparatora, D i dane wejściowe, L i dolna granica zakresu cząstkowego, H i górna granica zakresu cząstkowego. Możemy wyróżnić trzy przypadki funkcjonowania komparatora Q BA i dla i >0 w zależności od szerokości przedziału poprzedzającego: dla W i-1 =0 dla W i-1 =1 dla W i-1 =2 QBAi 1 00 Q, (5.8) BAi QBAi 1 11 f1( Di, Li, H i ), 11, f2( Di, Li, Hi), Q f3( Di, Li, Hi), 11, Q BAi BAi 1 Q BAi Q, (5.9) BAi 1 Q BAi f 2 ( Di, Li, H i ), 01, f 3( Di, Li, H i ), 11, Q Q Q Q BAi 1 BAi 1 BAi 1 BAi (5.10) Analizowany port odpowiada danej regule, jeżeli stan wyjść ostatniego komparatora jest różny od wartości 11. Sygnał trafienia dla takiego przypadku generuje dodatkowa bramka NAND. Ponieważ pojedynczy port sieciowy ma szerokość 16 bitów, element filtrujący składa się z 7 komparatorów (1 czterobitowy oraz 6 dwubitowych). Każdy z nich wykorzystuje po dwie pamięci RAM16X1D, co daje sumaryczną liczbę 28 pamięci na jedną regułę opisującą dwa porty: źródłowy i docelowy. Pamięci dwuportowe (litera D w nazwie komponentu) wybrano ze względu na łatwiejszą realizację procesu zapisu konfiguracji. Implementacja oraz praktyczne testy opracowanego rozwiązania na platformie Digilent XUP z układem Virtex II Pro XC2VP30 wykazały, że badany moduł o pojemności 32 reguł bezpieczeństwa 130

131 alokował 1829 bloków Slice (Tab. 5.5), co stanowi 13% wszystkich dostępnych zasobów sprzętowych układu FPGA. Maksymalna częstotliwość jego pracy wynosi około 162 MHz; ponieważ proces weryfikacji zajmuje jeden cykl zegara, teoretyczna przepustowość opracowanego filtru portów to około 160 milionów pakietów na sekundę [113]. Pełny raport syntezy zamieszczono w dodatki B, punkt Tab Wykorzystanie zasobów logiki reprogramowalnej FPGA przez filtr portów. Rodzaj zasobów Typ układu Virtex 2vp30ff896-7 Liczba bloków Slice 1829 Liczba 4-wejściowych LUT 1856 Parametry czasowe Maks. częstotliwość 162,973 MHz Maks. opóźnienie ścieżki kombinacyjnej 0,878 ns Moduł sterujący Moduł classifier_main integruje działanie niezależnych bloków filtrujących adresację oraz porty sieciowe, uzupełniając je o kilka istotnych elementów, niezbędnych do poprawnego zakończenia procesu klasyfikacji. Należą do nich m.in.: pamięć akcji zrealizowana przy wykorzystaniu pamięci blokowych typu RAMB16_S9_S9, dostępnych w zasobach układów reprogramowalnych Virtex, automat stanów sterujący pracą klasyfikatora, a w szczególności obsługą algorytmu karuzelowej analizy deskryptorów bezpieczeństwa z wielu kanałów komunikacyjnych oraz inicjalizacją konfiguracji wewnętrznej elementarnych jednostek filtrujących. Pamięć akcji przechowuje informacje o sposobie postępowania z analizowanymi pakietami. Każdy adres pamięci odpowiada konkretnej regule bezpieczeństwa. Dzięki temu, na podstawie wynikowego wektora trafionych reguł generowanego przez zestaw filtrów adresów oraz portów sieciowych, klasyfikator jest w stanie podjąć właściwą decyzję odnośnie dalszej obsługi przetwarzanego pakietu. Proces weryfikacji inicjowany jest wystąpieniem wysokiego poziomu logicznego na liniach zgłaszających obecność deskryptorów bezpieczeństwa clas_0_desc_ready lub clas_1_desc_ready (Rys. 5.22). Klasyfikator naprzemiennie sprawdza stan tych sygnałów, wykorzystując do tego celu dedykowany licznik mechanizmu Round-Robin rr_cnt. 131

132 Licznik mechanizmu Round-Robin Bieżący stan automatu FSM Zgłoszenie deskryptora do weryfikacji Potwierdzenie zakooczenia weryfikacji Rezultat weryfikacji Rys Funkcjonowanie modułu sterującego w trakcie procesu weryfikacji danych. W opracowanym rozwiązaniu pojedynczy klasyfikator obsługuje dwa interfejsy sieciowe, natomiast uwzględnienie w toku procedury projektowej założeń dotyczących skalowalności systemu, pozwala w łatwy sposób zwiększyć ich liczbę do poziomu nie degradującego wydajności przetwarzania danych. Funkcjonowanie automatu FSM, sterującego działaniem klasyfikatora, kodowane jest pięcioma stanami pracy (Rys. 5.23): check_desc oczekiwanie na zgłoszenie deskryptora bezpieczeństwa do analizy, classify zapis wyniku weryfikacji deskryptora do pamięci ramkowej, tcam_delay oczekiwanie na wynik klasyfikacji z pamięci TCAM, action_delay oczekiwanie na odczyt z pamięci akcji, load_policy obsługa ładowania konfiguracji filtrów klasyfikatora. Wczytywanie konfiguracji wewnętrznej filtrów klasyfikatora realizowane jest zawsze po włączeniu bądź restarcie urządzenia, jak również po wymuszeniu ładowania nowych definicji reguł bezpieczeństwa przez zewnętrzną aplikację zarządzającą. W tym stanie pracy klasyfikator domyślnie blokuje cały ruch sieciowy. Dalsze prace projektowe zakładają wdrożenie funkcjonalności pozwalającej na przełączanie zestawów definicji reguł bezpieczeństwa bez przerywania normalnego funkcjonowania klasyfikatora. 132

133 Reset, power up policy_we = '1' W trakcie ładowania konfiguracji filtrów cały ruch sieciowy jest blokowany policy_we = '0' load_policy policy_we = '1' policy_we = '0' and (rr_cnt = "1" and clas_0_desc_ready = '0' or rr_cnt = "1" and clas_1_desc_ready = '1' ) check_desc policy_we = '0' and ((rr_cnt = "0" and clas_0_desc_ready = '0') or (rr_cnt = "1" and clas_0_desc_ready = '0') or (rr_cnt = "1" and clas_1_desc_ready = '0') or (rr_cnt = "1" and clas_1_desc_ready = '0')) policy_we = '0' tcam_delay policy_we = '0' and ((rr_cnt = "0" and clas_0_desc_ready = '0') or (rr_cnt = "1" and clas_1_desc_ready = '0')) policy_we = '0' action_delay policy_we = '0' and ((rr_cnt = "0" and clas_0_desc_ready = '1') or (rr_cnt = "1" and clas_1_desc_ready = '1')) classify Rys Graf przejść automatu FSM sterującego pracą klasyfikatora Wyniki implementacji oraz ocena wydajności sprzętowego klasyfikatora pakietów Opracowany sprzętowy klasyfikator pakietów został zaimplementowany i przetestowany praktycznie przy pomocy płyty uruchomieniowej Digilent XUP z układem Virtex II Pro XC2VP30. W tabeli 5.6 przedstawiono podsumowanie wykorzystania zasobów sprzętowych logiki reprogramowalnej FPGA oraz uzyskane parametry czasowe. Pełny raport syntezy zamieszczono w dodatku B, punkt Teoretyczna maksymalna częstotliwość pracy klasyfikatora, raportowana przez narzędzia do syntezy logicznej, wynosi około 160 MHz (Tab. 5.6). Jest ona w praktyce limitowana głównie przez wydajności filtrów adresów oraz portów sieciowych, a w szczególności przez zastosowane metody implementacji pamięci TCAM, jak również łańcuchów komparatorów zakresów cząstkowych w filtrze portów. Z tego powodu dalsze prace optymalizacyjne powinny być skoncentrowane właśnie na tym obszarze. 133

134 Uzyskana maksymalna częstotliwość pracy wpływa na całkowitą wydajność przetwarzania danych sprzętowego klasyfikatora. Do oszacowania tego parametru należy jednak uwzględnić jeszcze kilka dodatkowy czynników: a) opóźnienia wynikające ze sposobu działania mechanizmu karuzelowego obsługi kontrolerów MAC, b) czas trwania analizy deskryptora w blokach filtrujących adresy oraz porty sieciowe, c) opóźnienie związane z odczytem danych z pamięci akcji, d) zapis wyniku klasyfikacji do pamięci ramkowej. Tab Wykorzystanie zasobów logiki reprogramowalnej FPGA przez sprzętowy klasyfikator pakietów. Rodzaj zasobów Typ układu Virtex 2vp30ff896-7 Liczba bloków Slice 2771 Liczba 4-wejściowych LUT 3660 Parametry czasowe Maks. częstotliwość 160,433 MHz Maks. opóźnienie ścieżki kombinacyjnej 1,674 ns W badanym prototypowym systemie bezpieczeństwa typu Firewall, w konfiguracji z dwoma interfejsami sieciowymi, całkowity czas klasyfikacji pojedynczego pakietu zajmował w skrajnym przypadku 8 cykli zegara systemowego sys_clk (Rys. 5.24). Przy maksymalnej częstotliwości pracy rzędu 160 MHz efektywna wydajność przetwarzania danych klasyfikatora wynosi około 20 milionów ramek na sekundę. W sieci 10Gb Ethernet największa dopuszczalna liczba ramek przesyłanych w ciągu sekundy jest równa [96]. Wynika stąd, że omawiany moduł bez problemu i ze znacznym zapasem wydajności jest w stanie znaleźć zastosowanie do weryfikacji danych we współczesnych sieciach teleinformatycznych o dużych przepustowościach. Zgłoszenie deskryptora toru 0 Przełączenie analizy na tor 0 Zakooczenie klasyfikacji Zakooczenie zapisu wyniku do pamięci ramkowej 5 taktów zegara sys_clk 3 takty zegara sys_clk CAŁKOWITY CZAS KLASYFIKACJI: 8 taktów zegara sys_clk Rys Całkowity czas weryfikacji pakietu. 134

135 5.4. Blok ładowania polityki bezpieczeństwa Do poprawnej pracy systemu typu Firewall niezbędne jest wbudowanie funkcjonalności umożliwiającej w dowolnym momencie ładowanie do bloków filtrujących nowych definicji reguł bezpieczeństwa. Rolę taką w opracowanym prototypie spełnia moduł fw_policy_loader, którego wewnętrzny schemat blokowy przedstawiono na rysunku fw_policy_loader.vhd rs232_active policy_we reset sys_clk Interfejs klasyfikatora address_we address_wr_data(21:0) address_wr_addr(log2_ceil(l_reguł-1)+3:0) port_we port_wr_data(27:0) port_wr_addr(log2_ceil(l_reguł-1)+3:0) action_we action_wr_data(7:0) action_wr_addr(log2_ceil(l_reguł-1)-1:0) rd_data(29:8) rules_cnt & ram_addr_cnt rd_data(59:32) rules_cnt & ram_addr_cnt rd_data(7:0) rules_cnt fw_policy_ram rd_data(63:0) sys_clk reset ram_0_we ram_0_wr_address (10:0) ram_0_wr_data(7:0) ram_1_we ram_1_wr_address (10:0) ram_1_wr_data(7:0) rd_address(8:0) (10:0) (10:0) rules_cnt & ram_addr_cnt rs_fsm (process) rs232_active ram_0_we ram_1_we write_cnt(11:0) policy_load wr_active sys_clk reset uart_intrx_o uart_wb_dat_o(7:0) uart_wb_we_i uart_wb_stb_i policy_fsm (process) wr_active sys_clk policy_load reset ram_addr_cnt(3:0) rules_cnt(log2_ceil(l_reguł-1)-1:0) address_we port_we action_we Interfejs RS232 RS232_TxD RS232_Rx uart TxD_PAD_O BR_Clk_I RxD_PAD_I WB_CLK_I WB_RST_I WB_ADR_I(1:0) IntRx_O WB_DAT_O(7:0) WB_WE_I WB_STB_I WB_ACK_O WB_DAT_I(7:0) IntTx_O 00" Rys Schemat wewnętrzny modułu fw_policy_loader. Tabelaryczne definicje polityki bezpieczeństwa zostają zamienione na odpowiednią postać binarną w specjalnie przygotowanej zewnętrznej aplikacji zarządzającej, omówionej szerzej w rozdziale 5.5. Dane konfiguracyjne są przesyłane do modułu fw_policy_loader za pomocą interfejsu RS232. Do obsługi transmisji szeregowej zaadaptowano otwarty pakiet miniuart, opracowany przez Philippe Cartona, a udostępniony w zasobach organizacji OpenCores [74]. Odebranie każdego bajtu przesyłanego poprzez RS232 sygnalizowane jest wysokim stanem logicznym na linii IntRx_O magistrali WISHBONE [73] bloku uart. Dedykowany automat stanów rs_fsm (Rys. 5.25), nadzorujący funkcjonowanie szeregowego odbioru danych konfiguracyjnych, generuje sygnały adresacji oraz zezwolenia zapisu (write_cnt, ram_0_we, ram_1_we) binarnych definicji reguł bezpieczeństwa do specjalnej pamięci buforującej fw_policy_ram. Zbudowana jest ona w oparciu o dwie dwuportowe pamięci synchroniczne typu BlockRAM RAMB16_S9_S36, o pojemności 2048 x 8 bitów każda, dostępne w zasobach układów Virtex. Zastosowanie pamięci dwuportowych upraszcza realizację procesu zapisu informacji pochodzących z interfejsu RS232 oraz ich dalszej transmisji do filtrów bloku klasyfikatora. 135

136 Nr reguły Adres pamięci konfiguracji RAM0 Dopełnienie (nieużywane) RAM16x1S nr 21 RAM16x1S nr 20 RAM16x1S nr 19 RAM16x1S nr 18 RAM16x1S nr 17 RAM16x1S nr 16 RAM16x1S nr 15 RAM16x1S nr 14 RAM16x1S nr 13 RAM16x1S nr 12 RAM16x1S nr 11 RAM16x1S nr 10 RAM16x1S nr 9 RAM16x1S nr 8 RAM16x1S nr 7 RAM16x1S nr 6 RAM16x1S nr 5 RAM16x1S nr 4 RAM16x1S nr 3 RAM16x1S nr 2 RAM16x1S nr 1 RAM16x1S nr 0 Tab Zawartość pamięci RAM0 przechowującej konfigurację filtru adresów, typu protokołu oraz akcji dla dwóch przykładowych reguł bezpieczeństwa. 32 -bitowe słowo danych pamięci konfiguracji RAM0 22 -bitowe słowo konfiguracji pamięci TCAM filtru adresów (22 pamięci RAM16x1S na pojedynczą regułę) 8 -bitowe słowo konfiguracji pamięci akcji Jedna z pamięci RAMB16_S9_S36, opisana w projekcie jako RAM0, służy do przechowywania konfiguracji wewnętrznej filtru adresów oraz typu protokołu. Pojedyncze słowo pamięci RAM0 zbudowane jest z dwóch kluczowych części: 22-bitowego wiersza konfiguracji wewnętrznej modułu TCAM, opisanego w rozdziale (po jednym bicie dla każdego z 22 elementów RAM16x1S) oraz 8-bitowego słowa konfiguracji pamięci akcji. Dwa najstarsze bity dopełnienia (nr 31 oraz 30) pozostają niewykorzystane. Ponieważ zaprogramowanie pamięci TCAM, zbudowanej w oparciu o elementy RAM16x1S, wymaga zapisania wszystkich 16 komórek, definicja jednej reguły bezpieczeństwa alokuje w sumie 16 wierszy pamięci RAM0. Przykładową zawartość mapy konfiguracji dla dwóch reguł zawarto w tabeli 5.7. Reguła nr 0: typ ramki dowolny, protokół TCP, adres źródłowy IP , 136

137 Nr reguły Adres pamięci konfiguracji RAM1 Dopełnienie (nieużywane) RAM_B_6 RAM_B_5 RAM_B_4 RAM_B_3 RAM_B_2 RAM_B_1 RAM_B_0 RAM_A_6 RAM_A_5 RAM_A_4 RAM_A_3 RAM_A_2 RAM_A_1 RAM_A_0 RAM_B_6 RAM_B_5 RAM_B_4 RAM_B_3 RAM_B_2 RAM_B_1 RAM_B_0 RAM_A_6 RAM_A_5 RAM_A_4 RAM_A_3 RAM_A_2 RAM_A_1 RAM_A_0 maska adresu źródłowego , adres docelowy IP dowolny, maska adresu docelowego dowolna, akcja zaakceptuj. Reguła nr 1: typ ramki dowolny, protokół ICMP, adres źródłowy IP dowolny, maska adresu źródłowego dowolna, adres docelowy IP , maska adresu docelowego , akcja odrzuć. Tab Zawartość pamięci RAM1 przechowującej konfigurację filtrów portów sieciowych dla dwóch przykładowych reguł bezpieczeństwa. 32- bitowe słowo danych pamięci konfiguracji RAM1 28 -bitowe słowo konfiguracji filtru portów źródłowych (28 pamięci RAM16x1D) 28 -bitowe słowo konfiguracji filtru portów docelowych (28 pamięci RAM16x1D)

138 Druga pamięć RAMB16_S9_S36, oznaczana jako RAM1, buforuje dane konfiguracji filtrów portów sieciowych, opisanych w rozdziale Ponieważ w skład bloku filtrującego dla jednej reguły wchodzi łącznie 28 elementów typu RAM16x1D, słowo danych konfiguracji ma długość 28 bitów. Nadmiarowe 4 bity dopełnienia pozostają niewykorzystane. Podobnie, jak w wypadku filtrów adresów, pełna definicja reguły alokuje 16 słów 32-bitowych pamięci RAM1. Przykładową zawartość mapy konfiguracji dla dwóch reguł zawarto w tabeli 5.8. Reguła nr 0: port źródłowy zakres od 1 do 100, port docelowy zakres od 1000 do Reguła nr 1: port źródłowy port nr 50, port docelowy dowolny. Po zakończeniu transmisji danych konfiguracyjnych z aplikacji zarządzającej do pamięci buforujących RAM0 oraz RAM1 automat stanów policy_fsm (Rys. 5.25) rozpoczyna procedurę inicjalizacji filtrów adresów i portów sieciowych, jak również pamięci akcji. W tym celu aktywuje on odpowiednie linie zezwolenia zapisu (address_we, port_we, action_we) oraz generuje sygnały adresowe dla poszczególnych bloków (address_wr_add, port_wr_add, action_wr_add). Mapy konfiguracji filtrów dostarczane są bezpośrednio z modułu pamięci buforującej fw_policy_ram (sygnał rd_data). Inicjalizacja filtru portów Inicjalizacja filtru adresów Inicjalizacja pamięci akcji Rys Przebiegi czasowe sygnałów modułu fw_policy_loader w trakcie inicjowania konfiguracji filtrów. 138

139 W trakcie trwania procedury inicjalizacji klasyfikator pakietów przechodzi w stan blokowania całego ruchu sieciowego. Ma to na celu wyeliminowanie ewentualnej możliwości złamania zabezpieczeń systemu Firewall w krótkim okresie braku spójności definicji polityki bezpieczeństwa. Proces inicjalizacji konfiguracji filtrów zachodzi także każdorazowo po restarcie systemu (Rys. 5.26). W dalszym etapie rozwoju zapory sieciowej konieczne jest dodanie funkcjonalności przechowywania definicji reguł bezpieczeństwa w pamięci nieulotnej, tak, aby po włączeniu urządzenie automatycznie ładowało właściwe parametry pracy. Dodatkowo należy wdrożyć mechanizmy autoryzacji dostępu administracyjnego, uniemożliwiając niepowołane zmiany konfiguracji Firewalla. Ze względu na specyfikę architektury wewnętrznej opracowanych modułów klasyfikatora pakietów, proces ładowania konfiguracji pojedynczej reguły zajmuje 16 cykli zegarowych. Znając częstotliwość zegara systemowego oraz rozmiar tabeli z definicjami reguł, łatwo jest wyliczyć sumaryczny czas wczytywania konfiguracji, przy założeniu przechowywania jej w dodatkowej pamięci nieulotnej. Przy wykorzystaniu zewnętrznej aplikacji zarządzającej czas ładowania danych konfiguracyjnych zależy od prędkości pracy medium transmisyjnego (w wypadku portu szeregowego domyślnie jest to 9600 b/s) oraz sumarycznego rozmiaru bitowego skonwertowanej tabeli definicji polityki bezpieczeństwa. Wykorzystanie do tego celu interfejsu RS232, pomimo zapewnienia oczekiwanej funkcjonalności, nie jest rozwiązaniem docelowym. W dalszym etapie rozbudowy systemu autor zamierza wdrożyć mechanizmy zarządzania Firewallem poprzez sieć Ethernet. Pozwoli to nie tylko na zwiększenie efektywności oraz bezpieczeństwa administrowania urządzeniem, ale również otworzy możliwości integracji nowych usług, jak choćby monitoring bieżących parametrów pracy. Opracowany moduł ładujący politykę bezpieczeństwa został zaimplementowany i przetestowany praktycznie przy pomocy płyty uruchomieniowej Digilent XUP z układem Virtex II Pro XC2VP30. W tabeli 5.9 przedstawiono podsumowanie wykorzystania zasobów sprzętowych logiki reprogramowalnej FPGA oraz uzyskane parametry czasowe. Pełny raport syntezy zamieszczono w dodatku B, punkt Tab Wykorzystanie zasobów logiki reprogramowalnej FPGA przez moduł ładowania polityki bezpieczeństwa. Rodzaj zasobów Typ układu Virtex 2vp30ff896-7 Liczba bloków Slice 68 Liczba 4-wejściowych LUT 120 Liczba pamięci RAMB16_S9_S36 2 Parametry czasowe Maks. częstotliwość 291,414 MHz 139

140 5.5. Aplikacja zarządzająca Definicje reguł bezpieczeństwa przesyłane są do modułu ładującego z zewnętrznej aplikacji zarządzającej. Ze względu na konieczność szybkiej weryfikacji funkcjonowania opracowanych modułów sprzętowego Firewalla, autor poszukiwał środowiska programistycznego umożliwiającego łatwą budowę tymczasowego interfejsu użytkownika. Ostateczny wybór padł na ogólnie dostępne oprogramowanie Microsoft Excel tabelaryczne ujęcie definicji reguł bezpieczeństwa jest powszechne wśród narzędzi do zarządzania zaporami sieciowymi, zaś łatwa składnia języka VBA (ang. Visual Basic for Applications) umożliwia szybkie opracowanie konwertera reguł oraz bloku szeregowej transmisji RS232. Oczywistym jest fakt, że taka postać systemu zarządzającego ma charakter testowy docelowo powinna być to dedykowana aplikacja napisana w języku wyższego poziomu, kompatybilna zarówno z komercyjnymi systemami operacyjnymi (np. Microsoft Windows), jak również z otwartymi rozwiązaniami (np. różnymi dystrybucjami systemu Linux). Jednakże opracowanie takiego programu z racji ograniczeń czasowych nie zostało wykonane w ramach przeprowadzonych badań i stanowić będzie przedmiot przyszłych prac nad rozwojem systemu. Przykładowe okno aplikacji zawierające tabelę z definicjami reguł bezpieczeństwa pokazano na rysunku Oprócz funkcji ładowania polityki aplikacja udostępnia dodatkowe narzędzia ułatwiające opracowywanie kodu VHDL poszczególnych modułów sprzętowego Firewalla. Rys Aplikacja konwertująca reguły bezpieczeństwa. 140

141 W skład pojedynczej reguły wchodzą następujące pola: Frame type typ ramki Ethernet; w wersji prototypowej aplikacja dekoduje ramki ARP oraz ramki dowolnego typu, opisywane za pomocą symbolu x. Pozostałe rodzaje ramek zostaną sukcesywnie uzupełniane w dalszych pracach nad rozwojem systemu; Protocol typ protokołu; w wersji prototypowej możliwe jest specyfikowanie protokołów ICMP, TCP, UDP oraz dowolnego typu poprzez zastosowanie znaku x ; Source IP adres źródłowy protokołu IP, zapisywany w postaci 4 sekcji dziesiętnych, np Adres dowolny definiuje symbol x ; Source Mask maska sieciowa adresu źródłowego, określająca zakres adresów podsieci. Maska definiowana jest analogicznie do adresów IP poprzez 4 sekcje dziesiętne, np ; maska dowolna oznaczana jest symbolem x ; Destination IP adres docelowy protokołu IP. Opis analogiczny jak w przypadku Source IP; Destination Mask maska sieciowa adresu docelowego. Opis analogiczny jak w przypadku Source Mask; Source Port adres portu źródłowego protokołu TCP/UDP; opis dziesiętny od 0 do Dopuszczalne jest definiowanie przedziałów zapisywanych z użyciem znaku -, np Port dowolny specyfikowany jest za pomocą symbolu x ; Destination Port adres portu docelowego protokołu TCP/UDP. Opis jak w przypadku Source Port; Action akcja do wykonania. W opracowanej wersji prototypowej możliwe są dwa warianty: A akceptacja bądź D odrzucenie pakietu. Głównym zadaniem aplikacji zarządzającej systemem Firewall jest odpowiednia translacja definicji polityki bezpieczeństwa z formy czytelnej dla administratora urządzenia do mapy zawartości wewnętrznej konfiguracji poszczególnych komórek pamięci filtrów adresów i portów sieciowych klasyfikatora pakietów. W opracowanej implementacji schemat polityki bezpieczeństwa w skonwertowanej formie binarnej, jak to zostało zasygnalizowane wcześniej, jest przesyłany do pamięci Firewalla poprzez port RS232. Do obsługi komunikacji szeregowej wykorzystano ewaluacyjną wersję biblioteki WSC4VB (ang. Windows Standard Serial Communications Library for Visual Basic) firmy MarshallSoft [65]. Proces konwersji definicji reguł jest podzielony, zgodnie ze sposobem funkcjonowania bloków filtrujących, na trzy etapy: tworzenie mapy konfiguracji filtru adresów, tworzenie mapy konfiguracji filtru portów, tworzenie mapy konfiguracji pamięci akcji. 141

142 5.6. Ocena wyników implementacji kompletnej zapory sieciowej Kompletny funkcjonalnie sprzętowy system bezpieczeństwa typu Firewall, obejmujący dwa kontrolery MAC, dwa moduły silników, jeden klasyfikator oraz moduł ładujący definicję polityki bezpieczeństwa składającej się z 32 reguł, zaimplementowano i przetestowano praktycznie przy pomocy płyty uruchomieniowej Digilent XUP z układem Virtex II Pro XC2VP30. W tabeli 5.10 przedstawiono podsumowanie wykorzystania zasobów sprzętowych logiki reprogramowalnej FPGA oraz uzyskane parametry czasowe kompletnego sprzętowego Firewalla. Pełny raport syntezy zamieszczono w dodatku B, punkt Tab Wykorzystanie zasobów sprzętowych i parametry czasowe kompletnego systemu sprzętowego Firewalla. Rodzaj zasobów Typ układu Virtex 2vp30ff896-7 Liczba bloków Slice 9164 Liczba 4-wejściowych LUT Liczba rejestrów przesuwnych SRL16E 3983 Liczba pamięci RAM16X1S 704 Liczba pamięci RAM16X1D 896 Liczba pamięci RAMB16_S9_S9 35 Liczba pamięci RAMB16_S9_S36 34 Liczba pamięci RAMB16_S18_S18 4 Parametry czasowe Maks. częstotliwość 139,019 MHz Maks. opóźnienie ścieżki kombinacyjnej 4,183 ns Raportowana przez narzędzia do syntezy logicznej maksymalna teoretyczna częstotliwość pracy zrealizowanego systemu bezpieczeństwa typu Firewall, wynosząca około 139 MHz, pozwala na jego wykorzystanie w sieciach Gigabit Ethernet. Co więcej, rezygnacja z zastosowania mechanizmu karuzelowego poprzez dedykowanie każdej ścieżce komunikacyjnej indywidualnego modułu klasyfikującego pakiety, umożliwia zwiększenie szybkości medium komunikacyjnego do 10 Gb/s. Celem praktycznego potwierdzenia poprawności funkcjonowania systemu w rzeczywistej infrastrukturze sieci Ethernet zestawiono specjalne środowisko testowe obejmujące cztery różne konfiguracje składowe (Rys. 5.28). Pierwszy wariant połączenia bezpośredniego dwóch komputerów, oznaczonych na rysunku 5.28 jako Host 1 oraz Host 2, posłużył oszacowaniu referencyjnej maksymalnej przepustowości transmisji danych przy braku jakichkolwiek systemów zabezpieczających. W drugim wariancie na komputerze Host 2 zainstalowano dwie wersje programowych zapór ogniowych: produkcji Sygate Personal Firewall [116] (firma Sygate została 142

143 przejęta w roku 2005 przez koncern Symantec) oraz Sunbelt Personal Firewall [104]. Dzięki temu możliwym stało się zbadanie wpływu oprogramowania zabezpieczającego transmisję danych na ogólne obciążenie systemu operacyjnego komputera. Trzecia konfiguracja wykorzystywała dedykowane komercyjne urządzenie zabezpieczające (tzw. appliance) typu Safe@Office 100B SBX-166LHGE-2 [103] produkcji firmy SofaWare z oprogramowaniem wewnętrznym opracowanym przez firmę Check Point. W ostatnim wariancie przetestowano opisany w niniejszej pracy sprzętowy system bezpieczeństwa typu Firewall. a) połączenie bezpośrednie brak systemów zabezpieczenia transmisji Host 1 Host 2 Ethernet 100 Mbps b) połączenie bezpośrednie host 2 wykorzystuje programowy Firewall Host 1 Host 2 Ethernet 100 Mbps Programowy Firewall c) połączenie poprzez Firewall CheckPoint SBX-166LHGE-2 Host 1 Firewall Safe@Office Host 2 SBX-166LHGE-2 Ethernet 100 Mbps Ethernet 100 Mbps d) połączenie poprzez sprzętowego Firewalla Host 1 Firewall sprzętowy Host 2 Ethernet 100 Mbps Ethernet 100 Mbps Rys Konfiguracja środowiska testowego. Do przeprowadzenia testów zdecydowano się wykorzystać konfigurację sprzętowego Firewalla w opcji z kontrolerami MAC typu FastEthernet. Spowodowane było to maksymalną przepustowością portów komunikacyjnych referencyjnego urządzenia Safe@Office 100B (Ethernet 10/100 Mb/s). Takie podejście pozwoliło jednak na ocenę poprawności działania kluczowego bloku sprzętowego Firewalla, tj. modułu klasyfikującego pakiety, umożliwiając równocześnie porównanie wydajności trzech różnych systemów zabezpieczających w celu zweryfikowania stopnia realizacji założeń projektowych. 143

144 Jako komputery Host 1 i Host 2 zastosowano profesjonalne serwery typu RackSaver, przeznaczone do instalacji w szafach teleinformatycznych. Każdy z nich zbudowany był w oparciu o płytę główną produkcji firmy SuperMicro z zainstalowanym procesorem Intel Xeon 2,4 GHz oraz 1 GB pamięci RAM. Komputer Host 1 pracował pod kontrolą systemu operacyjnego Scientific Linux w wersji 5.5, zaś Host 2, ze względu na wymagania testowanych programowych zapór ogniowych, pod kontrolą Windows XP Professional. W każdym z wymienionych systemów usunięto zbędne oprogramowanie czy też serwisy tak, aby uzyskać jak największą wydajność pracy. Podobnie w badanych zaporach ogniowych zdefiniowano jedynie minimalny zestaw reguł, pozwalający na przeprowadzenie testów przepustowości oraz czasu kopiowania zbiorów plików za pomocą protokołu SMB (ang. Server Message Block). W przypadku urządzenia Safe@Office 100B dezaktywowano także usługi analizy antyspamowej i antywirusowej. Dla poszczególnych konfiguracji badanych systemów, przedstawionych na rysunku 5.28, wykonano następujące procedury testowe: a) badanie przepustowości transmisji, w zależności od rozmiaru datagramu MTU (ang. Maximum Transmission Unit), przy wykorzystaniu oprogramowania iperf [101], b) pomiar średniej przepustowości przy kopiowaniu zbioru 3 tysięcy małych plików o łącznej pojemności 211 MB, c) pomiar średniej przepustowości przy kopiowaniu pojedynczego dużego pliku o rozmiarze 211 MB. Do przeprowadzenia testu wpływu systemów zabezpieczających na wartość przepustowości transmisji danych zdecydowano się wykorzystać aplikację iperf. Jest to otwarty program działający w architekturze klient serwer, umożliwiający badanie szybkości przesyłania danych w sieciach Ethernet przy pomocy protokołu TCP bądź UDP. Co ważne, dostępny jest on zarówno w wersji działającej na platformie systemów operacyjnych z rodziny Linux, jak również w wersji wpierającej systemy Windows. Bogata funkcjonalność pozwala na elastyczne definiowanie scenariuszy testów oraz ich praktyczną realizację. W celu zweryfikowania wpływu zastosowania poszczególnych systemów zabezpieczających na wydajność transmisji danych na komputerze Host 2 uruchomiono oprogramowanie ipref w trybie serwera (polecenie iperf s). Z kolei na komputerze Host 1 wydawano cyklicznie komendę iperf c <adres IP Host 2> t 30 M <MTU w bajtach>, zmieniając za każdym razem wartość parametru MTU w zakresie od 100 do 1470 B z krokiem 100 B (za wyjątkiem ostatniej maksymalnej wartości 1470 B). W jej efekcie uzyskiwano średnią wartość przepustowości rejestrowanej w czasie 30 sekund dla danego MTU. Taki podział ról komputerów wyniknął z niemożności sterowania wielkością datagramów wysyłanych pakietów w wypadku uruchomienia aplikacji iperf jako klienta na systemie operacyjnym Windows. Klient iperf funkcjonujący w systemie Linux pozwalał modyfikować wartość MTU, dzięki czemu, w związku z wzajemną kompatybilnością wersji oprogramowania, pozwolił na pomiar wydajności także w środowisku Windows. Uzyskane 144

145 Przepustowośd *Mb/s+ wyniki przepustowości transmisji danych dla poszczególnych konfiguracji środowiska testowego przedstawiono na rysunku Przepustowośd transmisji danych dla testów iperf Maksymalny rozmiar datagramu MTU [B] Bez zabezpieczeo Firewall CheckPoint Sygate Personal Firewall (bez IDS) Firewall sprzętowy Sunbelt Personal Firewall (z opcją IDS) Rys Przepustowość transmisji danych dla poszczególnych konfiguracja środowiska testowego. Referencyjna wartość przepustowości transmisji badanych komputerów została wyznaczona dla bezpośredniego ich połączenia przy braku jakichkolwiek systemów zabezpieczających. Największą szybkość transmisji, wynoszącą około 93,7 Mb/s, osiągnięto przy MTU równym 1470 B. Zmniejszając wielkość datagramu do granicy 400 B obserwowano niewielki kilkuprocentowy spadek mierzonej przepustowości. Poniżej tego progu nastąpiło gwałtowne ograniczenie szybkości przesyłania danych, osiągając jedynie 30,1 Mb/s dla MTU równego 100 B. Sytuacja taka powodowana jest prawdopodobnie przez dwa najważniejsze czynniki: duża liczba coraz mniejszych pakietów zwiększa pasmo zajmowane przez nagłówki poszczególnych warstw modelu ISO/OSI kosztem enkapsulowanych danych, coraz większa liczba pakietów generuje duże obciążenie procesora (Rys. 5.30), redukując tym samym wydajność programowej obsługi stosu protokołów TCP/IP. Znając wartość maksymalnej przepustowości testowej konfiguracji badanych komputerów, przystąpiono do weryfikacji programowych zapór ogniowych. Jako pierwsze sprawdzono oprogramowanie Sygate Personal Firewall charakteryzujące się z jednej strony stosunkowo niewielką funkcjonalnością, ale za to wykazujące bardzo małe zapotrzebowanie na zasoby pamięciowe oraz wydajność procesora. Uzyskana krzywa przepustowości w funkcji wielkości datagramu odwzorowała 145

146 Obciążenie procesora *%+ przebieg konfiguracji referencyjnej, przy czym w zakresie MTU od 300 B do 1470 B szybkość transmisji spadła o około 3 %. Dla najmniejszej badanej wartości datagramu zarejestrowana przepustowość wyniosła 26,9 Mb/s. Na tej podstawie można więc stwierdzić, że instalacja programowego Firewalla nie spowodowała drastycznego pogorszenia parametrów transmisyjnych. Watro jednak zwrócić uwagę, że odbyło się to kosztem ponad dwukrotnego zwiększenia obciążenia procesora komputera Host 2 (Rys. 5.30). Już przy MTU równym 900 B obserwowano 100% obciążenie procesora, a poniżej 400 B komputer przestawał odpowiadać na komendy użytkownika Obciążenie procesora serwera dla testów iperf Maksymalny rozmiar datagramu MTU [B] Bez zabezpieczeo Sunbelt Personal Firewall (z opcją IDS) Sygate Personal Firewall (bez IDS) Rys Obciążenie procesora komputera Host 2 w trakcie testów oprogramowaniem iperf. Druga z badanych programowych zapór ogniowych - Sunbelt Personal Firewall oprócz konwencjonalnej funkcjonalności Firewalla wyposażona była w system wykrywania intruzów IDS. Dodatkowa usługa zwiększyła obciążenie procesora, w stosunku do oprogramowania Sygate Personal Firewall jedynie o około 10 %. Zdecydowanie bardziej destrukcyjnie wpłynęła natomiast na przepustowość transmisji danych. Dla dużych pakietów (MTU powyżej 1000 B) maksymalny spadek przepustowości względem referencyjnej konfiguracji nie przekraczał 1,5 Mb/s. Dla mniejszych datagramów szybkość transmisji malała praktycznie liniowo aż do poziomu 10,4 Mb/s, przy MTU równym 100 B. Uruchomienie programowego Firewalla spowodowało więc w tym przypadku prawie trzykrotną redukcję przepustowości dla skrajnych warunków transmisji. Najbardziej zaskakujące wyniki uzyskano w trakcie analizy wydajności Firewalla Safe@Office 100B. Dedykowana platforma sprzętowa oraz oprogramowanie renomowanej firmy Check Point pozwalały przypuszczać, że, pomimo przeznaczenia urządzenia do zabezpieczania sieci komputerowych niewielkich organizacji, powinno ono bez problemu osiągnąć przepustowość 146

147 Przepustowośdd*Mb/s+ standardu Fast Ethernet. Tymczasem, nawet w przypadku wyłączenia dodatkowych usług analizy danych (system IDS oraz kontrola antywirusowa), omawiany Firewall osiągnął najgorsze wyniki szybkości transmisji danych spośród wszystkich badanych konfiguracji. Podobnie, jak dla zapory programowej Sunbelt Personal Firewall, przy MTU mniejszym od 1000 B zaobserwowano liniowy spadek przepustowości aż do granicznej wartości 9,1 Mb/s dla datagramu o rozmiarze 100 B. Maksymalną przepustowość wynoszącą 93,5 Mb/s zarejestrowano przy MTU równym 1470 B. W teście tym zrezygnowano z pomiaru obciążenia procesora, ponieważ na komputerze Host 2 nie funkcjonowało żadne oprogramowanie zabezpieczające. Średnia przepustowośd w testach kopiowania plików 80,0 64,6 70,5 69,4 70,0 60,0 50,0 22,3 22,4 23,3 55,5 58,6 40,0 19,2 30,0 21,0 20,0 10,0 0,0 3 tys. małych plików Jeden duży plik Sunbelt Personal Firewall (z opcją IDS) Firewall CheckPoint Sygate Personal Firewall (bez IDS) Firewall sprzętowy Bez zabezpieczeo Rys Średnia przepustowość w testach kopiowania plików. Ostatnim z badanych systemów była sprzętowa zapora ogniowa implementowana w logice reprogramowalne j FPGA. Zmierzone poziomy przepustowości dla datagramów większych od 300 B są identyczne z uzyskanymi w konfiguracji referencyjnej. Jedynie w przypadku małych MTU (od 100 do 300 B) zarejestrowano niewielki spadek wydajności (maksymalnie 0,4 Mb/s), co może wynikać z opóźnień wnoszonych przez sprzętowego Firewalla pracującego w trybie store and forward. Opracowany sprzętowy Firewall osiągnął najlepsze wyniki w testach iperf spośród wszystkich badanych konfiguracji systemów zabezpieczających, potwierdzając teoretycznie oszacowane parametry wydajnościowe. 147

148 Obciążenie procesora *%+ Rezultaty kolejnego etapu testów, polegającego na kopiowaniu dwóch zestawów plików za pomocą protokołu SMB również wykazały, że opracowana zapora ogniowa uzyskała poziom przepustowości najbliższy warunkom referencyjnym. Taka sytuacja miała miejsce zarówno przy kopiowaniu 3 tysięcy niewielkich zbiorów danych, jak również w czasie ciągłego transferu pojedynczego dużego pliku. Przy braku jakichkolwiek systemów zabezpieczających zmierzone maksymalne wartości przepustowości dla obydwu zestawów plików wyniosły odpowiednio: 23,3 Mb/s oraz 70,5 Mb/s (Rys. 5.31). Zastosowanie sprzętowego Firewalla zmniejszyło szybkość transmisji jedynie o 0,9 Mb/s dla małych plików i o 1,1 Mb/s dla pojedynczego pliku. Najgorzej w pierwszym przypadku wypadło urządzenie Safe@Office 100B, redukując przepustowość do poziomu 19,2 Mb/s, zaś w drugim programowa zapora Sunbelt Personal Firewall z wartością przepustowości równą 55,5 Mb/s. Obciążenie procesora komputera "Host 2" w testach kopiowania plików 66, , ,7 15,9 3 tys. małych plików Jeden duży plik Bez zabezpieczeo Sygate Personal Firewall (bez IDS) Sunbelt Personal Firewall (z opcją IDS) Rys Obciążenie procesora komputera Host 2 w trakcie testów kopiowania plików. Pomiar obciążenia procesora w trakcie testów kopiowania plików potwierdził obserwacje dokonane podczas badania przepustowości za pomocą aplikacji iperf. Także i tym razem zastosowanie programowych zapór ogniowych w bardzo widoczny sposób ograniczało dostępne zasoby obliczeniowe komputera (Rys. 5.32). Najgorzej prezentował się pod tym względem Sunbelt Personal Firewall, zwiększając obciążenie procesora z poziomu 13,7% do wartości 46% dla małych plików oraz z poziomu 15,9% do wartości 66,5% dla pojedynczego dużego pliku. 148