Badania możliwości wprowadzenia nowej struktury wewnętrznej dla kart NetFPGA

Transkrypt

1 Badania możliwości wprowadzenia nowej struktury wewnętrznej dla kart NetFPGA Marek Michalski, Tytus Sielach Politechnika Poznańska, Wydział Elektroniki i Telekomunikacji, Katedra Sieci Telekomunikacyjnych i Komputerowych ul. Polanka, Poznań, imie.nazwisko@put.poznan.pl, Streszczenie W niniejszym artykule przedstawiono skrócony opis istniejacej architektury wewnętrznej kart NetFPGA oraz typowy sposób jej wykorzystania. Przeprowadzona analiza pozwala stwierdzić, iż możliwe jest wprowadzenie zmian skutkujacych poprawa niektórych parametrów wydajnościowych kart (czas przejścia przez układ). W celu głębszej analizy skutków wprowadzonych zmian przygotowane zostanie środowisko badawcze i testowe oparte na narzędziach symulacyjnych i prototypie rozwiazania. Niniejszy artykuł skupia się na pierwszym elemencie badań, którym jest sprzętowa generacja ruchu na potrzeby badań symulacyjnych i analiza wygenerowanego strumienia ruchu pod k atem zgodności z założonymi rozkładami i wartościami parametrów. I. WPROWADZENIE Karty NetFPGA [] stanowią bardzo ciekawą platformę sprzętową do realizacji prototypów urządzeń sieci Ethernet. Z powodzeniem mogą być wykorzystywane jako realnie działające urządzenia sieci komputerowych oraz środowisko do badań naukowych. Są to karty rozszerzeń do komputerów PC, ale mogą również pracować jako niezależne węzły sieci. Ich funkcjonalność jest programowalna, a program jest wykonywany przez bardzo szybkie, programowalne układy FPGA. Karty są bardzo nowoczesnym produktem z obszaru urządzeń sieci komputerowych i z powodzeniem stanowią ekonomicznie korzystną alternatywę dla rozwiązań typowo komercyjnych. Z uwagi na dużą elastyczność są bardzo popularne w środowiskach naukowych [], stanowią podstawę badań [], dydaktyki [4], a także prac dyplomowych [5]. Istnieje wiele podobnych platform tego typu, jednak wyższością kart NetFPGA jest bardzo prężne i otwarte środowisko ich twórców i deweloperów projektów, które aktywnie wspiera mniej zaawansowanych użytkowników. Dotychczas opracowane zostały karty z interfejsami o przepustowości Gbps oraz Gbps, trwają prace nad kolejnymi, szybszymi, wersjami. W niniejszym artykule przedstawimy istniejące karty (rozdział II), sposób ich wykorzystania (rozdział III), a przede wszystkim zaproponujemy modyfikację istniejącej struktury wewnętrznej (rozdział IV) i przeanalizujemy proponowane zmiany (rozdział V). Artykuł traktuje głównie o jednym z pierwszych elementów badań nowej struktury, którym jest generator ruchu wykorzystywany do badań symulacyjnych realizowanych sprzętowo (rozdział VI). Artykuł kończą podsumowania i wnioski. Rysunek. Karta NetFPGA z elektrycznymi interfejsami sieciowymi RJ45 o przepustowości Gbps II. OPIS KART NETFPGA G I G Karta NetFPGA jest produktem końcowym projektu Net- FPGA.org []. Został on założony przez grupę naukowców ze Stanford University [6] pod kierownictwem prof. Nicka McKeowna [7]. Aktualnie projekt jest prowadzony wspólnie z analogiczną grupą z University of Cambridge [8] pod kierownictwem Andrew W. Moore a [9]. Wszelkie informacje są dostępne na stronie projektu [], są organizowane liczne wydarzenia promujące efekty prac grupy [], ostatnio, w maju, w Poznaniu odbyły się pięciodniowe warsztaty z programowania tych kart []. Na początku opracowana i udostępniona została karta Net- FPGA z portami o przepustowości Gbps (przedstawiona na rys. ) [], od niedawna dostępna jest nowsza wersja z portami o przepustowości G (rys. ). Aktualnie dostępne i szeroko używane są obie wersje kart NetFPGA. Obie są bardzo podobne, w przypadku każdej z nich mamy do czynienia z kartą rozszerzeń PC. Każda ma 4 porty ethernetowe, jednak, jak sugerują nazwy, mają porty o różnej maksymalnej przepustowości. W przypadku karty G do dyspozycji są cztery porty elektryczne (RJ45), natomiast w przypadku karty G dostępne są 4 gniazda na wkładki SFP+. Różne są też magistrale, którymi łączą sięzpc-sąto odpowiednio PCI oraz PCIe. Ich wewnętrzna budowa, na pewnym poziomie abstrakcji, jest bardzo podobna. Aktualnie ukończone są prace 48 XVIII Poznańskie Warsztaty Telekomunikacyjne - Poznań, grudnia 4

