Sistema Basado en Hardware Reconfigurable para el Filtrado de Contenidos en Proveedores de Servicio...

Universidad Autonoma de Madrid

Escuela Politecnica Superior

Sistema Basado en Hardware Reconfigurablepara el Filtrado de Contenidos en Proveedores

de Servicio de Internet

Jaime J. Garnica

Trabajo Final de Master

Master en Ingenierıa Informatica y de las Telecomunicaciones

20 de septiembre de 2012

Agradecimientos

A mi tutor

Mi mas sincero agradecimiento a Sergio Lopez Buedo por haberme aco-gido como tutor, tanto en la realizacion de este trabajo como en los ultimostres anos en el grupo de investigacion HPCN. De el he aprendido en granparte lo que me define laboralmente hoy en dıa.

A mis colaboradores

Un agradecimiento especial a Victor Lopez Alvarez, que me acompano du-rante la realizacion del proyecto y me ayudo con su experiencia.

Agradezco la colaboracion directa en este trabajo a Jorge Lopez de Verga-ra, Francisco Javier Gomez Arribas, Javier Aracil, Gustavo Sutter y AlvaroJimenez.

A mis companeros, familia y amigos

Agradezco a la gente del laboratorio C-113 el haber sido tan buenos com-paneros, de los que he aprendido mas de lo que podıa esperar. En especiala Francisco Javier Ramos, Victor Moreno, Dr. Felipe Mata, Dr. Jose LuisGarcıa, Pedro Santiago, David Madrigal y David Muelas. Tambien agradecera antiguos companeros como Jaime Fullaondo, Jose Luis Anamuro, RubenNieto y Diego Sanchez. Y por ultimo, a los nuevos integrantes que se hanincorporado este ano.

Finalmente, agradecer a mi familia y amigos que han sido los responsablesde entretenerme en los dıas y momentos de descanso.

Jaime J. Garnica

Indice

1. Introduccion 6

2. Objetivos 72.1. Objetivos de la solucion hıbrida . . . . . . . . . . . . . . . . . 82.2. Objetivos del sistema software . . . . . . . . . . . . . . . . . . 92.3. Objetivos del sistema hardware . . . . . . . . . . . . . . . . . 92.4. Objetivo HLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Estado del arte 113.1. Sistemas de filtrado . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Aplicaciones de seguridad de red en FPGA . . . . . . . . . . . 123.3. Lenguajes de alto nivel para sıntesis hardware . . . . . . . . . 13

4. Analisis de requisitos 144.1. Sistema portable y escalable . . . . . . . . . . . . . . . . . . . 144.2. Filtrado de paquetes a 10Gbps incluso paquetes pequenos . . . 154.3. Actualizacion dinamica de direcciones IP . . . . . . . . . . . . 154.4. Integracion en una plataforma PC de proposito general . . . . 164.5. Proporcionar un interfaz conocido al software . . . . . . . . . 16

5. Entornos de desarrollo 175.1. Plataforma basica . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1.1. Especificaciones . . . . . . . . . . . . . . . . . . . . . . 175.1.2. Firmware INVEA Tech . . . . . . . . . . . . . . . . . . 205.1.3. Escenario tıpico . . . . . . . . . . . . . . . . . . . . . . 21

5.2. Plataforma avanzada . . . . . . . . . . . . . . . . . . . . . . . 225.2.1. Especificaciones . . . . . . . . . . . . . . . . . . . . . . 225.2.2. Escenario tıpico . . . . . . . . . . . . . . . . . . . . . . 23

5.3. Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3.1. Lenguajes RTL . . . . . . . . . . . . . . . . . . . . . . 245.3.2. Simulacion de modulos . . . . . . . . . . . . . . . . . . 245.3.3. Validacion en placa . . . . . . . . . . . . . . . . . . . . 245.3.4. Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3.5. Lenguajes HLS . . . . . . . . . . . . . . . . . . . . . . 25

6. Arquitectura FPGA 266.1. Perifericos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.1. PCI-Express . . . . . . . . . . . . . . . . . . . . . . . . 276.1.2. Memorias QDR-II . . . . . . . . . . . . . . . . . . . . . 28

2


6.1.3. Interfaces 10GbE . . . . . . . . . . . . . . . . . . . . . 296.2. Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.3.1. Protocolo Local Bus . . . . . . . . . . . . . . . . . . . 336.3.2. Direccionamiento y funciones hash . . . . . . . . . . . 346.3.3. Protocolo FrameLink . . . . . . . . . . . . . . . . . . . 356.3.4. Flujo de paquetes . . . . . . . . . . . . . . . . . . . . . 366.3.5. MIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.3.6. Actualizacion y busqueda de reglas . . . . . . . . . . . 39

6.4. Proceso de filtrado . . . . . . . . . . . . . . . . . . . . . . . . 406.4.1. Parseo de tramas . . . . . . . . . . . . . . . . . . . . . 426.4.2. Busqueda de reglas . . . . . . . . . . . . . . . . . . . . 436.4.3. Filtrado de tramas al software . . . . . . . . . . . . . . 43

6.5. Actualizacion y gestion desde el software . . . . . . . . . . . . 436.5.1. Escritura de reglas en memoria . . . . . . . . . . . . . 446.5.2. Registros de control . . . . . . . . . . . . . . . . . . . . 45

6.6. Acceso a memorias . . . . . . . . . . . . . . . . . . . . . . . . 456.7. Integracion de modulos en pipeline . . . . . . . . . . . . . . . 46

7. Implementacion 477.1. Arquitectura basica . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1.1. Aplicacion de filtrado . . . . . . . . . . . . . . . . . . . 477.1.2. Acceso a memorias . . . . . . . . . . . . . . . . . . . . 487.1.3. Comunicacion con el host . . . . . . . . . . . . . . . . 49

7.2. Integracion hardware - software . . . . . . . . . . . . . . . . . 507.2.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.3. Plataforma avanzada . . . . . . . . . . . . . . . . . . . . . . . 517.4. Lenguajes HLS . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.4.1. HandelC . . . . . . . . . . . . . . . . . . . . . . . . . . 527.4.2. AutoESL . . . . . . . . . . . . . . . . . . . . . . . . . 53

8. Validacion hardware 548.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . 558.2. Pruebas de integracion . . . . . . . . . . . . . . . . . . . . . . 558.3. Validacion en tiempo real . . . . . . . . . . . . . . . . . . . . 58

8.3.1. Integracion 64b - 32b . . . . . . . . . . . . . . . . . . . 59

9. Resultados 619.1. Frecuencias de reloj . . . . . . . . . . . . . . . . . . . . . . . . 619.2. Consumo de recursos . . . . . . . . . . . . . . . . . . . . . . . 619.3. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3

Jaime J. Garnica

9.4. Entorno OPTENET . . . . . . . . . . . . . . . . . . . . . . . 639.4.1. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . 659.4.2. Pruebas de rendimiento . . . . . . . . . . . . . . . . . 65

9.5. Lenguajes HLS . . . . . . . . . . . . . . . . . . . . . . . . . . 66

10.Conclusiones y trabajo futuro 6810.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6810.2. Publicaciones resultantes . . . . . . . . . . . . . . . . . . . . . 6910.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.3.1. Ampliacion de funcionalidad . . . . . . . . . . . . . . . 6910.3.2. Comunicacion DMA a 10Gbps . . . . . . . . . . . . . . 7010.3.3. Filtrado en redes 100GbE . . . . . . . . . . . . . . . . 7010.3.4. Framework de alto nivel . . . . . . . . . . . . . . . . . 71

4

Jaime J. Garnica

1. Introduccion

En la actualidad, la deteccion y clasificacion de trafico es un area deimportancia estrategica desde varios puntos de vista como son la seguridad,la proteccion y la operacion de red. En el marco de la proteccion, la detecciony clasificacion de trafico ayuda al filtrado por contenidos. Con ello es posibletanto proteger a determinados colectivos de contenidos no apropiados talescomo violencia, pedofilia, discriminacion, apologıa de actos criminales, sexo,etcetera; como de realizar un control, parental o empresarial, en las redespara aquellos usuarios o administradores de las mismas que ası lo deseen.

Sin embargo, resulta crıtico contar con la velocidad de proceso suficienteen el equipo que realiza el filtrado. De hecho, las redes actuales estan es-calando rapidamente a velocidades de hasta 40 Gbps y 100Gbps [12]. Porello, las soluciones basadas en PCs de proposito general o similares [9, 8, 16]no sirven en este tipo de escenarios. Se hace necesario el uso de hardwareespecıfico con el paralelismo suficiente para hacer que el tiempo de filtradose reduzca al mınimo imprescindible [26, 6, 25]. Dentro de estas solucionesse encuentran los chips basados en FPGA (Field Programmable Gate Array)que, debido a su caracter reprogramable, permiten el desarrollo flexible dediferentes soluciones para diferentes escenarios y la actualizacion de las mis-mas. El estado del arte de esta tecnologıa a las tasas requeridas es amplio, ymuchos son los puntos de partida que se plantean en el mundo de las redesde comunicacion y la clasificacion de paquetes.

Es, en el marco descrito, en el que se centra este trabajo, implementando yevaluando una solucion basada en FPGA para el filtrado de direcciones IP quepermita, a diferentes aplicaciones software, llevar a cabo un filtrado basadoen contenidos de los paquetes de red. De este modo, nos encontramos con unasolucion hıbrida de hardware y software. Dentro de esta solucion cada uno delos dos sistemas cumple una funcion especıfica, donde el hardware realiza unprimer filtrado a nivel de red basandose en las especificaciones que el softwarele determine. Aligerando su carga de procesamiento de forma considerable (entorno al 90 %), permite al software realizar el filtrado a nivel de contenidos, deestos paquetes que han sido advertidos en una primera instancia por el filtrohardware. El resto de los paquetes de red, es decir, aquellos que el hardwareno ha considerado sospechosos, no llegaran al sistema software, sino que seranreenviados a la red de forma transparente.

Por otra parte, dentro del campo de los lenguajes RTL y los sistemasbasados en hardware programable, encontramos los llamados lenguajes delalto nivel para sıntesis hardware (HLS, High Level Synthesis). Estos lengua-jes y sus herramientas estan tomando una gran importancia, especialmenteen el mundo de las FPGAs. Esto se debe a su abstraccion de alto nivel para

6


sintetizar codigo RTL, evitando la necesidad de expertos en lenguajes de des-cripcion de hardware tales como VHDL y Verilog. Estas herramientas, de lasque se habla estan basadas en lenguajes de proposito general como C, C++o Java, acercando a programadores menos experimentados a la posibilidadde realizar disenos a medida sin implicar un gran tiempo de adaptacion oaprendizaje al entorno hardware.

2. Objetivos

El objetivo principal del proyecto es el desarrollo de un sistema colabo-rativo hardware-software para filtrado por contenidos en redes Ethernet dealtas tasas como se presenta en la Figura 1. El objetivo del sistema hardwaresera realizar un filtrado basado en las direcciones IP de los datagramas IP,mientras que el software sera el encargado de realizar un segundo filtrado,definitivo, de dichos paquetes, basandose en sus contenidos. Ambos sistemasdeben estar en comunicacion, siendo el software el que indica las direccionespotencialmente filtrables, y siendo el hardware el que redirige los paquetespotencialmente filtrables al software. Este desarrollo se plantea en el entronode las redes 10GbE (10 Gigabit Ethernet), donde las tasas de paquetes porsegundo alcanzan los 14,9 millones (Mpps) [11].

Sistema de filtrado

Red a 10

Gbps Enlace a filtrar 10 Gbps

Tarjeta FPGA

SW

filtrado

Trafico filtrado 10 Gbps

Figura 1: Esquema general de la solucion

El objetivo secundario es el estudio y evaluacion del empleo de lenguajesHLS con FPGA. Mediante el desarrollo con lenguajes HLS de algunos modu-los que ya se han creado y probado en VHDL se podra realizar una primeraobservacion y quizas evaluacion del empleo de estos lenguajes HLS frente alos lenguajes RTL.

7

Jaime J. Garnica

Los objetivos generales del trabajo se pueden enumerar de la siguientemanera:

Estudio, analisis y diseno de una solucion hardware-software para fil-trado por contenidos en redes 10GbE.

Desarrollo e integracion de un sistema hardware de filtrado basadoen direcciones IP que reduzca la carga de procesamiento del sistemasoftware en redes 10GbE.

Estudio y evaluacion de los lenguajes de alto nivel para sıntesis dehardware con el fin de determinar si estos son un buen camino a seguir.

2.1. Objetivos de la solucion hıbrida

El motivo de emplear un sistema hıbrido es aprovechar la flexibilidadque ofrece el software y el rendimiento del hardware. Gracias al primero,las diferentes paginas web podran ser analizadas a nivel de contenidos y sepodra, a su vez, buscar en diferentes bases de datos las diferentes URLs dedichas paginas que se consideran, bien de forma legal, como moral, comoempresarial, etc., paginas que deben ser filtradas. Mediante el escrutinio deestas URLs, el software podra crear una lista de direcciones que deber serfiltradas (lista negra) o bien una lista de las direcciones que tendran permi-tido el acceso (lsita blanca). Dicha lista, como el modo de tratarla (negra oblanca) sera comunicada al sistema hardware en modo de direcciones IP, elcual realizara un primer filtrado basado en dichas direcciones IP a altas tasasmediante el uso de la tecnologıa FPGA. Debido a que el numero de direccio-nes a filtrar es muy pequeno, el porcentaje que el hardware deja pasar a lared sin que la aplicacion software tenga constancia de ello es de entorno al90 %. Esta disminucion de trafico que el hardware proporciona al software,hace que este pueda emplear su capacidad de procesamiento en tareas mascomplejas, como puede ser la inspeccion en mayor profundidad, como es eneste caso la comprobacion de URLs.

La solucion llevada a cabo en este Trabajo Final de Master ofrece unfiltrado por contenidos en redes 10 GbE. Esto supone un filtrado de 14,9millones de paquetes por segundo (Mpps). En el enlace a 10 Gbps se insertael sistema de filtrado, que realiza las siguientes operaciones:

Pre-filtrado: el pre-filtrado se realiza en el nivel de la tarjeta FPGA.Se trata de un primer filtrado a alta velocidad que deja pasar aquellaparte del trafico que no se considera sospechosa. Se puede realizar enbase a patrones en la cabecera o campo de datos de los paquetes. Enesta trabajo estara basado en las direcciones IP de los paquetes.

8


Filtrado: en esta parte entra el software ya desarrollado por Optenet,donde se realiza un analisis mas en profundidad buscando contenidosindeseados o posibles ataques. Al recibir esta parte software un traficopre-filtrado, no necesita procesar a la velocidad del enlace. De ese modoes posible realizar el procesado en una plataforma PC de prestacionesmedias.

2.2. Objetivos del sistema software

El software, proporcionado por OPTENET, empresa espanola de solucio-nes de filtrado y seguridad en la red, es el encargado de realizar el filtradofinal del trafico que el hardware ha filtrado, o reencaminado, a este. Para elloutiliza una aplicacion llamada CCOTTA. Tiene como colaboradores impres-cindibles las diferentes bases de datos de paginas web con contenido ilıcitoo indeseado por ciertos grupos de usuarios. Como adicion a ello, realiza unseguimiento y comprobacion de los contenidos de las paginas web que sonvisitadas por los usuarios con la finalidad de poder analizar si deben, o no,ser filtradas. Esto tiene como consecuencia la constante actualizacion de labase de datos de direcciones IP que deben ser filtradas por el hardware.

Las aplicaciones software no tienen un acceso directo a los recursos hard-ware, por lo que es necesario crear un intermediario que comprenda el fun-cionamiento del hardware y ofrezca a las aplicaciones un interfaz conocidoque le de acceso a dichos recursos. Como objetivos en relacion a este softwarede este trabajo se consideran los siguientes puntos.

Desarrollo de un driver que gestione la comunicacion por PCIe con losmodulos pertinentes de la FGPA y controle la actualizacion de reglas.

Implementacion de un interfaz conocido por las aplicaciones que per-mita el acceso a la funcionalidad del driver.

Creacion de una API que facilite la comunicacion entre las aplicacionessoftware y el hardware.

2.3. Objetivos del sistema hardware

Debido a las capacidades del software actual, su rendimiento no es capazde alcanzar las tasas necesarias de filtrado que se requieren en las redes 10GbE. Es por esta razon por la cual se debe realizar un sistema hıbrido entreel software y el hardware. El sistema hardware, que es el implementado eintegrado en este trabajo debe cumplir los siguientes requisitos, planteadoscomo objetivos primarios:

9

Jaime J. Garnica

Desarrollo en lenguaje RTL para FPGA, facilmente portable a otrastarjetas y escalable a velocidades superiores a los 10GbE.

Filtrado de paquetes segun sus direcciones IP a 10Gbps tasa real, in-cluso con paquetes de tamano pequeno (64 bytes).

Actualizacion dinamica (sin cortar el trafico de red y sin perdida depaquetes) de la lista de direcciones IP que se debe filtrar.

