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
Pragnę wyrazić serdeczne podziękowania
Panu Profesorowi Kazimierzowi Wiatrowi
za inspirację, mobilizację oraz nieocenioną
pomoc w powstaniu tej rozprawy.
2
Spis treści
Wykaz skrótów.........................................................................................................................................5
1.
2.
Wstęp .............................................................................................................................................10
1.1.
Motywacja ............................................................................................................................. 10
1.2.
Cel i teza pracy ...................................................................................................................... 12
1.3.
Organizacja pracy .................................................................................................................. 14
Przegląd rozwiązań systemów ochrony danych przesyłanych w sieciach
teleinformatycznych .....................................................................................................................15
2.1.
Wprowadzenie ....................................................................................................................... 15
2.2.
Klasyfikacja funkcjonalna ..................................................................................................... 16
2.2.1.
Pasywne filtry pakietów ................................................................................................ 16
2.2.2.
Dynamiczne filtry pakietów .......................................................................................... 17
2.2.3.
Bramki typu Circuit-level.............................................................................................. 18
2.2.4.
Bramki aplikacyjne ....................................................................................................... 19
2.2.5.
Filtry typu Stateful Inspection ....................................................................................... 20
2.2.6.
Proxy odcinające ........................................................................................................... 20
2.2.7.
Rozwiązania typu Air Gap ............................................................................................ 21
2.2.8.
Filtry typu Deep Packet Inspection ............................................................................... 22
2.2.9.
Zunifikowane zarządzanie zagrożeniami ...................................................................... 23
2.3.
3.
4.
Klasyfikacja implementacyjna ............................................................................................... 24
2.3.1.
Firewalle programowe................................................................................................... 24
2.3.2.
Firewalle sprzętowe....................................................................................................... 34
Stanowisko badawcze ...................................................................................................................45
3.1.
Wprowadzenie ....................................................................................................................... 45
3.2.
Pakiet Active-HDL ................................................................................................................. 45
3.3.
Płyta testowo-uruchomieniowa Digilab 2E firmy Digilent ................................................... 47
3.4.
Płyta testowo-uruchomieniowa XUPV2 firmy Digilent ........................................................ 49
3.5.
Realizacja dostępowych interfejsów fizycznych dla sieci Fast i Gigabit Ethernet ................ 52
3.5.1.
Karta Fast Ethernet ........................................................................................................ 53
3.5.2.
Karta Gigabit Ethernet .................................................................................................. 59
Sprzętowa implementacja kontrolerów MAC dla sieci Ethernet .............................................65
4.1.
Wprowadzenie ....................................................................................................................... 65
4.2.
Struktura ramki Ethernet ........................................................................................................ 68
4.2.1.
Charakterystyka pól składowych ramki podstawowej .................................................. 69
4.2.2.
Format ramki znakowanej ............................................................................................. 71
3
4.3.
4.3.1.
Schemat blokowy .......................................................................................................... 72
4.3.2.
Tor odbiorczy Rx .......................................................................................................... 73
4.3.3.
Tor nadawczy TX .......................................................................................................... 77
4.3.4.
Moduł kontrolny............................................................................................................ 85
4.3.5.
Wyniki implementacji ................................................................................................... 87
4.4.
5.
Sprzętowy kontroler MAC - wersja Fast Ethernet ................................................................. 72
Sprzętowy kontroler MAC - wersja Gigabit Ethernet ........................................................... 88
4.4.1.
Schemat blokowy .......................................................................................................... 89
4.4.2.
Tor odbiorczy Rx .......................................................................................................... 90
4.4.3.
Tor nadawczy Tx ........................................................................................................... 96
4.4.4.
Moduł kontrolny.......................................................................................................... 104
4.4.5.
Wyniki implementacji ................................................................................................. 104
Sprzętowy system bezpieczeństwa typu Firewall.....................................................................105
5.1.
Wprowadzenie ..................................................................................................................... 105
5.2.
Silnik sprzętowego systemu typu Firewall .......................................................................... 109
5.2.1.
Schemat blokowy ........................................................................................................ 109
5.2.2.
Kontroler pamięci ramkowej ....................................................................................... 111
5.2.3.
Moduł generujący deskryptor bezpieczeństwa ............................................................ 113
5.2.4.
Pamięć wspomagająca cache ...................................................................................... 113
5.2.5.
Moduł zarządzający..................................................................................................... 117
5.2.6.
Wyniki implementacji ................................................................................................. 119
5.3.
Sprzętowy klasyfikator pakietów......................................................................................... 119
5.3.1.
Schemat blokowy ........................................................................................................ 120
5.3.2.
Filtr adresów sieciowych ............................................................................................. 122
5.3.3.
Filtr portów sieciowych ............................................................................................... 126
5.3.4.
Moduł sterujący ........................................................................................................... 131
5.3.5.
Wyniki implementacji oraz ocena wydajności sprzętowego klasyfikatora pakietów . 133
5.4.
Blok ładowania polityki bezpieczeństwa ............................................................................. 135
5.5.
Aplikacja zarządzająca ........................................................................................................ 140
5.6.
Ocena wyników implementacji kompletnej zapory sieciowej ............................................. 142
6.
Podsumowanie ............................................................................................................................149
7.
Bibliografia..................................................................................................................................154
8.
Dodatek A – opis funkcji sygnałów poszczególnych modułów sprzętowego systemu
Firewall .......................................................................................................................................163
9.
Dodatek B - szczegółowe wyniki syntezy modułów sprzętowego Firewalla ..........................172
10. Dodatek C – zawartość płyty CD ..............................................................................................186
4
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
niezależnym
przeszukiwaniu
(ang. Discretionary Access Control)
DCFL
- metoda
klasyfikacji
pakietów
bazująca
na
poszczególnych pól, połączonym z kodowaniem i agregacją pośrednich wyników
5
kwerend (ang. Distributed Crossproducting Field Labels)
DCFLE
- rozszerzona wersja algorytmu DCFL zaproponowana przez G. Jedhe et al.
(ang. Distributed Crossproducting of Field Labels Extended)
DCM
- blok zarządzania zegarem cyfrowym dostępny w zasobach układów FPGA Virtex
firmy Xilinx (ang. Digital Clock Management)
DDR
- podwójna szybkość przesyłu danych (ang. Double Data Rate)
DIRE
- metoda kodowania zakresów uzależniona od zawartości bazy reguł bezpieczeństwa
(ang. Database Independent Range Encoding)
DIRPE
- metoda kodowania zakresów niezależna od zawartości bazy reguł bezpieczeństwa
(ang. Database Independent Range PreEncoding)
DoS
- atak typu odmowa usługi (ang. Denial of Service)
DPI
- metoda pełnej (głębokiej) analizy pakietów (ang. Deep Packet Inspection)
EDA
- elektroniczne wspomaganie procesu projektowania (ang. Electronic Design
Automation)
EPP
- standard dwukierunkowego równoległego portu komunikacyjnego urządzeń
komputerowych (ang. Enhanced Parallel Port),
ERS
- metoda jawnego wyszukiwania zakresów zaproponowana przez Y. Lou et al.
(ang. Explicite Range Serach)
E-TCAM
- zmodyfikowana trójwartościowa pamięć adresowana zawartością, pozwalająca na
zapisywanie przedziałów (ang. Extended TCAM)
FCS
- sekwencja kontrolna ramki Ethernet zawierająca 4-bajtowy kod CRC (ang. Frame
Check Sequence)
FIFO
- kolejka, liniowy bufor danych (ang. First In, First Out)
FIS-tree
- algorytm klasyfikacji pakietów wykorzystujący zmodyfikowaną wersję drzewa
odcinków (ang. Fat Inverted Segment tree)
FPGA
- układy programowalne o architekturze matrycowej (ang. Field Programmable Gate
Array)
FSM
- automat skończony (ang. Finite State Machine)
FTP
- protokół transferu plików (ang. File Transfer Protocol)
GMII
- gigabitowy interfejs komunikacyjny niezależny od typu medium fizycznego
(ang. Gigabit Media Independent Interface)
GOT
- algorytm klasyfikacji pakietów bazujący na strukturach typu trie opracowany przez
V. Srinivasan’a et al. (ang. Grid-Of-Tries)
GPP
- procesor ogólnego przeznaczenia (ang. General Purpose Processor)
GUI
- graficzny interfejs użytkownika (ang. Graphical User Interface)
HiCuts
- heurystyczny algorytm klasyfikacji pakietów opracowany przez P. Gupta et al.
(ang. Hierarchical Intelligent Cuttings)
6
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 1149.1
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
(ang. Media Independent Interface)
MLS
- wielopoziomowy model bezpieczeństwa systemów komputerowych (ang. MultiLevel 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)
P2C
- 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
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
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
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. e-mail). Pomiędzy
styczniem a marcem roku 2009 wysłano 139 miliardów niepożądanych wiadomości e-mail (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
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).
1.2. 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
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
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
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
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.
2.2.1. 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. 2.1. 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
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.
2.2.2. 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
usuwać po określonym czasie (ang. time out) poszczególne wpisy z tabeli połączeń.
2.2.3. 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. 2.2. 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
2.2.4. 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. 2.3. 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
2.2.5. Filtry typu Stateful Inspection
Omówiona w punkcie 2.2.4 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
Sieć zewnętrzna
WARSTWY MODELU
REFERENCYJNEGO OSI
APLIKACJI
APLIKACJI
APLIKACJI
PREZENTACJI
PREZENTACJI
PREZENTACJI
SESJI
SESJI
SESJI
TRANSPORTOWA
TRANSPORTOWA
TRANSPORTOWA
SIECIOWA
SIECIOWA
SIECIOWA
ŁĄCZA DANYCH
ŁĄCZA DANYCH
ŁĄCZA DANYCH
FIZYCZNA
FIZYCZNA
Interfejs
sieciowy
WARSTWY MODELU
REFERENCYJNEGO OSI
Dynamiczny
filtr pakietów
FIZYCZNA
FIZYCZNA
Ograniczone
funkcje bramki
typu Circuit-level
Ograniczone
funkcje bramki
aplikacyjnej
Interfejs
sieciowy
Sieć wewnętrzna
Rys. 2.4. 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].
2.2.6. 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
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
APLIKACJI
APLIKACJI
PREZENTACJI
PREZENTACJI
SESJI
SESJI
TRANSPORTOWA
TRANSPORTOWA
SIECIOWA
SIECIOWA
ŁĄCZA DANYCH
ŁĄCZA DANYCH
FIZYCZNA
FIZYCZNA
Sieć zewnętrzna
Interfejs
sieciowy
WARSTWY MODELU
REFERENCYJNEGO OSI
Ograniczone
funkcje bramki
typu Circuit-level
FIZYCZNA
Dynamiczny
filtr pakietów
Interfejs
sieciowy
Sieć wewnętrzna
Rys. 2.5. 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.
2.2.7. 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
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. 2.6. 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.
2.2.8. 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
Liczba zarejestrowanych przypadków
Przyrost Malware
(pierwsze kwartały lat 2008–2010)
4,500,000
4,000,000
3,500,000
3,000,000
2,500,000
2,000,000
1,500,000
1,000,000
500,000
0,000
Q1 2008
Q1 2009
Q1 2010
Rys. 2.7. Porównanie liczby zarejestrowanych przypadków oprogramowania malware w pierwszych
kwartałach lat 2008-2010 [66].
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).
2.2.9. 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
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.
2.3.1. 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. 2.8. 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 2.9.
24
Liczba zarejestrowanych luk bezpieczeństwa
25
20
15
10
5
0
Microsoft Windows Server 2008
SUSE Linux Enterprise Server (SLES) 11
Red Hat Enterprise Linux ES4
Debian GNU/Linux 5.0
Rys. 2.9. 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
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. 2.10. 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
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
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
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: R1, R2… Rn. 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łą Ri 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. 2.1. Opis zmiennych wykorzystywanych w funkcjach złożoności czasowej poszczególnych
algorytmów.
Zmienna
Opis
N
Liczba reguł
d
Liczba wymiarów (analizowanych pól nagłówków)
W
Długość (bitowa) prefiksu pojedynczego wymiaru
S
Szerokość słowa danych pamięci
A, α, l
Parametry optymalizacyjne, specyficzne dla danego algorytmu
29
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. 2.2. Podział algorytmów klasyfikujących (na podstawie [33, 50]).
Kategoria
Przykłady algorytmów
Podstawowe struktury
danych
Przeszukiwanie liniowe, drzewa hierarchiczne,
drzewa przycinane, wektory bitowe
Geometryczne
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
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(Wd) [33, 50]. Możliwym jest
również dokonywanie przyrostowych aktualizacji hierarchii drzew w czasie O(d2W). 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(NddW).
Złożoność czasowa
aktualizacji, wynosząca O(N ), ogranicza obszar wykorzystania algorytmu do relatywnie małych
d
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
zagregowanego wektora bitowego o długości A, redukuje koszt operacji wstępnego przetwarzania
bazy reguł do wartości O(N2d), 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. GridOf-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(Wd-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 CT (ang. cross-product table) złożona ze zidentyfikowanych
zakresów wraz z odpowiadającymi im numerami reguł, przechowywanych w postaci krotek
i oznacza kolejne zakresy dla wymiaru d (np. [ ,
], [ ,
, gdzie
]….) [50]. Ponieważ dla N prefiksów
istnieje najwyżej 2N-2 zakresów, maksymalny rozmiar tablicy CT, a zarazem zapotrzebowanie na
zasoby pamięciowe algorytmu cross-producting, osiąga wartość O(Nd). 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 F1 jest ograniczony jedynie do formy
prefiksowej, drugi zaś F2 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 F1.
Węzłom zewnętrznym drzewa F1 przyporządkowane zostają niezachodzące na siebie przedziały
cząstkowe wymiaru F2, reprezentujące poszczególne reguły, zgodne z prefiksem wymiaru F1. 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
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
classID). Efektywność czasowa weryfikacji dla algorytmu RFC wynosi O(d), zaś zapotrzebowanie
pamięciowe O(Nd) [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(Nd) [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].
2.3.2. 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
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
192.168.1.*, gdzie „*” oznacza pozycję nieistotną, będzie zapisany w pamięci TCAM jako wartość
„11000000 10101000 00000001 00000000” z maską „11111111 11111111 11111111 00000000”.
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
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
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 vi przyjmuje wysoką wartość logiczną jedynie wówczas, kiedy klucz
zawiera się w przedziale Ri. 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 P2C (ang. Parallel Packet Classification)
pozwala na jednoczesne, niezależne wyszukiwanie informacji w wielu polach, ograniczając znacznie
zapotrzebowanie na zasoby pamięciowe. Algorytm P2C 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 P2C, 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
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
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(dN2).
Złożoność czasowa operacji wyszukiwania uzależniona jest od szerokości słowa pamięci
i wynosi
[33].
Tab. 2.3. Porównanie złożoności obliczeniowej oraz zapotrzebowania na zasoby pamięciowe
algorytmów klasyfikujących (na podstawie [33, 50]).
Algorytm
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(Wd)
O(NdW)
GOT
O(Wd-1)
O(NdW)
Cecilia (Set-pruning tries)
O(dW)
O(NddW)
Cross-producing
O(dW)
O(Nd)
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(Nd)
HiCuts
O(d)
O(Nd)
BVL
O(dN2)
Bitmap-intersection
Ternary CAM
Zbiorcze
zestawienie
O(1)
parametrów
czasowo-pamięciowych
O(N)
omawianych
algorytmów
przedstawiono w tabeli 2.3. Część z przedstawionych algorytmów można bezpośrednio
implementować w układach programowalnych FPGA (np. P2C [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
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 P2C, 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
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
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
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
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
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.
3.2. 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
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
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. 3.1. 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
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
Gniazdo
zasilające
5-9V DC
Przycisk
kontrolny
Dioda
sygnalizacyjna
LED
Stabilizator
2.5 V
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
Bufor
Przełącznik
trybu
programowania
Port rozszerzeń
C
Port
JTAG
Port rozszerzeń
A
Port rozszerzeń
E
Port rozszerzeń
B
Port rozszerzeń
F
Rys. 3.2. 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
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.
B
C
DB-9
A
37
11
Xilinx
Spartan2E
XC2S200E
-PQ208
F
D
DB-25
37
37
E
Rys. 3.3. 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].
3.4. 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
Rys. 3.4. 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:
13969 bloków Slice,
428 Kb pamięci Distributed RAM oraz 2448 Kb pamięci Block RAM,
50
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.
Złącza rozszerzeń
(zabezpieczenia
przeciążeniowe)
1
Diody LED, Przełączniki,
przyciski, porty
PS/2 Oraz RS-232
0
2
7
3
6
4
Pamięć 256M x 64/72 DDR SDRAM
DIMM
SXGA port
10/100
Ethernet
AC97 Audio
5
System ACE port
3.3V IO
2.5V IO
Rys. 3.5. 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
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.
3.5. 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
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.
3.5.1. 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)
MAC – MEDIA ACCESS CONTROL
GMII
PCS
PMA
PMD
PMD
MDI
PMA
PCS
PMA
MDI
PMA
DOPASOWANIE
MDI
FIZYCZNA
MAU
ŁĄCZA DANYCH
PLS
AUI
SIECIOWA
DOPASOWANIE
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
PHY
AUI
MII
TRANSPORTOWA
DOPASOWANIE
MDI
PLS
MII
SESJI
PLS = PHYSICAL LAYER SIGNALING
PCS = PHYSICAL CODING SUBLAYER
PMA = PHYSICAL MEDIUM ATTACHMENT
PHY = PHYSICAL LAYER DEVICE
PMD = PHYSICAL MEDIUM DEPENDENT
Rys. 3.6. Model warstwowy ISO/OSI z uwidocznionym położeniem układu PHY.
53
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
MLT-3
NRZI
Korekcja BLW
Detektor
szczytowy
Komparator
Korektor
adaptacyjny
RXIN +
RXIN -
RXD
Dekoder
5B/4B
Blok formowania
danych
Descrambler
Deserializacja
clk
data
Slave
PLL
RXC
25MHz
TXD
10/100 Mbps, Half/Full Duplex
Logika sterująca
Interfejs SNI
Interfejs MII
Dekoder
4B/5B
Scrambler
Serializacja
3-stanowy bufor
wyjsciowy
TXO +
TXO -
TXC
25MHz
Autonegocjacja 10/100 Mbps
Logika kontrolna
25MHz
Główna PLL
BLOK 10 Mbps
TXD10
Kodowanie
Menchester
Formowanie
sygnału
wyjściowego
Odtwarzanie
danych
Filtr dolnoprzepustowy
TXC10
RXD10
RXC10
Rys. 3.7. 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
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 802.3 [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 802.3 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
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/ „11000 10001” (ang. start-of-frame delimiter). Po zakończeniu
transmisji danych wysyłana jest sekwencja /T/R/ „01101 00111”
(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
32 cykle zegara
0
Preambuła
1
0
ST
1
A4
OP
A3
A2
A1
A0
R4
PHYAD[4:0]
R3
R2
R1
R0
1
REGAD[4:0]
0
D15
D14
D13
D12
D11
D10
D9
D8
TA
D7
D6
D5
D4
D3
D2
D1
D0
DANE
IDLE
Linia MDIO sterowana przez kontroler MAC; dane zapisywane do układu PHY przy narastającym zboczy zegara MDC
cykl zapisu
Z
32 cykle zegara
Preambuła
0
1
ST
1
0
OP
A4
A3
A2
A1
A0
R4
PHYAD[4:0]
R3
R2
R1
REGAD[4:0]
Linia MDIO sterowana przez kontroler MAC; dane zapisywane do układu PHY
przy narastającym zboczy zegara MDC
R0
0
D15
D14
D13
D12
TA
D11
D10
D9
D8
D7
D6
D5
D4
D3
D2
D1
D0
DANE
IDLE
Linia MDIO sterowana przez PHY; dane wystawiane przez PHY
przy narastającym zboczy zegara MDC
cykl odczytu
Rys. 3.8. 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 „00001” do „11111” (wartość „00000” 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. 3.1. Opis poszczególnych pól ramki zarządzającej układu RTL8201BL (na podstawie [83]).
Nazwa
Preambuła
Opis
'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
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'.
TA
DANE
Dane (ang. Data). 16-bitowa wartość odczytanych bądź zapisywanych danych.
IDLE
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
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. 3.2. 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
3
-
-
-
4
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 JP1JP10. 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. 3.3. Opis funkcji poszczególnych diod sygnalizacyjnych karty Fast Ethernet.
Nazwa
Funkcja
LED 0
Link: aktywna w momencie zestawienia poprawnego połączenia do medium.
LED 1
Full Duplex: aktywna w trybie Full Duplex.
LED 2
Link 10 Mb/Active: tryb 10Base-T; pulsuje w momencie transmisji bądź odbioru danych.
LED 3
Link 100 Mb/Active: tryb 100Base-TX; pulsuje w momencie transmisji bądź odbioru danych.
LED 4
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 3.9.
58
Rys. 3.9. 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
wymagały
DIP-switch
montażu
przewlekanego.
Rozmieszczenie
linii
zasilających
oraz
poszczególnych sygnałów interfejsu MII w złączu komunikacyjnym karty Fast Ethernet pokazano na
TXD2
TXD0
RXCLK
RXD2
5
7
9
11
13 15
17 19
21
23
25 27
29
31 33
35 37
39
2
4
6
8
10
12
14 16
18 20
22
24
26 28
30
32 34
36 38
40
COL
TXD3
TXD1
TXCLK
RXD3
RXDV
MDIO
RXER
RXD1
MDC
TXEN
3
CRS
VDD 3.3V
1
RXD0
GND
rysunku 3.10.
Rys. 3.10. Numeracja wyprowadzeń złącza interfejsu MII karty Fast Ethernet.
3.5.2. 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
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 802.3 10BASE-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 3.11. 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
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.
Mikrokontroler
zarządzający oraz
blok kontroli PHY
Blok multipleksera/
demultipleksera
MII
MII
GMII
1000BASE-T
PCS
10BASE-T
PMA
100BASE-TX
PMA
1000BASE-T
PMA
Blok 10BASE-T
100BASE-TX
PMD
MLT-3
100 Mb/s
Blok 1000BASE-T
100BASE-TX
PCS
Blok 100BASE-TX
10BASE-T
PLS
Manchester
10 Mb/s
RXD[7:0]
RX_DV
RX_ER
CRS
COL
RX_CLK
TX_CLK
TXD[7:0]
TX_EN
TX_ER
GTX_CLK
Wspólny interfejs MII/GMII/RGMII
Interrupt
MDC
MDIO
Interfejs zarządzający
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. 3.11. Schemat blokowy układu DP83865 (na podstawie [68]).
61
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. 3.4. Opis funkcji diod sygnalizacyjnych karty Fast Ethernet.
Nazwa
Funkcja
D1
ACTIVITY_LED: sygnalizacja błędu w stanie bezczynności (ang. Idle error) lub transferu pakietu.
D2
LINK10_LED: sygnalizacja poprawnego połączenia 10 Mb/s.
D3
LINK100_LED: sygnalizacja poprawnego połączenia 100 Mb/s.
D4
LINK1000_LED: sygnalizacja poprawnego połączenia 1000 Mb/s.
D5
DUPLEX_LED: sygnalizacja zestawienia poprawnego połączenia w trybie Full Duplex.
62
Tab. 3.5. Opis funkcji przełączników konfiguracyjnych w karcie Gigabit Ethernet.
Numer
1
2
3
Pozycja przełącznika
Funkcja
Reset manualny
Wybór napięcia zasilania stopnia I/O
(sygnał VDD_SEL_STRAP )
Włączenie zegara interfejsu MAC
(sygnał MAC_CLK_EN_STRAP)
A
B
-
-
2,5V
3,3V
Wyjście CLK_TO_MAC
nieaktywne
Wyjście CLK_TO_MAC
aktywne
4
Włączenie automatycznej konfiguracji par
interfejsu MDI (sygnał
MDIX_EN_STRAP)
Auto-MDIX wyłączone –
aktywne manualne ustawienia
(sygnał MAN_MDIX_STRAP)
Automatyczna konfiguracja
Auto-MDIX aktywna
5
Zezwolenie trybu wielowęzłowego
(sygnał MULTI_EN_STRAP)
Tryb jednowęzłowy
(karta sieciowa - NIC)
Tryb wielowęzłowy
(przełącznik lub koncentrator)
6
Adres PHY bit 4
(sygnał PHYADDR4_STRAP)
0
1
7
Typ interfejsu MAC
(sygnał RGMII_SEL1)
Interfejs GMII
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)
Dla RGMII_SEL1 = ‘1’
Interfejs RGMII – HP
Interfejs RGMII o typie
zależnym od wartości sygnału
RGMII_SEL0
Dla RGMII_SEL1 = ‘1’
Interfejs RGMII – 3COM
CLOCK TO MAC = 25 MHz
CLOCK TO MAC = 125 MHz
0
1
0
1
0
1
13
Ręczna konfiguracja krosowania interfejsu
MDI (sygnał MAN_MDIX_STRAP)
Tryb skrosowany
(crossover mode MDIX)
14
Włączenie trybu niekompatybilnego z IEEE
(sygnał NON_IEEE_STRAP)
Tryb prosty
(straight mode MDI)
Zezwolenie na operacje
kompatybilne z równoczesną
blokadą operacji
niekompatybilnych z IEEE
8
9
10
11
12
Zezwolenie na operacje
kompatybilne i
niekompatybilne z IEEE
Adres PHY bit 0
0
1
(sygnał PHYADDR0_STRAP)
Włączenie autonegocjacji
16
Autonegocjacja wyłączona
Autonegocjacja włączona
(sygnał AN_EN_STRAP )
Tryb komunikacji dupleksowej
17
Half Duplex
Full Duplex
(sygnał DUPLEX_STRAP)
Ustawienie prędkości pracy
18
0
1
(sygnał SPEED1_STRAP)
Ustawienie prędkości pracy
19
0
1
(sygnał SPEED0_STRAP)
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
1
1
1000BASE-T, 10BASE-T
1
0
1000BASE-T
1
0
1000BASE-T
0
1
100BASE-TX
0
1
1000BASE-T, 100BASE-TX
0
0
10BASE-T
0
0
1000BASE-T, 100BASE-TX,
10BASE-T
15
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
w 40-wyprowadzeniowy interfejs MII/GMII oraz 6-wyprowadzeniowy interfejs diagnostyczny.
TXD5
TXD3
TXD1
23
25 27
29
31 33
35 37
39
2
4
6
8
10
12
14 16
18 20
22
24
26 28
30
32 34
36 38
40
TX_TCLK
CRS
RXD6
RXD4
RXD0
TX_CLK
TX_EN
TXD6
TXD2
TXD0
MAC_CLK_EN
TXD7
21
RXD2
MDC
TX_ER
17 19
CLK_TO_MAC
RXD5
13 15
MDIO
RXD7
11
TXD4
RX_ER
9
RX_CLK
COL
7
RXD1
INT_N
5
RXD3
VDD 3.3V
3
RX_DV
GND
1
RESET_N
GTX_CLK
Rozmieszczenie sygnałów w złączu interfejsu MII/GMII pokazano na rysunku 3.12.
Rys. 3.12. 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. 3.13. Prototyp zmontowanej karty Gigabit Ethernet (widok od góry) – skala 1:1.
Zdjęcie prototypu zmontowanej karty Gigabit Ethernet przedstawia rysunek 3.13. 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
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
802.3 [40], wydanej w roku 1983. 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
S ysKonnect P 4DP 6 64 bit 66 MHz
Utracone pakiety [%]
100
80
60
40
Rozmiar pakietu
50 bajtów
20
100 bajtów
0
200 bajtów
0
5
10
15
20
25
Odstęp pomiędzy kolejnymi pakietami [μs]
30
35
40
400 bajtów
600 bajtów
Obciążenie procesora CPU1
stacji odbierającej [%]
800 bajtów
S ysKonnect P 4DP 6 64 bit 66 MHz
100
1000 bajtów
1200 bajtów
80
1400 bajtów
60
1472 bajty
40
20
0
0
5
10
15
20
25
Odstęp pomiędzy kolejnymi pakietami [μs]
30
35
40
Rys. 4.1. 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
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 802.3. 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 MODELU
REFERENCYJNEGO
OSI
WARSTWA TRANSPORTOWA
APLIKACJI
LLC – LOGICAL LINK CONTROL
PREZENTACJI
MAC CONTROL (opcjonalnie)
SESJI
MAC – MEDIA ACCESS CONTROL
WARSTWA SIECIOWA
AUI
PLS
MAU
AUI
SIECIOWA
PMD
MDI
PMD
MDI
PCS
PMA
MDI
PMA
PCS
PMA
MDI
PMA
DOPASOWANIE
GMII
DOPASOWANIE
MII
DOPASOWANIE
MII
PLS
TRANSPORTOWA
ŁĄCZA DANYCH
Sprzętowy
kontroler MAC
WARSTWY WYŻSZE
MEDIUM
MEDIUM
MEDIUM
MEDIUM
1 Mb/s, 10Mb/s
10Mb/s
100Mb/s
1000Mb/s
FIZYCZNA
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. 4.2. 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 4.2.
67
4.2. Struktura ramki Ethernet
Standard IEEE 802.3 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
PREAMBUŁA
1 Oktet
POLE STARTU RAMKI (SFD)
6 Oktetów
ADRES DOCELOWY
6 Oktetów
ADRES ŹRÓDŁOWY
Porządek
nadawania
bajtów ramki:
od góry do
dołu
DŁUGOŚĆ/TYP
2 Oktety
DANE KLIENTA MAC
46 – 1500
Oktetów
DOPEŁNIENIE (PAD)
4 Oktety
SUMA KONTROLNA (FCS)
ROZSZERZENIE (EXTENTION)
LSB
b0
b7
MSB
Porządek wysyłania poszczególnych
bitów: od LSB do MSB
Rys. 4.3. 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
Tab. 4.1. 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
512 okresów
bitowych
512 okresów
bitowych
4096 okresów
bitowych
9,6 μs
0,96 μs
0,096 μs
Limit prób dostępu (attemptLimit)
16
16
16
Limit ponowień algorytmu Backoff (backoffLimit)
10
10
10
Długość sygnału rozgłaszającego kolizję (jamSize)
32 bity
32 bity
32 bity
1518 oktetów
1518 oktetów
1518 oktety
Minimalna długość ramki (minFrameSize)
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
65 536 bitów
Okno czasowe (slotTime)
Odstęp międzyramkowy (interFrameGap)
Maksymalna długość ramki podstawowej
(maxUntaggedFrameSize)
4.2.1. Charakterystyka pól składowych ramki podstawowej
Z punktu widzenia funkcjonowania sieci opartej o standard specyfikacji IEEE 802.3 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: „10101010
10101010 10101010 10101010 10101010 10101010 10101010”. 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 „10101011”. 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. 4.4. Struktura pól adresowych ramki Ethernet.
69
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
Wynik obliczenia 32-bitowego kodu CRC zawartego w polu FCS jest transmitowany
w porządku od bitu x31 do bitu x0,
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.
4.2.2. 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.
8 7 6 5 4 3 2 1
7 Oktetów
PREAMBUŁA
1 Oktet
QTag
Prefix
POLE STARTU RAMKI (SFD)
6 Oktetów
ADRES DOCELOWY
6 Oktetów
ADRES ŹRÓDŁOWY
2 Oktety
DŁUGOŚĆ/TYP= 802.1QTagType
2 Oktety
INFORM. KONTROLNE ZNACZNIKA
2 Oktety
DŁUGOŚĆ/TYP KLIENTA MAC
Pierwszy oktet
0 0 0 0 0 0 0 0
Drugi oktet
user
priority
Pierwszy oktet
CFI
VLAN IDENTIFIER (VID, 12 bitów)
Drugi oktet
Porządek
nadawania
bajtów ramki:
od góry do
dołu
Informacja kontrolne znacznika
(ang. Tag Control Information)
DANE KLIENTA MAC
42 – 1500
Oktetów
1 0 0 0 0 0 0 1
DOPEŁNIENIE (PAD)
4 Oktety
SUMA KONTROLNA (FCS)
ROZSZERZENIE (EXTENTION)
LSB
b0
b7
MSB
Porządek wysyłania poszczególnych
bitów: od LSB do MSB
Rys. 4.5. 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
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).
4.3.1. 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].
Tor nadawczy TX
(moduł eth_tx)
Blok kontrolny
(moduł eth_control)
Interfejs Firewalla
Tor odbiorczy RX
(moduł eth_rx)
Interfejs MII
Karta sieciowa
Kontroler MAC
Rys. 4.6. 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 8.1.
72
moduł eth_mac.vhd
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) →
reset ←
eth_tx
→ phy_tx_clk
← phy_tx_en
← phy_tx_data(3:0)
→ phy_col
→ phy_crs
→ r_rx_mac_address(47:0)
→ r_rx_multicast_en
→ r_rx_promiscous_en
→ r_tx_crc_en
→ r_tx_padding_en
→ r_tx_crc_en
→ r_tx_padding_en
half_duplex ←
tx_enable ←
tx_running →
tx_retransmit →
tx_data(7:0) ←
tx_data_ack →
tx_ok →
tx_error →
tx_frame_size(10:0) ←
reset ←
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) ←
→ r_mii_config(15:0)
eth_control
→ phy_int_n
← phy_mdc
↔ phy_mdio
INTERFEJS FIREWALLA
KONFIGURACJA
INTERFEJS PHY MII
eth_rx
rx_enable ←
→ phy_rx_clk
rx_pause ←
→ phy_rx_dv
→ phy_rx_error
rx_data_valid →
→ phy_rx_data(3:0)
rx_data(7:0) →
rx_active →
→ r_rx_mac_address(47:0)
→ r_rx_multicast_en
rx_ok →
→ r_rx_promiscous_en
rx_error →
rx_frame_size(10:0) →
→ 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
eth_mac_ready →
eth_control_link →
eth_control_speed →
eth_control_half_duplex →
sys_clk ←
→ r_mii_config(15:0)
reset ←
sys_clk ←
reset ←
<= '0' when reset = reset_level
else '1';
Rys. 4.7. Struktura wewnętrzna modułu eth_mac w wersji Fast Ethernet.
4.3.2. 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 802.3 [40]. Funkcje oraz sposób
Tor odbiorczy RX
Dane
eth_rx_bitreceiver
Konfiguracja
Interfejs
Firewalla
Interfejs MII
Karta sieciowa
działania poszczególnych modułów zostaną szerzej opisane w dalszej części niniejszego rozdziału.
eth_rx_datadecap
eth_rx_recaddress
eth_rx_tlm
Sygnały
kontrolne
eth_rx_crc
Rys. 4.8. Schemat blokowy toru odbiorczego RX.
73
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
→ 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) →
eth_rx_datadecap
→ 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. 4.9. 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
Dane z układu PHY
Sygnalizacja
początku ramki
Dane wyjściowe
Sygnalizacja
kooca ramki
Długośd ramki
Rys. 4.10. 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.
Wartośd pola L/T
Kontekst pola L/T
Rys. 4.11. 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
Konfiguracji typów
obsługiwanych ramek
Sygnał detekcji poprawnie
zaadresowanej ramki
Rys. 4.12. 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 4.13.
Odbierane bajty danych
analizowanej ramki
Potwierdzenie
poprawności kodu CRC
Rys. 4.13. 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
Adres Mac
zgodny
Sekwencja CRC
zgodna z FCS
Długośd
poprawna
Informacja o poprawnym
zweryfikowaniu ramki
Rys. 4.14. Przebiegi czasowe sygnałów modułu eth_rx_tlm dla przykładowej ramki Ethernet.
4.3.3. 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].
Dane
eth_tx_bittran
Konfiguracja
Interfejs
Firewalla
Interfejs MII
Karta sieciowa
Tor nadawczy TX
eth_tx_crc
eth_tx_defer
eth_rx_tlm
Sygnały
kontrolne
eth_tx_backoff
Rys. 4.15. 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 802.3 [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
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
Tak
collisionDetect?
Tak
Późna kolizja i
prędkość >
100Mb/s
Nie
Nie
Nie
Transmisja
zakończona?
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. 4.16. 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 4.17. 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 8.3.
78
←
←
←
tx_data_ack_process
←
tx_retransmit_process
moduł eth_rx.vhd
←
←
←r_tx_crc_en
← r_tx_padding_en
Interfejs
konfiguracyjny
←
←
←
←
tx_attempt_cnt_eqlimit ←
tx_attempt_cnt_eq0 ←
tx_backoff_cnt_eq0 ←
r_tx_padding_en ←
r_tx_crc_en ←
tx_enable ←
phy_tx_col ←
phy_tx_crs ←
half_duplex ←
phy_tx_clk ←
← tx_fsm_padding
← tx_fsm_data
← tx_fsm_sfd
← tx_fsm_preamble
← tx_fsm_ifs2
← tx_fsm_ifs1
← tx_fsm_ifs
← tx_fsm_set_defer
← tx_fsm_idle
← phy_tx_clk
→ phy_tx_en
← phy_col
← phy_crs
→ phy_tx_data(3:0)
Interfejs MII
PHY
← tx_fsm_jam
phy_tx_en_process
Interfejs
Firewall’a
eth_tx_tlm
← tx_active
← tx_ok
← tx_fsm_start_backoff
← tx_fsm_start_crc
← tx_fsm_start_jam
← 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_igp_cnt_eq_ifs ←
← tx_fsm_start_ifs2
tx_eq_in_frame ←
← tx_fsm_start_ifs1
tx_eq_min_frame ←
← tx_fsm_start_ifs
tx_eq_crc ←
← tx_fsm_start_set_defer
← tx_fsm_start_idle
tx_eq_jam ←
tx_eq_sfd ←
← tx_fsm_backoff
tx_eq_preamble ←
← tx_fsm_crc
→ 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
←
Konwersja
nible->bajty
→ 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
←
eth_tx_bittran
→ phy_tx_clk
phy_tx_data(3:0) →
→ half_duplex
tx_eq_preamble →
→ tx_fsm_idle
tx_eq_sfd →
tx_eq_jam →
→ tx_fsm_preamble
→ tx_fsm_sfd
tx_eq_crc →
→ tx_fsm_data
tx_eq_min_frame →
tx_eq_in_frame →
→ tx_fsm_padding
tx_nible_counter(11:0) →
→ tx_fsm_jam
→ tx_fsm_crc
→ tx_fsm_start_preamble
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_fsm_start_idle
→ tx_fsm_start_backoff
→ tx_fsm_start_ifs
→ tx_fsm_start_ifs1
tx_igp_cnt_eq_ifs →
tx_igp_cnt_eq_ifs1 →
tx_igp_cnt_eq_ifs2 →
→ 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. 4.17. Struktura wewnętrzna modułu eth_tx w wersji Fast Ethernet.
79
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. 4.18. 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 4.19.
Początek pola
danych klienta MAC
Koniec pola danych
klienta MAC
Transmisja wyliczonego
kodu CRC
Rys. 4.19. Przebiegi czasowe sygnałów modułu eth_tx_crc dla transmisji przykładowej ramki Ethernet.
80
Moduł eth_tx_defer odpowiada funkcjonalnie procesowi Deference w modelu IEEE 802.3
[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
Nie
Kanał
wolny?
Tak
Odczekaj
czas równy
interframe
delay
Wyłącz
opóźnianie
Czy ramka jest
wysyłana
(aktywny syg.
frameWaiting)?
Nie
Tak
Rys. 4.20. 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. 4.21. Przebiegi czasowe sygnałów modułu eth_tx_defer dla transmisji przykładowej ramki Ethernet.
81
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 2k ,
(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. 4.22. 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
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. 4.23. 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. 4.24. Zakończenie procedury opóźniania backoff.
83
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. 4.25. 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 4.26.
84
TxTransmitEnabled = '0'
TxTransmitEnabled = '1' and
((HalfDuplex = '1' and PHYTxCarrier = '0') or
HalfDuplex = '0')
IDLE
TxTransmitEnabled = '1' and
HalfDuplex = '1' and
PHYTxCarrier = '1'
BackOffCntEq0 = '1' and
AttemptCntEqLimit = '1'
IGPCounterEqIFS = '1' and
((HalfDuplex = '0') or
(HalfDuplex = '1' and
(AttemptCntEqLimit = '1' or
TxOK = '1'))
IGPCounterEqIFS2 = '1' and
PHYTxCarrier = '1'
AttemptCntEq0 = '1' and
PHYTxCarrier = '0'
SetDefer
BackOffCntEq0 = '1' and
AttemptCntEqLimit = '0' and
PHYTxCarrier = '1'
WaitIFS1
IGPCounterEqIFS1 = '1'
AttemptCntEq0 = '0' and
PHYTxCarrier = '0'
PHYTxCarrier = '1' and
AttemptCntEq0 = '0' and
IGPCounterEqIFS = '1' and
AttemptCntEqLimit = '0'
WaitIFS
BackOffCntEq0 = '1' and
PHYTxCarrier = '0' and
AttemptCntEqLimit = '0'
WaitIFS2
IGPCounterEqIFS2 = '1' and
PHYTxCarrier = '0'
Preamble
BackOff
collisionDetect = '1'
IGPCounterEqIFS = '1' and
PHYTxCarrier = '0' and
HalfDuplex = '1' and
AttemptCntEqLimit = '0' and
TxOK = '0'
EqPreambleLenght = '1' and
collisionDetect = '0'
EqJamLenght = '1' and
BackOffCntEq0 = '1'
EqJamLenght = '1' and
BackOffCntEq0 = '0'
SFD
Jam
EqSFDLenght = '1' and
collisionDetect = '0'
EqDataLenght = '1' and
PaddingNeeded = '0' and
collisionDetect = '0'
Data
collisionDetect = '1'
Padding
EqCRCLenght = '1'
CRC
EqDataLenght = '1' and
PaddingNeeded = '1' and
collisionDetect = '0'
EqPadLenght = '1' and
collisionDetect = '0'
Rys. 4.26. Graf przejść automatu FSM sterującego torem TX.
4.3.4. 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
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 4.27.
Sygnał r_mii_config
b11
b10
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
LSB
Zarezerwowane
b12
Tryb pracy modułu
kontrolnego
b13
zmiana okresu
odświeżania stanu
rejestrów PHY
b14
Współczynnik
podziału zegara
b15
Adres PHY
MSB
Rys. 4.27. 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 fsys, 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 fr określa wówczas zależność:
fr
f sys
d 2 20
.
(4.3)
86
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 4.28.
Maskowanie
przerwao
Zerowanie
przerwao
Komunikacja
poprzez linię MDIO
Odczyt rejestrów
PHY
Tryb
połączenia
Oczekiwanie na
przerwanie PHY
Prędkośd
połączenia
Stan
połączenia
Rys. 4.28. Przykład przebiegów czasowych modułu eth_control.
4.3.5. 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. 4.2. Podsumowanie wykorzystania zasobów sprzętowych układów FPGA
oraz uzyskane parametry czasowe kontrolera MAC w wersji Fast Ethernet.
Rodzaj zasobów
Spartan
Virtex
Typ układu 2s200epq208-7 2vp30ff896-7
Liczba bloków Slice
295
329
Liczba 4-wejściowych LUT
555
610
547
602
8
8
użytych jako logika
użytych jako rejestry przesuwne
Parametry czasowe
Maks. częstotliwość
Maks. opóźnienie ścieżki kombinacyjnej
74,705 MHz 191,953 MHz
17,511 ns
6,864 ns
87
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.
4.4. 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. 4.29. Tryb transmisji seryjnej burst mode [40].
88
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
slotTime
okres obliczania FCS
próg występowania późnych kolizji (slotTime)
okres zajętości medium
Rys. 4.30. Mechanizm rozszerzania nośnej [40].
4.4.1. 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.
Tor nadawczy TX
(moduł eth_tx)
Blok kontrolny
(moduł eth_control)
Konfiguracja Interfejs Local Link
Kontroler
Kontroler MAC
MAC
Tor odbiorczy RX
(moduł eth_rx)
Interfejs
InterfejsGMII
MII
Karta sieciowa
Układ PHY
Rys. 4.31. Schemat blokowy sprzętowego kontrolera MAC w wersji Gigabit Ethernet.
89
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.32. 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.
→ phy_rx_clk
→ phy_crs
→ phy_rx_error
→ phy_rx_dv
→ phy_rx_data(7:0)
→ phy_col
← phy_tx_en
← phy_tx_error
← phy_tx_data(7:0)
← phy_int_n
← phy_mdc
↔ phy_mdio
← phy_reset_n
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) →
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 →
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 ←
cfg_rx_mac_addr(47:0) ←
cfg_rx_prmsc_en ←
cfg_rx_mltc_en ←
cfg_speed(1:0) ←
cfg_link ←
cfg_rx_mac_addr(47:0) ←
cfg_rx_prmsc_en ←
cfg_rx_mltc_en ←
cfg_tx_pause_en ←
cfg_mii(15:0) ←
eth_tx
→ phy_tx_clk
← phy_gtx_clk
→ phy_crs
→ phy_col
← phy_tx_en
← phy_tx_error
← phy_tx_data(7:0)
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 ←
stat_speed(1:0) →
stat_link →
stat_duplex →
KONFIGURACJA
INTERFEJS PHY GMII
eth_rx
→ phy_rx_clk
→ phy_crs
→ phy_rx_error
→ phy_rx_dv
→ phy_rx_data(7:0)
→ phy_tx_clk
← phy_gtx_clk
INTERFEJS LOCAL LINK
moduł eth_mac.vhd
cfg_tx_pause_en ←
cfg_speed(1:0) ←
cfg_link ←
cfg_duplex ←
eth_control
sys_clk ←
reset ←
mii_en_in ←
← phy_int_n
← phy_mdc
↔ phy_mdio
cfg_mii(15:0) ←
cfg_link →
cfg_speed(1:0) →
cfg_duplex →
<= '0' when reset = reset_level
else '1';
Rys. 4.32. Struktura wewnętrzna modułu eth_mac.vhd w wersji Gigabit Ethernet.
4.4.2. 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 802.3 [40] .
90
eth_rx_fifo_control
eth_rx_pattern_detect
eth_rx_frame_control
eth_rx_crc
eth_rx_fsm
Interfejs
LocalLink
eth_rx_bitreceiver
eth_rx_pause_control
Konfiguracja
Interfejs GMII
Karta sieciowa
Tor odbiorczy RX
Rys. 4.33. 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 4.3.2. 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 4.34. 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 8.5.
91
INTERFEJS PHY GMII
→ phy_rx_clk
→ phy_rx_dv
→ phy_rx_error
→ phy_crs
→ phy_rx_data(7:0)
eth_rx_bitreceiver
rx_data_8_val →
→ phy_rx_clk
rx_data_8(7:0) →
→ phy_rx_dv
rx_data_32_val →
→ phy_rx_data(7:0)
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) →
→ rx_read_enable
→ rx_state
→ rx_next_state
→ rx_sfd_detect
→ cfg_speed(1:0)
→ reset
eth_rx_pattern_detect
→ phy_rx_clk
→ rx_state
→ rx_next_state
→ rx_byte_counter(10:0)
→ rx_data_8_val
→ rx_data_8(7:0)
rx_crc_ok →
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 →
eth_rx_crc
→ cfg_rx_mac_addr(47:0)
→ reset
→ phy_rx_clk
→ rx_state
→ rx_next_state
→ rx_data_8_val
→ rx_data_8(7:0)
→ reset
moduł eth_rx.vhd
rx_state →
rx_next_state →
rx_frame_ok →
rx_frame_err →
eth_rx_frame_control
→ rx_crc_ok
→ rx_mac_detect
→ rx_bcast_detect
→ rx_pause_detect
→ rx_under_len
→ rx_over_len
eth_rx_fsm
→ cfg_rx_prmsc_en
→ cfg_rx_mltc_en
→ reset
→ phy_rx_clk
→ phy_rx_dv
→ rx_sfd_detect
→ rx_src_detect
→ rx_lt_detect
→ rx_data_detect
→ rx_read_enable
→ cfg_speed(1:0)
→ cfg_link
→ reset
rx_read_enable →
rx_data_out(31:0) →
rx_rem_out(3:0) →
rx_sof_out →
rx_eof_out →
eth_rx_fifo_control
→ phy_rx_clk
→ phy_rx_dv
→ phy_rx_error
→ phy_crs
rx_rdy_out →
→ rx_state
rx_ok_out →
→ rx_next_state
rx_err_out →
→ rx_tag_detect
rx_tag_out →
→ rx_frame_ok
rx_lenght_out(10:0) →
→ 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
rx_pause_cnt_eq0 →
eth_rx_pause_control
→ phy_rx_clk
→ 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
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 →
cfg_link ←
cfg_rx_mltc_en ←
cfg_rx_prmsc_en ←
cfg_rx_mac_addr(47:0) ←
cfg_speed(1:0) ←
INTERFEJS LOCAL LINK
KONFIGURACJA
Rys. 4.34. Struktura wewnętrzna modułu eth_rx w wersji Gigabit Ethernet.
92
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. 4.35. 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
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
Osiągnięto
minimalną długośd
Odebrano ramkę
typu broadcast
Rys. 4.36. 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. 4.37. Przebiegi czasowe sygnałów modułu eth_rx_frame_control
w trakcie odbierania przykładowej ramki Ethernet.
94
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. 4.38. Przebiegi czasowe sygnałów modułu eth_rx_fsm
w trakcie odbierania przykładowej ramki Ethernet.
Standard IEEE 802.3 [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 01-80-C2-00-00-01. 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 65535 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
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 4.39.
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 32bitowym słowie wyjściowym
Rys. 4.39. Przebiegi czasowe sygnałów modułu eth_rx_fifo_control
w trakcie odbierania przykładowej ramki w trybie Gigabit Ethernet.
4.4.3. Tor nadawczy Tx
Schemat blokowy toru transmisyjnego TX w wersji Gigabit Ethernet przedstawiono na
rysunku 4.40.
Interfejs
LocalLink
eth_tx_bittransmiter
eth_tx_fifo_control
eth_tx_crc
eth_tx_clk_mgmt
eth_tx_counters
eth_tx_fsm
Konfiguracja
Interfejs GMII
Karta sieciowa
Tor nadawczy TX
Rys. 4.40. Schemat blokowy toru transmisyjnego TX w wersji Gigabit Ethernet.
96
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 802.3 [40] (Rys. 4.41).
Proces transmisji ramki
(FrameTransmitter)
KLIENT WARSTWY MAC
(ang. MAC CLIENT)
Enkapsulacja
transmitowanej ramki
(TransmitDataEncap)
Transmisja ramki
(TransmitFrame)
Zarządzanie procesem transmisji
(TransmitLinkMgmt)
Dodawanie
uzupełnienia
(ComputePad)
Obliczanie
CRC
(CRC32)
Monitorowanie kolizji
(WatchForCollision)
Rozpoczęcie
transmisji
(StartTransmit)
Ponawianie
transmisji
(BackOff)
Randomizacja
(Random)
Obsługa trybu burst
(BurstTimer)
Proces transmisji danych
(BitTransmitter)
Opóźnienie transmisji
(Deference)
Rozszerzanie ramki
(InterFrameSignal)
Sterowanie transmisją
pól ramki
(PhisicalSignalEncap)
Opóźnienie czasu
rzeczywistego
(RealTimeDelay)
Transmisja
sygnału jam
(StartJam)
PODWARSTWA
DOSTĘPU DO MEDIUM
(ang. MEDIA ACCESS
SUBLAYER)
Transmisja
kolejnego bitu
(NextBit)
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. 4.41. 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
uwzględniający linie oraz wyprowadzenia interfejsów komunikacyjnych, przedstawiono na
rysunku 4.42.
eth_tx_clk_mgmt
moduł eth_tx.vhd
→ cfg_speed(1:0)
→ sys_clk
→ reset
eth_tx_bittransmiter
eth_tx_crc
→ tx_clk
→ tx_state
→ tx_next_state
→ tx_fifo_data(31:0)
→ tx_word_ptr(2:0)
tx_crc(31:0) →
→ tx_clk
→ tx_state
→ tx_next_state
→ tx_word_ptr(2:0)
→ tx_fifo_data(31:0)
→ tx_fifo_rem(3:0)
→ tx_crc_ptr(2:0)
→ tx_crc(31:0)
phy_tx_en →
phy_tx_error →
phy_tx_data(7: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
phy_gtx_clk →
tx_clk →
→ phy_tx_clk
→ cfg_duplex
→ cfg_link
→ cfg_speed(1:0)
→ sys_clk
→ reset
→ cfg_speed(1:0)
→ reset
eth_tx_fsm
tx_state →
tx_next_state →
→ phy_crs
→ phy_col
eth_tx_counters
→ phy_crs
→ phy_col
→ tx_clk
→ tx_state
→ tx_next_state
→ tx_eof
→ tx_lenght(10:0)
→ tx_empty
→ tx_fifo_rem(3:0)
→ cfg_duplex
→ cfg_speed(1:0)
→ reset
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_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
→ 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 ←
reset ←
sys_clk ←
cfg_speed(1:0) ←
cfg_link ←
cfg_duplex ←
cfg_tx_pause_en ←
INTERFEJS LOCAL LINK
tx_ce_sync →
tx_sof →
tx_eof →
tx_lenght(10:0) →
tx_empty →
tx_fifo_data(31:0) →
tx_fifo_rem(3:0) →
tx_pause_sync →
tx_rdy_out →
tx_ok_out →
tx_err_out →
KONFIGURACJA
→ tx_clk
→ tx_state
→ tx_next_state
→ tx_rd_word_en
→ tx_ok
→ tx_err
→ tx_byte_counter(10:0)
→ attmp_cnt_eqmax
→ tx_pause_cnt_eq0
→ tx_data_in(31:0)
→ tx_rem_in(3:0)
→ tx_sof_in
→ tx_eof_in
→ tx_ce_in
→ tx_wr_en_in
→ tx_lenght_in(10:0)
Rys. 4.42. Struktura wewnętrzna modułu eth_tx w wersji Gigabit Ethernet.
98
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. 4.43. 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
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. 4.44. 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 4.3.3.
100
Pole preambuły
Dane klienta MAC razem
z polami adresowymi
Pole FCS
Pole SFD
Rys. 4.45. 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
Sygnał osiągnięcia limitu
ponowieo transmisji
Sygnalizacja kooca
pola SFD
Sygnalizacja kooca
pola danych
Sygnalizacja kooca
pola FCS
Sygnał zakooczenia
odmierzania back-off
Rys. 4.46. 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
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 4.48. 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. 4.47. Przebiegi czasowe sygnałów modułu eth_tx_fsm w trakcie transmisji ramki Ethernet.
102
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'
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
= '1' or phy_crs = '1') and
cfg_duplex = '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 = '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 = '1'
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
colision = '1'
tx_en = '1' and
defer_cnt_eqifg1 = '0'
tx_en = '0'
tx_en = '1' and
colision = ‘0' and
sfd_done = '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')
ifs1
sfd
tx_en = '1' and
colision = '1'
tx_en = '1' and
colision = ‘0' and
sfd_done = '1'
ifs
jam
tx_en = '1' and
defer_cnt_eqifg = '0'
data
tx_en = '1' and
tx_empty = '0'
colision = '1'
tx_en = '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' or
tx_empty = '1'
tx_en = '1' and
colision = '1'
tx_en = '1' and tx_empty
= '0' colision = '0' and
data_done = '0'
crc
tx_en = '1' and
colision = '0' and
crc_done = '0'
tx_en = '0'
tx_en = '1' and colision = '0'
and extent_done = '1' and
(burst_done = '1' or tx_sof
= '0')
tx_en = '1' and
colision = '1'
extent
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 = '1' and
tx_empty = '0'
colision = '0' and
data_done = '1'
tx_en = '0'
tx_en = '0' or (tx_en =
'1' and defer_cnt_eqifg
= '1' and tx_done = '1'
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 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
jam_done = '1'
backoff
tx_en = '0' or (tx_en = '1' and
backoff_cnt_eq0 = '1' and
attmp_cnt_eqmax = '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. 4.48. Graf przejść automatu FSM sterującego torem TX.
103
4.4.4. Moduł kontrolny
Sposób funkcjonowania oraz implementacji sprzętowej modułu kontrolnego w wersji Gigabit
Ethernet jest identyczny z opisanym w rozdziale 4.3.4. 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.
4.4.5. 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. 4.3. Podsumowanie wykorzystania zasobów sprzętowych układów FPGA
oraz parametry czasowe kontrolera MAC w wersji Gigabit Ethernet.
Rodzaj zasobów
Virtex
Typ układu 2vp30ff896-7
Liczba bloków Slice
812
1502
Liczba 4-wejściowych LUT
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
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
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
NIC eth1
NIC eth0
FW 2
MAC 2
MAC 1
MAC 0
FW 1
FW 0
Router
Rys. 5.1. 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
802.3. 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
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
TX
RX
NIC eth0
MAC 0
MAC 1
TX
NIC eth1
RX
FW 1
Rys. 5.2. 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
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_padding_en
eth_mac_0_crc_en
eth_mac_0_promiscous_en
eth_1_config
eth_mac_1_mii_config(15:0)
eth_mac_1_multicast_en
eth_mac_1_mac_address(47:0)
eth_mac_1_padding_en
eth_mac_1_crc_en
eth_mac_1_promiscous_en
moduł fw_top.vhd
eth_0 :
fw_engine_0 :
address_wr_data((tcam_width/4)-1:0) ←
policy_we ←
address_wr_addr(log2_ceil(number_of_rules-1)+3:0) ←
classifier_main
→ clas_0_IP_SA(31:0)
→ clas_0_ETH_frame_type(15:0)
→ clas_0_IP_DA(31:0)
Classifier :
clas_IP_SA(31:0) →
clas_ETH_frame_type(15:0) →
→ eth_mac_ready_rx
clas_IP_DA(31:0) →
clas_IP_protocol(7:0) →
fw_engine
eth_mac_ready →
← eth_mac_rx_enable
eth_mac
← eth_mac_rx_pause
← phy_reset_n
→ eth_mac_rx_active
clas_S_port(15:0) →
→ clas_0_D_port(15:0)
→ clas_0_S_port(15:0)
port_we ←
address_we ←
eth_mac_rx_active →
eth_mac_rx_pause ←
eth_mac_rx_enable ←
clas_D_port(15:0) →
→ clas_0_IP_protocol(7:0)
→ phy_col
→ eth_mac_rx_data_valid
→ eth_mac_rx_data(7:0)
→ phy_rx_clk
eth_mac_rx_data(7:0) →
clas_S_port(15:0) →
→ clas_1_ETH_frame_type(15:0)
→ clas_1_IP_protocol(7:0)
→ clas_1_IP_SA(31:0)
action_ram_data(7:0) ←
action_wr_addr(log2_ceil(number_of_rules-1)-1:0) ←
action_we →
action_ram_data(7:0) →
action_wr_addr(log2_ceil(number_of_rules-1)-1:0) →
fw_policy_loader
port_we →
port_wr_data(27:0) →
port_wr_addr(log2_ceil(number_of_rules-1)+3:0) →
led_1 →
led_0 →
→ phy_tx_clk
sw_3 ←
sw_2 ←
sw_1 ←
sw_0 ←
RS232_RxD ←
RS232_TxD →
policy_we →
address_we →
address_wr_data((tcam_width/4)-1:0) →
address_wr_addr(log2_ceil(number_of_rules-1)+3:0) →
led_2 →
→ sys_clk
→ reset
→ sys_clk
← rs232_active
action_we ←
port_wr_data(27:0) ←
eth_mac_rx_data_valid →
port_wr_addr(log2_ceil(number_of_rules-1)+3:0) ←
← clas_0_ready
→ clas_0_desc_ready
clas_ready ←
clas_desc_ready →
→ eth_mac_rx_error
→ eth_mac_rx_ok
→ phy_rx_dv
eth_mac_rx_error →
eth_mac_rx_ok →
→ phy_tx_clk
← clas_0_result(7:0)
→ clas_1_IP_DA(31:0)
clas_result(7:0) ←
→ clas_1_S_port(15:0)
→ eth_mac_ready_tx
→ eth_mac_rx_frame_size(10:0)
← eth_mac_tx_enable
→ clas_1_D_port(15:0)
→ phy_rx_clk
→ eth_mac_tx_active
eth_mac_tx_active →
eth_mac_tx_retransmit →
→ eth_mac_tx_retransmit
eth_mac_tx_enable ←
eth_mac_rx_frame_size(10:0) →
← eth_mac_tx_data(7:0)
→ clas_1_desc_ready
eth_mac_tx_data_ack →
eth_mac_tx_data(7:0) ←
eth_mac_tx_ok →
→ r_mii_config(15:0)
→ r_rx_mac_address(47:0)
→ eth_mac_tx_data_ack
← clas_1_result(7:0)
→ r_rx_multicast_en
clas_IP_SA(31:0) →
clas_ETH_frame_type(15:0) →
→ eth_mac_rx_data(7:0)
clas_D_port(15:0) →
→ eth_mac_0_ready
clas_result(7:0) ←
→ reset
← clas_1_ready
eth_mac_tx_frame_size(10:0) ←
→ eth_mac_tx_ok
→ r_rx_promiscous_en
→ phy_tx_clk
→ eth_mac_tx_error
→ reset
← eth_mac_tx_frame_size(10:0)
→ sys_clk
→ eth_mac_ready_rx
clas_IP_protocol(7:0) →
fw_engine_1 :
← eth_mac_rx_enable
clas_IP_DA(31:0) →
← eth_mac_rx_pause
→ eth_mac_rx_active
→ eth_mac_rx_data_valid
clas_desc_ready →
→ eth_mac_ready_tx
clas_ready ←
→ eth_mac_rx_ok
→ eth_mac_rx_frame_size(10:0)
→ eth_mac_rx_error
→ phy_rx_clk
→ eth_mac_tx_active
← eth_mac_tx_enable
→ eth_mac_1_ready
monitoring
← eth_mac_tx_data(7:0)
→ rs232_active
→ reset
led_3 →
→ eth_mac_tx_data_ack
→ sys_clk
← eth_mac_tx_frame_size(10:0)
→ eth_mac_tx_error
→ eth_mac_tx_ok
→ eth_mac_tx_retransmit
PolicyLoader :
→ r_tx_crc_en
eth_mac_tx_active →
fw_engine
→ r_tx_padding_en
→ sys_clk
eth_1 :
← phy_reset_n
eth_mac_rx_pause ←
eth_mac_rx_enable ←
eth_mac_rx_data(7:0) →
eth_mac_rx_active →
→ phy_col
→ phy_rx_dv
eth_mac_rx_data_valid →
eth_mac_rx_error →
eth_mac_rx_ok →
eth_mac_rx_frame_size(10:0) →
eth_mac_tx_enable ←
← phy_tx_en
eth_mac_tx_data(7:0) ←
eth_mac_tx_retransmit →
eth_mac_tx_frame_size(10:0) ←
eth_mac_tx_error →
eth_mac_tx_ok →
eth_mac_tx_data_ack →
← phy_mdc
→ sys_clk
→ reset
→ r_tx_padding_en
→ r_tx_crc_en
→ r_rx_promiscous_en
→ r_rx_multicast_en
→ r_rx_mac_address(47:0)
→ r_mii_config(15:0)
↔ phy_mdio
→ phy_int_n
← phy_tx_data(3:0)
→ phy_tx_clk
→ phy_rx_data(3:0)
→ phy_rx_error
→ phy_rx_clk
→ phy_crs
eth_mac_ready →
→ reset
eth_mac_tx_error →
↔ phy_mdio
← phy_mdc
→ phy_int_n
← phy_tx_data(3:0)
← phy_tx_en
→ phy_rx_data(3:0)
→ phy_rx_error
eth_mac
→ phy_crs
Router
← 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. 5.3. Struktura wewnętrzna kompletnego systemu zabezpieczania transmisji danych typu Firewall
108
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).
5.2.1. 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.
fw_parser
Deskryptor
MAC 0
RX
Silnik Firewalla
Klasyfikator
fw_cache
fw_control
Akcja
MAC 1
TX
fw_page_mgr
Rys. 5.4. 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
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.
Interfejs klasyfikatora pakietów
fw_page_mgr
→ 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_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_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_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 →
fw_parser
← 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_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 ←
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)
→ fw_classify_ready
→ fw_classify_result
sys_clk ←
reset ←
Zegar i reset
systemowy
Interfejs kontrolerów MAC
moduł fw_engine.vhd
fw_control
sys_clk ←
reset ←
fw_cache_ready →
fw_cache_clr ←
fw_cache_wr_en ←
fw_cache_wr_action ←
fw_cache_hit →
fw_cache_action →
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. 5.5. Struktura wewnętrzna modułu fw_engine.
110
5.2.2. 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.
MAC 0
MAC 1
RX
TX
FSM sterujący
toru RX
FIFO
deskryptorów RX
Pamięć ramek
Firewall’a
FSM
zarządzający
pustymi stronami
Pamięć ramek
toru TX
FIFO pustych
stron
FSM sterujący
toru TX
FIFO
deskryptorów TX
Moduł weryfikujący reguły
bezpieczeństwa
Kontroler pamięci ramkowej
Rys. 5.6. 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
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. 5.7. 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
5.2.3. 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. 5.8. Przebiegi czasowe sygnałów modułu fw_parser w trakcie pracy Firewalla.
5.2.4. 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
Cache Memory
CAM_A : pamięć CAM na
ramki zaakceptowane
clk
← fw_classify_result
fw_sec_drop_page
← fw_classify_ready
→
→ fw_sec_check_ack
← fw_desc_ready
← reset
← sys_clk
← reset
din
sys_clk
- 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
←
←
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)
Cache Control
myCAM
124 x 32
busy
din (123:0)
match
we
rst
Cache Memory
FSM
Cache Control
FSM
match_addr (31:0)
wr_addr (4:0)
sys_clk
clk
fw_cache_ready
fw_cache_clr
cam_a_wr_addr (4:0)
fw_cache_wr_en
cam_a_wr_en
cam_d_wr_addr (4:0)
CAM_D : pamięć CAM na
ramki odrzucane
clk
fw_cache_wr_drop
fw_cache_ready
CACHE CONTROL
cam_a_busy
reset
fw_desc_ready
fw_cache_clr
fw_cache_wr_en
fw_sec_check_ack
fw_cache_wr_drop
fw_sec_drop_page
cam_d_wr_en
fw_cache_hit
fw_classify_ready
cam_d_busy
fw_cache_drop_page
fw_classify_result
myCAM
124 x 32
busy
din (123:0)
match
CacheHit
we
match_addr (31:0)
cam_a_match
wr_addr (4:0)
fw_cache_hit
fw_cache_hit
cam_d_match
fw_cache_drop_page
Rys. 5.9. 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
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. 5.10. 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
wejściowego. Wewnętrzny licznik zapisu wr_cnt porównywany jest w sekcji komparatorów
z 4-bitowymi fragmentami sygnału wejściowego din. Dzięki temu, dla adresów składowych zgodnych
z danymi wejściowymi, w słowach wpisywanych do poszczególnych rejestrów ustawione zostają
Q
Q Q
...
Q
D D
...
D
...
...
out(n)
match_addr(n)
match_addr(0)
match_addr(1)
din
match
wr_addr
wr_en
clk
busy
jedynki logiczne.
in
Binary to
Hot One
D
en
D
CLK
...
D
CLK
Latches
wr_busy
CE Q
wr_latch
Q
CE
Q
...
Latches
D
wr_counter
...
INIT X”1111"
Comparator
wr_cnt
...
Comparator
In_A(3:0)
out
Comparator
In_A(3:0)
In_A(3:0)
...
CE(0)
CE(1)
CE(n)
...
CLK
CAM Controller
COLUMN 0
In(1)
In(0)
match_addr(0)
match_addr(1)
out
D(n)
din(n)(3:0)
In_B(3:0)
out
D(1)
din(1)(3:0)
In_B(3:0)
out
D(0)
din(0)(3:0)
In_B(3:0)
COLUMN 1
MUXCY
In(n)
Match
Decoder
...
wr_cnt
wr_cnt(3:0)
match
wr_en
clk
...
match_addr(n)
out(1)
out(0)
COLUMN <m>
MUXCY
MUXCY
1
CI
CI
O
D
...
O
DI
S
0
A(3:0)
...
ROW 0
CI
O
DI
S
0
A(3:0)
SRL16E
D
Q
CE INIT X"0000"
A(3:0)
SRL16E
CE INIT X"0000"
CLK
DI
S
0
D
Q
SRL16E
CE INIT X"0000"
CLK
Q
CLK
...
...
MUXCY
1
MUXCY
CI
O
D
ROW 1
...
O
DI
S
0
A(3:0)
SRL16E
D
Q
A(3:0)
SRL16E
CE INIT X"0000"
CLK
DI
S
0
A(3:0)
CE INIT X"0000"
...
CI
O
DI
S
0
MUXCY
CI
D
Q
SRL16E
CE INIT X"0000"
CLK
Q
CLK
...
...
...
..
.
..
.
..
.
..
.
..
.
..
.
MUXCY
1
CI
O
A(3:0)
D
ROW <n>
SRL16E
CE INIT X"0000"
CLK
MUXCY
CI
CI
O
DI
S
0
...
0
D
SRL16E
CE INIT X"0000"
O
DI
S
DI
S
0
A(3:0)
Q
..
.
MUXCY
A(3:0)
D
Q
SRL16E
CE INIT X"0000"
CLK
CLK
Q
CAM Storage
Elements
...
...
Rys. 5.11. Schemat blokowy implementacji pamięci CAM opartej o rejestry przesuwne SRL16E.
116
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. 5.1. Porównanie wykorzystania zasobów sprzętowych komercyjnej wersji pamięci CAM
z opracowaniem własnym autora dla układu Xilinx 2vp30ff896-7.
Wersja pamięci
CAM 124 bity
Opracowanie własne autora
CAM CoreGen 6
Liczba wierszy
pamięci
16
32
64
128
256
16
32
64
128
256
Liczba bloków
Slice
675
1172
2257
4442
8792
632
1119
2180
4310
8568
709
1240
2312
4483
8790
622
1141
2173
4247
8393
148,252
139,019
133,501
123,075
106,736
148,252
139,019
121,370
124,320
124,320
Liczba
4-wejściowych
LUT
Maksymalna
częstotliwość
pracy [MHz]
5.2.5. 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 5.12. 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
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. 5.12. 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
Oczekiwanie na
deskryptor
Wysłanie potwierdzenia
weryfikacji
Trafienie w
cache
Informacja o
akcji
Rys. 5.13. Przebiegi czasowe sygnałów modułu fw_control w trakcie pracy Firewalla.
118
5.2.6. 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 9.10.
Tab. 5.2. Podsumowanie wykorzystania zasobów sprzętowych układów FPGA przez silnik Firewalla.
Rodzaj zasobów
Virtex
Typ układu 2vp30ff896-7
Liczba bloków Slice
2492
Liczba 4-wejściowych LUT
2527
Parametry czasowe
Maks. częstotliwość
Maks. opóźnienie ścieżki kombinacyjnej
190,422 MHz
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%.
5.3. 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
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].
5.3.1. 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 5.2.2. 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
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)
Konfiguracja pamięci akcji
Konfiguracja filtra portów
Konfiguracja filtra adresów
Inicjalizacja polityki
Akcja dla pakietu
Zakończenie analizy
Nagłówek IP eth<n>
Nagłówek IP eth1
Nagłówek IP eth0
...
FSM sterujący
Round-Robin
konfiguracja
port źródłowy
port docelowy
konfiguracja
adr. źródłowy
adr. docelowy
typ protokołu
Filtracja adresów
i typu protokołu
Filtracja portów
trafione
reguły portów
trafione
reguły adresów
i protokołu
Sygnalizacja trafienia w
jakąkolwiek regułę
...
reguły którym odpowiada
analizowany pakiet
Detektor trafienia
Priorytetowy
dekoder Hot-One
Informacja o akcji dla
analizowanego pakietu
konfiguracja
Adres najwyższej w
hierarchii trafionej reguły
Pamięć akcji
Rys. 5.14. 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 5.15.
121
action_we
action_ram_data
action_wr_addr
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
clk
rst
port_wr_addr
port_wr_data
port_we
address_wr_addr
address_wr_data
address_we
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_ETH_frame_type(15:0)
clas_0_IP_protocol(7:0)
clas_0_IP_SA(31:0)
clas_0_IP_DA(31:0)
clas_0_S_port(15:0)
clas_0_D_port(15:0)
clas_0_desc_ready
clas_0_ready
clas_0_result
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)
clas_1_S_port(15:0)
clas_1_D_port(15:0)
clas_1_desc_ready
clas_1_ready
clas_1_result
policy_we
rst
clk
address_data_in
source_port_in
dest_port_in
Main FSM
action
is_matched
Round-Robin
rst
clk
Address Filter
in(n)
port_match
wr_data(21:0)
wr_addr(8:0)
din_in(87:0)
in(n)
wr_data(27:0)
wr_addr(8:0)
WEA
Hot One to
binary
ENA
DOA(7:0)
DOPA
DOB(7:0)
ADDRB(10:0)
DIB(7:0)
"0"
out(3:0)
DOPB
open
open
open
DIPB
WEB
CLKB
in(1)
in(0)
we
DIPA
SSRA
'1'
...
port_filter
...
clk
...
Port Filter
DIA(7:0)
CLKA
in(1)
in(0)
(nr_rules-1:0)
"00000000"
"0"
'0'
Match
out
detector
matched_addr
we
RAMB16_S9_S9
ADDRA(10:0)
address_filter
...
clk
Action RAM
matched_addr
SSRB
'1'
match
ENB
(nr_rules-1:0)
rule_match(nr_rules-1:0)
source_port_in(15:0)
destination_port_in(15:0)
Rys. 5.15. Struktura wewnętrzna sprzętowego klasyfikatora pakietów.
5.3.2. 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
5.16. 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
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.
Adres pamięci RAM16X1S
Sygnał zezwolenia
zapisu dla
poszczególnych reguł
Multiplekser
Weryfikowany adres wraz z typem protokołu
Numer reguły
Inicjalizacja
Dane konfiguracji
Dekoder
Hot-One
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
Wiersz 0
Zapis konfiguracji
(dane reguły 0)
Reguła 0
Dane wejściowe/
adres dla danych
konfiguracji
(dane reguły 1)
Dane wejściowe/
adres dla danych
konfiguracji
Dane konfiguracji
Wiersz <n>
Zapis konfiguracji
(dane reguły <n>)
Reguła 1
...
Wiersz 1
Zapis konfiguracji
...
Dane konfiguracji
Reguła <n>
Reguły, którym odpowiada analizowany pakiet
Dane konfiguracji
Matryca komórek pamięci TCAM
Rys. 5.16. 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
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ę
...
match_addr(n)
match_addr(0)
match_addr(1)
wr_data(tcam_width/4)–1:0)
din(tcam_width-1:0)
we
wr_addr
clk
<rule_nr>&<3:0 ram addr>
opisywanej pamięci TCAM przedstawiono na rysunku 5.17.
en
<rule_nr>
WE(0:n)
out(n)
Binary to
Hot One
..
.
<3:0 ram addr>
...
out(1)
out(0)
in_A
en
Data
Multiplexer
in
Address Filter
out
in_B
COLUMN 0
D(m)
A(m)(3:0)
D(1)
A(1)(3:0)
WE(0)
D(0)
A(0)(3:0)
WE(1)
WE(n)
...
COLUMN 1
MUXCY
...
match_addr(n)
match_addr(0)
match_addr(1)
A(0:(m*4)-1)
COLUMN <m>
MUXCY
MUXCY
1
CI
CI
O
WE
WCLK
A(3:0)
D
O
WE
WCLK
INIT X"0000"
D
O
DI
S
0
RAM16X1S
WCLK
A(3:0)
O
INIT X"0000"
WE
...
DI
S
0
RAM16X1S
D
INIT X"0000"
A(3:0)
...
ROW 0
RAM16X1S
0
CI
O
DI
S
O
...
...
MUXCY
MUXCY
CI
O
WE
WCLK
O
DI
S
0
A(3:0)
D
O
WE
WCLK
INIT X"0000"
D
INIT X"0000"
WCLK
A(3:0)
O
RAM16X1S
WE
INIT X"0000"
D
RAM16X1S
A(3:0)
ROW 1
...
DI
S
0
...
CI
O
DI
S
0
MUXCY
CI
RAM16X1S
1
O
...
...
...
..
.
..
.
..
.
..
.
MUXCY
1
MUXCY
CI
O
WE
WCLK
INIT X"0000"
WCLK
D
...
O
DI
S
0
A(3:0)
O
CI
O
RAM16X1S
WE
INIT X"0000"
D
RAM16X1S
A(3:0)
ROW <n>
MUXCY
CI
DI
S
0
..
.
DI
S
0
A(3:0)
D
O
WE
WCLK
...
...
INIT X"0000"
..
.
RAM16X1S
..
.
O
TCAM
Storage
Elements
Rys. 5.17. 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
czterowejściowej komórki pamięci TCAM, wykrywającej adres „10**” (gdzie „*” oznacza wartość
nieistotną), została przedstawiona w tabeli 5.3.
Tab. 5.3. Przykładowa konfiguracja pojedynczej pamięci RAM16X1S.
Adres
Wartość
Adres
Wartość
0000
0
1000
1
0001
0
1001
1
0010
0
1010
1
0011
0
1011
1
0100
0101
0
0
1100
1101
0
0
0110
0
1110
0
0111
0
1111
0
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. 5.18. 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
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
9.11.
Tab. 5.4. Porównanie wykorzystania zasobów sprzętowych komercyjnej wersji pamięci TCAM
z koncepcją autorską dla układu Xilinx 2vp30ff896-7.
Wersja pamięci CAM 124 bity
CAM CoreGen 6
Liczba wierszy pamięci
Opracowanie własne
autora
88
88
Liczba bloków Slice
1795
810
Liczba 4-wejściowych LUT
2073
1536
130,416 MHz
257,732 MHz
Maksymalna częstotliwość pracy
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].
5.3.3. 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
Dane wejściowe
Konfiguracja
Dekoder
Hot-One
Sygnał zezwolenia
zapisu dla
poszczególnych reguł
Filtry portów docelowych
Filtry portów źródłowych
Adresacja
Filtry portów źródłowych
Filtry portów docelowych
Numer reguły
Inicjalizacja
Sterowanie filtra portów
Adres dla danych
konfiguracji
Dane konfiguracji
Filtr portu
źródłowego
Adres dla danych
konfiguracji
Filtr portu
docelowego
Adres dla danych
konfiguracji
Dane konfiguracji
Reguła <n>
Zapis konfiguracji
Dane
wejściowe
...
...
Zapis konfiguracji
...
Dane konfiguracji
Dane
wejściowe
Filtr portu
źródłowego
Reguły, którym odpowiada analizowany pakiet
Reguła 0
Zapis konfiguracji
Dane
wejściowe
Adres dla danych
konfiguracji
Dane konfiguracji
Zapis konfiguracji
Filtr portu
docelowego
Dane
wejściowe
Matryca elementów filtrujących
Rys. 5.19. 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
Trafione reguły
portów źródłowych
Wynikowy zestaw
trafionych reguł
Trafione reguły
portów docelowych
Rys. 5.20. 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:
(5.1)
QBA0 f 0 ( D0 , L0 , H 0 ) ,
gdzie:
QBA0 – stan wyjścia komparatora 0,
00, ( D0 L0 H 0 L0 ) ( D0 L0 H 0 )
,
01, L0 D0 H 0
f 0 ( D0 , L0 , H 0 )
10, D0 H 0 H 0 L0
11, D0 L0 D0 H 0
(5.2)
D0 – dane wejściowe komparatora 0,
L0 – dolna granica zakresu cząstkowego komparatora 0,
H0 – górna granica zakresu cząstkowego komparatora 0.
Szerokość analizowanego zakresu dla komparatora 0, oznaczona jako W0, wynosi:
H L0 , ( H 0 L0 ) 2
W0 0
2, ( H 0 L0 ) 2
,
(5.3)
Pozostałe komparatory, oprócz dwubitowych danych wejściowych, wykorzystują również
informację o stanie wyjść komparatora poprzedzającego QBA
i-1
oraz o szerokości poprzedzającego
zakresu cząstkowego Wi-1. Do opisu sposobu ich działania zdefiniujmy następujące funkcje:
00, ( Di Li H i Li ) ( Di Li H i )
,
01, Li Di H i
f 1 ( Di , Li , H i )
10, Di H i H i Li
11, Di Li Di H i
(5.4)
128
Config_data(13:0)
<RAM_B_00> & <RAM_A_00>,
<RAM_B_01> & <RAM_A_01>,
…
<RAM_B_15> & <RAM_A_15>,
RAM_A_0
DPRA0
DPRA1
DPRA2
DPRA3
SPO
A3
A2
A1
A0
DPO
SPO
A3
A2
A1
A0
port_in(15:0)
DPO
wr_data_A(0:7)
wr_data_B(0:7)
DPO
SPO
A3
A2
A1
A0
DPO
SPO
A3
A2
A1
A0
port_in(15:0)
RAM_A_1
DPRA0
DPRA1
DPRA2
DPRA3
D
WE
WCLK
RAM_B_1
DPRA0
DPRA1
DPRA2
DPRA3
D
WE
WCLK
RAM_A_2
DPRA0
DPRA1
DPRA2
DPRA3
D
WE
WCLK
RAM_B_2
DPRA0
DPRA1
DPRA2
DPRA3
D
WE
WCLK
A0
A1
A2
A3
SPO
DPO
A0
A1
A2
A3
SPO
DPO
...
...
...
...
...
...
...
...
...
...
...
RAM_A_6
DPRA0
DPRA1
DPRA2
DPRA3
D
WE
WCLK
RAM_B_6
DPRA0
DPRA1
DPRA2
DPRA3
D
WE
WCLK
INIT X"0000"
INIT X"0000"
D
WE
WCLK
INIT X"0000"
INIT X"0000"
config_addr(0)
RAM16X1D
RAM_B_0
DPRA0
DPRA1
DPRA2
DPRA3
D
INIT X"0000"
INIT X"0000"
config_addr(3:0)
config_addr(3)
config_addr(2)
config_addr(1)
WE
...
...
RAM16X1D
RAM16X1D
RAM16X1D
RAM16X1D
config_data(13:0)
WCLK
INIT X"0000"
INIT X"0000"
wr_data_A(0)
RAM16X1D
RAM16X1D
RAM16X1D
clk
config_wr
Conf_address:
0:
1:
...
F:
port_in(12)
clk
config_wr
wr_data_B(0)
port_in(15)
port_in(14)
port_in(13)
wr_data_B(1)
wr_data_A(1)
port_in(11)
port_in(10)
wr_data_B(2)
wr_data_A(2)
port_in(9)
port_in(8)
wr_data_B(6)
wr_data_A(6)
port_in(1)
port_in(0)
A0
A1
A2
A3
SPO
DPO
A0
A1
A2
A3
SPO
DPO
match
Rys. 5.21. Schemat wewnętrzny pojedynczego elementu filtrującego.
129
00, Di Li
f 2 ( Di , Li , H i ) 01, Di Li
11, Di Li
,
(5.5)
01, Di H i
f 3 ( Di , Li , H i ) 10, Di H i
11, Di H i
,
(5.6)
H i Li , Li H i ( H i Li ) 2 ( H i Li ) Wi 1
Wi Wi 1 , Li H i ( H i Li ) 2 Wi 1 ( H i Li ) ,
2, Li H i ( H i Li ) 2
(5.7)
gdzie:
Wi – szerokość przedziału cząstkowego dla i-tego komparatora,
Di – dane wejściowe,
Li – dolna granica zakresu cząstkowego,
Hi – górna granica zakresu cząstkowego.
Możemy wyróżnić trzy przypadki funkcjonowania komparatora QBA i dla i >0 w zależności od
szerokości przedziału poprzedzającego:
dla Wi-1=0
f ( D , L , H ), QBA i 1 00 ,
QBA i 1 i i i
11, QBA i 1 11
(5.8)
dla Wi-1=1
f 2 ( Di , Li , H i ), QBA i 1 00
QBA i f3 ( Di , Li , H i ), QBA i 1 10 ,
11, QBA i 1 11
(5.9)
dla Wi-1=2
QBA i
f 2 ( Di , Li , H i ),
01,
f 3 ( Di , Li , H i ),
11,
QBA i 1 00
QBA i 1 01 .
QBA i 1 10
QBA i 1 11
(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
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 9.12.
Tab. 5.5. Wykorzystanie zasobów logiki reprogramowalnej FPGA przez filtr portów.
Rodzaj zasobów
Virtex
2vp30ff896-7
Typ układu
Liczba bloków Slice
1829
Liczba 4-wejściowych LUT
1856
Parametry czasowe
Maks. częstotliwość
Maks. opóźnienie ścieżki kombinacyjnej
162,973 MHz
0,878 ns
5.3.4. 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
Licznik mechanizmu
Round-Robin
Zgłoszenie deskryptora
do weryfikacji
Bieżący stan
automatu FSM
Potwierdzenie
zakooczenia weryfikacji
Rezultat weryfikacji
Rys. 5.22. 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
Reset, power up
W trakcie ładowania
konfiguracji filtrów cały
ruch sieciowy jest
blokowany
policy_we = '1'
load_policy
policy_we = '0'
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'))
tcam_delay
policy_we = '0'
policy_we = '0' and ((rr_cnt = "0" and
clas_0_desc_ready = '0') or (rr_cnt = "1" and
clas_1_desc_ready = '0'))
action_delay
policy_we = '0'
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. 5.23. Graf przejść automatu FSM sterującego pracą klasyfikatora.
5.3.5. 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 9.12.
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
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. 5.6. Wykorzystanie zasobów logiki reprogramowalnej FPGA
przez sprzętowy klasyfikator pakietów.
Virtex
Typ układu 2vp30ff896-7
Rodzaj zasobów
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 14 880 952 [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
5 taktów zegara sys_clk
Zakooczenie zapisu wyniku
do pamięci ramkowej
3 takty zegara sys_clk
CAŁKOWITY CZAS KLASYFIKACJI: 8 taktów zegara sys_clk
Rys. 5.24. Całkowity czas weryfikacji pakietu.
134
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 5.25.
fw_policy_loader.vhd
Interfejs
klasyfikatora
← rs232_active
← policy_we
→ reset
→ sys_clk
← 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
rs_fsm (process)
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
← rs232_active
sys_clk ←
← ram_0_we
reset ←
← ram_1_we
← write_cnt(11:0)
uart_IntRx_O ←
uart_WB_DAT_O(7:0) ←
← policy_load
uart_WB_WE_I →
→ wr_active
uart_WB_STB_I →
policy_fsm (process)
Interfejs
RS232
sys_clk ←
← wr_active
reset ←
→ policy_load
← ram_addr_cnt(3:0)
← rules_cnt(log2_ceil(l_reguł-1)-1:0)
← address_we
← port_we
← action_we
uart
← RS232_TxD
→ RS232_Rx
← TxD_PAD_O
→ RxD_PAD_I
BR_Clk_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. 5.25. 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
Tab. 5.7. Zawartość pamięci RAM0 przechowującej konfigurację filtru adresów, typu protokołu
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10
0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 0 1 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 1 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 1 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 1 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 1 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 1 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1
RAM16x1S nr 0
RAM16x1S nr 2
RAM16x1S nr 3
RAM16x1S nr 4
RAM16x1S nr 5
RAM16x1S nr 6
RAM16x1S nr 7
RAM16x1S nr 8
RAM16x1S nr 9
RAM16x1S nr 10
RAM16x1S nr 11
RAM16x1S nr 12
RAM16x1S nr 13
RAM16x1S nr 14
RAM16x1S nr 15
RAM16x1S nr 16
RAM16x1S nr 17
RAM16x1S nr 18
RAM16x1S nr 19
RAM16x1S nr 20
RAM16x1S nr 21
22 -bitowe słowo konfiguracji pamięci TCAM filtru adresów
(22 pamięci RAM16x1S na pojedynczą regułę)
RAM16x1S nr 1
1
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32 -bitowe słowo danych pamięci konfiguracji RAM0
Dopełnienie (nieużywane)
Nr reguły
0
Adres pamięci konfiguracji RAM0
oraz akcji dla dwóch przykładowych reguł bezpieczeństwa.
9
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
8
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
8 -bitowe słowo konfiguracji
pamięci akcji
7
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
6
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
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 5.3.2 (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 –192.168.0.0,
136
maska adresu źródłowego – 255.255.255.0,
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 – 172.0.0.0,
maska adresu docelowego – 255.0.0.0,
akcja – odrzuć.
Tab. 5.8. Zawartość pamięci RAM1 przechowującej konfigurację filtrów portów sieciowych dla dwóch
RAM_A_6
RAM_A_5
RAM_A_4
RAM_A_3
RAM_A_2
RAM_A_1
RAM_A_0
30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10
0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 1
0 0 0 0 0 0 1 1 1 1 0 1 1 0 1 1 1 0 1 1 1
0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 1
0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 0 0 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1
0 0 0 1 1 0 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 0 1 1 1 1 1 1 0 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 0 1 1 1 1 1 1 0 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
RAM_B_0
RAM_B_3
RAM_B_4
RAM_B_5
RAM_B_6
RAM_A_0
RAM_A_1
RAM_A_2
RAM_A_3
RAM_A_4
RAM_A_5
RAM_B_0
RAM_A_6
RAM_B_1
RAM_B_2
RAM_B_3
RAM_B_4
RAM_B_5
RAM_B_6
28 -bitowe słowo konfiguracji filtru portów docelowych
(28 pamięci RAM16x1D)
RAM_B_1
31
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
28 -bitowe słowo konfiguracji filtru portów źródłowych
(28 pamięci RAM16x1D)
RAM_B_2
1
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32- bitowe słowo danych pamięci konfiguracji RAM1
Dopełnienie (nieużywane)
Nr reguły
0
Adres pamięci konfiguracji RAM1
przykładowych reguł bezpieczeństwa.
9
1
1
1
0
0
0
0
0
0
0
0
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
8
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
7
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
6
0
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
5
1
1
0
1
1
1
1
1
0
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
4
1
1
0
1
1
1
1
1
1
0
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
3
1
1
1
0
1
1
1
1
0
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
2
1
1
1
0
1
1
1
1
1
1
1
0
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
0
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
0
0
1
0
1
1
1
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
137
Druga pamięć RAMB16_S9_S36, oznaczana jako RAM1, buforuje dane konfiguracji filtrów
portów sieciowych, opisanych w rozdziale 5.3.3. 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 10000.
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. 5.26. Przebiegi czasowe sygnałów modułu fw_policy_loader
w trakcie inicjowania konfiguracji filtrów.
138
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 9.13.
Tab. 5.9. Wykorzystanie zasobów logiki reprogramowalnej FPGA
przez moduł ładowania polityki bezpieczeństwa.
Rodzaj zasobów
Virtex
2vp30ff896-7
Typ układu
Liczba bloków Slice
Liczba 4-wejściowych LUT
Liczba pamięci RAMB16_S9_S36
68
120
2
Parametry czasowe
Maks. częstotliwość
291,414 MHz
139
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 5.27. 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. 5.27. Aplikacja konwertująca reguły bezpieczeństwa.
140
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.
„192.168.0.0”. 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.
„255.255.0.0”; 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 65535.
Dopuszczalne jest definiowanie przedziałów zapisywanych z użyciem znaku „-”, np.
„1-100”. 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
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 9.14.
Tab. 5.10. Wykorzystanie zasobów sprzętowych i parametry czasowe
kompletnego systemu sprzętowego Firewalla.
Rodzaj zasobów
Virtex
Typ układu 2vp30ff896-7
Liczba bloków Slice
9164
11384
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
zabezpieczających.
transmisji
danych
przy
braku
jakichkolwiek
systemów
W drugim wariancie na komputerze „Host 2” zainstalowano dwie wersje
programowych zapór ogniowych: produkcji Sygate Personal Firewall [116] (firma Sygate została
142
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
SBX-166LHGE-2
Ethernet
100 Mbps
Host 2
Ethernet
100 Mbps
d) połączenie poprzez sprzętowego Firewalla
Host 1
Firewall sprzętowy
Ethernet
100 Mbps
Host 2
Ethernet
100 Mbps
Rys. 5.28. 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
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
wyniki przepustowości transmisji danych dla poszczególnych konfiguracji środowiska testowego
przedstawiono na rysunku 5.29.
Przepustowośd transmisji danych dla testów iperf
100
90
Przepustowośd *Mb/s+
80
70
60
50
40
30
20
10
0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1470
Maksymalny rozmiar datagramu MTU [B]
Bez zabezpieczeo
Firewall sprzętowy
Firewall CheckPoint
Sunbelt Personal Firewall (z opcją IDS)
Sygate Personal Firewall (bez IDS)
Rys. 5.29. 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
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
100
Obciążenie procesora *%+
90
80
70
60
50
40
30
20
10
0
100
200
300
400
500
600
700
800
900 1000 1100 1200 1300 1400 1470
Maksymalny rozmiar datagramu MTU [B]
Bez zabezpieczeo
Sunbelt Personal Firewall (z opcją IDS)
Sygate Personal Firewall (bez IDS)
Rys. 5.30. 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
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
70,5
69,4
64,6
Przepustowośdd*Mb/s+
80,0
70,0
23,3
22,4
60,0
22,3
50,0
58,6
55,5
19,2
40,0
21,0
30,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
Firewall sprzętowy
Bez zabezpieczeo
Sygate Personal Firewall (bez IDS)
Rys. 5.31. Ś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
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,5
46
Obciążenie procesora *%+
70
50
60
33,5
50
40
30
20
13,7
15,9
10
0
3 tys. małych plików
Jeden duży plik
Bez zabezpieczeo
Sygate Personal Firewall (bez IDS)
Sunbelt Personal Firewall (z opcją IDS)
Rys. 5.32. 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
6. Podsumowanie
Celem planowanych badań było poszukiwanie optymalnej architektury wewnętrznej
oraz
metod
implementacji
systemów
bezpieczeństwa
informatycznego
typu
Firewall,
realizowanych dotychczasowo na drodze programowej, w układach logiki programowalnej
FPGA. W efekcie końcowym realizacji prac projektowych powstała kompletna, w pełni
funkcjonalna, sprzętowa zapora ogniowa, charakteryzująca się bardzo dużą wydajnością pracy,
jak również zapewniająca wysoki poziom bezpieczeństwa procesu weryfikacji danych, adekwatny
do wymagań współczesnych sieci teleinformatycznych o dużych przepływnościach.
Ponieważ jednym z głównych priorytetów projektu było uzyskanie maksymalnej
wydajności funkcjonowania rozwiązania, zdecydowano się na pełną realizację sprzętową
wszystkich niezbędnych bloków sprzętowych architektury Firewalla. Zaprojektowanie od
początku wszystkich modułów funkcjonalnych z wykorzystaniem układów FPGA pozwoliło na
optymalizację szybkości działania każdego elementu składowego zapory ogniowej, co jest
niemożliwe do osiągnięcia przy zastosowaniu komercyjnych, zamkniętych modułów, tzw. IP
Cores. Do realizacji założonego celu należało najpierw przygotować niezbędne środowisko
uruchomieniowo-testowe, w skład którego wchodziły dedykowane płyty wyposażone w układy
FPGA oraz oprogramowanie
umożliwiające
opisywanie i
testowanie funkcjonalności
opracowywanego urządzenia przy pomocy kodu w języku VHDL, a następnie jego implementację
w układach logiki reprogramowalnej. Niezwykle ważny etap wstępnych prac przygotowawczych
dotyczył zaprojektowania, wykonania i przetestowania kart interfejsów sieciowych niezbędnych
do prawidłowego działania zapory ogniowej w infrastrukturze sieci Ethernet.
Przed przystąpieniem do realizacji zasadniczej części projektu – opracowania architektury
sprzętowego Firewalla wraz z implementacją poszczególnych jego elementów w układach FPGA,
autor dokonał szczegółowego funkcjonalnego przeglądu dostępnych typów zapór ogniowych oraz
algorytmów weryfikacji przetwarzanych danych, wykorzystywanych do budowy kluczowego
modułu klasyfikującego pakiety. Na podstawie przeprowadzonych analiz udało się zebrać
niezwykle istotne wnioski odnośnie słabych stron poszczególnych rozwiązań, będące punktem
wyjścia do poszukiwań optymalnej koncepcji organizacji wewnętrznej struktury sprzętowego
Firewalla. Pierwszym krokiem w tym kierunku była decyzja o implementacji w układach FPGA
kontrolerów MAC dla sieci Fast oraz Gigabit Ethernet. Teoretycznie istniała możliwość
skoncentrowania prac badawczych tylko na zasadniczym elemencie systemu - klasyfikatorze
pakietów, tym samym znacznie skracając czas realizacji całego przedsięwzięcia. W takim
przypadku do obsługi komunikacji sieciowej można byłoby wykorzystać rozwiązania
149
programowe bazujące na procesorach GPP. Jednak zaobserwowane negatywne skutki takiego
podejścia oraz świadomość wpływu wszystkich komponentów tak złożonego systemu, jakim jest
zapora ogniowa, na globalną wydajność przetwarzania danych, doprowadziły do wybrania drogi
bardziej pracochłonnej. Pozwalała ona jednak na zaprojektowanie urządzenia, w którym każdy
z najdrobniejszych elementów, począwszy od kontrolerów MAC a skończywszy na modułach
przetwarzających politykę bezpieczeństwa, zoptymalizowano 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ć przy takim podejściu kształtowane na
bieżąco, w zależności od wymagań stawianych przez potencjalny obszar zastosowań. Wykonane
w ramach prac badawczych sprzętowe moduły kontrolerów sieci Ethernet umożliwiły
przeprowadzenie testów praktycznych weryfikujących wydajność oraz stabilność działania
Firewalla implementowanego w układach FPGA.
Główny etap projektu stanowiło opracowanie koncepcji oraz implementacja silnika
Firewalla zawierającego moduł klasyfikacji pakietów. Nadrzędne cele projektowe: optymalizacja
wydajności oraz zapewnienie wysokiego poziomu bezpieczeństwa przetwarzania danych
wymusiły konieczność zastosowania szeregu mechanizmów, wykorzystujących w jak
największym stopniu potencjał i elastyczność logiki reprogramowalnej FPGA. Zaproponowana
przez autora koncepcja architektury Firewalla opierała się na tworzeniu dedykowanych kanałów
komunikacyjnych pomiędzy segmentami chronionych sieci. Dzięki temu, że każdy taki kanał
zawierał w sobie pełny tor przetwarzania i analizy bezpieczeństwa danych, możliwym stało się
zwiększanie
całkowitej
szybkości
pracy
zapory
poprzez
implementowanie
kolejnych
klasyfikatorów wraz z dodawaniem nowych interfejsów NIC. Koncepcja ta pozwalała również na
pełną separację ścieżek weryfikacji pakietów, tym samym zniwelowano zagrożenie degradacji
szybkości klasyfikacji w przypadku niesymetrycznych obciążeń interfejsów sieciowych. Na
wzrost ogólnej wydajności opracowanego systemu wpłynęło także zastosowanie potokowego
przetwarzania danych w silniku Firewalla. Specjalnie zorganizowana pamięć ramkowa wraz
z modułem zarządzającym umożliwiły transmisję ramek zweryfikowanych pod kątem zgodności
z regułami bezpieczeństwa, niezależnie od analizowania nieustają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 właściwej karty sieciowej.
Poszukując dalszych dróg optymalizacji procesu klasyfikacji pakietów,
dodatkowy
moduł
pamięci
podręcznej
cache,
przechowujący
autor opracował
informację
o
ostatnio
analizowanych deskryptorach bezpieczeństwa wraz z odpowiadającą im akcją (odrzucenie
lub zaakceptowanie). Dzięki zastosowaniu opracowanej specjalnie do tego celu pamięci
adresowanej zawartością typu CAM, już po jednym cyklu zegara systemowego w pamięci cache
dostępna była informacja o obecności deskryptora zgodnego z aktualnie weryfikowanym
nagłówkiem. W przypadku wymiany danych pomiędzy ograniczoną grupą komputerów,
150
rozwiązanie takie w znaczny sposób odciążyło blok klasyfikatora pakietów. W testowanej
praktycznie zaporze ogniowej zaimplementowano pamięć podręczną o pojemności 32
deskryptorów, aczkolwiek wartość ta była w pełni parametryzowana, co pozwoliło na łatwe jej
skalowanie w przypadku wykorzystywania nowszych generacji układów FPGA, dysponujących
zdecydowanie większą ilością zasobów sprzętowych.
Zdecydowanie najbardziej istotny i pracochłonny etap badań dotyczył opracowania
modułu
klasyfikacji
pakietów,
weryfikującego
zgodność
przetwarzanych
danych
z obowiązującym schematem polityki bezpieczeństwa. Na podstawie przeprowadzonych analiz
dostępnych rozwiązań oraz uwarunkowań implementacyjnych autor zdecydował o podziale
funkcjonalnym procesu klasyfikacji na dwa odrębne obszary: adresację sieciową wraz
z informacją o typie protokołu oraz porty sieciowe. Do celów weryfikacji adresacji sieciowej
w sprzętowej zaporze ogniowej wykorzystana została specjalnie zmodyfikowana pamięć
trójwartościowa TCAM, bazująca na elementach RAM16X1S dostępnych w zasobach układów
FPGA serii Virtex II Pro. Dzięki wprowadzonym zmianom udało się ponad dwukrotnie
zmniejszyć zapotrzebowanie na zasoby sprzętowe w porównaniu do komercyjnej wersji pamięci
wygenerowanej za pomocą oprogramowania Xilinx COREGenerator. Redukcja alokowanych
zasobów sprzętowych wpłynęła korzystnie na maksymalną częstotliwość pracy filtru adresów,
zwiększając ją do wartości około 257 MHz. W przypadku bardziej skomplikowanego
i problematycznego
zagadnienia
weryfikacji
portów
protokołów
transportowych
autor
zaproponował również nowatorskie rozwiązanie równoległego przetwarzania bazy reguł
bezpieczeństwa przy wykorzystaniu łańcuchów elementarnych komparatorów zakresów
cząstkowych. Bazowały one na kaskadach dwuportowych pamięci RAM16X1D, wchodzących
w skład zasobów sprzętowych układów reprogramowalnych FPGA firmy Xilinx. Teoretyczna
maksymalna częstotliwość pracy zrealizowanego filtru portów wyniosła około 162 MHz.
Ponieważ proces weryfikacji dokonywany był w trakcie pojedynczego cyklu zegara
systemowego, przepustowość filtru portów osiągnęła poziom około 160 milionów pakietów na
sekundę. Wartość ta stanowiła główny czynnik, warunkujący szybkość pracy kompletnego
modułu klasyfikującego, którego maksymalna wydajność raportowana przez narzędzia syntezy
logicznej była tożsama w tym wypadku z wydajnością filtru portów. Należy podkreślić,
że osiągnięto w pełni zadowalające parametry pracy sprzętowego klasyfikatora, umożliwiające
funkcjonowanie z ogromnym zapasem wydajności w infrastrukturze sieciowej, wykorzystującej
standard 10 Gb Ethernet. Z tego względu autor zdecydował o zastosowaniu w prototypowej
wersji Firewalla pojedynczego modułu klasyfikatora, weryfikującego za pomocą algorytmu
karuzelowego ruch pochodzący z dwóch interfejsów sieciowych. Całkowity czas klasyfikacji
pojedynczego pakietu zajmował wówczas dla najbardziej niekorzystnego przypadku 8 cykli
zegara systemowego, co przy maksymalnej częstotliwości pracy rzędu 160 MHz pozwoliło na
151
przetwarzanie danych z szybkością 20 milionów pakietów na sekundę (w sieci 10Gb Ethernet
największa dopuszczalna liczba ramek przesyłanych w ciągu sekundy wynosi 14 880 952).
Celem udowodnienia tezy oraz testowania kompletnej i funkcjonalnej zapory ogniowej,
autor zaimplementował odpowiednie moduły zarządzające jej pracą oraz ładowaniem bazy reguł
bezpieczeństwa. W ramach prowadzonych prac powstała także prototypowa wersja aplikacji
konwertującej tabelaryczne zestawienia polityki bezpieczeństwa do postaci binarnych map
konfiguracji wewnętrznej poszczególnych filtrów.
Opracowany sprzętowy Firewall został poddany praktycznym testom porównawczym
z komercyjnymi rozwiązaniami zabezpieczającymi. Osiągnął on najlepsze wyniki spośród
wszystkich
konfiguracji,
badanych
potwierdzając
teoretycznie
oszacowane
parametry
wydajnościowe oraz ogromny potencjał wykorzystania technologii logiki reprogramowalnej
FPGA w obszarze bezpieczeństwa systemów teleinformatycznych.
Do oryginalnych osiągnięć autora, zaprezentowanych w tej pracy, należy zaliczyć:
–
opracowanie koncepcji kompletnej, skalowalnej i elastycznej architektury sprzętowej
zapory ogniowej implementowanej w układach FPGA,
–
opracowanie koncepcji zrównoleglenia przetwarzania danych przy wykorzystaniu
dedykowanych kanałów transmisyjnych,
–
opracowanie zasady pracy modułu pamięci ramkowej minimalizującego opóźnienia
związane z weryfikacją pakietów,
–
opracowanie
dedykowanego
bloku
pamięci
podręcznej
cache,
wspomagającej
klasyfikator pakietów, a w konsekwencji zwiększającej całkowitą wydajność Firewalla,
–
optymalizację struktury pamięci CAM (przy wykorzystaniu rejestrów przesuwnych),
umożliwiającej łatwe dostosowanie konfiguracji pamięci do wymagań systemu Firewall,
redukującej zapotrzebowanie na zasoby układu FPGA oraz zwiększającej maksymalną
szybkość pracy,
–
opracowanie struktury wydajnego, skalowalnego oraz w pełni deterministycznego
sprzętowego klasyfikatora pakietów, opartego na dwóch niezależnych blokach
filtrujących adresy i porty sieciowe, umożliwiającego przetwarzanie do 160 milionów
pakietów na sekundę,
–
opracowanie na potrzeby szybkiej filtracji adresów autorskiej metody implementacji
pamięci TCAM, charakteryzującej się ponad dwukrotnie bardziej efektywnym
wykorzystaniem zasobów sprzętowych oraz o około 30% większą szybkością pracy
w porównaniu z wersją pamięci uzyskaną za pomocą Xilinx COREGeneratora,
–
opracowanie specjalnej, autorskiej metody szybkiego filtrowania zakresów portów
w oparciu o kaskady elementarnych komparatorów zbudowanych z pamięci RAM16X1D,
wchodzących w skład zasobów sprzętowych układów reprogramowalnych FPGA,
152
–
zaprojektowanie, realizacja i testowanie kompletnej architektury sprzętowej zapory
ogniowej implementowanej w układach FPGA,
–
zaprojektowanie, wykonanie i uruchomienie kart sieciowych obsługujących standardy
Fast oraz Gigabit Ethernet, współpracujących z płytami FPGA oraz implementacja
wysokowydajnych sprzętowych kontrolerów MAC dla standardu sieci Ethernet.
Zaprezentowane w niniejszej pracy rezultaty prowadzonych badań pozwalają stwierdzić,
że postawiona na wstępie teza: „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” została w pełni wykazana.
Pozytywna weryfikacja tezy pracy w połączeniu ze stale rosnącymi wymaganiami
wydajnościowymi, które stawia się kolejnym generacjom urządzeń zabezpieczających sieci
teleinformatyczne, motywuje do kontynuowania rozwoju i optymalizacji sprzętowego Firewalla.
Dalsze prace badawcze, zdaniem autora, powinny koncentrować się przede wszystkim na
następujących zagadnieniach:
–
implementacji sprzętowych kontrolerów 10 Gb Ethernet,
–
realizacji funkcjonalności analizy pakietów typu „stateful inspection” lub DPI,
–
wdrożeniu dodatkowych usług, takich jak: system IPS, ochrona antywirusowa, itp.,
–
wprowadzeniu szczegółowego monitorowania parametrów pracy,
–
optymalizacji wydajności oraz zapotrzebowania na zasoby sprzętowe klasyfikatora
pakietów,
–
rozbudowie funkcjonalności aplikacji zarządzającej.
Tak nakreślony obszar rozwoju sprzętowej zapory ogniowej ma na celu z jednej strony
jak najlepsze dostosowanie jej parametrów użytkowych do rzeczywistych potrzeb produkcyjnych
systemów przetwarzania danych, z drugiej zaś zapewnienie ciągłej optymalizacji wydajności
analizy pakietów, odpowiadającej niezwykle dynamicznemu wzrostowi szybkości transmisji
danych we współczesnych sieciach teleinformatycznych.
153
7. Bibliografia
[1] Abdelghani M., Sezer S., Garcia E., Jun M.: Packet Classification Using Adaptive Rules Cutting
(ARC), Advanced Industrial Conference on Telecommunications/Service Assurance with Partial
and Intermittent Resources Conference/E-Learning on Telecommunications Workshop, IEEE, 2005
[2] Abie H.: An Overview of Firewall Technologies, Telektronikk, vol. 96, 2000, pp.47-52
[3] Aho A., Hopcroft J., Ullman J.: Algorytmy i struktury danych, Wydawnictwo Helion, Gliwice, 2003
[4] Aldec, Active-HDL, http://www.aldec.com/Products/Product.aspx?productid=77a6c939-42b0-4c57a8a0-7d9714b054d4
[5] Baboescu F., Singh S., Varghese G.: Packet Classification for Core Routers: Is there an alternative
to CAMs?, Proceedings of Infocom, 2003
[6] Baboescu F., Varghese G.: Scalable Packet Classification, IEEE/ACM Trans. Netw., 2005, pp. 2-14
[7] Baker Z., Prasanna V.: Highthroughput LinkedPattern Matching for Intrusion Detection Systems,
Proceedings of the 2005 ACM symposium on Architecture for networking and communications
systems, 2005
[8] Banachowski L., Diks K., Rytter W.: Algorytmy i struktury danych, Wydawnictwa NaukowoTechniczne, Warszawa, 2006
[9] Bell D., LaPadula L.: Secure Computer Systems: Mathematical Foundations, MITRE Technical
Report 2547, Volume I, 1973
[10] Bhagchandka D.: Classification of Firewalls and Proxies, Computer Science Research and Writing,
2003
[11] Bremler-Barr A., Hendler D.: Space-Efficient TCAM-based Classification Using Gray Coding, IEEE
INFOCOM, 2007, pp. 1388–1396
[12] Buddhikot M., Suri S., Waldvogel M.: Space decomposition techniques for fast layer-4 switching,
Proceedings of Conference on Protocols for High Speed Networks, 1999, pp. 25-41
[13] Chadwick D.: Network Firewall Technologies, Proceedings of the NATO Advanced Networking
Workshop on Advanced Security Technologies in Networking, Slovenia, 2000
[14] Check Point Software Technologies Ltd.: Smarter, Not Harder: Many Cores are Faster than One,
http://www.checkpoint.com/securitycafe/readingroom/general/multi_core_processors.html
[15] Cisco, Internetworking Technology Handbook - LAN Switching,
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/LAN-Switching.html
[16] DARPA: Transmission Control Protocol - DARPA Internet Program Protocol Specification,
Information Sciences Institute, University of Southern California, 1981,
154
http://tools.ietf.org/pdf/rfc793.pdf
[17] DatacenterDynamic: Report: More than 1m 10GbE switch ports shipped during Q2 for first time
ever, http://www.datacenterdynamics.com/ME2/dirmod.asp?sid=&nm=&type=news&
mod=News&mid=9A02E3B96F2A415ABC72CB5F516B4C10&tier=3&nid=
99557444C0CE4DC1B28736EC811B171D
[18] De Berg M., Van Kreveld M., Overmars M., Schwarzkopf O.: Geometria obliczeniowa: algorytmy
i zastosowania, Wydawnictwa Naukowo-Techniczne, Warszawa, 2007
[19] Department of Defense: Trusted Computer System Evaluation Criteria, DOD 5200.28-STD, 1985
[20] Derfler F.: Sieci komputerowe dla każdego, Gliwice, Wydawnictwo Helion, 2001
[21] Digilent Inc., Digilab 2E FPGA Development Board,
http://www.digilentinc.com/Data/Products/D2E/D2E-brochure.pdf
[22] Digilent Inc., Product Categories, http://www.digilentinc.com/nav1index.cfm?NavTop=2
[23] Digilent Inc., Virtex-II Pro Development System,
http://www.digilentinc.com/Products/Detail.cfm?Prod=XUPV2P
[24] Drozdek A.: C++ Algorytmy i struktury danych, Wydawnictwo Helion, Gliwice, 2004
[25] Dubrawsky I.: Firewall Evolution - Deep Packet Inspection, Symantec, 2003,
http://www.symantec.com/connect/articles/firewall-evolution-deep-packet-inspection
[26] Feldmann A., Muthukrishnan S.: Tradeoffs for Packet Classification, Proceedings of IEEE
INFOCOM, 2000, pp. 1193-1202
[27] Ferraiolo D., Kuhn D.: Role-Based Access Controls, 15th National Computer Security Conference,
1992, pp. 554 - 563
[28] Finkel R., Bentley J.: Quad Trees: A Data Structure for Retrieval on Composite Keys, Acta
Informatica 4 (1974), Springer-Verlag , 1974, pp. 1-9
[29] Fortinet: Firewall solutions, http://www.fortinet.com/solutions/firewall.html
[30] Frantzen M., Kerschbaum F., Schultz E., Fahmy S.: A Framework for Understanding Vulnerabilities
in Firewalls Using a Dataflow Model of Firewall Internals, Computers & Security, vol. 20, no. 3,
2001, pp. 263-270
[31] Gao M., Zhang K., Lu J.: Efficient Packet Matching for Gigabit Network Intrusion Detection using
TCAMs, Proceedings of the 20th International Conference on Advanced Information Networking
and Applications (AINA’06), IEEE, 2006
[32] Girija N., Basu A., Zane F.: CoolCAMs: Power-Efficient TCAMs for Forwarding Engines,
Proceedings of Infocom, 2003
[33] Gupta P., McKeown N.: Algorithms for packet classification, IEEE Network, vol. 15, no. 2, 2001,
pp. 24–32
155
[34] Gupta P., Mckeown N.: Packet Classification on Multiple Fields, ACM Sigcomm, 1999, pp. 147-160
[35] Gupta P., McKeown N.: Packet Classification using Hierarchical Intelligent Cuttings, Proceedings
of the Hot Interconnects VII, 1999, pp. 34-41
[36] Henry P.: Handbook od Firewall Architecture, Secure Computing White Paper,
www.securecomputing.com
[37] HiTechGlobal, Prototyping Boards, http://www.hitechglobal.com/boards/allboards.htm
[38] Hughes-Jones R., Dallison S., Fairey G., Clarke P., Bridge and I.: Performance Measurements
on Gigabit Ethernet NICs and Server Quality Motherboards, In Proceedings of the 1st International
Workshop on Protocols for Fast Long-Distance Networks (PFLDnet 2003), Geneva, Switzerland,
February 2003
[39] Hughes-Jones R., Clarke P., Dallison S.: Performance of 1 and 10 Gigabit Ethernet cards with server
quality motherboards, Future Gener. Comput. Syst. 21, 4 (Apr. 2005), s.469-488
[40] IEEE, 802.3 IEEE Standard for Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks, 2005
[41] Info-Tech Research Group, Vendor Landscape: IT Security Appliances, 2009,
http://www.sonicwall.nl/downloads/WP-ENG-047_Vendor-Landscape-IT-Security-Appliances.pdf
[42] International Organization for Standardization, Information technology – Open Systems
Interconnection – Basic Reference Model,
http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip
[43] Jedhe G., Ramamoorthy A., Varghese K.: A scalable high throughput firewall in FPGA, Proceedings
of the 2008 16th International Symposium on Field-Programmable Custom Computing Machines,
2008, pp. 43-52
[44] Jiang W., Prasanna V.: A FPGA-based Parallel Architecture for Scalable High-Speed Packet
Classification 20th IEEE International Conference on Application-specific Systems, Architectures
and Processors, ASAP, 2009, pp. 24-31
[45] Jiang W., Prasanna V.: Large-scale wire-speed packet classification on FPGAs, Proceedings
of the ACM/SIGDA international symposium on Field programmable gate arrays, 2009, pp. 219-228
[46] Kennedy A., Wang X., Liu B.: Energy efficient packet classification hardware accelerator,
Proceedings of the IEEE International Symposium on Parallel and Distributed Processing, 2008
[47] Kennedy A., Liu Z., Wang X., Liu B.: Multi-Engine Packet Classification Hardware Accelerator,
Proceedings of 18th International Conference on Computer Communications and Networks, 2009,
pp. 1-6
[48] Kijewski P., Szczypiorski K.: Bezpieczeństwo w sieciach TCP/IP, Przegląd Telekomunikacyjny,
no. 5–6, 2001, s. 367-373
[49] Knuth D.: The Art of Computer Programming. Volume 3: Sorting and Searchning, Addison-Wesley
156
Publishing Company, 1973
[50] Kolehmainen A.: Optimizing firewall performance, TKK T-110.5190 Seminar on Internetworking,
2007
[51] Kumar, S. Dharmapurikar S. , Yu F. , Crowley P., Turner J.: Algorithms to Accelerate Multiple
Regular Expressions Matching for Deep Packet Inspection, In Proceedings of the Annual Conference
of the ACM Special Interest Group on Data Communication, 2006, pp. 339-350
[52] Lakshman T., Stiliadis D.: High-Speed Policy-based Packet Forwarding Using Efficient Multidimensional Range Matching, Proceedings of ACM Sigcomm, 1998, pp. 191-202
[53] Lakshminarayanan K., Anand Rangarajan A., Venkatachary S.: Algorithms for advanced packet
classification with Ternary CAMs, ACM SIGCOMM, 2005, pp. 193-204
[54] LeClaire J.: Google: Malware Runs Rampant on the Web, Enterprise Security Today, 2007,
http://www.enterprise-security-today.com/news/Google-Malware-Rampant-on-theWeb/story.xhtml?story_id=100000A0CEHC
[55] Levin T., Irvine C., Weissman C., Weissman T.: Analysis of Three Multilevel Security Architectures,
Proceedings of the 2007 ACM workshop on Computer security architecture, 2007, pp. 37-46
[56] Ligatti J., Gage C.: Dimension-independent Table-based Firewalls, Technical Report CSE-111108NS, 2008, http://www.cse.usf.edu/~ligatti/papers/fw-tr.pdf
[57] Linear Technology, LT1963 Series,
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1040, C1055,P2222,D3148
[58] Liu H.: Efficient Mapping of Range Classifier into Ternary-CAM, Proceedings of the 10th
Symposium on High Performance Interconnects HOT Interconnects, IEEE, 2002
[59] Loinig J., Wolkerstorfer J., Szekely A.: Packet Filtering in Gigabit Networks Using FPGAs,
Proceedings of the 15th Austrian Workshop on Microelectronics (2007), Austrochip, 2007,
pp. 53 - 60
[60] Loscocco P., Smalley S., Muckelbauer P., Taylor R., Turner S., Farrell J.: The Inevitability
of Failure: The Flawed Assumption of Security in Modern Computing Environments, In Proceedings
of the 21st National Information Systems Security Conference, 1998, pp. 303–314
[61] Lu J., Moscola J., Song H.: Control Packet Security for CAM based Firewall, Washington University,
2002
[62] Lunteren J., Engbersen T.: Fast and Scalable Packet Classification, IEEE Journal on selected areas
in communications, vol. 21, no. 4, 2003
[63] Luo Y., Xiang K., Li S.,: Acceleration of Decision Tree Searching for IP Traffic Classification ,
ACM/IEEE Symposium on Architectures for Networking and Communications Systems, 2008,
pp. 40-49
[64] Mahini H., Berangi R., Mahini A.: MLET: A Power Efficient Approach for TCAM Based, IP Lookup
157
Engines in Internet Routers, International Journal of Computer Networks & Communications, 2010,
pp. 13-26
[65] MarshallSoft, Windows Standard Serial Communications Library for Visual Basic (WSC4VB),
http://www.marshallsoft.com/wsc4vb.htm
[66] McAfee, McAfee Threats Report: First Quarter 2010,
http://www.mcafee.com/us/local_content/reports/2010q1_threats_report.pdf
[67] McAfee: TrustedSource: The Next Generation Reputation System for Enterprise Gateway Security,
http://nwtechusa.com/pdf/mcafee_wp_trustedsource.pdf
[68] National Semiconductor Corp., DP83865 Data Sheet, http://www.national.com/ds/DP/DP83865.pdf
[69] National Semiconductor Corp., DP83865 Reference Design,
http://www.national.com/appinfo/networks/files/dp83865_refdesign.pdf
[70] Niederberger R., Allcock W., Gommans L., Grünter E., Metsch T., Monga I., Volpato G., Grimm C.:
Firewall Issues overview, Open Grid Forum, 2006, http://www.ogf.org/documents/GFD.83.pdf
[71] Nikitakis A., Papaefstathiou I.: A Multi Gigabit FPGA-based 5-tuple classification system, IEEE
International Conference on Communications, 2008, pp. 2081-2085
[72] Nowicki K.: Ethernet – sieci, mechanizmy, Gdańsk , Infotech, 2006
[73] Opencores, WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores,
http://opencores.org/downloads/wbspec_b3.pdf
[74] OpenCores, www.opencores.org
[75] Papaefstathiou I., Papaefstathiou V.: Memory-efficient 5D packet classification at 40 Gbps, 26th
IEEE International Conference on Computer Communications INFOCOM, 2007, pp. 1370–1378
[76] Pereira J.: Comparison of Firewall, Intrusion Prevention and Antivirus Technologies, White Paper,
Juniper Networks Inc., http://www.juniper.net/solutions/literature/white_papers/200063.pdf
[77] Piotrowski M.: Bezpieczny Linux – przegląd projektów, hakin9, Nr 2/2006, Software-Wydawnictwo,
Warszawa, 2006
[78] Pradhan P.: Hardening of UNIX Operating System, International Journal of Computer
Communication and Technology, vol. 1, no. 1, 2009
[79] Pulse, PulseJack 1x1 Tab-Down RJ45 Data Sheet,
http://ww2.pulseeng.com/products/datasheets/J403.pdf
[80] Pulse, PulseJack Gigabit Data Sheet, http://ww2.pulseeng.com/products/datasheets/J411.pdf
[81] Qin H., Sasao T., Butler J.,: Implementation of LPM Address Generators on FPGAs, Reconfigurable
Computing: Architectures and Applications, vol. 3985/2006, Springer, 2006, p.170-181
[82] Qiu L., Varghese G., Suri S.: Fast firewall implementations for software and hardware-based
158
routers, Network Protocols Ninth International Conference on ICNP, 2001, pp. 241-250
[83] Realtek, RTL8201BL Data Sheet, http://www.alldatasheet.com/datasheetpdf/pdf/82934/ETC/RTL8201BL.html
[84] Realtek, RTL8201BL General Description,
http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=13&Level=5
&Conn=4&ProdID=24
[85] Realtek, RTL8201BL/CL/CP application circuit - interface with MAC(MII),
http://www.wiznet.co.kr/rg4_board/down.php?&bbs_code=en_qna&page=106
&bd_num=13185&key=0&mode=down
[86] Runge C.: The Path to Multi-Level Security in Red Hat Enterprise Linux, Red Hat, 2006,
http://www.redhat.com/f/pdf/sec/path_to_mlsec.pdf
[87] SC Magazine, Multi-function appliances, 2006, http://www.scmagazineus.com/multi-functionappliances-2006/printgrouptest/20/
[88] Secunia: Vulnerability Report: Cisco Intrusion Prevention System (IPS) 5.x,
http://secunia.com/advisories/product/5600/?task=statistics
[89] Secunia: Vulnerability Report: Cisco IOS 12.x,
http://secunia.com/advisories/product/182/?task=statistics
[90] Secunia: Vulnerability Report: Cisco PIX 6.x, http://secunia.com/advisories/product/56/?task=statistic
[91] Sedgewick R.: Algorithms in C, Addison-Wesley Publishing Company, 1990
[92] Singh S., Baboescu F., Varghese G., Wang J.: Packet classification using multidimensional cutting,
Proceedings of ACM SIGCOMM, 2003, pp. 213–224
[93] Song H., Lockwood J.: Efficient Packet Classification for Network Intrusion Detection using FPGA,
International Symposium on Field-Programmable Gate Arrays (FPGA'05), Monterey, CA, 2005
[94] Sourdis I., Pnevmatikatos D.: Pre-decoded CAMs for Efficient and High-Speed NIDS Pattern
Matching, IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM), Napa,
CA, 2004
[95] Spencer R., Smalley S., Loscocco P., Hibler M., Andersen D., Lepreau J.: The Flask Security
Architecture: System Support for Diverse Security Policies, In The Eighth USENIX Security
Symposium, 1999, pp. 123–139
[96] Spirent Communications Inc., How to Test 10 Gigabit Ethernet Performance,
http://gospirent.com/whitepaper/10GE_Perf_Testing.pdf
[97] Spitznagel E., Taylor D., Turner J.: Packet Classification Using Extended TCAM, Proceedings
of the 11th IEEE International Conference on Network Protocol, 2003, p.120
[98] Srinivasan V., Vargheset G., SuriS S., Waldvogelg M.: Fast and Scalable Layer Four Switching,
159
ACM SIGCOMM '98, 1998, pp. 191-202
[99] Srinivasan V., Suri S., Varghese G.: Packet Classification using Tuple Space Search, Proceedings
of ACM Sigcomm, 1999, pp. 135-46
[100] Stawoski M.: Zapory sieciowe firewal. Projektowanie i praktyczne implementacje na bazie
zabezpieczeń Check Point NGX, ArsKom, Warszawa, 2006
[101] Strona domowa aplikacji iperf, http://iperf.sourceforge.net/
[102] Strona domowa firmy Secunia, http://secunia.com/
[103] Strona domowa firmy SofaWare, http://www.sofaware.com/uploadFiles/[email protected]
[104] Strona domowa firmy Sunbelt Software, Sunbelt Personal Firewall,
http://www.sunbeltsoftware.com/Home-Home-Office/Sunbelt-Personal-Firewall/
[105] Strona domowa IEEE P802.3ba 40Gb/s oraz 100Gb/s Ethernet Task Force,
http://grouper.ieee.org/groups/802/3/ba/index.html
[106] Strona domowa organizacji 10GEA, Introduction to the TCP/IP offload Engine,
http://www.10gea.org/tcp-ip-offload-engine-toe.htm
[107] Sułkowski G., Twardy M., Wiatr K.: Filtrowanie adresów sieciowych w sprzętowym systemie
bezpieczeństwa typu Firewall, Kwartalnik Pomiary, Automatyka i Kontrola nr 7, 2009, s.479-481
[108] Sułkowski G., Twardy M., Wiatr K.: Implementacja standardu sieci Ethernet IEEE 802.3 w układach
FPGA na potrzeby systemu bezpieczeństwa typu Firewall, Kwartalnik Pomiary Automatyka
i Kontrola nr 7, 2007, s. 30-32
[109] Sułkowski G., Twardy M., Wiatr K.: Implementacja systemu bezpieczeństwa typu Firewall dla
potrzeb sieci Ethernet w oparciu o układy reprogramowalne FPGA, Kwartalnik Pomiary,
Automatyka i Kontrola nr 5, 2007, s. 114-116
[110] Sułkowski G., Twardy M., Wiatr K.: Implementation of a hardware Firewall Security System using
FPGA Technology, Materiały z konferencji Sieci i Systemy Informatyczne 2008 (SIS’08). Wydanie
elektroniczne (ISBN 978-83-909161-1-8), 2008
[111] Sułkowski G., Twardy M., Wiatr K.: Implementation of the Ethernet Network IEEE 802.3 standard
in the FPGA devices for a security system of the Firewall type, Materiały konferencji Narzędzia
Technologii Informacyjnych 2007 (NTI’07), 2007, s. 57-63
[112] Sułkowski G., Twardy M., Wiatr K.: Implementation of the Hardware Packet Classification System,
Journal of Applied Computer Science, vol. 17, no. 2, 2009, pp.97-111
[113] Sułkowski G., Twardy M., Wiatr K.: Szybka filtracja portów sieciowych w sprzętowym systemie
bezpieczeństwa typu Firewall, Kwartalnik Pomiary, Automatyka i Kontrola nr 8, 2009, s. 615-617
[114] Sułkowski G., Twardy M., Wiatr K.: Weryfikacja reguł bezpieczeństwa wspomagana mechanizmami
pamięci podręcznej w sprzętowej implementacji systemu bezpieczeństwa typu firewall, Kwartalnik
160
Pomiary, Automatyka i Kontrola nr 8, 2008, s. 511-513
[115] Sułkowski G., Twardy M., Wiatr K.: Wielościeżkowe równoległe przetwarzanie danych
w sprzętowym systemie bezpieczeństwa klasy Firewall, Przegląd Telekomunikacyjny nr 6, 2008,
s.726-728
[116] Sygate: Sygate Personal Firewall, http://sygate-personal-firewall.brothersoft.com/
[117] Taiwan Semiconductor, TS823/824/825 Series Data Sheet,
http://www.ts.com.tw/db/pictures/modules/PDT/PDT060207001/TS823_24_25_B07.pdf
[118] Taylor D., Turner J.: Scalable packet classification using distributed crossproducing of field labels,
24th Annual Joint Conference of the IEEE Computer and Communications Societies, INFOCOM,
2005, pp. 269 - 280
[119] Taylor D.: Survey and taxonomy of packet classification techniques, ACM Computer Surverys, 2005,
pp. 238–275
[120] Terasic Technologies, FPGA Systems, http://www.terasic.com.tw
[121] Tsuchiya P.: A Search Algorithm for Table Entries with Non-contiguous Wildcarding, Bellcore,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.37.3234&rep=rep1&type=pdf
[122] Wiatr K.: Akceleracja obliczeń w systemach wizyjnych, Wydawnictwa Naukowo-Techniczne,
Warszawa, 2003
[123] Wiatr K.: Sprzętowe implementacje algorytmów przetwarzania obrazów w systemach wizyjnych czasu
rzeczywistego, Kraków, Wyd. Naukowo-Dydaktyczne AGH, 2002
[124] Wikberg M.: Secure computing: SELinux, TKK T-110.5290 Seminar on Network Security, 2007,
http://www.tml.tkk.fi/Publications/C/25/papers/Wikberg_final.pdf
[125] Xilinx, 16-Deep by 1-Wide Static Dual Port Synchronous RAM,
http://www.xilinx.com/itp/xilinx5/data/docs/lib/lib0345_329.html
[126] Xilinx, 170 MHz FIFOs Using the Virtex Block SelectRAM+ Feature,
http://www.xilinx.com/support/documentation/application_notes/xapp131.pdf
[127] Xilinx, Designing Flexible, Fast CAMs with Virtex Family FPGAs,
http://www.xilinx.com/support/documentation/application_notes/xapp203.pdf
[128] Xilinx, Digital Clock Manager (DCM) Module,
http://www.xilinx.com/support/documentation/ip_documentation/dcm_module.pdf
[129] Xilinx, IEEE 802.3 Cyclic Redundancy Check,
http://www.xilinx.com/support/documentation/application_notes/xapp209.pdf
[130] Xilinx, LocalLink Interface Specification, SP006 (v2.0), 2005,
http://www.xilinx.com/products/ipcenter/LocalLink_UserInterface.htm
[131] Xilinx, An Overview of Multiple CAM Designs in Virtex Family Devices,
161
http://www.xilinx.com/support/documentation/application_notes/xapp201.pdf
[132] Xilinx, Spartan-II FPGA Family Data Sheet,
http://www.xilinx.com/support/documentation/data_sheets/ds001.pdf
[133] Xilinx, System Clock Management Simplified with Virtex-II Pro FPGAs,
http://www.xilinx.com/support/documentation/white_papers/wp190.pdf
[134] Xilinx, Using the Virtex Block SelectRAM+ Features,
http://www.xilinx.com/support/documentation/application_notes/xapp130.pdf
[135] Xilinx, Virtex-II Pro and Virtex-II Pro X Platform FPGAs: Complete Data Sheet,
http://www.xilinx.com/support/documentation/data_sheets/ds083.pdf
[136] Xilinx, Xilinx CORE Generator System, http://www.xilinx.com/tools/coregen.htm
[137] Yu H.: A Memory- and Time-efficient On-chip TCAM Minimizer for IP Lookup, Design, Automation
& Test in Europe Conference & Exhibition (DATE), 2010, pp. 926-931
[138] Zane F., Narlikar G., Basu A.: CoolCAMs: Power-Efficient TCAMs for Forwarding Engines,
INFOCOM 2003, Twenty-Second Annual Joint Conference of the IEEE Computer and
Communications , vol. 1, 2003, pp. 42-52
[139] Zheng K., Che H., Wang Z., Liu B., Zhang X.: DPPC-RE: TCAM-Based Distributed Parallel Packet
Classification with Range Encoding, IEEE Transactions on Computers, vol. 55, 2006, pp. 947-961
162
8. Dodatek A – opis funkcji sygnałów
poszczególnych modułów sprzętowego
systemu Firewall
8.1. Sygnały modułu eth_mac w wersji Fast Ethernet
Interfejs PHY MII:
phy_rx_clk - zegar toru odbiorczego (25 MHz dla szybkości 100 Mb/s oraz 2,5 MHz dla trybu
10 Mb/s),
phy_rx_dv - sygnał potwierdzający przy narastającym zboczu zegara phy_rx_clk obecność
poprawnych danych na wejściu phy_rx_data(3:0),
phy_rx_error - sygnał zgłoszenia błędu odbioru (przyjmuje wysoki poziom logiczny
w momencie wystąpienia jakiegokolwiek błędnego symbolu w kodzie 5B),
phy_rx_data(3:0) – odbierane nible (połówki bajtu) danych,
phy_tx_clk - zegar toru nadawczego (25 MHz dla szybkości 100 Mb/s oraz 2,5 MHz dla trybu
10 Mb/s),
phy_tx_en – sygnał zezwolenia transmisji,
phy_tx_data(3:0) – nible danych przeznaczonych do wysłania,
phy_col – sygnał zgłoszenia kolizji w medium fizycznym,
phy_crs – sygnał detekcji nośnej,
phy_int_n – sygnał zgłoszenia przerwania (tylko dla kart Gigabit Ethernet),
phy_mdc - zegar synchronizujący linię MDIO,
phy_mdio - dwukierunkowa linia służąca przesyłaniu informacji sterujących pracą PHY,
phy_reset_n – sygnał resetu układu PHY (tylko dla kart Gigabit Ethernet).
Interfejs komunikacyjny Firewalla:
sys_clk – zegar systemowy (w przypadku płyty XUPV 100 MHz),
reset – reset kontrolera MAC,
eth_mac_ready - kontroler MAC zestawił poprawne połączenie ze stacją docelową,
eth_mac_rx_enable – zezwolenie na odbiór danych,
eth_mac_rx_pause – zatrzymanie procesu odbioru (reset toru RX w związku z przepełnieniem
buforu FIFO),
eth_mac_rx_active – sygnał informujący o aktywności toru RX,
eth_mac_rx_data(7:0) – odebrany bajt danych,
eth_mac_rx_data_valid – sygnał walidujący odebrany bajt danych,
eth_mac_rx_ok – informacja o poprawnie odebranej ramce,
163
eth_mac_rx_error – zgłoszenie błędu podczas odbierania ramki,
eth_mac_rx_frame_size(10:0) – długość odebranej ramki w bajtach,
eth_mac_tx_enable – zezwolenie na transmisję danych,
eth_mac_tx_active – sygnał informujący o aktywności toru TX,
eth_mac_tx_retransmit – konieczna retransmisja ramki w związku z wystąpieniem kolizji,
eth_mac_tx_data(7:0) – wejście transmitowanych danych,
eth_mac_tx_data_ack – potwierdzenie wysłania bajtu danych,
eth_mac_tx_ok – poprawne zakończenie transmisji ramki,
eth_mac_tx_error – transmisja ramki zakończona błędem,
eth_mac_tx_frame_size(10:0) – długość transmitowanej ramki w bajtach.
Interfejs konfiguracyjny:
r_rx_promiscous_en – praca
w trybie promiscous (akceptacja
wszystkich ramek
przychodzących),
r_rx_multicast_en – akceptacja ramek rozgłoszeniowych typu multicast,
r_rx_mac_address(47:0) – adres MAC kontrolera,
r_tx_crc_en – włączenie obliczania sumy kontrolnej CRC dla transmitowanej ramki,
r_tx_padding_en – włączenie trybu automatycznego dopełniania ramek krótszych od długości
minimalnej,
r_mii_config(15:0) – wektor konfiguracyjny zarządzania PHY poprzez magistralę MDIO:
o
(15:11) – adres PHY,
o
(10:3) – okres odświeżania linii MDIO,
o
(2) – tryb pracy MDIO,
o
(1:0) – zarezerwowane.
8.2. Sygnały modułu eth_rx w wersji Fast Ethernet
Interfejs PHY MII:
phy_rx_clk - zegar toru odbiorczego (25 MHz dla szybkości 100 Mb/s oraz 2,5 MHz dla trybu
10 Mb/s),
phy_rx_dv - sygnał potwierdzający przy narastającym zboczu zegara phy_rx_clk obecność
poprawnych danych na wejściu phy_rx_data(3:0),
phy_rx_error - sygnał zgłoszenia błędu odbioru (przyjmuje wysoki poziom logiczny
w momencie wystąpienia jakiegokolwiek błędnego symbolu w kodzie 5B),
phy_rx_data(3:0) – odbierane nible (połówki bajtu) danych.
Interfejsu komunikacyjny Firewalla:
sys_clk – zegar systemowy (w przypadku płyty XUPV 100 MHz),
reset – reset modułu,
eth_mac_rx_enable – zezwolenie na odbiór danych,
164
eth_mac_rx_pause – zatrzymanie procesu odbioru (reset toru RX w związku z przepełnieniem
buforu FIFO),
eth_mac_rx_active – sygnał informujący o aktywności toru RX,
eth_mac_rx_data(7:0) – odebrany bajt danych,
eth_mac_rx_data_valid – sygnał walidujący odebrany bajt danych,
eth_mac_rx_ok – informacja o poprawnie odebranej ramce,
eth_mac_rx_error – zgłoszenie błędu podczas odbierania ramki,
eth_mac_rx_frame_size(10:0) – długość odebranej ramki w bajtach.
Interfejs konfiguracyjny:
r_rx_promiscous_en – praca
w trybie promiscous (akceptacja
wszystkich ramek
przychodzących),
r_rx_multicast_en – akceptacja ramek rozgłoszeniowych typu multicast,
r_rx_mac_address(47:0) – adres MAC kontrolera.
8.3. Sygnały modułu eth_tx w wersji Fast Ethernet
Interfejs PHY MII:
phy_tx_clk - zegar toru nadawczego (25 MHz dla szybkości 100 Mb/s oraz 2,5 MHz dla trybu
10 Mb/s),
phy_tx_col – sygnał zgłoszenia kolizji w medium fizycznym,
phy_tx_crs – sygnał detekcji nośnej,
phy_tx_en – zezwolenie na transmisję danych,
phy_tx_data(3:0) – nible danych przeznaczonych do wysłania,
Interfejsu komunikacyjny Firewalla:
reset – reset modułu,
half_duplex – sygnał informujący o pracy w trybie Half Duplex,
tx_enable – zezwolenie na transmisję danych,
tx_running – sygnał informujący o aktywności toru TX,
tx_data_ack – potwierdzenie wysłania bajtu danych,
tx_data(7:0) – wejście transmitowanych danych,
tx_ok – poprawne zakończenie transmisji ramki,
tx_retransmit – konieczna retransmisja ramki w związku z wystąpieniem kolizji,
tx_error – transmisja ramki zakończona błędem,
tx_frame_size(10:0) – długość transmitowanej ramki.
Interfejs konfiguracyjny:
r_tx_crc_en – włączenie obliczania sumy kontrolnej CRC dla transmitowanej ramki,
r_tx_padding_en – włączenie trybu automatycznego dopełniania ramek krótszych od długości
minimalnej.
165
8.4. Sygnały modułu eth_mac w wersji Gigabit Ethernet
Interfejs PHY GMII:
phy_rx_clk - zegar toru odbiorczego (125 MHz dla 1000 Mb/s GMII, 25 MHz dla szybkości
100 Mb/s oraz 2,5 MHz dla trybu 10 Mb/s),
phy_rx_dv - sygnał potwierdzający przy narastającym zboczu zegara phy_rx_clk obecność
poprawnych danych na wejściu phy_rx_data(3:0) dla interfejsu MII oraz phy_rx_data(7:0) dla
interfejsu GMII,
phy_rx_error - sygnał zgłoszenia błędu odbioru (przyjmuje wysoki poziom logiczny
w momencie wystąpienia jakiegokolwiek błędnego symbolu w kodzie 5B),
phy_rx_data(7:0) – odbierane
dane o szerokości phy_rx_data(3:0) dla interfejsu MII
oraz phy_rx_data(7:0) dla interfejsu GMII,
phy_tx_clk - zegar toru nadawczego w trybie MII (25 MHz dla szybkości 100 Mb/s
oraz 2,5 MHz dla trybu 10 Mb/s),
phy_gtx_clk - zegar toru nadawczego 125 MHz w trybie GMII generowany przez kontroler
MAC,
phy_tx_en – sygnał zezwolenia transmisji,
phy_tx_data(3/7:0) – dane do transmisji o szerokości phy_tx_data(3:0) dla interfejsu MII
oraz phy_tx_data(7:0) dla interfejsu GMII,
phy_tx_error – wymuszenie transmisji niepoprawnych symboli,
phy_col – sygnał zgłoszenia kolizji w medium fizycznym,
phy_crs – sygnał detekcji nośnej,
phy_int_n – sygnał zgłoszenia przerwania (tylko dla kart Gigabit Ethernet),
phy_mdc - zegar synchronizujący linię MDIO,
phy_mdio - dwukierunkowa linia służąca przesyłaniu informacji sterujących pracą PHY,
phy_reset_n – sygnał resetu układu PHY (tylko dla kart Gigabit Ethernet).
Interfejs komunikacyjny Firewalla:
sys_clk – zegar systemowy (w przypadku płyty XUPV 100 MHz),
reset – reset kontrolera MAC,
mac_ce_in – sygnał Chip Enable dla kontrolera MAC,
rx_data_out(31:0) – 32-bitowe dane wyjściowe,
rx_rem_out(3:0) – walidacja pełnych bajtów w 32-bitowowym słowie danych wyjściowych,
rx_sof_out – potwierdzenie rozpoczęcia odbierania ramki,
rx_eof_out – potwierdzenie zakończenia odbierania ramki,
rx_rd_en_in – sygnał zezwolenia odbierania ramek,
rx_rdy_out – potwierdzenie gotowości toru RX,
rx_ok_out – potwierdzenie poprawności odebranej ramki,
rx_err_out – zgłoszenie błędu w odebranej ramce,
rx_tag_out – informacja o odebraniu ramki znakowanej,
rx_lenght_out(10:0) – długość odebranej ramki (w bajtach),
166
tx_data_in(31:0) – 32-bitowe słowo danych wejściowych przeznaczonych do transmisji,
tx_rem_in(3:0) – walidacja pełnych bajtów w 32-bitowowym słowie danych wejściowych,
tx_sof_in – początek transmisji ramki,
tx_eof_in – koniec transmisji ramki,
tx_wr_en_in – zezwolenie na transmisję ramki,
tx_rdy_out – zgłoszenie gotowości toru TX,
tx_ok_out – informacja o poprawnym zakończeniu transmisji ramki,
tx_err_out – zgłoszenie błędu podczas transmisji ramki,
tx_lenght_in(10:0) – długość wysyłanej ramki (w bajtach).
Interfejs konfiguracyjny:
cfg_rx_prmsc_en
–
praca
w
trybie
promiscous
(akceptacja
wszystkich
ramek
przychodzących),
cfg_rx_mltc_en – akceptacja ramek rozgłoszeniowych typu multicast,
cfg_rx_mac_addr(47:0) – adres MAC kontrolera,
cfg_tx_pause_en – zezwolenie na obsługę ramek kontroli przepływu typu PAUSE,
cfg_mii (15:0) – wektor konfiguracyjny zarządzania PHY poprzez magistralę MDIO:
o
(15:11) – adres PHY,
o
(10:3) – okres odświeżania linii MDIO,
o
(2) – tryb pracy MDIO,
o
(1:0) – zarezerwowane.
stat_speed(1:0) – sygnał informujący o bieżącej szybkości pracy kontrolera MAC („00” –
10 MB/s, „01” – 100 Mb/s, „10” – 1000 Mb/s).
stat_link – sygnał informujący o zestawieniu poprawnego połączenia (‘0’ – brak połączenia,
‘1’ – połączenie zestawione),
stat_duplex – sygnał informujący o trybie Duplex (‘0’ – Half Duplex, ‘1’ – Full Duplex).
8.5. Sygnały modułu eth_rx w wersji Gigabit Ethernet
Interfejs PHY GMII:
phy_rx_clk - zegar toru odbiorczego (125 MHz dla 1000 Mb/s GMII, 25 MHz dla szybkości
100 Mb/s oraz 2,5 MHz dla trybu 10 Mb/s),
phy_rx_dv - sygnał potwierdzający przy narastającym zboczu zegara phy_rx_clk obecność
poprawnych danych na wejściu phy_rx_data(3:0) dla interfejsu MII oraz phy_rx_data(7:0) dla
interfejsu GMII,
phy_rx_error - sygnał zgłoszenia błędu odbioru (przyjmuje wysoki poziom logiczny
w momencie wystąpienia jakiegokolwiek błędnego symbolu w kodzie 5B),
phy_rx_data(7:0) – odbierane
dane o szerokości phy_rx_data(3:0) dla interfejsu MII
oraz phy_rx_data(7:0) dla interfejsu GMII,
phy_crs – sygnał detekcji nośnej.
167
Interfejs komunikacyjny Firewalla:
sys_clk – zegar systemowy (w przypadku płyty XUPV 100 MHz),
reset – reset kontrolera MAC,
rx_ce_in – sygnał Chip Enable dla toru RX,
rx_data_out(31:0) – 32-bitowe dane wyjściowe,
rx_rem_out(3:0) – walidacja pełnych bajtów w 32-bitowowym słowie danych wyjściowych,
rx_sof_out – potwierdzenie rozpoczęcia odbierania ramki,
rx_eof_out – potwierdzenie zakończenia odbierania ramki,
rx_rd_en_in – sygnał zezwolenia odbierania ramek,
rx_rdy_out – potwierdzenie gotowości toru RX,
rx_ok_out – potwierdzenie poprawności odebranej ramki,
rx_err_out – zgłoszenie błędu w odebranej ramce,
rx_tag_out – informacja o odebraniu ramki znakowanej,
rx_lenght_out(10:0) – długość odebranej ramki (w bajtach).
Interfejs konfiguracyjny:
rx_prmsc_en – praca w trybie promiscous (akceptacja wszystkich ramek przychodzących),
rx_mltc_en – akceptacja ramek rozgłoszeniowych typu multicast,
rx_mac_addr(47:0) – adres MAC kontrolera,
cfg_speed(1:0) – sygnał informujący o bieżącej szybkości pracy kontrolera MAC („00” –
10 MB/s, „01” – 100 Mb/s, „10” – 1000 Mb/s).
cfg_link – sygnał informujący o zestawieniu poprawnego połączenia (‘0’ – brak połączenia,
‘1’ – połączenie zestawione).
8.6. Sygnały modułu eth_tx w wersji Gigabit Ethernet
Interfejs PHY GMII:
phy_tx_clk - zegar toru nadawczego w trybie MII (25 MHz dla szybkości 100 Mb/s
oraz 2,5 MHz dla trybu 10 Mb/s),
phy_gtx_clk - zegar toru nadawczego 125 MHz w trybie GMII generowany przez kontroler
MAC,
phy_col – sygnał zgłoszenia kolizji w medium fizycznym,
phy_crs – sygnał detekcji nośnej,
phy_tx_en – sygnał zezwolenia transmisji,
phy_tx_data(3/7:0) – dane do transmisji o szerokości phy_tx_data(3:0) dla interfejsu MII
oraz phy_tx_data(7:0) dla interfejsu GMII,
phy_tx_error – wymuszenie transmisji niepoprawnych symboli.
Interfejs komunikacyjny Firewalla:
sys_clk – zegar systemowy (w przypadku płyty XUPV 100 MHz),
reset – reset kontrolera MAC,
168
tx_ce_in – sygnał Chip Enable dla toru RX,
tx_data_in(31:0) – 32-bitowe słowo danych wejściowych przeznaczonych do transmisji,
tx_rem_in(3:0) – walidacja pełnych bajtów w 32-bitowowym słowie danych wejściowych,
tx_sof_in – początek transmisji ramki,
tx_eof_in – koniec transmisji ramki,
tx_wr_en_in – zezwolenie na transmisję ramki,
tx_rdy_out – zgłoszenie gotowości toru TX,
tx_ok_out – informacja o poprawnym zakończeniu transmisji ramki,
tx_err_out – zgłoszenie błędu podczas transmisji ramki,
tx_lenght_in(10:0) – długość wysyłanej ramki (w bajtach),
tx_pause_cnt_eq0 – zgłoszenie zakończenia obsługi ramki typu PAUSE.
Interfejs konfiguracyjny:
cfg_tx_pause_en – zezwolenie na obsługę ramek kontroli przepływu typu PAUSE,
cfg_speed(1:0) – sygnał informujący o bieżącej szybkości pracy kontrolera MAC („00” –
10 MB/s, „01” – 100 Mb/s, „10” – 1000 Mb/s),
cfg_link – sygnał informujący o zestawieniu poprawnego połączenia (‘0’ – brak połączenia,
‘1’ – połączenie zestawione),
cfg_duplex – sygnał informujący o trybie Duplex (‘0’ – Half Duplex, ‘1’ – Full Duplex).
8.7. Sygnały modułu fw_engine
Interfejs MAC:
sys_clk – zegar systemowy (w przypadku płyty XUPV 100 MHz),
reset – reset silnika,
phy_rx_clk - zegar toru odbiorczego
eth_mac_ready_rx - kontroler MAC toru RX zestawił poprawne połączenie ze stacją
docelową,
eth_mac_rx_enable – zezwolenie na odbiór danych,
eth_mac_rx_pause – zatrzymanie procesu odbioru (reset toru RX w związku z przepełnieniem
buforu FIFO),
eth_mac_rx_active – sygnał informujący o aktywności toru RX,
eth_mac_rx_data(7:0) – odebrany bajt danych,
eth_mac_rx_data_valid – sygnał walidujący odebrany bajt danych,
eth_mac_rx_ok – informacja o poprawnie odebranej ramce,
eth_mac_rx_error – zgłoszenie błędu podczas odbierania ramki,
eth_mac_rx_frame_size(10:0) – długość odebranej ramki w bajtach,
phy_tx_clk - zegar toru nadawczego
eth_mac_tx_enable – zezwolenie na transmisję danych,
169
eth_mac_ready_rx - kontroler MAC toru TX zestawił poprawne połączenie ze stacją
docelową,
eth_mac_tx_active – sygnał informujący o aktywności toru TX,
eth_mac_tx_retransmit – konieczna retransmisja ramki w związku z wystąpieniem kolizji,
eth_mac_tx_data(7:0) – wejście transmitowanych danych,
eth_mac_tx_data_ack – potwierdzenie wysłania bajtu danych,
eth_mac_tx_ok – poprawne zakończenie transmisji ramki,
eth_mac_tx_error – transmisja ramki zakończona błędem,
eth_mac_tx_frame_size(10:0) – długość transmitowanej ramki w bajtach.
Interfejs klasyfikatora:
clas_ETH_frame_type(15:0) – typ ramki Ethernet,
clas_IP_protocol(7:0) – typ protokołu IP,
clas_IP_SA(31:0) – adres źródłowy nagłówka IP,
clas_IP_DA(31:0) – adres docelowy nagłówka IP,
clas_S_port(15:0) – port źródłowy nagłówka TCP/UDP,
clas_D_port(15:0) – port docelowy nagłówka TCP/UDP,
clas_desc_ready – zgłoszenie deskryptora do analizy,
clas_ready – potwierdzenie zakończenia weryfikacji,
clas_result(7:0) – wynik (akcja) klasyfikacji (aktualnie: „00000000” – pakiet zaakceptowany,
„00000001” – pakiet odrzucony; pozostałe stany zarezerwowane).
8.8. Sygnały modułu classifier_main
Interfejs systemowy:
sys_clk – zegar systemowy (w przypadku płyty XUPV 100 MHz),
reset – reset klasyfikatora.
Interfejs silnika toru 0:
clas_0_ETH_frame_type(15:0) – typ ramki Ethernet,
clas_0_IP_protocol(7:0) – typ protokołu IP,
clas_0_IP_SA(31:0) – adres źródłowy nagłówka IP,
clas_0_IP_DA(31:0) – adres docelowy nagłówka IP,
clas_0_S_port(15:0) – port źródłowy nagłówka TCP/UDP,
clas_0_D_port(15:0) – port docelowy nagłówka TCP/UDP,
clas_0_desc_ready – zgłoszenie deskryptora do analizy,
clas_0_ready – potwierdzenie zakończenia weryfikacji,
clas_0_result(7:0)
–
wynik (akcja) klasyfikacji (aktualnie: „00000000” – pakiet
zaakceptowany, „00000001” – pakiet odrzucony; pozostałe stany zarezerwowane).
Interfejs silnika toru 1:
clas_1_ETH_frame_type(15:0) – typ ramki Ethernet,
170
clas_1_IP_protocol(7:0) – typ protokołu IP,
clas_1_IP_SA(31:0) – adres źródłowy nagłówka IP,
clas_1_IP_DA(31:0) – adres docelowy nagłówka IP,
clas_1_S_port(15:0) – port źródłowy nagłówka TCP/UDP,
clas_1_D_port(15:0) – port docelowy nagłówka TCP/UDP,
clas_1_desc_ready – zgłoszenie deskryptora do analizy,
clas_1_ready – potwierdzenie zakończenia weryfikacji,
clas_1_result(7:0)
–
wynik (akcja) klasyfikacji (aktualnie: „00000000” – pakiet
zaakceptowany, „00000001” – pakiet odrzucony; pozostałe stany zarezerwowane).
Interfejs bloku ładowania konfiguracji:
policy_we – inicjalizacja ładowania definicji reguł bezpieczeństwa,
address_we – zezwolenie na zapis konfiguracji wewnętrznej filtru adresów,
address_wr_data(87:0) – szyna danych konfiguracji wewnętrznej filtru adresów,
address_wr_addr(log2_ceil(liczba_reguł-1)+3:0) – szyna adresowa dla zapisu konfiguracji
wewnętrznej filtru adresów,
port_we – zezwolenie na zapis konfiguracji wewnętrznej filtru portów,
port_wr_data(27:0) – szyna danych konfiguracji wewnętrznej filtru portów,
port_wr_addr(log2_ceil(liczba_reguł-1)+3:0) – szyna adresowa dla zapisu konfiguracji
wewnętrznej filtru portów,
action_we – zezwolenie na zapis konfiguracji wewnętrznej pamięci akcji,
action_ram_data(7:0) – szyna danych konfiguracji wewnętrznej pamięci akcji,
action_wr_addr(log2_ceil(liczba_reguł-1)-1:0) – szyna adresowa dla zapisu konfiguracji
wewnętrznej pamięci akcji.
171
9. Dodatek B - szczegółowe wyniki syntezy
modułów sprzętowego Firewalla
9.1. Wykorzystanie zasobów sprzętowych układów FPGA
oraz parametry czasowe implementacji modułu kontrolnego
dla wersji Fast Ethernet.
Moduł
Typ układu
eth_control
Spartan
Virtex
2s200epq208-7 2vp30ff896-7
Number of Slices
69
Number of Slice Flip Flops
86
86
125
128
Number of IOs
25
25
Number of bonded IOBs
15
15
1
1
Number of 4 input LUTs
67
Number used as logic
Number used as Shift registers
Number of GCLKs
Timing Summary
8,114ns
3,087ns
123,244MHz
323,950MHz
Minimum input arrival time before clock
7,286ns
3,302ns
Maximum output required time after clock
9,443ns
4,521ns
Minimum period
Maximum Frequency
Maximum combinational path delay
No path found No path found
Cell Usage
BELS
150
146
GND
1
1
INV
2
2
LUT2
8
8
LUT2_D
4
4
33
31
LUT3_D
2
4
LUT3_L
2
2
66
63
LUT4_D
6
7
LUT4_L
2
5
MUXCY
5
5
MUXF5
12
6
LUT1
2
LUT2_L
LUT3
LUT4
VCC
1
FlipFlops/Latches
86
86
FDC
33
33
FDE
4
4
FDP
2
2
Clock Buffers
1
1
BUFGP
1
1
IO Buffers
8
8
IBUF
8
8
OBUF
5
5
172
9.2. Wykorzystanie zasobów sprzętowych układów FPGA oraz parametry czasowe modułów toru RX
w wersji Fast Ethernet.
Moduł
Typ układu
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
Number used as logic
Number used as Shift registers
Number of IOs
Number of bonded IOBs
Number of GCLKs
Timing Summary
Minimum period
Maximum Frequency
Minimum input arrival time before clock
Maximum output required time after clock
Maximum combinational path delay
Cell Usage
BELS
GND
INV
LUT2
LUT2_D
LUT2_L
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
LUT4_L
MUXCY
MUXF5
VCC
FlipFlops/Latches
FDC
FDE
Shift Registers
SRL16E
Clock Buffers
BUFGP
IO Buffers
IBUF
OBUF
eth_rx_bitreceiver
eth_rx_crc
eth_rx_datadecap
eth_rx_recaddress
eth_rx_tlm
eth_rx
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7
31
30
41
59
29
27
33
36
2
2
83
101
43
43
34
34
23
22
4
4
3
3
105
105
58
57
78
111
50
47
58
62
4
4
157
190
149
182
8
8
48
48
28
28
44
44
76
76
41
41
83
83
48
48
17
17
36
36
68
68
8
8
33
33
1
1
1
1
1
1
1
1
1
1
1
1
9,262ns
3,271ns
107,968MHz 305,689MHz
7,236ns
3,810ns
8,610ns
4,131ns
7,836ns
4,656ns
6,829ns
2,237ns
146,434MHz 447,117MHz
7,853ns
3,529ns
9,096ns
5,114ns
7,730ns
5,159ns
7,160ns
3,464ns
139,655MHz 288,675MHz
7,255ns
4,076ns
6,500ns
3,359ns
No path found No path found
84
1
1
17
82
1
1
15
89
1
122
1
59
1
55
1
3
5
9
22
8
2
20
21
1
1
6
16
1
1
11
2
20
1
1
14
1
4
11
1
22
1
1
6
1
44
9
7
9
11
54
2
12
9
16
43
4
43
4
1
34
1
1
9
9
38
1
1
9
9
38
1
1
15
15
1
4,452ns
2,062ns
224,618MHz 484,966MHz
11,334ns
5,879ns
6,140ns
3,293ns
No path found No path found
67
1
1
4
72
1
1
7
8
5
16
43
47
1
34
4
5
2
1
23
2
5
1
1
22
2
5
2
1
4
2
5
3
1
4
1
1
15
15
1
1
1
18
18
17
1
1
18
18
17
1
1
66
66
1
1
1
66
66
1
No path found No path found
9,127ns
3,302ns
109,565MHz 302,879MHz
4,204ns
2,343ns
7,277ns
3,712ns
6,140ns
3,293ns
8,493ns
4,203ns
No path found No path found No path found No path found
4
4
1
3
1
3
3
1
3
1
1
1
4
4
3
1
1
4
4
3
185
1
3
41
3
220
1
3
40
1
26
44
1
11
62
4
16
20
4
1
105
12
8
8
8
1
1
9
9
23
2
66
5
3
20
2
1
105
12
8
8
8
1
1
9
9
23
173
9.3. Wykorzystanie zasobów sprzętowych układów FPGA oraz parametry czasowe modułów toru TX
w wersji Fast Ethernet.
Moduł
Typ układu
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
Number used as logic
Number used as Shift registers
Number of IOs
Number of bonded IOBs
Number of GCLKs
Timing Summary
Minimum period
Maximum Frequency
Minimum input arrival time before clock
Maximum output required time after clock
Maximum combinational path delay
Cell Usage
BELS
GND
INV
LUT1
LUT2
LUT2_D
LUT2_L
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
LUT4_L
MUXCY
MUXF5
VCC
FlipFlops/Latches
FDC
Shift Registers
SRL16E
Clock Buffers
BUFGP
IO Buffers
IBUF
OBUF
eth_tx_backoff
eth_tx_bittran
eth_tx_crc
eth_tx_defer
eth_tx_tlm
eth_tx
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
Spartan
Virtex
2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7 2s200epq208-7 2vp30ff896-7
25
26
21
21
49
68
9
9
34
34
143
163
43
43
16
16
32
32
5
5
14
14
112
111
45
45
39
39
92
125
16
16
65
65
270
299
8
8
1
8
8
1
7,407ns
3,249ns
135,007MHz 307,801MHz
7,066ns
3,451ns
9,046ns
4,872ns
No path found No path found
60
59
1
60
59
1
5,447ns
2,777ns
183,587MHz 360,107MHz
9,000ns
4,822ns
9,214ns
5,099ns
7,990ns
5,401ns
72
1
29
21
1
29
21
1
6,829ns
2,237ns
146,434MHz 447,117MHz
7,763ns
3,529ns
9,829ns
4,914ns
11,408ns
6,278ns
79
1
3
79
1
3
72
1
92
125
18
18
4
4
1
5
8
8
14
14
5
2
17
15
1
18
18
1
43
10
3
17
2
1
16
4
11
74
2
12
1
43
10
3
17
2
1
16
4
1
64
9
7
15
14
1
1
15
1
1
4
4
3
1
1
4
4
3
1
1
36
36
22
1
1
36
36
22
7
15
14
1
15
14
1
4,566ns
2,010ns
219,010MHz 497,401MHz
6,055ns
3,363ns
8,106ns
4,132ns
No path found No path found
16
16
46
46
1
46
46
1
10,903ns
3,976ns
91,718MHz 251,487MHz
11,552ns
5,322ns
12,092ns
5,326ns
12,223ns
6,444ns
67
66
1
1
3
3
10
1
8
1
5
1
5
1
11
2
7
7
32
4
4
10
2
2
31
4
6
2
1
32
32
5
5
14
14
1
1
16
16
4
1
1
16
16
4
1
1
10
10
3
1
1
10
10
3
1
1
19
19
26
1
1
19
19
26
37
37
1
37
37
1
13,386ns
5,168ns
74,705MHz 193,487MHz
13,198ns
5,601ns
13,622ns
6,531ns
14,072ns
6,882ns
336
1
3
11
38
1
1
27
4
3
152
19
11
33
2
1
112
15
377
1
3
11
32
1
1
28
3
2
186
20
12
33
14
1
111
15
1
1
26
26
10
1
1
26
26
10
174
9.4. Podsumowanie wykorzystania zasobów sprzętowych układów
FPGA oraz parametrów czasowe pełnego kontrolera MAC
w wersji Fast Ethernet.
Moduł
Typ układu
eth_mac
Spartan
Virtex
2s200epq208-7 2vp30ff896-7
Number of Slices
295
329
Number of Slice Flip Flops
299
298
Number of 4 input LUTs
555
610
Number used as logic
547
602
Number used as Shift registers
Number of IOs
Number of bonded IOBs
Number of GCLKs
8
8
140
140
80
80
3
3
13,386ns
5,210ns
Timing Summary
Minimum period
Maximum Frequency
74,705MHz 191,953MHz
Minimum input arrival time before clock
14,617ns
5,561ns
Maximum output required time after clock
14,257ns
6,512ns
Maximum combinational path delay
17,511ns
6,864ns
BELS
672
743
GND
1
1
INV
8
8
LUT1
11
11
LUT2
Cell Usage
91
84
LUT2_D
4
3
LUT2_L
1
3
97
109
LUT3_D
6
6
LUT3_L
2
2
294
342
LUT4_D
20
21
LUT4_L
13
13
MUXCY
58
58
MUXF5
18
34
LUT3
LUT4
1
1
299
298
FDC
60
60
FDE
12
12
FDP
2
2
Shift Registers
8
8
SRL16E
8
8
Clock Buffers
3
3
BUFGP
3
3
IO Buffers
40
40
IBUF
40
40
OBUF
36
36
VCC
FlipFlops/Latches
175
9.5. Wykorzystanie zasobów sprzętowych układów FPGA
oraz parametry czasowe modułu kontrolnego
dla wersji Gigabit Ethernet.
Moduł
Typ układu
Number of Slices
eth_control
Virtex 2vp30ff896-7
85
Number of Slice Flip Flops
116
Number of 4 input LUTs
151
Number used as logic
Number used as Shift registers
Number of IOs
26
Number of bonded IOBs
24
Number of GCLKs
1
Timing Summary
Minimum period
Maximum Frequency
Minimum input arrival time before clock
Maximum output required time after clock
Maximum combinational path delay
3,431ns
291,426MHz
3,357ns
4,521ns
No path found
Cell Usage
BELS
221
GND
1
INV
1
LUT2
10
LUT2_D
LUT2_L
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
3
1
31
3
1
90
7
LUT4_L
4
MUXCY
27
MUXF5
13
VCC
FlipFlops/Latches
1
116
FDC
63
FDE
4
FDP
2
Clock Buffers
1
BUFGP
1
IO Buffers
17
IBUF
17
OBUF
5
176
9.6. Wykorzystanie zasobów sprzętowych układów FPGA oraz parametry czasowe modułów toru RX
w wersji Gigabit Ethernet.
Moduł
Typ układu
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
Number used as logic
Number used as Shift registers
Number of IOs
Number of bonded IOBs
Number of BRAMs
Number of GCLKs
Timing Summary
Minimum period
Maximum Frequency
Minimum input arrival time before clock
Maximum output required time after clock
Maximum combinational path delay
Cell Usage
BELS
GND
INV
LUT1
LUT2
LUT2_D
LUT2_L
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
LUT4_L
MUXCY
MUXF5
VCC
FlipFlops/Latches
FDC
FDP
RAMS
RAMB16_S18_S18
RAMB16_S36_S36
Clock Buffers
BUFGP
IO Buffers
IBUF
OBUF
eth_rx_bitreceiver
eth_rx_pattern_detect
Virtex 2vp30ff896-7
Virtex 2vp30ff896-7
65
56
101
62
68
97
eth_rx_crc
Virtex 2vp30ff896-7
62
32
114
eth_rx_frame_control
Virtex 2vp30ff896-7
2
4
eth_rx_fsm
Virtex 2vp30ff896-7
9
8
16
eth_rx_pause_control
Virtex 2vp30ff896-7
49
46
89
eth_rx_fifo_control
Virtex 2vp30ff896-7
101
89
185
eth_rx
Virtex 2vp30ff896-7
316
339
582
11
10
17
13
60
57
1
1
118
118
2
2
139
139
2
2
3,481ns
287,233MHz
5,199ns
5,007ns
No path found
3,553ns
281,464MHz
4,391ns
4,150ns
5,189ns
6,217ns
160,861MHz
7,410ns
7,489ns
6,497ns
147
1
1
12
2
279
1
7
34
14
27
46
4
3
66
6
5
44
10
1
89
40
4
2
1
1
2
2
62
62
54
776
1
23
47
32
8
1
146
4
2
277
25
17
91
12
1
339
60
5
2
1
1
2
2
67
67
70
122
122
86
86
18
15
1
1
1
3,063ns
326,499MHz
3,999ns
4,336ns
5,301ns
2,925ns
341,910MHz
4,739ns
4,036ns
6,693ns
2,868ns
348,663MHz
3,451ns
8,100ns
8,634ns
No path found
No path found
No path found
5,333ns
1,757ns
569,120MHz
2,268ns
5,281ns
5,792ns
112
1
100
1
116
4
16
7
1
3
6
2
47
3
6
4
12
2
2
3
48
2
2
20
1
43
2
11
4
75
10
4
2
2
105
17
63
32
8
7
1
1
1
20
20
101
1
1
75
75
10
1
1
13
13
1
1
1
6
6
6
8
8
2
45
1
1
27
1
46
1
1
55
55
1
177
9.7. Wykorzystanie zasobów sprzętowych układów FPGA oraz parametry czasowe elementów toru TX
w wersji Gigabit Ethernet.
Moduł
Typ układu
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
Number of IOs
Number of bonded IOBs
Number of BRAMs
Number of GCLKs
Timing Summary
Minimum period
Maximum Frequency
Minimum input arrival time before clock
Maximum output required time after clock
Maximum combinational path delay
Cell Usage
BELS
GND
INV
LUT1
LUT2
LUT2_D
LUT2_L
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
LUT4_L
MUXCY
MUXF5
VCC
FlipFlops/Latches
FDC
FDP
RAMS
RAMB16_S18_S18
RAMB16_S36_S36
Clock Buffers
BUFGP
IO Buffers
IBUF
OBUF
DCMs
DCM
eth_tx_bittransmiter
Virtex 2vp30ff896-7
56
eth_tx_clk_mgmt
Virtex 2vp30ff896-7
1
1
7
6
eth_tx_crc
Virtex 2vp30ff896-7
52
32
129
79
75
eth_tx_fsm
Virtex 2vp30ff896-7
37
13
65
49
34
eth_tx_counters
Virtex 2vp30ff896-7
117
108
215
65
58
102
99
86
1
eth_tx_fifo_control
Virtex 2vp30ff896-7
119
135
188
137
122
2
2
eth_tx
Virtex 2vp30ff896-7
424
288
782
92
80
2
3
1
1
1
No path found
No path found
No path found
No path found
9,226ns
No path found
No path found
3,802ns
2,681ns
372,933MHz
6,487ns
4,090ns
No path found
2,612ns
382,826MHz
4,110ns
6,439ns
7,880ns
4,052ns
246,770MHz
4,858ns
6,489ns
7,274ns
3,356ns
297,938MHz
5,430ns
4,080ns
5,030ns
7,463ns
134,001MHz
8,290ns
9,443ns
7,075ns
119
2
1
129
71
328
1
2
12
38
289
1
7
34
12
1
992
1
11
79
102
2
5
129
9
13
355
30
47
95
26
1
288
71
5
2
1
1
2
1
60
60
18
1
1
32
4
1
24
3
4
13
1
65
1
10
74
17
76
76
10
3
3
2
1
1
7
1
11
4
34
2
6
32
5
1
13
12
1
1
1
42
42
32
1
1
25
25
8
2
78
1
2
77
2
1
51
11
1
108
10
1
1
24
24
33
40
1
5
74
2
12
44
17
1
135
49
4
2
1
1
2
2
65
65
55
178
9.8. Wykorzystanie zasobów sprzętowych układów FPGA
oraz parametrów czasowe dla całego kontrolera MAC
w wersji Gigabit Ethernet.
Moduł
Typ układu
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
eth_mac
Virtex 2vp30ff896-7
812
735
1502
Number used as logic
Number used as Shift registers
Number of IOs
242
Number of bonded IOBs
240
Number of BRAMs
4
Number of GCLKs
4
Timing Summary
Minimum period
Maximum Frequency
6,833ns
146,342MHz
Minimum input arrival time before clock
8,059ns
Maximum output required time after clock
9,489ns
Maximum combinational path delay
6,783ns
Cell Usage
BELS
BUF
1969
1
GND
1
INV
35
LUT1
126
LUT2
145
LUT2_D
LUT2_L
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
9
7
321
10
12
719
55
LUT4_L
63
MUXCY
213
MUXF5
47
VCC
1
FlipFlops/Latches
735
FDC
186
FDE
4
FDP
12
RAMS
4
RAMB16_S18_S18
2
RAMB16_S36_S36
2
Clock Buffers
3
BUFGP
2
IO Buffers
131
IBUF
131
OBUF
105
DCMs
1
DCM
1
179
9.9. Porównanie wykorzystania zasobów sprzętowych
komercyjnej wersji pamięci CAM z rozwiązaniem autorskim.
Wersja pamięci CAM 124
bity
124 x (liczba wierszy)
CAM CoreGen 6
16
32
Typ układu FPGA
64
Koncepcja autorska
128
256
16
32
2vp30ff896-7
64
128
256
8568
2vp30ff896-7
Number of Slices
675
1172
2257
4442
8792
632
1119
2180
4310
Number of Slice Flip Flops
154
174
208
273
403
147
163
195
259
387
Number of 4 input LUTs
709
1240
2312
4483
8790
622
1141
2173
4247
8393
Number used as logic
213
248
328
515
854
126
149
189
279
457
496
992
1984
3968
7936
496
992
1984
3968
7936
148
165
198
263
392
148
165
198
263
392
148
165
198
263
392
148
165
198
263
392
1
1
1
1
1
1
1
1
1
1
Number used as
Shift registers
Number of IOs
Number of bonded IOBs
Number of GCLKs
Speed Grade -7
Minimum period
6,745ns
7,193ns
7,491ns
8,125ns
9,369ns
6,745ns
7,193ns
8,239ns
8,044ns
8,044ns
Maximum Frequency
148,252
MHz
139,019
MHz
133,501
MHz
123,075
MHz
106,736
MHz
148,252
MHz
139,019
MHz
121,370
MHz
124,320
MHz
124,320
MHz
6,946ns
7,502ns
7,961ns
8,718ns
9,936ns
3,371ns
3,356ns
3,440ns
4,289ns
4,286ns
Minimum input arrival time
before clock
Maximum output required
time after clock
Maximum combinational
path delay
3,461ns
3,461ns
3,483ns
3,461ns
3,461ns
3,580ns
3,483ns
3,483ns
3,390ns
3,427ns
No path
found
No path
found
No path
found
No path
found
No path
found
No path
found
No path
found
No path
found
No path
found
No path
found
BELS
775
1314
2394
4581
8920
626
1153
2191
4281
8459
GND
1
1
1
1
1
1
1
1
1
1
2
2
2
1
1
37
33
32
35
32
1
33
3
3
7
81
152
240
417
2000
4000
8000
Cell Usage
INV
LUT2
32
32
65
319
606
LUT2_D
1
1
1
1
LUT3
3
69
4
4
4
LUT3_D
4
2
4
5
6
168
137
246
167
202
85
2
1
LUT4
LUT4_L
1
2
LUT4_D
4
7
6
19
33
MUXCY
496
1000
2000
4000
8000
496
1000
MUXF5
64
64
64
64
64
2
2
VCC
1
1
1
1
1
1
1
1
1
1
154
174
208
273
403
147
163
195
259
387
20
37
69
133
261
1
1
1
1
1
128
129
130
131
132
141
157
189
253
381
FDR
1
1
1
1
1
1
1
1
1
1
FDRE
3
6
7
7
8
FDS
1
4
4
4
4
4
FDSE
1
1
1
1
1
Shift Registers
496
992
1984
3968
7936
496
992
1984
3968
7936
SRL16E
496
992
1984
3968
7936
496
992
1984
3968
7936
Clock Buffers
1
1
1
1
1
1
1
1
1
1
BUFGP
1
1
1
1
1
1
1
1
1
1
IO Buffers
129
130
131
132
133
129
130
131
132
133
IBUF
129
130
131
132
133
129
130
131
132
133
OBUF
18
34
66
130
258
18
34
66
130
258
FlipFlops/Latches
FD
FDC
FDE
FDP
180
9.10. Wykorzystanie zasobów sprzętowych przez moduły
wchodzące w skład silnik Firewalla.
Nazwa modułu
Typ układu
Number of Slices
fw_page_mgr
2vp30ff896-7
139
fw_paresr
2vp30ff896-7
137
Number of Slice Flip Flops
169
Number of 4 input LUTs
Number used as logic
255
140
138
221
212
1984
146
146
41
40
1984
186
184
3
1
1
1
3
Number used as Shift registers
Number of IOs
Number of bonded IOBs
Number of GCLKs
fw_cache
2vp30ff896-7
2110
fw_control
2vp30ff896-7
24
fw_engine
2vp30ff896-7
2492
178
342
22
683
247
2043
59
44
2527
543
Timing Summary
Minimum period
Maximum Frequency
Minimum input arrival time before clock
Maximum output required time after clock
Maximum combinational path delay
3,083ns
3,430ns
5,251ns
1,763ns
5,251ns
324,316MHz
3,763ns
3,375ns
3,867ns
291,571MHz
4,509ns
3,514ns
No path found
190,422MHz
4,420ns
5,375ns
No path found
567,231MHz
3,193ns
3,340ns
No path found
190,422MHz
4,166ns
5,375ns
3,867ns
269
1
7
22
5
1
38
12
2
145
3
20
257
1
2049
1
4
7
45
1
10
3
2
31
2
1
2569
1
11
39
4
1
76
4
5
374
18
11
1984
39
1
683
4
310
314
9
8
1984
1984
35
17
16
2
Cell Usage
BELS
GND
INV
LUT2
LUT2_D
LUT2_L
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
LUT4_L
MUXCY
MUXF5
VCC
FlipFlops/Latches
FD
FDC
FDE
FDP
FDS
Shift Registers
SRL16E
RAMS
RAMB16_S9_S9
RAMB16_S9_S36
RAMB16_S18_S18
Clock Buffers
BUFGP
IO Buffers
IBUF
OBUF
5
1
4
14
2
2
196
13
10
12
1
169
7
1
178
123
178
16
1
18
8
1984
4
1
342
4
16
314
7
22
20
2
8
1984
1984
35
17
16
2
3
3
62
62
73
1
1
52
52
159
1
1
135
135
10
1
1
20
20
19
3
3
38
38
143
181
9.11. Porównanie wykorzystania zasobów sprzętowych
komercyjnej wersji pamięci TCAM z rozwiązaniem autorskim.
Typ pamięci TCAM
(88 bitów x 32 wiersze)
Typ układu FPGA
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
Number used as logic
Number used as Shift registers
Number of IOs
Number of bonded IOBs
Number of GCLKs
TCAM CoreGen 6
Rozwiązanie autorskie
2vp30ff896-7
1795
229
2073
665
1408
217
217
1
2vp30ff896-7
810
32
1536
832
7,668ns
130,416MHz
3,880ns
257,732MHz
Minimum input arrival time before clock
7,977ns
6,121ns
Maximum output required time after clock
3,461ns
3,293ns
No path found
No path found
2173
1
1538
1
704
Timing Summary
Minimum period
Maximum Frequency
Maximum combinational path delay
Cell Usage
BELS
GND
LUT1
LUT2
LUT2_D
LUT3
LUT3_D
LUT4
LUT4_D
MUXCY
MUXF5
VCC
FlipFlops/Latches
FD
FDE
FDR
FDRE
FDSE
Shift Registers
SRL16E
RAMS
RAM16X1S
Clock Buffers
BUFGP
IO Buffers
IBUF
OBUF
1
1
157
2
497
7
1416
90
1
229
37
181
1
9
1
1408
1408
1
1
182
182
34
153
153
1
120
8
704
1
32
32
704
704
1
1
120
120
32
182
9.12. Wykorzystanie zasobów sprzętowych przez moduły
wchodzące w skład klasyfikatora pakietów.
Nazwa modułu
Typ układu
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
address_filter
port_filter
classifier_main
2vp30ff896-7
2vp30ff896-7
2vp30ff896-7
787
1829
2771
32
32
206
1496
1856
3660
Number used as logic
792
64
1164
Number of IOs
153
103
347
Number of bonded IOBs
153
103
347
1
1
1
Number of GCLKs
Timing Summary
Minimum period
3,880ns
6,136ns
6,233ns
257,732MHz
162,973MHz
160,433MHz
Minimum input arrival time before clock
6,110ns
6,740ns
6,110ns
Maximum output required time after clock
3,293ns
3,293ns
3,293ns
Maximum combinational path delay
1,674ns
0,878ns
1,674ns
1498
84
1890
20
20
Maximum Frequency
Cell Usage
BELS
BUF
GND
1
1
LUT1
704
704
LUT2
LUT3
32
80
32
288
88
LUT4
91
LUT4_L
MUXCY
VCC
FlipFlops/Latches
1
704
704
1
32
1
32
FDC
137
FDP
FDR
206
5
32
32
64
RAMS
704
896
1601
RAM16X1S
704
RAM16X1D
704
896
RAMB16_S9_S9
896
1
Clock Buffers
1
1
BUFGP
1
1
1
1
IO Buffers
120
70
328
IBUF
120
70
328
OBUF
32
32
18
183
9.13. Wykorzystanie zasobów sprzętowych modułu
fw_policy_loader.
Nazwa modułu
Typ układu
Number of Slices
Number of Slice Flip Flops
Number of 4 input LUTs
fw_policy_loader
2vp30ff896-7
68
78
120
Number of IOs
90
Number of bonded IOBs
90
Number of GCLKs
1
Timing Summary
Minimum period
Maximum Frequency
Minimum input arrival time before clock
Maximum output required time after clock
Maximum combinational path delay
3,432ns
291,414MHz
3,975ns
3,555ns
No path found
Cell Usage
BELS
177
GND
1
INV
13
LUT1
12
LUT2
15
LUT2_D
LUT3
LUT3_D
LUT3_L
LUT4
LUT4_D
1
24
1
1
46
6
LUT4_L
1
MUXCY
22
MUXF5
9
VCC
1
FlipFlops/Latches
78
FDC
32
FDE
18
FDR
9
FDS
6
FDSE
2
RAMS
2
RAMB16_S9_S36
2
Clock Buffers
1
BUFGP
1
IO Buffers
2
IBUF
2
OBUF
87
184
9.14. Wykorzystanie zasobów sprzętowych kompletnego systemu
sprzętowego Firewalla.
Nazwa modułu:
Typ układu
Kompletny Firewall
2vp30ff896-7
Nazwa modułu:
Typ układu
Kompletny Firewall
2vp30ff896-7
Number of Slices
9164
FlipFlops/Latches
Number of Slice Flip Flops
2258
FD
11384
FDC
923
Number used as logic
4905
FDE
669
Number used as Shift registers
3983
FDP
27
Number of IOs
50
FDR
73
Number of bonded IOBs
46
FDS
22
5
FDSE
2
FDCE
363
Number of 4 input LUTs
Number of GCLKs
Timing Summary
Minimum period
Maximum Frequency
7,193ns
139,019MHz
2258
8
FDCP
12
FDPE
153
LDC_1
6
Minimum input arrival time before clock
6,028ns
Shift Registers
3983
Maximum output required time after clock
4,521ns
SRL16E
3983
Maximum combinational path delay
4,183ns
RAMS
1673
Cell Usage
BELS
10634
GND
RAM16X1S
704
RAM16X1D
896
RAMB16_S9_S9
35
1
RAMB16_S9_S36
34
INV
47
RAMB16_S18_S18
4
LUT1
716
Clock Buffers
5
LUT2
435
BUFG
LUT2_D
LUT3
21
1265
5
IO Buffers
23
IBUF
23
LUT3_D
14
IBUFG
LUT3_L
14
IOBUF
2
2282
OBUF
19
LUT4
LUT4_D
56
LUT4_L
55
MUXCY
4840
MUXF5
527
MUXF6
162
MUXF7
80
VCC
2
1
185
10. Dodatek C – zawartość płyty CD
Katalog fast_ethernet_doc – dokumentacja karty sieciowej Fast Ethernet:
fast_ethernet_cfg.pdf – rozlokowanie elementów sygnalizacyjno-konfiguracyjnych,
fast_ethernet_nic.pdf – schemat ideowy karty,
fast_ethernet_pcb.pdf – matryce poszczególnych warstw obwodu drukowanego,
fast_ethernet_phy.pdf – opis wyprowadzeń układu RTL8201BL.
Katalog gigabit_ethernet_doc – dokumentacja karty sieciowej Gigabit Ethernet:
gigabit_ethernet_cfg.pdf – rozlokowanie elementów sygnalizacyjno-konfiguracyjnych,
gigabit _ethernet_nic.pdf – schemat ideowy karty,
gigabit _ethernet_pcb.pdf – matryce poszczególnych warstw obwodu drukowanego,
gigabit _ethernet_phy.pdf – opis wyprowadzeń układu DP83865.
Katalog source_code – kod źródłowy modułów składowych sprzętowej zapory ogniowej:
podkatalog firewall_engine – pliki VHDL opisujące silnik Firewalla,
podkatalog mac_fast_ethernet – pliki VHDL opisujące kontroler MAC w wersji Fast Ethernet,
podkatalog mac_gigabit_ethernet – pliki VHDL kontrolera MAC w wersji Gigabit Ethernet,
podkatalog packets_classifier – pliki VHDL opisujące klasyfikator pakietów,
podkatalog rs232 – pliki VHDL kontrolera interfejsu RS232,
podkatalog utilities – pliki VHDL modułów dodatkowych.
186