2 Rysunek. Karta NetFPGA z uniwersalnymi interfejsami sieciowymi SFP+ o przepustowości Gbps nad kartą z interfejsami o przepustowościach Gbps oraz Gbps [], będzie ona dostępna od grudnia 4 []. Karta G jest produkowana przez firmę Digilient [4], natomiast karta z portami G jest dostępna w ofercie firmy Hightech Global [5]. Obie wersje są osiągalne jako darowizny w ramach Xilinx University Program [6], którego nasza katedra jest beneficjentem - otrzymaliśmy pięć egzemplarzy karty z interfejsami G. Aktualnie nasza laboratoryjna sieć kart NetFPGA [7] składa się z kart G i pięciu kart G oraz wielu dodatkowych urządzeń sieciowych, które umożliwiają im funkcjonowanie oraz tworzenie elastycznych topologii i wykorzystanie różnorodnych mechanizmów sieciowych. Platforma sprzętowa to jedno, równie istotne jest oprogramowanie tych kart, szczególnie, że praktycznie pełną funkcjonalność kart należy samemu zaprogramować. Na szczęście można skorzystać z udostępnionych przykładowych projektów referencyjnych. Są one dostępne zarówno jako kody źródłowe, jak i gotowe do uruchomienia pliki. Do kompilacji kodu źródłowego konieczne jest posiadanie rozbudowanego środowiska uruchomieniowego firmy Xilinx [8], pełne informacje o wymaganiach i sposobie konfiguracji dostępne są na stronie projektu []. Zaprogramowanie karty NetFPGA to jeden z kroków koniecznych do jej wykorzystania. Karta może pracować samodzielnie, jednak aby mogła ona współdziałać z systemem operacyjnym komputera, należy zainstalować w nim odpowiedni sterownik. Jego kody źródłowe dostępne są w standardowym zestawie oprogramowania dla kart NetFPGA, należy go skompilować i uruchomić według dostarczonej procedury. Po poprawnym wykonaniu wszystkich wymaganych czynności interfejsy karty są widoczne w systemie jak standardowe interfejsy sieciowe, natomiast oprogramowanie do samej karty może być wgrane w zależności od wersji karty: w przypadku karty G - przez systemową magistralę PCI i dostarczony program (nf_download) lub w przypadku kart G - przez zewnętrzny programator USB i narzędzie z pakietu oprogramowania firmy Xilinx - program Impact. Poprawnie uruchomiona karta może być wykorzystywana jak zwykła karta sieciowa lub należy dla niej przygotować dodatkowe oprogramowanie, które jest specyficzne i zależne od realizowanych funkcjonalności. III. PRZEPŁYW DANYCH W ŚRODOWISKU NETFPGA Ramki ethernetowe odbierane są z fizycznych portów przez odpowiednie układy i umieszczane w postaci ciągu bitów w buforach wejściowych. Każdy port posiada swój bufor (na rysunku oznaczone są jasnozielonym kolorem, na rysunku 4 dodatkowo podpisane są jako - ). Dane z ramek dzielone są na słowa o stałej długości, 64 bitowe słowa występują w całym projekcie karty NetFPGA G, natomiast w przypadku karty G długość słowa to 56 bitów. Należy zwrócić uwagę, że ramki wysyłane przez procesor do sieci, zanim przejdą przez kartę, są traktowane jak ramki do niej przychodzące isą umieszczane w jej buforach wejściowych powiązanych z procesorem. Te bufory zaznaczono na rysunku kolorem jasnoniebieskim, natomiast na rysunku 4 dodatkowo podpisano jako. Tym oto sposobem do karty wchodzi 8 strumieni danych, po cztery od strony portów fizycznych i po cztery od strony procesora. Z punktu widzenia przetwarzania danych są one równorzędne i mogą być traktowane jednorodnie lub unikatowo w zależności od zamierzeń programisty. Analogiczna sytuacja ma miejsce z buforami wyjściowymi - jeśli ramka ma być wysłana na port fizyczny - jest umieszczana w buforze wyjściowym powiązanym z odpowiednim portem (ciemnozielony port ), jeśli natomiast ma trafić do systemu operacyjnego - jest umieszczana w kolejce oznaczonej kolorem ciemnoniebieskim (). Jak łatwo zauważyć, na rysunkach przyjęto konwencję, że bufory związane z portami fizycznymi są oznaczone kolorem zielonym, natomiast do procesora - niebieskim. Bufory na wejściu do karty oznaczono jasnym odcieniem odpowiedniego koloru, natomiast na wyjściu - ciemnym kolorem. Takie dodatkowe oznaczenie ułatwia studentom szybkie i intuicyjne odnalezienie się wśrodowisku karty NetFPGA. A. Obsługa ramki ethernetowej niosacej zapytanie ARP przez system z karta sieciowa NetFPGA Poniżej zostanie przeanalizowana procedura obsługi zapytania protokołu ARP w celu przedstawienia typowego sposobu obsługi ramki ethernetowej w karcie NetFPGA. Załóżmy, że do karty jest wgrane oprogramowanie, które czyni z niej typową kartę sieciową. Załóżmy również, że ramka niosąca zapytanie ARP została odebrana na porcie eth. Zostanie więc ona umieszczona w buforze na wejściu do karty (jasnozielony). Następnie moduł Input Arbiter w odpowiednim momencie wybierze z kolejki wejściowej tę ramkę do obsługi i przekaże ją domodułu Użytkownika i dalej do Output Port Lookup. Głównym zadaniem modułów w obrębie karty NetFP- GA jest przekazanie ramek na odpowiednie porty wyjściowe, przekazanie takie odbywa się przez ustawienie odpowiednich zmiennych sterujących oznaczających bufor wyjściowy. Na podstawie tych danych kolejny moduł (Output Queues) umieści ramkę w odpowiednim buforze wyjściowym. W tym przypadku funkcjonalność protokołu ARP wymusza przekazanie tej ramki do systemu operacyjnego przez interfejs nf, dlatego też ramka ta zostanie umieszczona w ciemnoniebieskim buforze na wyjściu, czyli w kolejce do nf (). W tym momencie ramkę przejmuje system operacyjny i odpowiedni proces XVIII Poznańskie Warsztaty Telekomunikacyjne - Poznań, grudnia 4 49