Integracion en plataforma PC de proposito general y comunicacion conel software a traves del bus PCI-Express de forma transparente para elsoftware.

2.4. Objetivo HLS

La introduccion de lenguajes de alto nivel en el campo de la sıntesis desistemas hardware esta cobrando una gran importancia en los ultimos anospor dos razones principales. Por un lado, los diferentes fabricantes y desarro-lladores de hardware han implementado compiladores cada vez mas potentesy con mejores modelos de computacion. Por otro lado, y como consecuenciade la aclaracion anterior, la necesidad de expertos en lenguajes de bajo nivelse ve reducida con el uso de estas nuevas herramientas basadas en lenguajesde proposito general bien conocidos como son C, C++ o Java.

Debido a la gran familiarizacion con los lenguajes de proposito general porlos desarrolladores de sistemas informaticos y de telecomunicaciones, se pue-de pensar como en una consecuencia directa el uso de lenguajes HLS (HighLevel Synthesis) debido a que dichos lenguajes implican un menor tiempode aprendizaje y desarrollo en las aplicaciones con un menor nivel de espe-cializacion. Aun ası, para conseguir que un sistema hardware funcione aunes necesario el desarrollo previo de un entorno de desarrollo que se encar-gue de los modulos mas especıficos del hardware. Por lo tanto, los objetivosrelacionados con el uso de lenguajes HLS son:

Aprendizaje y desarrollo de modulos hardware con lenguaje HLS paraFPGA.

Integracion y validacion de modulos creados con lenguajes HLS dentrode sistemas FPGA ya validados.

Evalucacion de los lenguajes HLS empleados para concretar sus carac-terısticas y aportaciones a la creacion de hardware.

10


3. Estado del arte

Actualmente, gran parte de los desarrollos en redes de alta velocidad,donde las tasas de paquetes superan en gran medida la capacidad de proce-samiento de los equipos convencionales, se desarrollan en sistemas de hard-ware dedicado. Entre estos, los basados en FPGA estan tomando una granimportancia. A continuacion se expone el estado del arte de los sistemas defiltrado y de las diferentes soluciones a los problemas u objetivos indicadosen los apartados anteriores con el fin de establecer una base de partida sobrela que comenzar el trabajo.

3.1. Sistemas de filtrado

Los metodos de filtrado se han realizado tradicionalmente con solucionesbasadas en sistemas software [9, 8, 16]. Las principales ventajas de estas solu-ciones son su flexibilidad y la posibilidad de implementar metodos complejosde busqueda en tablas, ası como la posibilidad de actualizarse de manerasencilla, lo cual es esencial en el campo de la seguridad debido a la rapidaevolucion de los ataques. Estos metodos no solo son usados en aplicacionesde filtrado, sino tambien en motores de busqueda [9], web caching [8] o redesde distribucion de contenidos [16]. Sin embargo, como desventaja, las solu-ciones basadas en software tienen un consumo de tiempo por peticion delorden de milisegundos [26]. Para mejorar el rendimiento de los metodos defiltrado basados en la URL hay cuatro aproximaciones. La primera de ellases mejorar el algoritmo de busqueda de la URL [26]. En segundo lugar, laimplementacion de algoritmos que se puedan paralelizar para aprovechar lasposibilidades que nos ofrecen los las arquitecturas multi-core [6, 25]. Otramejora posible es partir el trafico entrante en multiples maquinas. Y porultimo, reducir el consumo de la CPU en la captura de paquetes mediantehardware dedicado [7].

El hardware dedicado se puede definir como el sistema basado en hard-ware que se implementa para cumplir un objetivo concreto, normalmenteresuelto de forma previa por sistemas software. Normalmente este fenomenoes debido a que los procesadores no son capaces de alcanzar las tasas necesa-rias. Estos sistemas pueden ser NICs (Network Interface Card) de propositoespecial como las Endace DAGs, procesadores de red tales como Cavium, otarjetas con un chip FPGA [3]. La mayor ventaja de la tecnologıa FPGA esque su hardware puede ser programado ad-hoc para una cierta aplicacion ymas tarde ser reprogramado para cumplir los nuevos requisitos del sistema ode la aplicacion. Hasta el momento, se puede decir que la unica vıa existentepara implementar algoritmos que alcancen tasas de lınea de 100Gbps [12] es

11

Jaime J. Garnica

mediante el empleo de hardware dedicado [18], bien sea FPGA o networkprocessors, como Cavium.

3.2. Aplicaciones de seguridad de red en FPGA

Un recurso muy habitual para el manejo o desarrollo de aplicaciones enlas redes de alta velocidad son las FPGA, debido a su capacidad de reprogra-macion para una aplicacion nueva, proporcionan flexibilidad y posibilidad deactualizacion del sistema. Estas caracterısticas son esenciales en sistemas deseguridad, donde actualizar el sistema es necesario a medida que las activi-dades maliciosas evolucionan. En el campo de las redes de comunicaciones,los desarrollos en FPGA se pueden dividir en cuatro tipos de solucionesprincipales como podemos encontrar en la compilacion mostrada en [3]. Laclasificacion de las mismas se resume en las categorıas de: , , P y deteccionde anomalıas.

Clasificacion de paquetes [13, 18, 1], donde cada uno de los paqueteses analizado, o bien sus cabeceras (Ethernet, IP, TCP, etc.), o bien susdatos, o bien ambas, de manera que dependiendo de los valores que seestan buscando se realizan diferentes acciones que conllevan clasificar elpaquete dentro de unas condiciones iniciales, bien para crear estadsticasde tipos de paquetes y flujos, o bien reenviarlos por diferentes interfaces,o bien filtrarlos, etc..

Reconocimiento de patrones [2], si el objeto de la solucion es encontrarun patron, o cadena de bytes, dentro de las cabeceras o de los datosdel paquete (DPI, Deep Packet Inspection) para realizar una acciondeterminada sobre dicho paquete, crear estadısticas, evitar un ataque,etc..

Mantenimiento del stack TCP, de manera que se mantengan las comu-nicaciones entre dos puntos.

Deteccion de anomalıas, estudiando las diferentes condiciones y carac-terısticas del trafico, como puede ser la frecuencia de ciertos paquetes(tamano, cabeceras, protocolo, etc.), la cantidad de los mismos, el com-portamiento, etc., se consigue realizar una base sobre la cual contrastarel comportamiento en tiempo real del trafico futuro sobre la misma redy detectar cualquier comportamiento anomalo que pueda indicar quehay un ataque.

El filtrado de trafico se puede entender como un tipo de clasificacion depaquetes, ya que dependiendo de una serie de reglas se clasifica el caracter

12


de los paquetes como filtrados o no filtrados. Dentro de esta clasificacionhay muchos artıculos que presentan diferentes soluciones. Las soluciones mascomunes son:

Tecnologıas de TCAM [13], donde se emplean memorias ternarias, esdecir, que presentan 3 valores posibles, uno de ellos indica que el bitcorresponde con el valor buscado, otro indica que no y otro es indefinido.Este ultimo valor se puede emplear para realizar reconocimiento dereglas que coinciden en ciertos bits, pero en otros no, ahorrando espacio.

Binary Tries [18, 1], mediante la creacion de arboles binarios basados enconjuntos de reglas conocidos, se consigue crear un sistema de busquedarealizables en tiempos pequenos o que permitan la implementacion deun pipeline y, por lo tanto, alcancen las tasas requeridas por la red.

Bloom Filters [19], o sistemas de multiples hash, donde se genera unacadena de valores a partir de un conjunto de reglas inicial conocido.Cada una de las posiciones de dicha cadena hace referencia a un resul-tado de reconocimiento de la regla, es decir, se realiza un hash sobrela regla que proporciona la direccion dentro de la cadena de valores,accediendo ası al bit que indica si la regla ha sido reconocida o no. Parala creacion de dicha cadena se emplean multiples hashes sobre cada unade las reglas del conjunto inicial que se quiere contrastar.

Sin embargo, las TCAM, o memorias ternarias, han quedado obsoletasdebido a su alto coste y consumo, por lo que se han descartado para estetrabajo. En cuanto a las soluciones basadas en Binary Tries y Bloom Filters,presentan el impedimento de tener que volver a crear el sistema de busquedade reglas una vez que el conjunto de las mismas ha cambiado. Lo cual requiereel corte del trafico y del filtrado del mismo, siendo incompatible con losobjetivos presentados en este trabajo.

3.3. Lenguajes de alto nivel para sıntesis hardware

El principal problema de las soluciones basadas en hardware dedicado esla necesidad de una preparacion especıfica de los ingenieros y desarrolladoresque tienen como objetivo llevarlas a cabo. Debido a ello se ha abierto un cam-po de investigacion en los ultimos anos que intenta paliar dicho problema.Para ello, uno de los caminos que se siguen es el empleo de compiladores basa-dos en lenguajes de alto nivel para generacion de codigo RTL. Los lenguajesde alto nivel que mas se han empleado son los basados en C y Java.

13

Jaime J. Garnica

El artıculo [2] presenta una solucion para FPGA implementada en underivado de lenguaje Java para el reconocimiento de patrones basados enexpresiones regulares. En el caso de los lenguajes basados en C, es decir,lenguajes que o bien emplean C para compilar o emplean un subconjuntode mismo junto a modificaciones en la sintaxis para especificar comporta-mientos propios del hardware. Diferentes soluciones se han presentado comoHandelC [14] y AutoESL [4], proporcionando herramientas para la compi-lacion a partir de C, esta es una buena base de partida para estudiar losmismos.

4. Analisis de requisitos

Como esta indicado en la Seccion 2.3 del trabajo, hay cuatro requisitosesenciales que deben cumplirse por el sistema hardware:

Sistema portable a otras tarjetas de forma rapida y escalable a veloci-dades superiores a los 10GbE.

Filtrado de paquetes segun sus direcciones IP a 10Gbps tasa real, in-cluso con paquetes de tamano pequeno (64 bytes).

Actualizacion de forma dinamica (sin cortar el trafico de red y sinperdida de paquetes) de la lista de direcciones IP que se debe filtrar.

Integracion en una plataforma PC de proposito general, comunicandosecon el software a traves del bus PCI-Express. Permitiendo ası al softwa-re correr en una plataforma de proposito general, con sistema operativoLinux.

Proporcionar un interfaz conocido para que el programa de filtradosoftware sea capaz de definir filtros dinamicamente y agregarlos a latarjeta FPGA.

Analizandolos en profundidad, cada uno de ellos implica los siguientesrequisitos especıficos del sistema hardware, es decir de la implementacionsobre la tarjeta FPGA.

4.1. Sistema portable y escalable

Para que el sistema sea portable a otras plataformas debe generarse unenvoltorio de los modulos que forman parte de la aplicacion cuyas interfacessean las estandares correspondientes al manejo de paquetes, de reglas y de

14


comunicacion con el software. Este envoltorio, junto con los modulos de apli-cacion debe ser facilmente portable a otros sistemas que tengan configuradassus interfaces con los perifericos de manera identica a la de dicha aplicacion.El metodo empleado en el diseno de la arquitectura debe ser modular, esdecir, los componentes de la arquitectura deben presentar una serie de inter-faces estandar de manera que sean intercambiables e integrables de manerarapida y sencilla. Dichas interfaces de comuniacion pueden seguir protocolosya definidos.

Conseguir que el sistema sea escalable a arquitecturas superiores a los10Gbps puede llevarse a cabo mediante el cambio de anchos de palabras enlas interfaces y de frecuencias de reloj. Por ello no de se deben realizar com-probaciones de los mismos ni concretar su uso a unos valores preconcebidos.

4.2. Filtrado de paquetes a 10Gbps incluso paquetespequenos

El filtrado de paquetes de tamano pequeno (64 bytes) a una tasa de10Gbps implica que la frecuencia de llegada de paquetes es de un paquetecada 67 nanosegundos. Esto implica la necesidad de ser capaces de procesarun paquete en un tiempo menor al indicado o, al menos, que la salida delos paquetes se cumpla con dicha frecuencia. Para obtener la tasa de sali-da deseada, se debe crear un sistema en pipeline que, anadiendo un retardoaceptable, sea capaz de consultar las reglas indicadas y reenviar un paquetesin retrasar la recepcion de los sucesivos. Una de las tareas mas importantesen este aspecto es seleccionar un tipo de memorias que presente una tem-porizacion que habilite el pipeline, es decir, que tenga un tiempo de accesodeterminista para cada una de las peticiones que se realizan y ası asegurarel mismo tiempo de acceso a cada una de las peticiones que se realizarandurante el filtrado.

Como requisito hardware, la comunicacion a 10Gbps se debe realizar me-diante un sistema que pueda funcionar a dicha tasa. Para ello es necesarioencontrar una frecuencia de trabajo y un ancho de palabra en la llegada delos paquetes que alcance la tasa de 10Gbps, al igual que es necesaria una tar-jeta en la que se encuentren dos interfaces a 10Gbps, de modo que se puedenfiltrar ambos sentidos de la red.

4.3. Actualizacion dinamica de direcciones IP

Con el fin de asegurar el continuo filtrado de la comunicacion, uno de losaspectos a mas crıticos a tener en cuenta es la actualizacion de las reglas

15

Jaime J. Garnica

por parte de la aplicacion software. Para actualizar de forma dinamica lalista de las direcciones IP sospechosas se deben almacenar en un recursomodificable durante el funcionamiento del sistema, evitando precargar la listaal programar la FPGA y de ese modo la reprogramacion de la misma parasu modificacion. La reprogramacion del sistema implicarıa un corte en elflujo de datos entrante. Dicha modificacion dinamica se puede solventar conmemorias accesibles para su escritura durante la ejecucion del sistema.

Para que el filtrado del trafico no se vea interrumpido se debe crear unsistema de acceso al recurso que, tanto permita realizar escrituras al mismotiempo que se realizan lecturas, como funcione a una frecuencia suficiente deaccesos que permita intercalar las lecturas y escrituras sin perjudicar la tasade la lınea. Las especificaciones tecnicas para que este requisito se cumplapasan por la integracion de memorias accesibles a alta velocidad y con unacapacidad suficiente para almacenar las direcciones IP.

4.4. Integracion en una plataforma PC de propositogeneral

Para facilitar la cooperacion entre el software y el hardware es necesariocrear un sistema mediante el cual ambas partes puedan comunicarse. Paraque tenga el caracter de ser una plataforma de proposito general, como un PCse debe emplear un recurso comun, como es el caso de PCI-Express (PCIe).Este recurso se encuentra en la mayorıa de los ordenadores que se vendenactualmente en el mercado y la forma mas comun de comunicar las tarjetasde red, en este caso las tarjetas con FPGA. Para acceder a dicho recursosambas partes del sistema deben introducir en sus arquitecturas un accesoal mismo. Desde el punto de vista del software basado en Linux se puedeacceder mediante la implementacion de drivers para el sistema operativo.En el caso del sistema hardware sera necesario adjuntar algun tipo de core(modulo hardware) que maneje el recurso de la tarjeta.

La comunicacion a traves del PCIe debera permitir al hardware propor-cionar dos servicios fundamentales al software. El primero de ellos es el envıode paquetes que cumplan las reglas de filtrado que el hardware ha recibido.En segundo lugar, la comunicacion de esas reglas de filtrado para mantenerla consistencia con las bases de datos y mantener el sistema actualizado.

4.5. Proporcionar un interfaz conocido al software

Para proporcionar un interfaz conocido entre el software y el hardwarese puede dividir este en dos puntos esenciales. En primer lugar la tarjeta

16


ha de mostrarse al sistema operativo como si de una NIC convencional setratase. En segundo lugar implementar una serie de controladores de entrada-salida (IOCTL, Input Output ConTroLler) a traves de los cuales la aplicacioncorrespondiente pueda acceder a la memoria de reglas de la tarjeta.

La importancia de proporcionar un interfaz conocido reside en facilitarla integracion de las aplicaciones que se van ejecutar empleando el desarrollodel filtrado, tanto las que ya se encuentran desarrolladas como las posiblesfuturas aplicaciones. Esto es importante ya que, como ha sido explicado an-teriormente, la evolucion de las actividades maliciosas es continua y esto im-plica que el cambio de aplicaciones software, o la actualizacion de las mismas,sea constante. Por lo tanto, el sistema debe ser compatible con soluciones yaexistentes.

5. Entornos de desarrollo

Las tarjetas basadas en FPGA no son todas iguales, por lo que debeseleccionarse una entre las diferentes opciones del mercado. Dicha tarjetadebe presentar unas especificaciones que permitan cumplir con los requisitosde la solucion. Por ello, como especificaciones mınimas deben tener, al menos,dos interfaces 10GbE. Tambien deben presentar memorias accesibles duranteel funcionamiento del sistema, las cuales deben tener una capacidad lo mayorposible. Por ultimo, dichas tarjetas deben conectarse a traves del PCIe, demanera que se puedan enviar los paquetes filtrados por la FPGA al software.

5.1. Plataforma basica

La plataforma elegida para el desarrollo ha sido desarrollada por la empre-sa INVEA-Tech, de origen checo. Esta plataforma ofrece un ventaja esencialsobre el resto de las plataformas planteadas como es la incorporacion deun entorno de trabajo ya desarrollado. INVEA-TECH proporciona un servi-dor pre-configurado (Figura 2). El servidor es una maquina de montaje enbastidor 2U disenado a medida de la tarjeta COMBO-LXT, que viene conun sistema operativo CentOS 5.2 precargado con los drivers y librerıas deNetCOPE.

5.1.1. Especificaciones

La tarjeta basada en FPGA proporcionada por INVEA Tech es la llamadaCOMBO-LXT. esta es una tarjeta PCIe x8 GEN1 que incluye una FPGAde la familia Virtex-5 de Xilinx, en particular la XC5VLXT155. Sobre esta

17

Jaime J. Garnica

Figura 2: Servidor NetCope de INVEA-Tech [15]

tarjeta se pueden conectar modulos de interfaz, existiendo en la actualidadel COMBOI-1G4 que proporciona 4 interfaces opticas gigabit Ethernet tipoSFP, y el COMBOI-10G2 que dispone de dos interfaces opticas 10 GbEimplementadas mediante modulos XFP. Esta ultima es la que se ha empleadoen este proyecto. El conjunto completo puede verse en la Figura 3.

Figura 3: Tarjeta combo LXT-COMBOI-10G2 de INVEA-Tech [15]

Los detalles de la tarjeta pueden verse en la Figura 4. La FPGA se co-necta directamente con el bus PCIe, ofreciendo una configuracion PCIe x8GEN1 que alcanza velocidades efectivas (una vez que se tiene en cuenta lasobrecarga a nivel fısico y de enlace) de mas de 12 Gbps full-duplex. La FP-GA tiene disponible dos memorias QDR-II tipo CY7C1513AV18 de 72 Mbits,organizadas como 4Mx18, y tambien esta conectada a un zocalo para memo-rias SODIMM tipo DDR2, hasta 2 GBytes. La placa dispone de dos tiposde conectores para enchufar placas de interfaz de red, 4 de baja velocidad(LSC, low-speed connector) y dos de alta velocidad (IFC, interface connec-tor). Estos ultimos es donde se conectan los SERDES de alta velocidad de la

18


FPGA.

Figura 4: Arquitectura de la tarjeta LXT de INVEA-Tech [15]

19

Jaime J. Garnica

La configuracion de la FPGA Virtex-5 se hace a traves de una FPGAsecundaria tipo Spartan-3, que tiene asociada una memoria Flash. La ven-taja de este esquema es que se puede reconfigurar la FPGA sin perder laconexion PCIe con el host, y sin necesitar de un rearranque del sistema. Adi-cionalmente, la placa ofrece un conector JTAG donde enchufar el cable deprogramacion de Xilinx, que permite por ejemplo usar las herramientas dedepuracion en sistema (ChipScope).Finalmente, la placa dispone de variosgeneradores de reloj, y de los conversores DC/DC necesarios para alimentarlos diferentes dispositivos. Toda la alimentacion se obtiene a traves de la lıneade +12V de PCIe, no siendo necesario usar alimentaciones adicionales.

5.1.2. Firmware INVEA Tech

El diseno FPGA de la plataforma NetCOPE contiene todos los bloquesnecesarios como punto de partida para implementar aplicaciones de red:

Acceso a las interfaces de red

Colas DMA para transferir los paquetes al host

Interfaz de configuracion de la aplicacion desde el host

Estos bloques se ofrecen bien como codigo fuente VHDL, como cores que sepueden generar con la herramienta Xilinx Coregen, o como netlists presin-tetizadas. En la Figura 5 se puede ver la estructura del diseno FPGA de laplataforma NetCOPE.

Figura 5: Firmware de INVEA Tech [15]

En el lado de la izquierda se pueden observar las interfaces de red, quedependiendo de la tarjeta de interfaz que se use pueden ser 4 interfaces gigabitEthernet o 2 interfaces 10 GbE. En este proyecto solo se va a considerar elsegundo de los caso, 10 GbE. El chip de medio fısico asociado a cada conector

20


XFP (Vitesse VSC8486) proporciona una interfaz XAUI a la FPGA. Dentrode la FPGA, el bloque Network module implementa los cores 10 GbE y ofrecehacia la aplicacion 2 streams por interfaz de red, uno de transmision y otrode recepcion. Estos streams siguen el formato FrameLink, que se describe enla Seccion 6.3.3. Asociado al bloque Network module esta el bloque Pacodagmodule. Pacodag significa PAcket COntrol DAta Generator, y es un moduloque basicamente se encarga de poner una cabecera a cada trama que se recibecon la longitud, interfaz de llegada y timestamp, aunque futuras versiones deNetCOPE se podrıa usar en para anadir mas informacion.

Por el lado de la derecha esta la interfaz PCIe. NetCOPE es una tarjetaPCIe x8 GEN1. El bloque cv2 PCI debe estar compuesto principalmente porel core PCIe de Xilinx, aunque esta informacion es difıcil de confirmar puestoque se ofrece como una netlist presintetizada. A traves de una conexion destreaming tipo Internal Bus se conecta con el modulo NetCOPE base, que esel que se encarga de procesar y generar los TLPs (transaction layer packets)de PCIe. El modulo NetCOPE base proporciona dos interfaces, Internal Busy Local Bus (Seccion 6.3.1). Internal Bus es una interfaz de alta velocidadtipo streaming, mientras que Local Bus es una conexion mas sencilla, similara los buses clasicos, pero con prestaciones limitadas puesto que no permitepipelining. Internal Bus esta pensado para la transferencia de grandes blo-ques de datos, mientras que Local Bus se orienta al acceso de registros deconfiguracion. Ambos buses acaban en dos switches: IB switch y LB switch.Esto se debe a que DMA module necesita ambos buses, lo mismo que laaplicacion.

Finalmente aparece el bloque Application, que es donde el usuario puedeanadir su aplicacion de red. Este bloque tiene acceso a traves de conexionesFrameLink a las interfaces 10 GbE y a las colas DMA para la transferencia depaquetes hacia el host. Tambien tiene acceso a los buses Internal Bus y LocalBus, y se proporcionan unos endpoints (IB endpoint y LB endpoint) parasimplificar aun mas el acceso a estos buses. La modularidad de la arquitecturaque rodea el bloque Aplicacion y, por lo tanto, la interfaz de la misma, juntoa los protocolos empleados en la comunicacion de los perifericos, hace quesea sencillo seguir el diseno modular que se especificaba en la Seccion 4.1.

5.1.3. Escenario tıpico

El escenario tıpico que se puede implementar con esta plataforma es eldescrito en el objetivo de este Trabajo Final de Master, es decir, un filtradoque se implante entre dos extremos de una comunicacion, empleado unainterfaz para la comunicacion entre el filtro y el cliente y otra entre el filtroy la comunicacion con Internet tal y como muestra la Figura 6.

21

Jaime J. Garnica

Filtering appliance

InternetUser

Security management

server

Figura 6: Escenario para una tarjeta con 2 interfaces de red

5.2. Plataforma avanzada

Una vez desarrollada la solucion en la plataforma y durante el transcursode la misma, se han estudiado nuevas opciones a las que migrar el desarrollo.La solucion mas atractiva es una placa desarrollada en la Universidad deStanford, llamada NetFPGA 10G y mostrada en la Figura 7.

Figura 7: Tarjeta NetFPGA 10G de HiTech Global [24]

5.2.1. Especificaciones

La FPGA tiene disponible dos bloques de memoria. Por un lado, tieneconectadas tres memorias QDR-II tipo CY7C1515JV18, de 72Mbits en or-

22


ganizacion 2Mx36. Por el otro, tiene tambien 4 memorias RLDRAM tipoMT49H64M9, de 576Mbits en organizacion 64Mx9 en 8 bancos. Las memo-rias RLDRAM se situan a medio camino entre las QDR y las DDR2/3 tantoen tiempo de acceso aleatorio como tamano. El tiempo de acceso para undato cualquiera es de 4 ciclos de reloj (12 ns a 333 MHz), lo que resulta muyadecuado para hacer busquedas en tablas a alta velocidad.

Con respecto a la configuracion, usa dos memorias PlatformFlash XLconectadas a la FPGA a traves de un CPLD que hace que aparezcan como sifuesen un unico dispositivo del doble de capacidad. La alimentacion es mixtaentre el bus PCIe y un conector externo tipo IDE, y dispone ademas de unpar de conectores de alta velocidad que podrıan usarse para conectar placassecundarias con mas puertos de red. El mayor problema de esta tarjeta es quea diferencia de la COMBO-LXT no se ofrece ninguna plataforma de desarrollorapido de aplicaciones, como NetCOPE. Por ello, es necesario hacer todo eldesarrollo tanto de drivers como interfaces 10 GbE y PCIe. Sin embargo,serıa posible reutilizar el trabajo hecho para NetCOPE a nivel de prueba deconcepto.

5.2.2. Escenario tıpico

Bajo estas condiciones, un posible entorno de prueba serıa el que describela Figura 8, donde la tarjeta de HiTech Global hace de puente entre dosredes, y el trafico que no puede ser reenviado se manda a dos instancias deCCOTTA, una para filtrar trafico en cada sentido:

TarjetaHitechGlobal

Dos servidores CCOTTA

Red Externa

Red Interna

Figura 8: Escenario para una tarjeta con 4 puertos 10GbE

23

Jaime J. Garnica

5.3. Metodologıa

5.3.1. Lenguajes RTL

La implementacion del fichero que sera cargado en la FPGA, llamadobitstream, se lleva a cabo mediante las herramientas de Xilinx. En primerlugar, para el desarrollo de la aplicacion que correra en la FPGA se utilizala herramienta Xilinx ISE. En dicha herramienta, se crean proyectos basadosen codigo RTL, en esta caso el lenguaje VHDL. Estos lenguajes basan suorganizacion en modulos, los cuales siguen una jerarquıa dependiendo de laforma en la que se instancian los unos a los otros, a partir de un modo gene-ral, o top-level. No obstante, cierto modulos no es necesario generarlos al sermodulos muy comunes y previamente generador por la herramienta XilinxCoregen, o Core Generator, que crea dichos modulos a partir de unos parame-tros establecidos por el desarrollador. Una vez realizada la implementaciondel bitstream, este fichero se descarga a la placa mediante la herramientaXilinx iMPACT.

5.3.2. Simulacion de modulos

Para realizar tanto las pruebas unitarias como las de integracion, se em-plea un entorno de simulacion en modo de caja blanca, de manera que sepuedan comprobar las diferentes senales y su comportamiento dentro delmodulo. La herramienta de simulacion que se ha empleado para este trabajoes la llamada ModelSim de Modeltech. Esta herramienta emplea un script desimulacion en el que se cargan el/los modulos que se van a probar. Una vezcargados dichos modulos se lanza el llamado testbench (del ingles, banco depruebas), escrito tambien VHDL, en el que se instancian las diferentes prue-bas o caso de uso que se desean comprobar, generando las entradas, incluidaslas de reloj y reset. Una vez llevado a cabo el procesamiento de las senalesse pueden comprobar las salidas.

5.3.3. Validacion en placa

Una vez se ha comprobado que las simulaciones funcionan correctamen-te, se debe llevar a cabo la comprobacion del funcionamiento en placa. Paraello se debe implementar, antes de la sıntesis, el sistema con los modulos devalidacion que permitan comprobar ciertas senales preseleccionadas mientrasel diseno esta corriendo en placa. Para la verificacion con trafico real se pro-pone el uso de la herramienta ChipScope, tal como muestra la Figura 9, quepermite implementar un analizador logico dentro de la propia FPGA, usandosus recursos libres. De esta manera se pueden ver en tiempo real el estado

24


de las senales internas a la FPGA, usando la herramienta Analyzer, que atraves del puerto JTAG de configuracion se conecta con los cores ChipScopeque hay instanciados dentro de la FPGA. Para crear los cores ChipScope,en particular el ILA (Integrated Logic Analyzer), que es el adecuado en estecaso, se propone el uso de la herramienta CoreGen de Xilinx. Una vez gene-rado, se instancia dentro de la descripcion VHDL del modulo que se deseaverificar, y se le conectan las senales que se quiere monitorizar. Se puedeninstanciar hasta 15 de estos bloques ILA dentro de la FPGA, y todos ellosdeben estar conectados a un bloque ICON (Integrated Controller) que es elque se encarga de hacer de interfaz con el puerto JTAG.

Figura 9: Esquema general de la herramienta ChipScope

5.3.4. Drivers

Para el manejo correcto y el completo aprovechamiento de la funciona-lidad de la tarjeta y sus desarrollos, es necesario crear una serie de contro-ladores que establezcan y gestionen la comunicacion entre el hardware y lasaplicaciones software. Estos controladores se situan en el Kernel de Linuxen forma de modulos. Para el desarrollo de los controladores, o drivers, serequiere una codificacion en leguaje C y la ejecucion de diferentes comandosdel sistema para cargar dichos modulos.

5.3.5. Lenguajes HLS

Como se ha explicado en secciones anteriores, los lenguajes HLS son len-guajes de alto nivel, normalmente basados en el lenguaje C. Por lo tanto,

25

Jaime J. Garnica

la codificacion de dichos lenguajes se realiza de forma similar, sin embargo,dichos lenguajes tienen configuraciones y comandos propios. En el caso deeste trabajo se va a realizar un estudio de las herramientas HandelC y Auto-ESL. La primera de ellas porporciona un lenguaje basado en C, el cual se hamodificado ligeramente, anadiendo nueva sintaxis y funciones que permitencontrolar la temporizacon y compilacion del codigo. La segunda, proporcio-nada por Xilinx, es un compilador que proporciona un entorno de codificacionpara C y C++. No modifica la codificacion del lenguaje, sin embargo, permi-te incluir una serie de directivas que afectan al procesamiento del compiladorpara optimizar la creacion el lenguaje RTL y, por lo tanto, del comportamien-to del software (e.g. pipeline en bucles, tipo de interfaces de los parametros).Una vez generado el codigo RTL, este es incluido en el proyecto hardwarecomo si de cualquier otro modulo se tratase.

6. Arquitectura FPGA

El diseno de la arquitectura que se integra en la FGPA se basa princi-palmente en el uso de perifericos que contiene la placa para llevar a cabo lafuncionalidad deseada. Tal como se puede ver en la Figura 10, en el exteriorde la FPGA estan los diferentes perifericos que se van a emplear y, dentrode la misma, la forma en que se comunican con la aplicacion de filtrado.

Figura 10: Arquitectura general de la FPGA

26


Los perifericos de este sistema son el PCIe para realizar la comunicacioncon el software con el fin, tanto de actualizar la tabla de reglas como degestionar el sistema, y recibir los paquetes filtrados; interfaces 10GbE pararecoger y reenviar la comunicacion en ambos sentidos de la red, conectandoun extremo a Internet y otro al equipo subscriptor; y el conjunto de memo-rias QDR-II que almacenen las reglas de filtrado. El modulo llamado FilteringEngine (del ingles, motor de filtrado) es el envoltorio que permite aislar laaplicacion de filtrado de los modulos que gestionan los perifericos. De esamanera, cambiar de aplicacion no requiere modificar el sistema completo,sino solo modificar el contenido de dicho modulo, consiguiendo ası habilitarla reutilizacion de la plataforma para diferentes soluciones y del modulo pa-ra diferentes plataformas. Mediante esta solucion se cumple el requisito deportabilidad planteado en la seccion 4.1.

6.1. Perifericos

El manejo de perifericos desde el hardware se realiza con la implementa-cion e integracion de cores especıficos. Dichos cores llevan a cabo la configu-racion, manejo e interpretacion de la comunicacion mediante el periferico yel resto del sistema. A continuacion se presentan los perifericos que se van aemplear en el trabajo.

6.1.1. PCI-Express

El PCIe se emplea para establecer una comunicacion entre el sistemasoftware (el servidor) y el sistema hardware (la tarjeta FPGA). Esta co-municacion sera esencial para las diferentes partes del trabajo como son lafuncionalidad, el control, la depuracion y la verificacion.

En cuanto a la funcionalidad, podemos caracterizar dos puntos impor-tantes. En primer lugar, se debe poder enviar los paquetes filtrados por latarjeta al servidor de forma transparente a este, como si de una NIC (Net-work Interface Card) se tratase, cumpliendo el requisito mencionado en laSeccion 4.4. Esta comunicacion se realizara mediante DMA (Direct MemoryAccess), de forma que se pueda alcanzar una tasa alta paquetes por segun-do. En segundo lugar, la actualizacion de reglas de direcciones IP medianteescrituras y lecturas por el PCIe y una debida gestion de las mismas en latarjeta, ası como diferentes opciones de lista blanca o negra, puenteado deinterfaces, ect..