3 eth eth eth eth Input Arbiter Moduł użytkownika Output Port Lookup Output Queues Input Arbiter - wybór obsługiwanej kolejki wejściowej Moduł użytkownika (dodany) Output Port Lookup ustalenie kolejki wyjściowej NetFPGA FPGA chip PCI/PCIe driver Output Queues - Rozdział na kolejki wyjściowe Operating System nf nf nf nf Rysunek. Najważniejsze elementy budowy karty NetFPGA Rysunek 4. NetFPGA Dotychczasowy sposób organizacji przepływu danych w kartach sieciowy (o ile taki jest uruchomiony na danym komputerze) przeanalizuje zapytanie ARP i odpowiednio na nie zareaguje. Załóżmy, że analizowana ramka niesie zapytanie o adres naszego komputera, więc, zgodnie z funkcjonalnością ARP, ten komputer odpowie na nią odpowiednim komunikatem ARP. Ten komunikat zostanie wygenerowany przez proces sieciowy w systemie operacyjnym i wysłany przez port nf do sieci. Wysłanie ramki przez interfejs nf polega na umieszczeniu jej w buforze wejściowym do karty NetFPGA, w tym przypadku ramka do karty przychodzi od strony procesora (przez interfejs obecny w systemie operacyjnym), czyli będzie umieszczona w jasnoniebieskim (wejściowym) buforze oznaczonym jako. Moduł Input Arbiter odbierze tę ramkę, a kolejne moduły zadecydują o przesłaniu jej na port wyjściowy eth, czyli umieszczą ją w ciemnozielonej kolejce wyjściowej, stamtąd odpowiednie mechanizmy ją odczytająiwyślą do łącza przez port eth. Obsługa ramek (podstawowa wersja) w głównej kości FPGA karty NetFPGA polega na przyjęciu ramki do kolejki na wejściu, zadecydowaniu o przeznaczeniu danej ramki, odpowiednim jego oznaczeniu i umieszczeniu ramki w odpowiedniej kolejce wyjściowej. Powyższy przykład przedstawił obsługę ramki przy współudziale procesora komputera i systemu operacyjnego, taka ramka przeszła przez kartę dwa razy. O wiele ciekawsza jest sytuacja, gdy do obsługi ramki wystarczy funkcjonalność zakodowana w kości FPGA i nie jest konieczna interakcja z systemem operacyjnym. Gdy karta samodzielnie obsługuje ruch, wydajność przetwarzania danych jest o wiele wyższa, gdyż pomijane jest dwukrotne przejście danych przez magistralę i obsługa przez procesor. IV. NOWE PODEJŚCIE DO PRZETWARZANIA DANYCH A. Słabości dotychczasowego rozwiazania W dotychczasowym podejściu do obsługi ramek w głównym module projektu, zaproponowanym we wszystkich projektach referencyjnych, wykorzystywany jest moduł, który w danym momencie wybiera jedną ramkę spośród oczekujących i przekazuje ją do obsługi przez jeden, wspólnie wykorzystywany pipeline. Dzięki wewnętrznemu przyspieszeniu nie ma problemu z obsługą ruchu z ośmiu kolejek wejściowych przez pojedyncze moduły i układy funkcyjne. Każdy moduł analizuje nagłówek i po zakończeniu jego analizy przetwarza (zazwyczaj transmituje przezroczyście) dalszą część ramki. Takie podejście wymusza na kolejnych ramkach oczekiwanie na pełne zakończenie obsługi poprzedniej ramki. Powoduje to pewne opóźnienia, których można uniknąć poprzez reorganizację procesu przetwarzania danych. Pierwotne podejście do każdej ramki sprowadza się do rozbicia funkcji analizy nagłówka ramki i jej transmisji do dwóch grup stanów FSM, które są realizowane w tej samej maszynie, czyli system albo analizuje nagłówek, albo przesyła część danych, tzn, w danym momencie wykonywana jest tylko jedna z tych funkcjonalności. Oznacza to, że w danym momencie obsługiwana jest tylko jedna ramka przez jedną z dwóch funkcjonalności. B. Założenia nowej struktury wewnętrznej Przeanalizowaliśmy charakterystykę czasową oraz wzajemne umiejscowienie w czasie poszczególnych operacji (operacje te to analiza nagłówka w celu wybrania portu wyjściowego () i transmisja ramki przez moduł()) wykonywanych podczas obsługi wielu ramek przez układ wykorzystujący dotychczasowąinową architekturę. Zakładamy, że w najgorszym przypadku wszystkie bufory wejściowe oczekują, że ich ramka będzie 5 XVIII Poznańskie Warsztaty Telekomunikacyjne - Poznań, grudnia 4

4 przesłana do bufora wyjściowego. Na rys. 6 schematycznie przedstawiono cztery ramki dostępne w buforach wejściowych i oczekujące na ich transmisję do buforów wyjściowych. Dotychczasowe podejście zakłada pełną obsługę ramek z kolejno wybieranych buforów (sposób podejmowania decyzji nie jest istotny dla prezentowanych tutaj rozważań), tzn. przed przejściem do kolejnej ramki, poprzednia ramka musi opuścić moduł. Uproszczoną charakterystykę takiej sytuacji przedstawiono na rys. 7, gdzie wyraźnie widać, że transmisja kolejnej ramki następuje dopiero po całkowitej obsłudze ramki poprzedniej. Innymi słowy, układ obsługuje nagłówek albo pola danych, ale nigdy nie robi tego jednocześnie. Biorąc pod uwagę działanie układu, poszczególne bloki są wykorzystywane naprzemiennie. Doszliśmy do wniosku, że gdyby można było wykonywać te operacje jednocześnie, to cała kolejna ramka nie musiałaby czekać na obsługę do czasu zakończenia obsługi poprzedniej (tak jak to jest pokazane na rysunku 7). Sprowadza się to do tego,że gdy funkcjonalność związana z analizą nagłówka już podejmie decyzję o sposobie transmisji ramki, może wykorzystać te informacje jako sygnały sterujące polem komutacyjnym, uruchomić transmisję ramki w taki sposób, że nie blokuje ona analizy nagłówka kolejnej ramki i co najważniejsze - przejść do analizy kolejnej ramki. Dzięki temu analiza nagłówka może odbywaćsię podczas transmisji ramek, których nagłówki już zostały przeanalizowane. Takie podejście może być zrealizowane w strukturze z rysunku 5. Funkcjonalność analizy działa przez krótki czas, a następnie aktywowana jest funkcjonalność transmisji ramki do odpowiedniego bufora wyjściowego. Zaraz po zakończeniu analizy jednej ramki (i rozpoczęciu jej transmisji przez pole), układ sterujący może przejść do analizy nagłówka kolejnej ramki (jednocześnie realizując transmisji ramek już przeanalizowanych). Oznacza to, że może odbywać się jednoczesna transmisja do 8 ramek. Charakterystyka czasowa takiej realizacji obsługi danych przedstawiona jest na rys. 8. Od razu widać znaczne skrócenie czasu całkowitego przetwarzania, czyli czasu, który upływa od momentu pojawienia się ramek w buforach wejściowych do momentu ich pojawienia się w buforach wyjściowych. Rysunek 5. Rysunek 6. Zmodyfikowany moduł sterowania Nieblokowalne pole komutacyjne 8x8 Nowa struktura przetwarzania danych w kartach NetFPGA Cykle poświęcone na nagłówek Cykle poświęcone na ładunek Cztery ramki jednocześnie dostępne na wejściu do układu C. Wady i zalety nowej struktury wewnętrznej Proponowane zmiany powodują zauważalny wzrost skomplikowania projektu i zaburzają dotychczasowe podejście zakładające niezależność modułów. W przypadku niektórych projektów może to być utrudnieniem i zmuszać projektanta do realizacji kilku dodatkowych funkcjonalności lub zaplanowana funkcjonalność będzie musiała uwzględnić zrównoleglenie realizowane w module sterującym. Modyfikacje te można potraktować jako realizację kilku funkcjonalności w jednym, bardziej rozbudowanym, module, który efektywniej realizuje zadania osobnych i niezależnych modułów. Dzięki temu uzyskujemy możliwość o wiele bardziej efektywnego wykorzystania przepustowości układu i jednoczesnej transmisji kilku ramek, co znacznie skróci całkowity czas ich obsługi. Należy zwrócić uwagę, że nie wzrośnie przepustowość, lecz jedynie spadnie czas przebywania poszczególnych Rysunek 7. Czasowa charakterystyka obsługi czterech ramek wg pierwotnej architektury przez pojedynczy pipeline Rysunek 8. Czasowa charakterystyka obsługi czterech ramek wg nowej architektury przez zrównoleglony pipeline XVIII Poznańskie Warsztaty Telekomunikacyjne - Poznań, grudnia 4 5