La gestion y control del sistema mediante la consulta de registros es asi-mismo importante para asegurar el correcto funcionamiento del sistema glo-bal, es decir, el sistema hardware maneja unos registros de los que el software

27

Jaime J. Garnica

puede leer el estado del filtrado y en los que el software puede escribir con-figuraciones para el funcionamiento de la tarjeta. Igualmente esta serie deregistros, junto a otros mas especıficos, seran empleados durante la depura-cion y verificacion del sistema.

El motivo que antepone el empleo de PCIe en lugar de PCI convencionales, principalmente la tasa de datos que se consigue en las transferencias. enel caso del PCI convencional la tasa de datos maxima que se obtiene porlınea des es de 500Mbps. En el caso del PCIe la tasa obtenida depende de lageneracion que se emplee del mismo. Por ejemplo en el caso de la generacionPCIe 1.0 la tasa de lınea obtenida es de 2,5×0,8×(0,75/0,85) = 0,88Gbps porcada lınea de transmision. Al tratarse, este, de un trabajo en redes de 10Gbpsconviene que la tasa que se obtenga no impida que el sistema trabaje a dichatasa en el caso de las redes de comunicacion. Por ello y por lo explicado eneste parrafo el sistema de comunicacion que se adopta en el trabajo debe serigual o superior en capacidades al PCIe 1.0.

6.1.2. Memorias QDR-II

El conjunto de reglas que se va a emplear para consultar el filtrado decada paquete debe ser almacenado en memorias, principalmente para poderrealizar su actualizacion dinamica. Para ello se debe llevar a cabo la seleccioncorrecta de las memorias que se van a emplear basandose en los diferentesaspectos que debemos tener en cuenta como son, esencialmente, el tamanodel conjunto de reglas y el tiempo de acceso a cada regla. Las reglas sobrelas que se va a actuar es todo el conjunto de reglas IP posibles en la red, esdecir, 232 reglas si hablamos de IPv4. Para almacenar un bit para cada unade las reglas de todo el conjunto deberıa obtenerse una memoria de 4Gbits,es decir 512MBytes.

Las unicas memorias accesibles desde una FPGA en la actualidad quealcanzan la capacidad de 512MBytes son las memorias DDR [10]. Este tipode memorias tienen una temporizacion de acceso particular. Para accedera un dato se debe cargar previamente la pagina en la que se encuentra elmismo, eso tiene como consecuencia que si un dato no esta en la paginaprecargada en ese momento se debera perder un tiempo extra de acceso paracargar dicha pagina. Puesto que la llegada de las direcciones IP al sistema esaleatoria esto conllevarıa un tiempo excesivo de acceso y no determinista ala memoria, mucho mayor que el tiempo entre llegada de los paquetes. Porestas razones se descarta el uso de este tipo de memorias.

El tipo de memoria que tiene un acceso inmediato en las tarjetas basadasen FPGA son las BlockRAM. Estas memorias tienen un tiempo de acceso deun ciclo (pocos nanosegundos). Sin embargo, el problema principal de estas

28


memorias es la capacidad que ofrecen al sistema, la cual no llega a los Mbits.Hay, por lo tanto, un trade-off (del ingles, compromiso) que se debe estudiarsobre el tamano de las memorias y su temporizacion de acceso a datos.

Un tercer tipo de memorias que se encuentra en las tarjetas con FPGAactuales son las llamadas QDR y QDR-II [17]. Este tipo de memorias presen-tan una temporizacion determinista, es decir, el tiempo de acceso a los datoses constante par cualquiera que sea la direccion, y una capacidad de Mbits dealmacenamiento. Concretamente llegan hasta las decenas de Mbits. Para queel trade-off no se vea comprometido por la capacidad de almacenamiento seemplea un metodo de almacenamiento de datos basado en direccionamientohash con colisiones, empleando una funcion de hash de menos longitud queel tamano de una direccion IP (e. g. 226 direcciones para un hash de 26 bits,es decir, una memoria de 64Mbits de capacidad).

6.1.3. Interfaces 10GbE

Para que la tarjeta tenga una comunicacion con Internet y el resto deredes, a la tasa de datos que se desea obtener, se requiere el uso de interfacesde red 10GbE (Gigabit Ethernet). Muchos son los tipos de conectores yde sistemas que se pueden emplear en estos casos. La principal distincionentre los mismos es su medio de transporte, encontrando dos tipo esencialescomo son el cable de cobre y la fibra optica. En este trabajo se ha pensadoprincipalmente en el uso de conectores XFP, que proporcionan una interfazoptica. Sin embargo tambien se puede llevar a cabo la comunicacion mediantecable de cobre empleando transceptores del tipo CX4.

6.2. Aplicacion

La aplicacion implementa dos puentes, bridge01 y bridge10, tal como serepesenta en la Figura 11. El puente bridge01 recoge trafico por la interfaz0 y lo reenvıa a la interfaz 1 si sus direcciones IP no estan restringidas. Encaso contrario, el trafico se envıa a la cola DMA asociada con el dispositivo/dev/ceth0 del host. De la misma manera, el puente recoge las tramas queenvıa el host a traves de la cola DMA asociada al dispositivo /dev/ceth1, ylas reenvıa a la salida de la interfaz1. Alternativamente, el puente bridge10recoge trafico por la interfaz 1 y lo reenvıa a la interfaz 0 si sus direccionesIP no estan restringidas. En caso contrario, el trafico se envıa a la cola DMAasociada con el dispositivo /dev/ceth1 del host. De la misma manera, elpuente recoge las tramas que envıa el host a traves de la cola DMA asociadaal dispositivo /dev/ceth0, y las reenvıa a la salida de la interfaz0.

29

Jaime J. Garnica

BRIDGE01

BRIDGE10

DMA1

DMA0

IF1IF0

Figura 11: Puentes de filtrado

La Figura 12 muestra la arquitectura global de la aplicacion de filtrado,integrada en el diseno FPGA. Las lıneas finas son senales, las lıneas de grosormedio son buses, y las lıneas gruesas representan conexiones FrameLink.

Los puentes se implementan mediante los bloques IF CTRL. Este bloquerecoge el trafico proveniente de la interfaz de red a traves de la interfaz Fra-meLink FROM NET, y lo reenvıa hacia el filtro por la interfaz TO FILTER.El filtro mira las direcciones IP fuente y destino de los paquetes, de tal ma-nera que se clasifica el trafico en dos clases: el que se puede reenviar sinproblema, que entra por el puerto FROM FILTER 1, y el que no se pue-de reenviar, que entra por el puerto FROM FILTER 2. El trafico del puer-to FROM FILTER 1 se envıa hacia la interfaz de red a traves del puertoTO NET, junto con el trafico proveniente del host que entra por el puer-to FROM DMA. Por otro lado, el trafico del puerto FROM FILTER 2 sereenvıa directamente hacia el host a traves del puerto TO DMA.

La pieza clave de toda esta estructura es el filtro FILTER, que es quienimplementa los clasificadores de trafico. El filtro tiene dos puertos de entradaNI0 IN y NI1 IN, correspondientes con las dos interfaces de red. El traficoproveniente de cada una de estas dos interfaces es clasificado en reenviable, ono reenviable, de acuerdo a las direcciones IP origen y destino de los paque-tes. Si es reenviable, se devuelve respectivamente por los puertos NI0 NETy NI1 NET, y si no se puede reenviar, se manda respectivamente por lospuertos NI0 DMA y NI1 DMA. Para hacer esta clasificacion, el filtro tieneque acceder a las memorias donde se almacenan las direcciones restringidas

30


Figura 12: Arquitectura general de la aplicacion hardware

31

Jaime J. Garnica

para el reenvıo (o mas concretamente, los hashes de las direcciones, comose describe en la Seccion 6.3.2. Hay dos memorias, una para las direccionesexternas (Internet) y otra para las direcciones internas (subscriptores). Elacceso a las memorias se hace a traves del protocolo Local Bus.

6.3. Comunicaciones

Tanto los modulos del sistema como los cores que manejan los diferentesperifericos necesitan comunicarse entre sı. Muchas son las formas de comuni-cacion, pero en cuanto a sistemas de escritura y lectura con direcciones o enstreaming (flujo de datos) lo mas habitual es definir una serie de protocolosque determinen esa comunicacion.

En la Figura 13 se muestra el flujo de los datos a lo largo de los modu-los de la arquitectura, distinguiendo dos flujos como son los paquetes y laspeticiones de acceso a las memorias. El flujo de paquetes comienza en lascomunicaciones externas, DMA e Interfaz de Red, y atraviesa los diferen-tes modulos de filtrado, los cuales deciden el siguiente modulo por el quesera dirigido dicho flujo. En cuanto al flujo de peticiones de busqueda, estascomienzan cuando un paquete atraviesa el modulo de parseo de direccionesIP y es enviado a los modulos de consulta y comprobacion de reglas, loscuales redirigen al modulo de acceso a las memorias QDR. Por ultimo, laspeticiones desde el PCIe, es decir, desde el software, son gestionadas por unmodulo que decide si son peticiones de registros y devuelve sus valores, osi se refieren a actualizacion/consulta de reglas y en ese caso son dirigidastambien al modulo de acceso a las memorias QDR.

IP parsing Packet

FIFO

Packet

Matching DMA Filtering

Request FIFO

Rule Updating

Module

Updating

Request FIFO

QDR-II

Manager

QDR

memories

Packet Filtering Module

QDR-II Access Module

Rule data flow

Packet flow

IP parsing Packet

FIFO

Output IF1

Output IF0

Input IF1

Input IF0

PCI Main modules Data flows

Figura 13: Flujo de datos del sistema

En la arquitectura propuesta se emplean hasta 3 tipos de protocolo den-tro de la aplicacion de filtrado (un mayor numero si tenemos en cuenta las

32


comunicaciones entre los cores y sus respectivos perifericos). El primero deellos, el protocolo Local Bus, es el protocolo que se ha empleado para manejardatos con direccionamiento a lo largo de los modulos del sistema. Es un pro-tocolo sencillo. En segundo lugar se emplea el conocido protocolo LocalLink,o mejor dicho, su variante FrameLink, el cual se empleara para el streaminga lo largo del diseno. Por ultimo, el protocolo de control de memoria, o MIG,que sera el empleado para accedes a las memorias QDR-II.

6.3.1. Protocolo Local Bus

El Local Bus es un bus cuya mayor ventaja es la sencillez. Aunque tambienes un bus segmentado, por lo que permite transferir una palabra por ciclo dereloj, a diferencia del Internal Bus no esta preparado para transferir grandesrafagas de datos ni para transferencias DMA. Es tambien un bus sıncrono, yel endpoint proporciona estas senales para acceder a el:

MI DWR: Input Data, datos de escritura

MI ADDR: Address, direccion de acceso

MI RD: Read Request, bandera de lectura

MI WR: Write Request, bandera de escritura

MI BE: Byte Enable, indexador de bytes validos

MI DRD: Output Data, datos de lectura

MI ARDY: Address Ready, bandera de confirmacion

MI DRDY: Data Ready, bandera de respuesta

La Figura 14 presenta una lectura tıpica de varias posiciones de la apli-cacion por parte del endpoint. Cuando el endpoint quiere leer una posicion,pone la direccion y el byte enable, y activa la senal RD. Se ordena una lecturacada ciclo de reloj salvo que la aplicacion quiera introducir estados de esperamediante la senal ARDY. Cuando la aplicacion tiene los datos disponibles,los devuelve por el bus DRD, indicando que hay un dato valido mediante lasenal DRDY. Los datos se devuelven consecutivamente, siguiendo el mismoorden que fueron solicitados por el endpoint. Si la aplicacion no es capaz dedevolver datos a la tasa que permite el reloj, introduce estados de esperadesactivando la senal DRDY.

La Figura 15 muestra una transferencia de escritura tıpica desde el end-point hacia la aplicacion. El endpoint indica que quiere escribir datos acti-vando la senal WRITE, y al mismo tiempo pone la direccion, dato y byte

33

Jaime J. Garnica

Figura 14: Lectura LocalBus [15]

enable de la posicion a escribir. Se produce una escritura en la aplicacion concada flanco de reloj, salvo que la aplicacion no este preparada para recibirdatos y meta un estado de espera desactivando la senal ARDY.

Figura 15: Escritura LocalBus [15]

6.3.2. Direccionamiento y funciones hash

El protocolo Local Bus es empleado en la busqueda de direcciones IP,tanto antes como despues de realizar el hash, por los modulos de entrada,salida y procesamiento de tramas. Es empleado tambien en la comunicacion

34


con el PCI-Express y por lo tanto con el software. Tanto en el manteni-miento de las reglas como en la comprobacion y modificacion de registrosde configuracion y de estado. De esta manera, mediante un traductor delprotocolo PCI-Express a este protocolo se pueden manejar dichas peticionesdel software de manera sencilla.

La actualizacion de reglas se realiza mediante escrituras por parte delsoftware hacia la tarjeta mediante el protocolo de LocalBus. En dichas es-crituras el direccionamiento hace referencia al resultado de la funcion hashsobre una o varias direcciones IP y los datos a escribir son los valores defiltrado deseados para dichas direcciones IP. La busqueda de reglas se rea-liza de forma analoga a la escritura. En este caso, la direccion de escriturahace referencia a los datos que se desean leer y estos son devueltos por elsistema que contiene dichas reglas. Normalmente, el tamano de las memo-rias es menor que el tamano necesario para las reglas, por lo que funcion dehash presentara colisiones, dando falsos positivos, que seran resueltas por elsoftware finalmente.

6.3.3. Protocolo FrameLink

La transmision de las tramas se realiza mediante el protocolo FrameLink,mostrado en la Figura 16, variante del LocalLink capaz de diferenciar laspartes por las que esta constituido el mismo. El ancho de los datos es de128bits y la frecuencia de transmision es de 125MHz.

Figura 16: Transferencia FrameLink [15]

35

Jaime J. Garnica

CLK: FrameLink es un bus sıncrono, todas las transferencias se hacenen flanco de subida de CLK. En el caso de NetCOPE, el reloj es de 125MHz.

SRC RDY N, DST RDY N: Senales activas a nivel bajo que indican sila fuente (SRD RDY N) o el destino (DST RDY N) estan preparados.Una palabra de datos entre fuente y destino se considera transferidacuando hay un flanco de reloj de CLK con SRC RDY N y DST RDY Ncon ambos a 0.

SOF N, EOF N: Senales activas a nivel bajo que usa la fuente paraindicar el inicio (SOF N) y la finalizacion (EOF N) de trama.

SOP N, EOP N: Senales activas a nivel bajo que usa la fuente paraindicar el inicio (SOP N) y la finalizacion (EOP N) de una parte dela trama. Cuando la trama tiene cabecera Pacodag, tendra dos partes(cabecera y trama, ver Seccion 5.1.2).

DATA, REM: Los datos en sı, que vendran en un bus de 8 (250 MHz) o16 (125 MHz) bytes. La senal REM es valida al finalizar cada parte dela trama (EOP N a 0) y se usa para indicar cuantos bytes son validos enla ultima transferencia, por si el tamano de la trama no es multiplo de8 o 16 bytes. REM vale uno menos el tamano de la ultima transferenciaen bytes.

6.3.4. Flujo de paquetes

Para manejar el flujo de paquetes a lo largo de la solucion se ha creadoun bloque de transferencias FrameLink que envuelve la aplicacion en lasconexiones de dicho protocolo con los perifericos. Este bloque contiene todaslas FIFOs que comunican las diferentes conexiones FrameLink, y ademasimplementa el switch que permite que por la interfaz de red de salida semande trafico proveniente tanto del bridge como del propio host. La Figura 17muestra la arquitectura de los modulos de contencion del flujo de paquetes.

Los modulos FIFO CONTROL son basicamente FIFOs que permiten ais-lar los tiempos de proceso de la aplicacion del resto de elementos de la pla-taforma NetCOPE. El primer problema es que el filtro tiene que acceder ala memoria de direcciones. Aunque este acceso se puede hacer a mayor tasade la que llegan los paquetes, pues esta segmentado (pipeline), la latenciaque se tiene no es despreciable. Por esa razon hay anadir una FIFO antes delfiltro para absorber la latencia de acceso a memoria. Por otro lado, el traficodel filtro no se saca directamente por la interfaz de salida, sino que hay que

36


Figura 17: Sistema de contencion del flujo de paquetes

agregar tambien el trafico que proviene desde el host. Por eso es necesarioanadir sendas FIFOs antes del switch para almacenar el trafico de una fuentemientras se cursa el trafico de la otra. Los modulos FIFO CONTROL son pa-rametrizables en terminos de las cabeceras Pacodag. Se puede especificar si elstream FrameLink de entrada tiene cabecera o no, y si se desea que se eliminea la entrada o se anada a la salida. De esta manera, con un mismo modulo sepuede manejar diferentes conexiones FrameLink que incluyen o no cabecerasPacodag. Para implementar las FIFOs de los modulos FIFO CONTROL seusa la herramienta Coregen de Xilinx. Estos modulos incluyen una salida quecuenta los paquetes cursados, que se hace disponible al host a traves de losregistros de control, como se vera en apartados posteriores. Finalmente, elmodulo SWITCH es una sencilla maquina de estados que en modo round-robin distribuye el trafico proveniente de sus dos entradas A y B hacia lasalida C.

6.3.5. MIG

Este protocolo se usa en la interfaz del controlador de memoria proporcio-nado por Xilinx a traves de la aplicacion MIG (Memory Interface Generator,del ingles, generador de interfaz de memoria). Para memorias QDR-II, lainterfaz con el controlador de memoria usa estas senales:

AD W N: Solicitud de escritura en la FIFO de direcciones de escritura

37

Jaime J. Garnica

AD WR: Entrada a la FIFO de direcciones de escritura

D W N: Solicitud de escritura en la FIFO de datos de escritura

BWL N, BWH N: Byte enable de los datos en la FIFO de datos deescritura

DWL, DWH: Entrada a la FIFO de datos de escritura

WR FULL: Flag de FIFO de escritura llena

R N: Solicitud de escritura en la FIFO de direcciones de lectura

AD RD: Entrada a la FIFO de direcciones de lectura

QRL,QRH: Dato leıdo

QR VALID: Flag de dato leıdo valido

RD FULL: Flag de FIFO de lectura llena

CAL DONE: Flag que indica si la calibracion inicial de la interfaz conla memoria se ha realizado con exito

Es necesario considerar que el controlador de memoria usa FIFOs paraalmacenar las solicitudes de lectura y escritura y mandarlas en modo pipelineal dispositivo. Puesto que el reloj de la aplicacion podrıa ser diferente al dela memoria (aunque no es el caso de este proyecto), las FIFOs podrıan llegara llenarse, por eso el controlador incluye las senales WR FULL y RD FULL.

La Figura 18 muestra una escritura tıpica en una QDR con rafagas delongitud 4, como las que usa la tarjeta COMBO. Una vez que la calibracionde la interfaz ha terminado con exito, Las direcciones y los datos se puedenmandar a la FIFO de escritura, indicandolo mediante la activacion de lassenales AD W N y D W N durante un ciclo de reloj. Hay que tener en cuentaque como la longitud de las rafagas es 4, hay que mandar 4 datos en total,dos en cada ciclo de reloj (se pueden mandar dos datos por ciclo de relojporque la memoria tiene una interfaz DDR). Una vez que se han mandadolos 4 datos en dos ciclos de reloj, se puede escribir la siguiente rafaga.

Por otro lado, la lectura sigue un proceso similar, vease la Figura 19. Semanda una direccion a la FIFO de escritura y se activa la senal R N duranteun ciclo de reloj. Tras un cierto numero de ciclos de reloj, la memoria de-vuelve 4 datos, dos por ciclo de reloj. El controlador usa la senal QR VALIDpara indicar que los datos de lectura son validos. Al igual que en el caso deescritura, hay que tener en cuenta que se debe dejar un ciclo de reloj entresolicitud y solicitud de lectura, puesto que las rafagas son de 2 ciclos (4 datosen total).

38


Figura 18: Lectura MIG 3.1. QDR-II [20]

Figura 19: Escritura MIG 3.1. QDR-II [20]

6.3.6. Actualizacion y busqueda de reglas

Para manejar las memorias se usa el controlador proporcionado por Xilinxa traves de su core MIG (Memory Interface Generator). La interfaz de acce-so al MIG, que se describe en el punto anterior, es sustancialmente diferenteal Local Bus. Basicamente, el acceso a las memorias se resuelve mediantedos bloques. Primeramente, QDR SWITCH sirve para dar servicio a los dosbloques que necesitan tener acceso a las memorias: el filtro, y el host paraactualizar la tabla de direcciones restringidas. QDR SWITCH recoge las pe-ticiones de ambos bloques y las va procesando de una manera ordenada. Por

39

Jaime J. Garnica

otro lado, QDR SWITCH no proporciona directamente una interfaz LocalBus, si no que para mayor sencillez ofrece una interfaz similar a la del MIG.La conversion entre estos dos tipos de interfaces (Local Bus y MIG) se haceen los bloques LBEP2QDRFIFOS.

6.4. Proceso de filtrado

Los contenidos del bloque FILTER se muestran en la Figura 20. El filtradopropiamente dicho lo hace el bloque FILTER NI CTRL. Este bloque recogeel trafico de la interfaz de red a traves del puerto IN, y parsea los paquetespara obtener las direcciones IP fuente y destino. Una vez que lo ha hecho, lasmanda al bloque FILTER NI SELECT, indicando que hay direccion validaactivando los flags IP SRC RDY e IP DST RDY. Una vez que este moduloha hecho la busqueda en las memorias, devuelve el resultado en RESULT, yactiva el flag de RESULT RDY. RESULT es un bit que indica si el paquetese pueden reenviar o no, porque alguna de las direcciones esta restringida.Dependiendo de este bit, el paquete se saca bien por el puerto NET o por elpuerto DMA.

Figura 20: Modulo de filtrado de paquetes

40


FILTER NI SELECT se encarga de realizar el hash de las direcciones IPpara calcular la direccion de la memoria de tablas donde se debe buscar. Elcomponente que hace esta busqueda es QDR IP SEARCH, que usa para elloel bloque CRC32 disponible en las FPGAs de Xilinx para calcular este hash.El acceso a las memorias se hace usando el protocolo Local Bus, que se hadescrito en la Seccion 6.3. Existe un bloque QDR IP SEARCH para cada unade las memorias, pero en un momento dado pueden llegar dos direcciones IPfuente (IP0 SRC e IP1 SRC) y dos destino (IP0 DST e IP1 DST), puestoque hay dos puentes en la FPGA. Para ello, es de vital importancia que tan-to FILTER NI SELECT como QDR IP SEARCH puedan trabajar en modopipeline, para poder optimizar el acceso a la memoria de direcciones. Esto seconsigue implementando un mecanismo de colas circulares, donde las solici-tudes, que se pueden hacer una por ciclo de reloj, se almacenan en la cola, yse van sacando segun se van obteniendo los resultados.

El bloque FILTER tiene un puerto de entrada parameters que es un busque contiene los parametros de configuracion, en particular las senales BRID-GE01 y BRIDGE10 para indicar si se activan los puentes o no, y la senalLIST MODE para configurar los puertos en modo lista blanca o lista negra.Estas senales se corresponden con los parametros SBRIDGE IOCTIPMODE,SBRIDGE IOCSNEWBRIDGE y SBRIDGE IOCSDELBRIDGE del Swift-Bridge.

Finalmente, FILTER exporta el numero de peticiones y respuestas obte-nidas de cada una de las memorias a traves de los puertos REQ COUNT0,REQ COUNT1, RES COUNT0 y RES COUNT1. Esta informacion se pasaal modulo LBEP2QDR para que sea accesible por parte del host, y se utilizapara asegurar que todos los paquetes se consultan, y que todas las consultasa la memoria son contestadas, esto es, para asegurar el buen funcionamientodel filtro y comprobar que no hay bugs en su implementacion.

En el caso del flujo de trafico de red se debe subrayar la division en sub-conjuntos u operaciones basicas como son la recepcion y parseo de tramas, labusqueda de reglas, el filtrado de trafico al software y el reenvıo de trafico an-teriormente filtrado y descartado por el software. Dichas operaciones debenrealizarse para cada una de las tramas recibidas de forma continua, es decir,sin anadir ningun tipo de retardo entre las mismas, con el fin de poder man-tener la tasa de lınea de la red. Para ello se ha creado un sistema en pipelineque realice cada una de las acciones en fases diferentes y ası poder analizaruna trama mientras la anterior es reenviada o la siguiente es recibida.

41

Jaime J. Garnica

6.4.1. Parseo de tramas

Una vez recibidas las tramas en los modulos de control de entrada FIL-TER NI CTRL, estas mismas se deben almacenar mientras se lleva a cabo labusqueda de sus correspondientes direcciones IP en las memorias de reglas,manteniendolas en la cola hasta que se decida cual es el destino al que seranenviadas por el filtro. Seran enviadas al DMA en caso de ser filtradas y a lared por la interfaz opuesta a la de su recepcion en caso de no serlo.

Para realizar el filtrado es necesario conocer el valor de las direcciones IPque llegan en las tramas, es decir, hay que acceder a las cabeceras de nivel3 , o nivel de red, para las tramas Ethernet/IP. El metodo mas comun es elparseo de las tramas, es decir, descomponer las mismas en los campos quelas conforman. Las tramas de Ethernet/IP tienen tanto cabecera Ethernet(Figura 21) como cabecera IP (Figura 22). Por ello, si cada ciclo de reloj sereciben 128 bits, o 16 bytes, se debe esperar al segundo ciclo de trama parapoder recoger la direccion IP de origen y la mitad de la destino y al tercerciclo para completar esta ultima.

Figura 21: Cabecera Ethernet

Figura 22: Cabecera IP

42


6.4.2. Busqueda de reglas

Una vez parseada la trama se envıan las direcciones IP a los modulosencargados de realizar las busquedas en las memorias, estos son los llamadosFILTER IP SEARCH. El protocolo empleado en este caso es el de Local Bus,tanto para comunicar las direcciones IP entre los modulos de filtrado comopara enviar peticiones a las memorias. Concretamente se emplea la lectura,donde la direccion de busqueda es la funcion de hash realizada sobre la direc-cion IP a buscar, tal y como se ha guardado anteriormente en memoria. Taly como esta explicado en el apartado 5.2.3. Esta funcion hash devuelve unvector de bits con un ancho necesario para indexar cada bit que se almacenaen la memoria. Por ello, los modulos de busqueda de reglas deben realizarel mismo hash para realizar la busqueda de las direcciones IP del paqueteque se esta comprobando, empleando los bits de mayor peso (tantos comoel ancho de direccionamiento de la memoria). Una vez recibido el resultadodesde la memoria se debe indexar el bit que hace referencia a la direccion IPbuscada usando como ındice los bits de menor peso del hash (tantos comohagan falta para indexar el ancho de datos que se guardan en memoria).

6.4.3. Filtrado de tramas al software

Una vez se ha comprobado que el paquete que se esta gestionando y suresultado es positivo, es decir, su direccion IP se encuentra en la memoriacomo sospechosa, dicho paquete debe ser enviado al software para este querealice la comprobacion de la URL. Este envıo se realiza mediante DMA,utilizando el protocolo FrameLink de nuevo.

Una vez el software ha comprobado la URL del paquete sospechoso pue-den ocurrir dos cosas. La primera, que la URL no deba ser filtrada y por lotanto el paquete deba ser reenviado a la red y, la segunda, que el paquetesı que deba ser filtrado. En el ultimo caso el software descarta el paquete y latanto la tarjeta FPGA como la red se desentienden del mismo. En el primercaso, donde el paquete no debe ser filtrado, mediante DMA de nuevo el pa-quete es reenviado a la tarjeta. La tarjeta se encargara de integrar el paqueteen la red agregando la entrada de los paquetes que no han sido filtrado por elhardware, con los que tampoco lo han sido definitivamente por el software.

6.5. Actualizacion y gestion desde el software

El almacenamiento de las reglas de filtrado (direcciones IP), tal y como seha especificado anteriormente, se llevara a cabo mediante memorias QDR-II.Para que el filtrado sea dinamico se deben realizar actualizaciones a lo largo

43

Jaime J. Garnica

del funcionamiento de la plataforma, para lo cual es necesario implementaruna comunicacion entre el software (en este caso por el PCI-Express) y lasmemorias. Por lo tanto una traduccion desde los protocolos de transferenciadel PCIe seran necesarios, el protocolo a obtener sera nuevamente el protocoloLocal Bus.

El bloque LBEP2QDR, que es el que implemente el Rule Updating Mo-dule, se conecta directamente con el endpoint Local Bus, que recoge las peti-ciones PCIe. Su utilidad es proporcionar acceso a las memorias por parte delhost, para leer y/o actualizar las tablas de filtrado. Adicionalmente, recogeinformacion de gestion (contadores de tramas, de accesos a memorias, etc.)para permitir que se pueda controlar el estado del sistema desde el host. Estambien un bloque sencillo, que consiste principalmente en una maquina deestados que realiza la traduccion de las peticiones del PCIe y selecciona laaccion a realizar, es decir, el acceso a cada uno de estos recursos. El mayorproblema que se plantea es que el tamano de las memorias puede ser mayorque el espacio de direcciones disponible por PCIe, por lo que hay que imple-mentar un mecanismo de paginado, anadiendo un registro en el que el hostindica los n bits iniciales de la direccion a escribir.

6.5.1. Escritura de reglas en memoria

Debido a que la cantidad de actualizaciones de la tabla es mucho menora la cantidad de comprobaciones de direcciones IP de los paquetes de la red,este modulo no necesita presentar un pipeline, lo cual, a su vez ayuda a des-cargar la carga de peticiones en memoria y dar ası prioridad a las busquedasde reglas. La escritura de reglas en memoria se realiza de forma analoga ala busqueda de las mimas desde el motor de filtrado. En este caso se em-plea la operacion de escritura del protocolo Local Bus. El ancho de datosproporcionado por el protocolo Local Bus tras la traduccion desde el PCIepuede ser menor que el ancho de direccionamiento requerido. En ese casose puede llevar a cabo un paginado, es decir, una primera escritura en unregistro que indique el valor de la pagina, o lo que es lo mismo, el valor delos bits de direccion mas altos; mientras que el valor del campo direccion delas transferencias haran referencia a los valores mas bajos de dicha direccionen memoria.

Una vez recogida la direccion de la transferencia, los bits menos significa-tivos de la misma son, a su vez, retirados del direccionamiento en el accesoa memoria. Esto se debe al ancho de palabra recibido en cada peticion, yaque solo queremos resolver el valor de un bit. Por lo tanto esos ultimos bits,tantos como sean necesarios para indexar un bit en la palabra recibida, seranempleados una vez obtenida la respuesta de la memoria. En el caso de la

44


escritura, se debera leer el valor actual de la direccion de memoria, actuali-zar el bit para el que se ha pedido el cambio y volver a escribir dicho valoren memoria. Esta operacion se puede realizar a nivel de FPGA o desde elsoftware de actualizacion del driver.

6.5.2. Registros de control

Como hemos indicado en apartados anteriores, la comunicacion con elsoftware no debe limitarse a la funcionalidad concreta de la aplicacion sinoque puede extenderse para obtener un control y flexibilidad mayores de lamisma. En el caso de esta aplicacion de filtrado se pueden emplear diferentesregistros para funcionalidad extra como el paginado, el modo de filtrado (listanegra o lista blanca), la activacion o desactivacion del filtrado (bypass), de-puracion/verificacion del funcionamiento real y comprobacion de estadısticasen el flujo de tramas y peticiones a memoria.

6.6. Acceso a memorias

El bloque QDR SWITCH, que implementa el gestor de acceso a la me-moria, recibe las solicitudes de acceso a la memoria del filtro y del host, enocasiones de forma simultanea, y las multiplexa. Mediante esta gestion sehabilita la actualizacion de reglas sin cortar el trafico, cumpliendo el requisi-to planteado en la Seccion 4.3. Para ello usa una aproximacion round-robin,inspecciona alternativamente ambas interfaces y si hay una solicitud de lec-tura o escritura, la envıa a la memoria y almacena la referencia en una colacircular, de donde se extrae cuando el resultado es devuelto por la memoria.Esta aproximacion de cola circular es la misma que se empleo en los modulosdel filtro, y permite implementar de una manera muy efectiva el acceso enmodo pipeline a los datos.

El bloque LBEP2QDR FIFOS, que implementa las fifos que contienen laspeticiones a memoria delante del gestor de acceso, es mostrado en la Figu-ra 23. Este bloque hace de frontera entre el dominio de reloj de la aplicaciony el de las memorias. Tambien efectua la conversion de protocolos entre Lo-cal Bus y el protocolo del controlador de memoria MIG, descrito en el puntoanterior. La implementacion de este modulo es relativamente sencilla, y sebasa en FIFOs creadas mediante la herramienta Coregen de Xilinx. Cuandohay una solicitud de lectura o escritura por parte de la aplicacion (lado LocalBus) se almacena en la FIFO, y por el otro lado se usa el flag de vacıo paradetectar que hay una transaccion pendiente y mandarla al switch. Cuandoel switch asiente la transaccion, se activa WR REQ o RD REQ, y de estamanera se sabe que la transaccion pendiente se puede retirar de la FIFO. En

45

Jaime J. Garnica

el caso de una escritura el proceso termina aquı, y para las lecturas, cuandoel dato esta disponible (QR VALID activo), se almacena en una FIFO queva hacia el lado Local Bus. La senal de FIFO no vacıa es la que se usa paragenerar la senal DRDY de dato disponible, y al mismo tiempo se usa tambienpara retirar automaticamente el dato de la FIFO de lectura. De esta mane-ra, se consigue implementar el paso entre dominios de reloj de una maneraeficiente y compacta.

MEMORY FIFO IN

ADDR

DWR

DRD

RD

DRDY

WR

ARDY

WR F

E RD

DATA_OUT DATA_IN

WR F

E RD

DATA_OUT DATA_IN

WR F

E RD

DATA_OUT DATA_IN

WR F

E RD DATA_OUT DATA_IN

125MHz 250MHz

QDR_d_w_n

QDR_ad_w_n

QDR_r_n

QDR_dw

QDR_qr

QDR_qr_valid

QDR_r_ad

QDR_w_ad

ARDY

ARDY QDR_switch_req

QDR_switch_req

QDR_switch_req

Figura 23: Traduccion de LocalBus a MIG

6.7. Integracion de modulos en pipeline

Para conseguir que el sistema funcione a tasa de lınea, y concluir con elloel requisito establecido en la Seccion 4.2, lo mas importante es no insertarningun retardo entre paquetes. Para ello se debe implementar el sistemade manera segmentada, o en pipeline. Es decir, cada una de las tareas quese realizan sobre el paquete deben estar separadas en fases, de manera quemientras un paquete esta en una de ellas, el siguiente lo este en la anterior (porejemplo, mientras un paquete esta esperando el resultado de su busqueda, unoposterior puede ser parseado para realizarse su comprobacion en memoria).

Aunque todos los modulos tienen un pipeline interno, en rasgos generalesse pueden dividir las fases tal y como estan presentadas en la Figura 24. estascorresponden a los modulos ya explicados en este apartado 5. El primero de

46


ellos es el modulo de filtrado, cuyas fases del pipeline se puede diferenciaren (1) parseado de paquetes y recoleccion de direcciones IP, (2) hash de ladireccion IP, (3) envıo de la peticion de lectura al modulo de acceso a laQDR-II, (4) espera de la respuesta y (5) resolucion de reenvıo del paquete.En el modulo de actualizacion de reglas, el pipeline se divide en (1) recepcionde la peticion PCIe, (2) traduccion de la peticion, (3) envıo de solicitud almodulo de acceso a la QDR-II y (4, en caso de lectura) espera de la respuestay reenvıo de la misma al PCIe. Por ultimo, el pipeline de acceso a la QDR-II,debe adaptarse a los dos anteriores, por lo tanto las fases del mismo son (1)seleccion de la entrada de peticion, (2) acceso a la memoria y (3, en caso delectura) reenvıo de la respuesta al modulo correspondiente.

Packet

Parsing

IP

Hashing

Result

Waiting

Packet

Output

PCIe

Request

Request

Translate

PCIe

Result

Request

Selection

QDR-II

Request

QDR-II

Result

QD

R-I

I

Access

Module

Ru

le

Up

dating

Module

Packet

Filt

eri

ng

Module

Figura 24: Pipeline de la aplicacion

7. Implementacion

7.1. Arquitectura basica

Tal y como se explico en la Seccion 5, la arquitectura se ha implementadopara un entorno de desarrollo de 10Gbps. Principalmente para la plataformade INVEA Tech expuesta en la Seccion 5.1, donde se especifica un entornode desarrollo en la Figura 5.

7.1.1. Aplicacion de filtrado

Este firmare funciona bajo una frecuencia de reloj para el sistema de125MHz y una frecuencia de acceso a memorias de 250MHz. La recepcionde paquetes se realiza a la velocidad del sistema con un ancho de datos de

47

Jaime J. Garnica

128bits, por lo que es la frecuencia es mas que suficiente para alcanzar los10Gbps (125MHz ∗ 128bits = 16Gbps). Por otro lado, la frecuencia de lamemoria permite 250 millones de accesos por segundo, mucho mayor quelos 14,8 millones de accesos requeridos por cada interfaz, incluso el doble alfiltrar ambas interfaces, que es referente a la tasa de paquetes recibidos a10Gbps.

7.1.2. Acceso a memorias

El tamano total de las memorias QDR-II 72Mbits, descontando los bitsde paridad se emplean 64Mbits, es decir 226bits. Por lo tanto, el tamano deldireccionamiento es de 26 bits, dejando los 6 bits mas altos del CRC32 sinemplear. El numero de colisiones es entonces de 232−226 = 26 = 64 colisionespor cada direccion del hash. En cuanto al direccionamiento de las reglas, sepuede entender fijandose en la Figura 25. Por un lado, ya que el numerode bits por direccion IP es 1 y el ancho de palabra de la comunicacion porLocalBus es mayor (32 bits), se debe direccionar dentro de dicha palabrala busqueda del bit. Para ello se emplean los bits de menor peso del hash(para palabras de 32 bits se emplean 5 bits de direccionamiento). Por otrolado, debido a que el ancho de direccionamiento del LocalBus (16 bits) esmenor que el de las memorias (20 bits), se lleva a cabo un paginado en elLocalBus. Por lo tanto, los bits me mayor peso obtenidos en la funcion dehash se emplean para referirse al paginado (4 bits en este caso).

32-bit IP

CRC 32 (25 Válidos)

FILTER QDR_ADDR (20) + BIT_IN_WORD (5)

CRC 32 (25 Válidos)

PAGING QDR + PAGE (9) + ADDR_IN_PAGE(10) + BIT_IN_WORD

QDR_ADDR (20)

Figura 25: Hashing y direccionamiento basado en las direcciones IP

48


7.1.3. Comunicacion con el host

En cuanto a la comunicacion entre el host y la tarjeta, tal y como seexplico en la arquitectura, el diseno presenta una serie de registros accesiblesvıa PCIe. El espacio de direcciones del LocalBus del PCIe es el mostrado enla Tabla 1.

Tabla 1: Registros de control

Offset Descripcion

0x2XXXX Acceso a la QDR-II (15:0)

0x30000 Pagina de acceso a la QDR-II (25:16)

0x30010 Modo de lista de filtrado (blanca/negra)

0x30020 Puenteo de conexion IF0 a IF1

0x30030 Puenteo de conexion IF1 a IF0

0x30100 Contador de paquetes: Entrada 0

0x30110 Contador de paquetes: Salida 0

0x30120 Contador de paquetes: Filtrados 0

0x30130 Contador de paquetes: Reenviados 0

0x30140 Contador de paquetes: No filtrados 0

0x30150 Contador de paquetes: Entrada 1

0x30160 Contador de paquetes: Salida 1

0x30170 Contador de paquetes: Filtrados 1

0x30180 Contador de paquetes: Reenviados 1

0x30190 Contador de paquetes: No filtrados 1

0x301A0 Contador de solicitudes a la QDR 0

0x301B0 Contador de respuestas de la QDR 0

0x301C0 Contador de solicitudes a la QDR 1

0x301D0 Contador de respuestas de la QDR 1

0x301E0 Registro de control E - N/A

0x301F0 Registro de control F - N/A

49

Jaime J. Garnica

7.2. Integracion hardware - software

El sistema requiere que la comunicacion entre hardware y sofware sea im-plementada. El desarrollo que el equipo de INVEA Tech proporciona permiteque los paquetes que se envıan a traves del DMA sean tratado como si de unatarjeta de red convencional se tratase gracias a un driver de red desarrolladopor ellos. Sin embargo, la comunicacion de las reglas, ası como el control delsistema mediante el acceso a registros, desde el punto de vista del hardware,es particular del diseno del trabajo. Por lo tanto, es necesario desarrollar undriver propio que gestione las peticiones PCIe y a la vez proporcione un APIsimilar a la que CCOTTA emplea en soluciones solo software.

7.2.1. API

El driver desarrollado es un modulo del kernel que se debe cargar antesde lanzar las aplicaciones software. Para que estas sean capaces de emplear eldriver, como se establecio como requisito en la Seccion 4.5, se ha desarrolladouna API, la cual presenta una serie de primitivas de funciones en C quepueden ser empleadas por las aplicaciones. Dichas funciones de la API seencargan de enmascarar las llamadas al modulo kernel mediante IOCTLs.La funcionalidad que la API ofrece se enumera de la siguiente manera:

ip mode: establece el modo de la lista de direcciones IP almacenada enmemoria. Las dos opciones que hay es lita negra, en el caso en el quelas direcciones almacenadas deban ser boqueadas; y lista blanca, en elcaso en el que solo las direcciones IP de la lista deben ser reenviadas ala red.

clear ips: vacıa la lista de direcciones IP, dejando todos los valores delas memorias a 0.

ip add: anade una direccion IP recogida como parametro a la memoria.

ip del: elimina una direccion IP de la lista de direcciones, se encargade eliminar solo la IP indicada, sin eliminar las demas direcciones cuyohash colisiona.

new bridge: puentea dos interfaces.

del bridge: elimina un puente previamente creado.

get register: permite leere el registro de control que se encuentre en eloffset indicado (ver Tabla 1).

50


set register: funcion analoga a la anterior que cambia el valor del regis-tro en lugar de leerlo.

7.3. Plataforma avanzada

Para la plataforma avanzada basada en la tarjeta de HiTech Global semodifican ciertos aspectos de la arquitectura. La razon principal es que sedebe crear el entrojo que conecta con los perifericos, de manera que la apli-cacion de filtrado desarrollada para la plataforma basica pueda ser empleadapara esta plataforma sin tener que modificarse la interfaz. Como se puedeobservar en la Figura 26, los principales cambios en esta plataforma son lossiguientes:

Figura 26: Arquitectura FPGA de la plataforma avanzada

Creacion del protocolo FrameLink: se debe implementar la traducciondel protocolo LocalLink, que genera el core de Xilinx para las inter-faces de red, al protocolo FrameLink, que emplea INVEA Tech en sudesarrollo.

51

Jaime J. Garnica

Desaparicion del PACODAG: la cabecera creada por INVEA Tech noes empleada en la aplicacion, por lo que en esta arquitectura no se debetener en cuenta su generacion.

Uso de 4 interfaces: en este escenario, los paquetes filtrados no se envıanpor DMA al software, sino que es reenviado por otra interfaz hacia otroPC. Para ello, el protocolo FrameLink que envıa al DMA los paquetesse conecta a una de las 2 interfaces nuevas.

Configuracion de las interfaces de red (MDIO): las interfaces de reddeben ser configuradas, por lo que se crea un sistema basado en Micro-blaze que lo haga.

7.4. Lenguajes HLS

Para la implementacion con lenguajes HLS, se han desarrollado una se-rie de modulos basicos y se han simulado para observar el funcionamientode los compiladores. Debido a la complejidad de los modulos creados porlos compiladores no se pueden validar de forma trivial. Por ello, un primeracercamiento basado en simulaciones ha sido realizado para este trabajo conel finde presentar una evaluacion posterior. Los modulos elegidos para es-te trabajo han sido los encargados de controlar la entrada de los paquetesdesde las interfaces y de parsear las direcciones IP de cada paquete, con elfin de enviarlas a los modulos de busqueda. Tal como se ha explicado en laSeccion 5.3.5, los compiladores empleados son HandelC y AutoESL.

7.4.1. HandelC

Este lenguaje utiliza un subconjunto de C, al que se ha anadido nuevasintaxis y nuevos componentes, como son ciertas estructuras de datos, loscanales, que permiten el envıo de datos entre funciones a modo de FIFO.Esto permite al desarrollador tener un mejor control y posibilidades propiasdel hardware, pero no le permite realizar una potabilidad directa de aplica-ciones, ni modulos, ya desarrolladas en software, debido a la necesidad deintroducirse en el codigo. Se puede observar en las Figuras 27 y 28 el canalllamado ”dma”, que indica el resultado para la salida de los paquetes por lared, en caso de valer 0, o por el dma.

En esta implementacion, el conjunto de sentencias dentro de cada unode los bucles se ejecutan en paralelo, al emplearse la directiva ”par”; encaso contrario se ejecuta una sentencia cada ciclo de reloj, es decir, en modosecuencial. A modo de prueba, en el canal llamado ”dma”se inserta siempre elresultado de la busqueda, en esta prueba siempre el mismo valor, que indica

52


Figura 27: Control de entrada en HandelC

que el paquete no se filtre. En la imagen 28 se muestra la secuencia que seejecuta cada vez que se recibe un valor por el canal ”dma”, seleccionandola salida del paquete correspondiente por la red o por el DMA, segun dichovalor recibido.

Figura 28: Decision de destino segun resultado en HandelC

7.4.2. AutoESL

A diferencia de HandelC, AutoESL emplea la misma sintaxis de C, sinmodificar nada. Por ello, la potabilidad de ciertas aplicaciones es posible,siempre que las librerıas que emplea esten disponibles para AutoESL. Comose muestra en la Figura 29, la sintaxis es identica, donde cada una de las fun-ciones se compila en un modulo de lenguaje RTL. Para conseguir un uso derecursos como FIFOs, memorias y otros metodos hardware, los parametros

53

Jaime J. Garnica

de las funciones son compilados mediante el empleo de directivas. Por ejem-plo, un puntero a memoria puede compilarse con una interfaz de FIFO, decontrol de bus o de memorias. Los parametros que pasan por valor, puedenser compilados siguiendo diferentes metodos, como es emplear una banderade ”valid”que indica que el valor es valido en ese ciclo, no indicar cuando esvalido o no, etc.. El codigo mostrado es un fragmento de una funcion quecontrola la entrada del protocolo FrameLink (ver Seccion 6.3.3).

Figura 29: Control de entrada en AutoESL

8. Validacion hardware

La verificacion del diseno FPGA se ha planteado a dos niveles tal ya ex-puestos en la Seccion 5.3. Primeramente se ofrece un entorno de simulacionVHDL del modulo de aplicacion, que permite hacer una primera depuraciondel sistema y eliminar los errores que ocurran en los casos basicos de prueba.Para la depuracion en pruebas reales de trafico se plantea una aproximacioncomplementaria, basada en la herramienta ChipScope que permite una vi-sualizacion en tiempo real de las senales dentro de la FPGA, a traves de lainterfaz JTAG. Por ultimo se presenta la arquitectura de la integracion delsistema software y hardware sobre el que se ha validado la solucion completa.

54


8.1. Pruebas unitarias

El diseno de los casos de pruebas de simulacion durante el desarrollo deltrabajo se han dividido en diferentes niveles. El primer nivel son las pruebasunitarias, es decir, las pruebas individuales de cada uno de los modulos quese han implementado y han sido presentados en la Figura 12. Algunos delos mas importantes, en lo que a simulacion unitaria se refiere, pueden serel modulo de busqueda y creacion de hash (ver Figura 30), necesario paracomprobar una coherencia entre el hash hardware y el hash software.

Figura 30: Simulacion del hash de una direccion IP entrante

8.2. Pruebas de integracion

Una vez realizadas las pruebas unitarias se puede considerar el buen fun-cionamiento, a nivel de simulacion, de los modulos individuales. Partiendo deesa base se integran los modulos unitarios en modulos de mas complejos querequieran el funcionamiento conjunto de los mismos. Se consigue de ese mo-do probar que la comunicacion entre modulos y su funcionamiento conjunto(tanto latencias, como peticiones y respuestas entre ellos) es correcto. Losmodulos complejos que mas importancia tienen en el desarrollo del trabajoson el motor de filtrado, la busqueda direcciones IP en memoria, el procesa-miento de peticiones a la QDR por ambos sentidos y la transformacion depeticiones por PCIe en los protocolos LocalBus y consulta de registros.

Finalmente se debe realizar la prueba de integracion de todo el siste-ma. Para ello, la Figura 31 muestra la estructura en el entorno de simulacionVHDL que se ha desarrollado. El testbench integra los BFMs (Bus FunctionalModels) proporcionados por INVEA para Local Bus y FrameLink, y ademasincluye el modelo Verilog de la familia de memorias Samsumg k7rxxxx84x,compatible con la QDR-II de Cypress disponible en la placa COMBO-LXT.

55

Jaime J. Garnica

Los BFMs permiten generar transacciones en los buses de una manera sen-cilla.

Figura 31: Arquitectura del entorno de simulacion

Como ejemplo, el trozo de codigo del testbench mostrado en la Figura 32se usa para escribir un valor por el Local Bus y mandar una trama por lainterfaz 1. Como se puede observar, simular una escritura en el Local Bus estan sencillo como hacer una llamada a lb op, y para mandar una trama poruna interfaz FrameLink se usa la funcion SendWriteFile. Esta funcion hacereferencia a un archivo que contiene el volcado hexadecimal de la trama, unejemplo de este archivo se presenta en la Figura 33. A la izquierda de lafigura se muestra una trama con cabecera Pacodag, $ representa la fronteraentre partes de la trama. A la derecha se muestra la misma trama pero sincabecera. En el entorno de INVEA Tech, las tramas que vienen de la interfazde red tienen cabecera, pero las que viene del motor DMA no.

El resultado de la simulacion del todo el sistema se puede observar enla Figura 34. En la figura se muestra como el trafico entrante llega por lainterfaz 1, siguiendo el protorocolo FrameLink, y las peticiones de escrituraen memoria por el LocalBus se realizan de forma simultanea, sin cortar eltrafico. Esto hace que las interfaces de MIG de las memorias QDR-II activensus senales de escritura y lectura, procedentes del software y de las interfaces

56


Figura 32: Ejemplo de codigo de testbech

Figura 33: Estructura del fichero de ejemplo de trama

de red correspondientemente, y se recogen los valores de la respuesta paradecidir que el trafico salga por una interfaz o por otra, en este caso por lasalida 0 todos los paquetes. Se puede ver como no hay corte de trafico durante

57

Jaime J. Garnica

las peticiones de escritura desde el LocalBus. Otro comportamiento que sepuede comprobar es que el retardo es constante entre paquetes a la salida delfiltro, lo que nos indica que el pipeline funciona correctamente.

Figura 34: Simulacion general del sistema

8.3. Validacion en tiempo real

La Figura 35 muestra una captura de pantalla de la herramienta Analyzeren la que se monitorizan las senales correspondientes al protocolo FrameLinkque generan los controladores de las interfaces de red a la entrada de paquetesde la interfaz 1 (prefijo IN1 ) y el parseo de los mismos para realizar labusqueda de las direcciones IP de destino y origen (prefijo NI1 IP ). Tras elretardo correspondiente al acceso a la memoria QDR-II se recibe el valor delresultado de las busquedas (senales NI1 RESULT y NI1 RESULT RDY) y

58


se procede a reenviar la trama con el protocolo FrameLink por la interfaz desalida (prefijo OUT1 ).

Figura 35: Captura de validacion en tiempo real con ChipScope

8.3.1. Integracion 64b - 32b

La plataforma de INVEA trabaja con un sistema operativo de 64 bits.Sin embargo, la aplicacion de CCOTTA esta desarrollada para un entorno de32 bits. Para solucionar este problema se evaluaron tres posibles soluciones:

Trabajar con la aplicacion CCOTTA como una aplicacion de 32 bitssobre un Linux de 64 bits. El problema es que CCOTTA hace llamadasdirectas a los drivers suponiendo un entorno de 32 bits, por lo que estasolucion no serıa posible.

Migrar la aplicacion CCOTTA a 64 bits. La migracion de una aplicacionde la magnitud y aplicacion como CCOTTA, es un proyecto en sı mismoy se escapa de los recursos de este proyecto.

Usar virtualizacion para tener un sistema operativo de 32 bits dentrode la maquina de INVEA de 64 bits. Esta solucion se vio como la masfactible ya que permitıa validar la solucion si realizar un desarrolloextremadamente complicado, como las soluciones anteriores.

59

Jaime J. Garnica

La solucion basada en virtualizacion se resume en la Figura 36. Estafigura muestra la maquina real (INVEA) que tiene un sistema operativode 64 bits. Dentro de ella, utilizando un software de Virtual Box [22] seinstalo una maquina virtual de 32 bits. Esta maquina virtual contiene elsoftware CCOTTA de 32 bits.

Maquina real 64b Maquina virtual 32b

ceth0

ceth1

eth1

eth2

eth0

eth0

Driver real

Driver virtual

C-COTTA

Proceso virtual

PCIe

Proceso real

Figura 36: Arquitectura del entorno de virtualizacion

El sistema CCOTTA interacciona con la plataforma de INVEA de dosmaneras: (1) actualizacion de las direcciones IP a inspeccionar y (2) recep-cion, inspeccion y transmision de paquetes. A continuacion se muestra comose solucionan dichas funcionalidades con el sistema virtualizado:

Actualizacion de las direcciones IP a inspeccionar. Para actualizar lasdirecciones IP a inspeccionar se ha desarrollado un driver virtual ası co-mo dos procesos para comunicar la solicitud de CCOTTA con el driverreal. De este modo el CCOTTA envıa la solicitud al driver virtual, comosi fuese la interfaz con la tarjeta de INVEA. Este driver virtual envıalas solicitudes al proceso virtual que a traves de un socket se comunicacon un proceso real que realiza la llamada al driver real. Es este driverreal el que realiza la llamada a la tarjeta para actualizar las direccionesIP en la memoria QDR.

Recepcion, inspeccion y transmision de paquetes. Para mantener la fun-cionalidad de gestion de paquetes, se ha conectado las interfaces ceth0y ceth1 con eth1 y eth2, respectivamente. A traves de estas interfacesel C-COTTA recibe el trafico que debe ser inspeccionado. Una vez el

60


paquete es inspeccionado el CCOTTA puede elegir que hacer con elpaquete si enviarlo a la tarjeta para su transmision o descartarlo comoen su operacion normal.

Gracias a la virtualizacion, se puede validar la solucion como prueba de con-cepto, ası como el desarrollo de la tarjeta INVEA. La virtualizacion permitemantener las funcionalidades, a costa de aumentar el gasto de recursos enel servidor. Esto hace que el software, se vea gravemente afectado ya queel servidor no tiene recursos para correr a su vez el sistema de INVEA y elvirtualbox y CCOTTA encima.

9. Resultados

En este apartado se calculan los requisitos necesarios para el funciona-miento del sistema en redes a 100Gbps [12]. Para ello, son analizadas lasfrecuencias de reloj y el empleo de los recursos en la implementacion de10Gbps. Una vez calculados, se interpolan y se validan con las tarjetas basa-das en FPGA del estado del arte.

9.1. Frecuencias de reloj

Puesto que una peticion es realizada cada ciclo de reloj, alcanzar una altatasa de acceso a las memorias es crıtico con el finde mantener el rendimientonecesario. La tasa de paquetes alcanzada a 10Gbps es de hasta 14,8Mpps [11],para paquetes de 60bytes. Lo anterior implica que la frecuencia de reloj parael acceso a las memorias debe ser al menos 14,8MHz por el numero de inter-faces.Ya que hay dos interfaces, la frecuencia debe ser mas de 29,8MHz. Laactualizacion de reglas es un proceso no constante y no alcanza una tasa queaya que tener en cuenta. Por lo tanto los 125MHz del sistema y los 250MHzde las memorias son validos.

9.2. Consumo de recursos

Debido a que el ancho de palabra de las FIFOs de peticiones a las QDR-II y a que solo se hace una peticion por paquete, la seccion se centra en elsistema de contencion de paquetes que rodea a la aplicacion. Estas FIFOstienen un ancho de palabra de 128bits, tal y como las interfaces de red. Laprofundidad mınima de cada FIFO debe ser igual al numero de ciclos quese tarda en procesar la peticion de un paquete. Ya que se ha observado quedicho numero de ciclos es 15 y que la implementacion tiene 512 palabras deprofundidad, esta es mas que suficiente. El numero de FIFOs empleadas es

61

Jaime J. Garnica

de 10, 5 por cada sentido de la red. Cada una de ellas tiene un tamano de128b × 512 = 64Kb, por lo que el total del sistema es 64 × 10 = 640Kb. Laherramienta ISE ofrece un reporte llamado Design Summary, el cual ofrece lautilizacion de los recursos como se puede observar en la Tabla 2. El reporte delproceso de mapeo nos muestra que las FIFOs usan BlockRAMs y el trabajocompleto emplea el 48 % de las disponibles.

Tabla 2: Empleo de recursos para un ancho de datos de 128bits

Slice Logic Utilization Used Available Utilization

Number of Slice Registers 25,803 97,280 26 %

Number of Slice LUTs 31,330 97,280 32 %

Number of bonded IOBs 487 640 76 %

Number of BlockRAM/FIFO 103 212 48 %

Number using BlockRAM only 53

Number using FIFO only 50

Total Memory used (KB) 3,438 7,632 45 %

9.3. Rendimiento

Para medir el rendimiento del sistema en redes de 10Gbps, se conectaa la entrada del filtro un generador de paquetes sinteticos TCP/IP en cadauna de las interfaces. Este generador ha sido tambien desarrollado dentro delmarco del trabajo y se encarga de generar una serie de paquetes sinteticos,es decir, con campos preestablecidos, y enviarlos por una interfaz de red. Suimplementacion ha sido igualmente desarrollada para FPGA. Los tamanosde los paquetes varıan desde los 60 a los 1500bytes y las direcciones IP decada paquete varıan. En primer lugar, se crea un experimento en el que sereduce el tamano de los paquetes y el tiempo entre los mismo con el fin desaturar el filtro al alcanzar el maximo numero de paquetes por segundo, quees de 14,89Mpps. En segundo lugar, se crea otro experimento en el que seaumenta el tamano de los paquetes hasta el maximo, 1514 bytes, y reduciendoel tiempo entre paquetes, de manera que se alcanza la tasa de 10Gbps. Elrendimiento se muestra en la Figura 37.

62


0 100 200 3000

2

4

6

8

10

12

14

16x 10

6

time (s)

pp

s

Minimum packet size test

0 100 200 3000

2

4

6

8

10

x 109

time (s)

bp

s

Maximum packet size test

Figura 37: Evaluacion de rendimiento

9.4. Entorno OPTENET

El entorno de pruebas utilizado para evaluar la solucion desarrollada con-siste una maquina a probar, la cual se situa entre dos switches con interfacesinternas de 10Gb cada uno, y conectado una serie de tomas de 1Gb a losmismos, un conjunto variable de appliances responsables de generar el trafico(clientes) y de recibirlo y devolverlo (servidores). Cada una de las maquinasde generacion y recepcion de trafico es un appliance de prestaciones altascapaces de generar o servir trafico hasta saturar su interfaz de 1Gb. Tam-bien es posible utilizar appliances de prestaciones menores como los modelosde Optenet, alcanzandose cuotas de generacion y recepcion de 0.7Gb. Adi-cionalmente a las maquinas de generacion y respuesta, se pueden introducirmaquinas para la disrupcion de trafico, de similares prestaciones, en el ladodel servidor.

El entorno especıfico de pruebas para operador se representa en la Fi-gura 38 en la que se representan las maquinas cliente con el codigo CL, lasmaquinas servidor como SR, y las maquinas encargadas de la introduccionde disrupciones como DS.

El software utilizado para generar y recibir el trafico es tecnologıa pro-pietaria de Optenet, y posee funcionalidades como las siguientes:

Generacion de trafico multiprotocolo y mixto.

Variacion dinamica de las direcciones IP, para simular la entrada y

63

Jaime J. Garnica

Figura 38: Entorno de pruebas de OPTENET

salida de decenas a centenares de miles de clientes.

Definicion de curvas de trafico, con crecimiento y decrecimiento ba-jo demanda, y capacidad de emular trafico real segun distribucionescaptadas en operadores.

Variaciones configurables en el tiempo de ancho de banda, peticionespor segundo, y correos electronicos por segundo.

Introduccion de disrupciones como aumentos de latencia, desordenacionde paquetes, corrupcion de paquetes, etc. Esta funcionalidad permitesimular entornos reales de operadores en todos los ambitos geografi-cos, ası como probar las capacidades de las soluciones ante errores yanomalıas de red.

En el caso de las pruebas aplicadas a la solucion desarrollada, se hanefectuado las siguientes particularizaciones en el sistema de pruebas:

Se utiliza un sistema doble de clientes A500 y un A200 como genera-dores y receptores de trafico, capaces de generar hasta 2.7Gb.

No se utilizan disruptores, a fin de mantener las pruebas limpias.

64


9.4.1. Pruebas funcionales

Con esta prueba se pretende validar la funcionalidad de lectura y escriturade IPs en la tarjeta por parte de la componente software de la solucion.Para ello, se han realizado escrituras y lecturas de IPs y el paso del traficoasociado a las mismas a la componente software. Se ha generado traficoescalonadamente, hasta llegar a 300Mbps, con el fin de comprobar las posiblesperdidas, segun el patron mostrado en la Figura 39.

0

50

100

150

200

250

300

350

Mbps

Figura 39: Resultado pruebas de OPTENET (Funcionales)

9.4.2. Pruebas de rendimiento

Para realizar esta prueba se ha definido un escenario de saturacion detrafico con el 100 % de bypaseo del mismo, y la tabla completa de direccionesIP de un escenario real (60,000) cargadas en la tarjeta. De nuevo, se generael trafico de manera escalonada como se muestra en la figura 39, y los re-sultados obtenidos es que la componente hardware de la solucion es capazde procesar la totalidad del trafico generado (2,7Gb). Como consecuencia deesta prueba, entendemos que el escenario se puede extender anchos de bandamuy proximos a los 10Gb, llegando a pasar un 10 % del trafico a la solucionsoftware, segun los requisitos definidos.

65

Jaime J. Garnica

0

500

1000

1500

2000

2500

3000

Mbps

Figura 40: Resultado pruebas de OPTENET (Rendimiento)

9.5. Lenguajes HLS

En la Figura 41 se muestra el resultado del control de la entrada conAutoESL. Como puede verse, el sistema sigue funcionando una vez insertadoel modulo HLS.

Figura 41: Simulacion con parseo en AutoESL

La Tabla 3 presenta un analisis cualitativo de los diferentes lenguajesque se han empleado. La primera de las calificaciones se basa en la facilidadde aprendizaje y de desarrollo de las aplicaciones. Los lenguajes RTL comoVHDL y Verilog requieren un aprendizaje previo donde los desarrolladoresdeben aprender mas que una sintaxis nueva, tambien un modelo de compu-

66


tacion de los sistemas, por lo que su tiempo de desarrollo es mayor y requierede un conocimiento mas alto. HandelC y AutoESL, siguen la sintaxis dellenguaje C, el cual es conocido y dominado por un gran porcentaje de losdesarrolladores. Sin embargo, HandelC requiere de un aprendizaje previo enel uso de la sintaxis y estructuras anadidas, lo que requiere un tiempo extrafrente a AutoESL. En segundo lugar, otra de las caracterısticas a analizares la portabilidad de aplicaciones ya desarrolladas en software. Los lenguajesRTL requieren una traduccion y un cambio de diseno que los compiladoresHLS nos proporcionan. En los mismos, HandelC requiere de una leve mo-dificacion para conseguir una coherencia con el modelo de computacion einterfaces requeridas por el hardware, mientras que AutoESL puede tan solorequerir el anadir una serie de directivas que modifiquen las interfaces de en-trada y salida y el comportamiento de la compilacion como es la ejecucion enpipeline o desenrrollado de bucles. En tercer lugar, el control de la temporiza-cion, tanto en los lenguajes RTL como en HandelC es muy preciso, mientrasque en AutoESL se rige por la interpretacion de las directivas. Finalmente,la validacion del sistema en modo de caja blanca es solo trivial en el caso delos lenguajes RTL con herramientas como ChipScope.

Tabla 3: Comparacion de lenguajes en sıntesis hardware

Lenguajes RTL HandelC AutoESL

Facilidad de desarrollo Bajo Medio Alto

Portabilidad software Bajo Medio Alto

Control de la temporizacion Alto Alto Medio

Validacion de los resultados Alto Bajo Bajo

Recapitulando, los lenguajes HLS ganan terreno en el desarrollo de sis-temas hardware al proporcionar un bajo tiempo de aprendizaje y desarrollo,ası como poder emplear soluciones ya desarrollada en software. Un objetivoimportante para los lenguajes HLS es ofrecer un mayor control de la ejecu-cion a nivel de ciclo. Igualmente, a medida que la validacion de los sistemascreados con herramientas HLS sea mejorada, el empleo de dichos lenguajescobrara mayor sentido, pudiendo sustituir a los lenguajes RTL.

67

Jaime J. Garnica

10. Conclusiones y trabajo futuro

10.1. Conclusiones

Este Trabajo Final de Master presenta una implementacion hıbrida dehardware y software de filtrado basado en contenidos. Dicho sistema ofreceel filtrado de sitios web que, bien por cuestiones legales, parentelas o deci-siones de empresa, se desea que no sean accesibles por ciertos usuarios o latotalidad de los mismos. Este sistema presenta las ventajas de ambos ambi-tos, la flexibilidad del software, el cual se encarga de mantener actualizadaslas bases de datos que contienen los sitios webs prohibidos; y la temporiza-cion y rendimiento del hardware, que permiten aplicar soluciones paquete apaquete de la red a tasas altas superiores a los 10Gbps.

El desarrollo llevado a cabo se centra en la parte hardware. Esta parterealiza un primer filtrado basado en las direcciones IP de los paquetes, lascuales son adjudicadas por el sistema software de forma dinamica sin cortede trafico. La utilizacion de hardware reconfigurable hace que sea posibleprocesar paquetes a tasas de alta velocidad, 10Gbps en este caso, y realizarcon ellos acciones como es el filtrado basado en reglas contenidas en memo-ria. El empleo de un primer filtrado hardware de paquetes basado en reglasdefinidas por el software, proporciona al mismo una considerable descargadel trafico que debe procesar. De esta manera, la aplicacion software dedicasu capacidad de procesamiento a tareas mas complejas. Como por ejemplo,la actualizacion de su base de datos y la comprobacion de contenidos con elfin de mantener actualizada la lista de reglas de la FPGA.

La arquitectura disenada permite ademas la portabilidad de la aplicaciony su escalabilidad, tanto a otras plataformas, como a otros escenarios, eincluso otras tasas mas elevadas. De la misma manera, se puede cambiar deaplicacion para la misma plataforma, sin tener que modificar el control delos perifericos. Esto permita un rapido prototipado de nuevas a aplicaciones,a la par que un rapido despliegue de las ya realizadas en nuevas plataformasmas modernas, permitiendo a su vez una escalabilidad a tasas superiores.

Mediante un primer acercamiento a los lenguajes HLS, se ha comprobadocomo en un futuro cercano se podra simplificar el desarrollo de aplicacioneshardware mediante el empleo de lenguajes de alto nivel. Esto combinara laprecision de los sistemas RTL y la flexibilidad de la programacion de altonivel. Al igual que acercara a un mayor numero de desarrolladores al empleode FPGAs. Para ello es necesario que se mejore la validacion de los lenguajesHLS ya que hoy en dıa no es una tarea trivial.

68


10.2. Publicaciones resultantes

Este trabajo a dado como resultado la presentacion de un artıculo enla conferencia ReConFig’12 (International Conference on ReConFigurableComputing and FPGAs) que tendra lugar los dıas 5 al 7 de dicembre de2012 en Cancun, Mejico. A dıa de hoy el artıculo esta bajo revision por elcomite de la conferencia.

10.3. Trabajo futuro

El estudio, diseno y desarrollo llevados a cabo en este trabajo deja abier-tos muchos caminos por los que poder evolucionar a partir de lo expuestoanteriormente. Todo ello, unido a la rapida evolucion de la tecnologıa en loscampos de las comunicaciones, las altas prestaciones y las tecnicas de desa-rrollo en la informatica, ayuda a establecer un punto de partida para futurostrabajos.

10.3.1. Ampliacion de funcionalidad

Dada la potencia de la tarjeta, se plantea la ampliacion de una funciona-lidad mas avanzada que pueda permitir notables aumentos del rendimientode la solucion en funcion del tipo de trafico recibido:

Dada la creciente presencia de trafico comprimido en red, ya que lasprincipales paginas Web sirven un porcentaje importante de las peti-ciones recibidas de manera comprimida para disminuir la latencia per-cibida por el usuario, se plantea implementar las funciones de cifradoy descifrado de trafico en la tarjeta.

Tambien se ha percibido un aumento notable de la transmision de trafi-co cifrado, especialmente conexiones SSL/HTTPS. Para poder realizarla inspeccion de este trafico con alto rendimiento, se plantea descargarla solucion software de la funcion de filtrado sobre la tarjeta.

Vista asimismo la tendencia de crecimiento exponencial de trafico ti-po streaming y/o de archivos de gran tamano, se plantea el bypaseoselectivo de conexiones a partir del analisis inicial de las mismas.

Para las redes IPv6, solo es necesario camber la funcion de hash a64bits. Sin embargo, el numero de colisiones se incrementa de formaconsiderable. Por lo tanto, una tarea pendiente es encontrar la manerade minimizar dichas colisiones.

69

Jaime J. Garnica

10.3.2. Comunicacion DMA a 10Gbps

Un primer acercamiento en futuros desarrollos es el establecimiento deuna comunicacion entre la tarjeta y el software del servidor que la contiene auna velocidad lo suficientemente alta para proporcionar mayores prestacionesal manejo de paquetes. Bien sea en filtrado como en otras aplicaciones, uncuello de botella es el producido debido a las transferencias entre la tarjetaque contiene la FPGA y recibe los paquetes y el controlador de la misma atraves del PCIe. este se debe principalmente al stack del sistema operativo,por la cantidad de copias que se hacen de los datos recibidos, en las que sepierde mucho rendimiento.

Para solucionar el problema del cuello de botella en las transferencias atraves del PCI se utiliza el sistema llamado DMA, ya visto anteriormente,en el que se copia directamente una transferencia (o conjunto de las mismas)desde el espacio de memoria de la tarjeta hacia el espacio de memoria delsoftware.

10.3.3. Filtrado en redes 100GbE

Para las redes de tasa 100Gbps, tasa de paquetes que se debe alcanzar enel pero de los casos es de 149Mpps [12]. Por lo tanto, la frecuencia de relojen el acceso a memorias debe ser mayor que 298MHz. Afortunadamente,las memorias QDR-ii actuales son capaces de alcanzar frecuencias de hasta333MHz, e. g. [5]. Por otro lado, el ancho del bus ofrecido por los actualescores que se encargan del funcionamiento de las interfaces de red puede serde hasta 256bits [23]. Siendo entonces, en el peor de los casos (paquetes de60bytes) un paquete llegara al filtro cada 2 ciclos. Para alcanzar la tasa de149Mpps por interface, el reloj del sistema deberıa ser tambien de 298MHz.Los chip de la familia Virtex-7 alcanzan frecuencias de reloj mayores [21].Debido a estos resultados se puede concluir que en lo referente a la frecuenciade reloj, el sistema esta preparado para alcanzar los 100Gbps.

En cuanto al consumo de los recursos disponibles, el ancho de las FIFOssera de 256bits, como se ha explicado en el parrafo anterior. Por lo tantoel sistema de contencion de paquetes duplicarıa su tamano respecto a laimplementacion de 10Gbps. Por lo tanto, requerirıa hasta 1280Kb. La Tabla 4muestra la utilizacion de recursos en la implementacion del sistema con unancho de bus de 256bits. Esta implementacion se ha realizado sobre el mismochip Virtex-5, en este caso la memoria empleada es de 4158Kb, tan soloel 54 % de la capacidad. Porcentaje que disminuye en chips de la familiaVirtex-7 [21]. No se debe olvidar que la implementacion de los componentesa 100Gbps incrementa el uso de recursos mas alla de las FIFOs, sin embargo

70


el porcentaje mostrado es el mas crıtico. Gracias a estos resultados, se puededeterminar que el sistema esta preparado para funcionar a 100Gbps una vezlas tarjetas presenten dichas interfaces.

Tabla 4: Empleo de recursos para un ancho de datos de 256bits

Slice Logic Utilization Used Available Utilization

Number of Slice Registers 25,817 97,280 26 %

Number of Slice LUTs 31,771 97,280 32 %

Number of bonded IOBs 487 640 76 %

Number of BlockRAM/FIFO 125 212 58 %

Number using BlockRAM only 55

Number using FIFO only 70

Total Memory used (KB) 4,158 7,632 54 %

10.3.4. Framework de alto nivel

Como se ha observado en el trabajo, el estudio y empleo de los lenguajesHLS esta avanzando notablemente y abre un nuevo campo en el que llevar acabo investigaciones interesantes. Continuando el camino comenzado en estetrabajo, una evolucion logica del mismo es la creacion de sistemas basadosen plataforma. Estos sistemas proporcionan un desarrollo de alto nivel deaplicaciones y modulos en lenguajes como C, haciendoles independientes delsistema que desee ejecutarlos. Esta caracterıstica abstrae a los desarrolladoresde tener que adquirir conocimientos avanzados en campos concretos como esel hardware y las FPGAs.

La diferenciacion del desarrollo de aplicaciones de la decision del hard-ware que se va a emplear en las mismas, facilita la incorporacion de un altonumero de desarrolladores que por falta de conocimiento o imposibilidad deaprendizaje no realizan trabajos en campos como el manejo de redes de al-ta velocidad con hardware dedicado. Su incorporacion, junto con la posiblepotabilidad de aplicaciones desarrolladas ya en lenguajes de alto nivel pa-ra sistemas software, hace que sea posible acceder a un amplio abanico desoluciones futuras sin requerir un esfuerzo, notable como pasa hoy en dıa.

71

Jaime J. Garnica

Referencias

[1] M. Bando, Y.-L. Lin, and H. J. Chao. Flashtrie: Beyond 100-gb/sip route lookup using hash-based prefix-compressed trie. Networking,IEEE/ACM Transactions on, PP(99):1, 2012.

[2] P. Bellows and B. Hutchings. Jhdl-an hdl for reconfigurable systems.In FPGAs for Custom Computing Machines, 1998. Proceedings. IEEESymposium on, pages 175 –184, apr 1998.

[3] Hao Chen, Yu Chen, and D.H. Summerville. A survey on the applicationof fpgas for network infrastructure security. Communications SurveysTutorials, IEEE, 13(4):541 –561, quarter 2011.

[4] J. Cong, Bin Liu, S. Neuendorffer, J. Noguera, K. Vissers, and ZhiruZhang. High-level synthesis for fpgas: From prototyping to deployment.Computer-Aided Design of Integrated Circuits and Systems, IEEE Tran-sactions on, 30(4):473 –491, april 2011.

[5] CY7C1511KV18, CY7C1526KV18, CY7C1513KV18, CY7C1515KV1872-Mbit QDR II SRAM 4-Word Burst Architectu-re Design Guide. (September 2010). [Online]. Available:http://www.cypress.com/?docID=24145.

[6] M. Dashtbozorgi and M. Abdollahi Azgomi. A high-performance andscalable multi-core aware software solution for network monitoring. TheJournal of Supercomputing, pages 1–24, 2010.

[7] L. Degioanni and G. Varenni. Introducing scalability in network mea-surement: toward 10 Gbps with commodity hardware. In Proceedings ofthe 4th ACM SIGCOMM Conference on Internet Measurement, pages233–238. ACM, 2004.

[8] L. Fan, P. Cao, J. Almeida, and A.Z. Broder. Summary cache: a scala-ble wide-area web cache sharing protocol. IEEE/ACM Transactions onNetworking (TON), 8(3):281–293, 2000.

[9] Q. Gan and T. Suel. Improved techniques for result caching in websearch engines. In Proceedings of the 18th international conference onWorld wide web, pages 431–440. ACM, 2009.

[10] General DDR SRAM functionality. (July 2001). [Online]. Available:http://download.micron.com/pdf/technotes/TN4605.pdf.

72


[11] Home page of the IEEE 802.3ae 10Gb/s Ether-net Task Force. (October 2007). [Online]. Available:http://grouper.ieee.org/groups/802/3/ae/public/index.html.

[12] Home page of the IEEE 802.3ba 40Gb/s and 100Gb/s Et-hernet Task Force. (January 2011). [Online]. Available:http://grouper.ieee.org/groups/802/3/ba/public/index.html.

[13] Weirong Jiang and Viktor K. Prasanna. Field-split parallel architecturefor high performance multi-match packet classification using fpgas. InProceedings of the twenty-first annual symposium on Parallelism in al-gorithms and architectures, SPAA ’09, pages 188–196, New York, NY,USA, 2009. ACM.

[14] V. Muthukumar and D.V. Rao. Image processing algorithms on reconfi-gurable architecture using handelc. In Digital System Design, 2004. DSD2004. Euromicro Symposium on, pages 218 – 226, aug.-3 sept. 2004.

[15] NetCOPE FPGA Platform for Rapid Development of NetworkApplications. User guide. [Online]. Available: http://www.invea-tech.com/data/netcope.

[16] Z.G. Prodanoff and K.J. Christensen. Managing routing tables for URLrouters in content distribution networks. International Journal of Net-work Management, 14(3):177–192, 2004.

[17] QDR-II, QDR-II+, DDR-II, and DDR-II+ Design Guide. (November2007). [Online]. Available: http://www.cypress.com/?docID=25736.

[18] Y. Qi, J. Fong, W. Jiang, B. Xu, J. Li, and V. K. Prasanna. Multi-dimensional Packet Classification on FPGA: 100 Gbps and Beyond.In Proceedings of International Conference on on Field-ProgrammableTechnology. ACM, December 2010.

[19] Haoyu Song, Fang Hao, M. Kodialam, and T.V. Lakshman. Ipv6 lookupsusing distributed and load balanced bloom filters for 100gbps core routerline cards. In INFOCOM 2009, IEEE, pages 2518 –2526, april 2009.

[20] UG086 - Memory Interface Solutions User Guide. [Online]. Availa-ble:http://www.xilinx.com/support/documentation/ip documentation/ug086.pdf.

[21] Virtex 7 family overview. (January 2010). [Online]. Availa-ble: http://www.xilinx.com/products/silicon-devices/fpga/virtex-7/index.htm.

73

Jaime J. Garnica

[22] VirtualBox Home Page. [Online]. Available:http://www.vitrualbox.com/.

[23] Xilinx AXI Reference Guid. (September 2010). [Online]. Available:http://www.xilinx.com/support/documentation/.

[24] Xilinx Virtex5 TX240T PCI Express 40 GIG SFP+ De-velopment Platform. NetFPGA10G [Online]. Available:http://www.hitechglobal.com/Boards/PCIExpress SFP+.htm.

[25] H. Yuan, B. Wun, and P. Crowley. Software-based implementations ofupdateable data structures for high-speed URL matching. In Proceedingsof the 6th ACM/IEEE Symposium on Architectures for Networking andCommunications Systems, page 15. ACM, 2010.

[26] Z. Zhou, T. Song, and Y. Jia. A High-Performance URL Lookup Engi-ne for URL Filtering Systems. In Communications (ICC), 2010 IEEEInternational Conference on, pages 1–5. IEEE, 2010.

74

Jaime J. Garnica

Indice de figuras

1. Esquema general de la solucion . . . . . . . . . . . . . . . . . 72. Servidor NetCope de INVEA-Tech [15] . . . . . . . . . . . . . 183. Tarjeta combo LXT-COMBOI-10G2 de INVEA-Tech [15] . . . 184. Arquitectura de la tarjeta LXT de INVEA-Tech [15] . . . . . . 195. Firmware de INVEA Tech [15] . . . . . . . . . . . . . . . . . . 206. Escenario para una tarjeta con 2 interfaces de red . . . . . . . 227. Tarjeta NetFPGA 10G de HiTech Global [24] . . . . . . . . . 228. Escenario para una tarjeta con 4 puertos 10GbE . . . . . . . . 239. Esquema general de la herramienta ChipScope . . . . . . . . . 2510. Arquitectura general de la FPGA . . . . . . . . . . . . . . . . 2611. Puentes de filtrado . . . . . . . . . . . . . . . . . . . . . . . . 3012. Arquitectura general de la aplicacion hardware . . . . . . . . . 3113. Flujo de datos del sistema . . . . . . . . . . . . . . . . . . . . 3214. Lectura LocalBus [15] . . . . . . . . . . . . . . . . . . . . . . . 3415. Escritura LocalBus [15] . . . . . . . . . . . . . . . . . . . . . . 3416. Transferencia FrameLink [15] . . . . . . . . . . . . . . . . . . 3517. Sistema de contencion del flujo de paquetes . . . . . . . . . . . 3718. Lectura MIG 3.1. QDR-II [20] . . . . . . . . . . . . . . . . . . 3919. Escritura MIG 3.1. QDR-II [20] . . . . . . . . . . . . . . . . . 3920. Modulo de filtrado de paquetes . . . . . . . . . . . . . . . . . 4021. Cabecera Ethernet . . . . . . . . . . . . . . . . . . . . . . . . 4222. Cabecera IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4223. Traduccion de LocalBus a MIG . . . . . . . . . . . . . . . . . 4624. Pipeline de la aplicacion . . . . . . . . . . . . . . . . . . . . . 4725. Hashing y direccionamiento basado en las direcciones IP . . . 4826. Arquitectura FPGA de la plataforma avanzada . . . . . . . . 5127. Control de entrada en HandelC . . . . . . . . . . . . . . . . . 5328. Decision de destino segun resultado en HandelC . . . . . . . . 5329. Control de entrada en AutoESL . . . . . . . . . . . . . . . . . 5430. Simulacion del hash de una direccion IP entrante . . . . . . . 5531. Arquitectura del entorno de simulacion . . . . . . . . . . . . . 5632. Ejemplo de codigo de testbech . . . . . . . . . . . . . . . . . . 5733. Estructura del fichero de ejemplo de trama . . . . . . . . . . . 5734. Simulacion general del sistema . . . . . . . . . . . . . . . . . . 5835. Captura de validacion en tiempo real con ChipScope . . . . . 5936. Arquitectura del entorno de virtualizacion . . . . . . . . . . . 6037. Evaluacion de rendimiento . . . . . . . . . . . . . . . . . . . . 6338. Entorno de pruebas de OPTENET . . . . . . . . . . . . . . . 64

76


39. Resultado pruebas de OPTENET (Funcionales) . . . . . . . . 6540. Resultado pruebas de OPTENET (Rendimiento) . . . . . . . . 6641. Simulacion con parseo en AutoESL . . . . . . . . . . . . . . . 66

77

Jaime J. Garnica

Indice de tablas

1. Registros de control . . . . . . . . . . . . . . . . . . . . . . . . 492. Empleo de recursos para un ancho de datos de 128bits . . . . 623. Comparacion de lenguajes en sıntesis hardware . . . . . . . . . 674. Empleo de recursos para un ancho de datos de 256bits . . . . 71

78

Sistema Basado en Hardware Reconfigurable para el Filtrado de Contenidos en Proveedores de Servicio...

Technology

Transcript of Sistema Basado en Hardware Reconfigurable para el Filtrado de Contenidos en Proveedores de Servicio...