5 Rysunek 9. Rozkład równomierny ramek w układzie, co ma bezpośrednie przełożenie na opóźnienie ich transmisji. Należy również zwrócić uwagę, że układ sterujący, mimo, że steruje nieblokowalnym polem komutacyjnym (tzn. takim, które może zrealizować dowolne połączenie między wolnym wejściem i wolnym wyjściem), poprzez odpowiednie planowanie i wykorzystanie poszczególnych kierunków transmisji (np. poprzez chwilowe jej wstrzymanie) musi rozwiązać ewentualny konflikt w dostępnie do wyjścia, czyli nie może dopuścić do sytuacji, gdy do jednego bufora wyjściowego jednocześnie będzie transmitowana ramka z więcej niż z jednego bufora wejściowego. Ten problem jest znany pod pojęciem blokady zewnętrznej, jej głębsza analiza wykracza poza zakres tego artykułu, ale jest brana pod uwagę podczas projektowania układu sterującego. Rysunek. LFSR V. SYMULACJA Do przeprowadzenia analizy możliwości proponowanej architektury i porównania jej z istniejącą przewidziano badania symulacyjne. W celu jak najszybszego jej wykonania zostanie ona zrealizowana na układzie FPGA. W ten sposób przetwarzanie danych w symulacji zostanie maksymalnie zrównoleglone. Podstawowym elementem każdej symulacji są generatory liczb pseudolosowych. W naszym przypadku będzie potrzebny generator pseudolosowy o równomiernym rozkładzie prawdopodobieństwa (w celu wyznaczania długości pakietu) oraz generator o rozkładzie wykładniczym, w celu wyznaczania czasu pomiędzy nadejściem kolejnych pakietów. Dla sprawnego działania symulatora generatory powinny być zdolne podawania nowych liczb pseudolosowych co takt zegara systemowego. A. Generator o rozkładzie równomiernym Został utworzony moduł zawierający rejestr przesuwny LFSR o długości 8 bitów bazujący na wielomianie pierwotnym. Pobierane są z niego najmniej znaczące bity jako liczba pseudo losowa. Przeprowadzono badanie generatora na 4 wygenerowanych liczb, uzyskano histogram odpowiadający równomiernemu rozkładowi prawdopodobieństwa przedstawionym na rysunku 9. Niestety, tak tworzone kolejne liczby pseudolosowe są skorelowane ze sobą. Im większa odległość pomiędzy liczbami tym ich powiązanie ze sobą mniejsze. Dlatego w celu uzyskania dobrych właściwości losowych należy pobierać, na przykład, co wygenerowaną liczbę. W tym przypadku należałoby czekać cykle zegara, a to zbyt długo. Czas ten można skrócić przez wykorzystanie odpowiednich funkcji logicznych. 5 XVIII Poznańskie Warsztaty Telekomunikacyjne - Poznań, grudnia 4

6 opóźnienie ich transmisji. Do zweryfikowania założeń przygotowane zostanie środowisko badawcze oparte na sprzętowej symulacji. Artykuł opisuje wykorzystany sprzętowy generator liczb losowych. Dalsze badania będą weryfikowały pochodne tego generatora oraz pozostałe elementy systemu. Należy zwrócić uwagę, że proponowana modyfikacja nie podniesie przepustowości układu, lecz zmniejszy opóźnienia przejścia transmitowanych ramek. Rysunek. Odwrócony rozkład wykładniczy B. Generator o rozkładzie wykładniczym Architektura układu FPGA znacząco ułatwia utworzenie generatora pseudolosowego o rozkładzie równomiernym, lecz utworzenie generatora o rozkładzie wykładniczym jest znacznie trudniejszą kwestią. Generowanie liczb losowych o rozkładzie wykładniczym bazuje na rozkładzie równomiernym [9] oraz funkcji logarytmicznej : U = ln( x)/λ, () która jest bardzo trudna do zaimplementowania w logice układu FPGA. Wymaga ona również dużych zasobów sprzętowych, szczególnie jeśli ma być wykonywana szybko (maksymalnie kilka cykli zegara). Wyjątkiem jest logarytm o podstawie. W związku z tym, w celu sprawdzenia możliwości takiego układu, zastosowano zmodyfikowany wzór : U = log (x). () Pozwoliło to uzyskać ciąg liczb, którego histogram prezentowany jest na rysunku. VI. PODSUMOWANIE W niniejszym artykule przedstawiono propozycję zmian istniejącej architektury wewnętrznej karty NetFPGA. Taka zmiana pozwoli skrócić czas oczekiwania ramek w układzie na ich analizę i przetwarzanie, co przełoży się na mniejsze VII. PODZIEKOWANIA Projekt został sfinansowany z dotacji Ministerstwa Nauki i Szkolnictwa Wyższego na rok 4. LITERATURA [] Główna strona projektu NetFPGA [] Podstrona z aktualną listą publikacji związanych z kartami NetFPGA: [] M. Michalski: "The System for Delay Measurement in Ethernet Networks on NetFPGA Cards", IEEE 5th International Conference on High Performance Switching and Routing, Vancouver, Canada, -4 czerwca 4. [4] M. Michalski: "Karty NetFPGA w procesie dydaktycznym", Poznańskie Warsztaty Telekomunikacyjne, Poznań, grudnia. [5] Tytus Sielach, Praca dyplomowa magisterska pt. "OpenFlow Switch with xdpd on NetFPGA card", Politechnika Poznańska, Wydział Elektroniki i Telekomunikacji, Poznań 4. [6] Strona informacyjna grupy NetFPGA [7] Strona informacyjna - Nick McKeown [8] Główna strona www Computer Laboratory, Faculty of Computer Science and Technology, University of Cambridge [9] Strona informacyjna - Andrew W. Moore [] Wydarzenia w ramach projektu NetFPGA [] Strona informacyja warsztatów NetFPGA [] Glen Gibb, John W. Lockwood, Jad Naous, Paul Hartke, and Nick McKeown NetFPGA Open Platform for Teaching How to Build Gigabitrate Network Switches and Routers IEEE Trans. on Education, 8. [] Zilberman, N., Audzevich, Y., Covington, A., Moore, A.W.. "NetFPGA SUME: Toward Research Commodity Gb/s", IEEE Micro, Sep-Oct 4. [4] Strona produktu NetFPGA G Detail.cfm?Prod=NETFPGA. [5] Strona produktu NetFPGA G PCIExpress_SFP+.htm. [6] Xilinx University Program [7] Strona projektu Środowisko testowe protokołów sieciowych na bazie systemu OpenFlow [8] Główna strona www firmy Xilinx [9] robert/miss/w.pdf (dostęp 4..4) XVIII Poznańskie Warsztaty Telekomunikacyjne - Poznań, grudnia 4 5