Este documento presenta un sistema basado en hardware reconfigurable para el filtrado de contenidos en proveedores de servicios de Internet. El sistema proporciona un filtrado de paquetes a alta velocidad de 10 Gbps utilizando una tarjeta FPGA. El sistema fue diseñado para ser portable, escalable y permitir la actualización dinámica de reglas de filtrado. El documento describe los objetivos, el estado del arte, los requisitos, la arquitectura propuesta y la implementación del sistema tanto en hardware como en software.

1. Universidad Aut´noma de Madrid
o
Escuela Polit´cnica Superior
e
Sistema Basado en Hardware Reconfigurable
para el Filtrado de Contenidos en Proveedores
de Servicio de Internet
Jaime J. Garnica
Trabajo Final de M´ster
a
M´ster en Ingenier´ Inform´tica y de las Telecomunicaciones
a ıa a
20 de septiembre de 2012

2. Agradecimientos
A mi tutor
Mi m´s sincero agradecimiento a Sergio L´pez Buedo por haberme aco-
a o
gido como tutor, tanto en la realizaci´n de este trabajo como en los ultimos
o ´
tres a˜os en el grupo de investigaci´n HPCN. De ´l he aprendido en gran
n o e
parte lo que me define laboralmente hoy en d´ ıa.
A mis colaboradores
o ´
Un agradecimiento especial a Victor L´pez Alvarez, que me acompa˜´ du-
no
rante la realizaci´n del proyecto y me ayud´ con su experiencia.
o o
Agradezco la colaboraci´n directa en este trabajo a Jorge L´pez de Verga-
o o
´
ra, Francisco Javier G´mez Arribas, Javier Aracil, Gustavo Sutter y Alvaro
o
Jim´nez.
e
A mis compa˜ eros, familia y amigos
n
Agradezco a la gente del laboratorio C-113 el haber sido tan buenos com-
pa˜eros, de los que he aprendido m´s de lo que pod´ esperar. En especial
n a ıa
a Francisco Javier Ramos, Victor Moreno, Dr. Felipe Mata, Dr. Jos´ Luis
e
Garc´ Pedro Santiago, David Madrigal y David Muelas. Tambi´n agradecer
ıa, e
a antiguos compa˜eros como Jaime Fullaondo, Jos´ Luis A˜amuro, Rub´n
n e n e
Nieto y Diego S´nchez. Y por ultimo, a los nuevos integrantes que se han
a ´
incorporado este a˜o.
n
Finalmente, agradecer a mi familia y amigos que han sido los responsables
de entretenerme en los d´ y momentos de descanso.
ıas

3. Jaime J. Garnica
´
Indice
1. Introducci´n
o 6
2. Objetivos 7
2.1. Objetivos de la soluci´n h´
o ıbrida . . . . . . . . . . . . . . . . . 8
2.2. Objetivos del sistema software . . . . . . . . . . . . . . . . . . 9
2.3. Objetivos del sistema hardware . . . . . . . . . . . . . . . . . 9
2.4. Objetivo HLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Estado del arte 11
3.1. Sistemas de filtrado . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Aplicaciones de seguridad de red en FPGA . . . . . . . . . . . 12
3.3. Lenguajes de alto nivel para s´
ıntesis hardware . . . . . . . . . 13
4. An´lisis de requisitos
a 14
4.1. Sistema portable y escalable . . . . . . . . . . . . . . . . . . . 14
4.2. Filtrado de paquetes a 10Gbps incluso paquetes peque˜os n . . . 15
4.3. Actualizaci´n din´mica de direcciones IP . . . . . . . . .
o a . . . 15
4.4. Integraci´n en una plataforma PC de prop´sito general .
o o . . . 16
4.5. Proporcionar un interfaz conocido al software . . . . . . . . . 16
5. Entornos de desarrollo 17
5.1. Plataforma b´sica . . . . . . .
a . . . . . . . . . . . . . . . . . . 17
5.1.1. Especificaciones . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Firmware INVEA Tech . . . . . . . . . . . . . . . . . . 20
5.1.3. Escenario t´ıpico . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Plataforma avanzada . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1. Especificaciones . . . . . . . . . . . . . . . . . . . . . . 22
5.2.2. Escenario t´ıpico . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Metodolog´ . . . . . . . . . .
ıa . . . . . . . . . . . . . . . . . . 24
5.3.1. Lenguajes RTL . . . . . . . . . . . . . . . . . . . . . . 24
5.3.2. Simulaci´n de m´dulos
o o . . . . . . . . . . . . . . . . . . 24
5.3.3. Validaci´n en placa . .
o . . . . . . . . . . . . . . . . . . 24
5.3.4. Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.5. Lenguajes HLS . . . . . . . . . . . . . . . . . . . . . . 25
6. Arquitectura FPGA 26
6.1. Perif´ricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
e
6.1.1. PCI-Express . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.2. Memorias QDR-II . . . . . . . . . . . . . . . . . . . . . 28
2

4. Trabajo Final de Master
6.1.3. Interfaces 10GbE . . . . . . . . . . . . . . . . . . . . . 29
6.2. Aplicaci´n . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . 29
6.3. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3.1. Protocolo Local Bus . . . . . . . . . . . . . . . . . . . 33
6.3.2. Direccionamiento y funciones hash . . . . . . . . . . . 34
6.3.3. Protocolo FrameLink . . . . . . . . . . . . . . . . . . . 35
6.3.4. Flujo de paquetes . . . . . . . . . . . . . . . . . . . . . 36
6.3.5. MIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.6. Actualizaci´n y b´squeda de reglas
o u . . . . . . . . . . . 39
6.4. Proceso de filtrado . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4.1. Parseo de tramas . . . . . . . . . . . . . . . . . . . . . 42
6.4.2. B´squeda de reglas . . . . . . . . .
u . . . . . . . . . . . 43
6.4.3. Filtrado de tramas al software . . . . . . . . . . . . . . 43
6.5. Actualizaci´n y gesti´n desde el software .
o o . . . . . . . . . . . 43
6.5.1. Escritura de reglas en memoria . . . . . . . . . . . . . 44
6.5.2. Registros de control . . . . . . . . . . . . . . . . . . . . 45
6.6. Acceso a memorias . . . . . . . . . . . . . . . . . . . . . . . . 45
6.7. Integraci´n de m´dulos en pipeline . . . .
o o . . . . . . . . . . . 46
7. Implementaci´n o 47
7.1. Arquitectura b´sica . . . . . . . .
a . . . . . . . . . . . . . . . . 47
7.1.1. Aplicaci´n de filtrado . . .
o . . . . . . . . . . . . . . . . 47
7.1.2. Acceso a memorias . . . . . . . . . . . . . . . . . . . . 48
7.1.3. Comunicaci´n con el host
o . . . . . . . . . . . . . . . . 49
7.2. Integraci´n hardware - software .
o . . . . . . . . . . . . . . . . 50
7.2.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3. Plataforma avanzada . . . . . . . . . . . . . . . . . . . . . . . 51
7.4. Lenguajes HLS . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.4.1. HandelC . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.4.2. AutoESL . . . . . . . . . . . . . . . . . . . . . . . . . 53
8. Validaci´n hardware
o 54
8.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2. Pruebas de integraci´n . . .
o . . . . . . . . . . . . . . . . . . . 55
8.3. Validaci´n en tiempo real .
o . . . . . . . . . . . . . . . . . . . 58
8.3.1. Integraci´n 64b - 32b
o . . . . . . . . . . . . . . . . . . . 59
9. Resultados 61
9.1. Frecuencias de reloj . . . . . . . . . . . . . . . . . . . . . . . . 61
9.2. Consumo de recursos . . . . . . . . . . . . . . . . . . . . . . . 61
9.3. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3

5. Jaime J. Garnica
9.4. Entorno OPTENET . . . . . . . . . . . . . . . . . . . . . . . 63
9.4.1. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . 65
9.4.2. Pruebas de rendimiento . . . . . . . . . . . . . . . . . 65
9.5. Lenguajes HLS . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.Conclusiones y trabajo futuro 68
10.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
10.2. Publicaciones resultantes . . . . . . . . . . . . . . . . . . . . . 69
10.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.3.1. Ampliaci´n de funcionalidad .
o . . . . . . . . . . . . . . 69
10.3.2. Comunicaci´n DMA a 10Gbps
o . . . . . . . . . . . . . . 70
10.3.3. Filtrado en redes 100GbE . . . . . . . . . . . . . . . . 70
10.3.4. Framework de alto nivel . . . . . . . . . . . . . . . . . 71
4

7. Jaime J. Garnica
1. Introducci´n
o
En la actualidad, la detecci´n y clasificaci´n de tr´fico es un ´rea de
o o a a
importancia estrat´gica desde varios puntos de vista como son la seguridad,
e
la protecci´n y la operaci´n de red. En el marco de la protecci´n, la detecci´n
o o o o
y clasificaci´n de tr´fico ayuda al filtrado por contenidos. Con ello es posible
o a
tanto proteger a determinados colectivos de contenidos no apropiados tales
como violencia, pedofilia, discriminaci´n, apolog´ de actos criminales, sexo,
o ıa
etc´tera; como de realizar un control, parental o empresarial, en las redes
e
para aquellos usuarios o administradores de las mismas que as´ lo deseen.
ı
Sin embargo, resulta cr´ ıtico contar con la velocidad de proceso suficiente
en el equipo que realiza el filtrado. De hecho, las redes actuales est´n es-a
calando r´pidamente a velocidades de hasta 40 Gbps y 100Gbps [12]. Por
a
ello, las soluciones basadas en PCs de prop´sito general o similares [9, 8, 16]
o
no sirven en este tipo de escenarios. Se hace necesario el uso de hardware
espec´ ıfico con el paralelismo suficiente para hacer que el tiempo de filtrado
se reduzca al m´ ınimo imprescindible [26, 6, 25]. Dentro de estas soluciones
se encuentran los chips basados en FPGA (Field Programmable Gate Array)
que, debido a su car´cter reprogramable, permiten el desarrollo flexible de
a
diferentes soluciones para diferentes escenarios y la actualizaci´n de las mis-
o
mas. El estado del arte de esta tecnolog´ a las tasas requeridas es amplio, y
ıa
muchos son los puntos de partida que se plantean en el mundo de las redes
de comunicaci´n y la clasificaci´n de paquetes.
o o
Es, en el marco descrito, en el que se centra este trabajo, implementando y
evaluando una soluci´n basada en FPGA para el filtrado de direcciones IP que
o
permita, a diferentes aplicaciones software, llevar a cabo un filtrado basado
en contenidos de los paquetes de red. De este modo, nos encontramos con una
soluci´n h´
o ıbrida de hardware y software. Dentro de esta soluci´n cada uno de
o
los dos sistemas cumple una funci´n espec´
o ıfica, donde el hardware realiza un
primer filtrado a nivel de red bas´ndose en las especificaciones que el software
a
le determine. Aligerando su carga de procesamiento de forma considerable (en
torno al 90 %), permite al software realizar el filtrado a nivel de contenidos, de
estos paquetes que han sido advertidos en una primera instancia por el filtro
hardware. El resto de los paquetes de red, es decir, aquellos que el hardware
no ha considerado sospechosos, no llegar´n al sistema software, sino que ser´n
a a
reenviados a la red de forma transparente.
Por otra parte, dentro del campo de los lenguajes RTL y los sistemas
basados en hardware programable, encontramos los llamados lenguajes del
alto nivel para s´ıntesis hardware (HLS, High Level Synthesis). Estos lengua-
jes y sus herramientas est´n tomando una gran importancia, especialmente
a
en el mundo de las FPGAs. Esto se debe a su abstracci´n de alto nivel para
o
6

8. Trabajo Final de Master
sintetizar c´digo RTL, evitando la necesidad de expertos en lenguajes de des-
o
cripci´n de hardware tales como VHDL y Verilog. Estas herramientas, de las
o
que se habla est´n basadas en lenguajes de prop´sito general como C, C++
a o
o Java, acercando a programadores menos experimentados a la posibilidad
de realizar dise˜os a medida sin implicar un gran tiempo de adaptaci´n o
n o
aprendizaje 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 de
altas tasas como se presenta en la Figura 1. El objetivo del sistema hardware
ser´ realizar un filtrado basado en las direcciones IP de los datagramas IP,
a
mientras que el software ser´ el encargado de realizar un segundo filtrado,
a
definitivo, de dichos paquetes, bas´ndose en sus contenidos. Ambos sistemas
a
deben estar en comunicaci´n, siendo el software el que indica las direcciones
o
potencialmente filtrables, y siendo el hardware el que redirige los paquetes
potencialmente filtrables al software. Este desarrollo se plantea en el entrono
de las redes 10GbE (10 Gigabit Ethernet), donde las tasas de paquetes por
segundo alcanzan los 14,9 millones (Mpps) [11].
Sistema de filtrado
Trafico filtrado
10 Gbps
Red a SW
10 Tarjeta filtrado
FPGA
Gbps Enlace a filtrar
10 Gbps
Figura 1: Esquema general de la solucion
El objetivo secundario es el estudio y evaluaci´n del empleo de lenguajes
o
HLS con FPGA. Mediante el desarrollo con lenguajes HLS de algunos m´du- o
los que ya se han creado y probado en VHDL se podr´ realizar una primera
a
observaci´n y quiz´s evaluaci´n del empleo de estos lenguajes HLS frente a
o a o
los lenguajes RTL.
7

9. Jaime J. Garnica
Los objetivos generales del trabajo se pueden enumerar de la siguiente
manera:
Estudio, an´lisis y dise˜o de una soluci´n hardware-software para fil-
a n o
trado por contenidos en redes 10GbE.
Desarrollo e integraci´n de un sistema hardware de filtrado basado
o
en direcciones IP que reduzca la carga de procesamiento del sistema
software en redes 10GbE.
Estudio y evaluaci´n de los lenguajes de alto nivel para s´
o ıntesis de
hardware con el fin de determinar si ´stos son un buen camino a seguir.
e
2.1. Objetivos de la soluci´n h´
o ıbrida
El motivo de emplear un sistema h´ ıbrido es aprovechar la flexibilidad
que ofrece el software y el rendimiento del hardware. Gracias al primero,
las diferentes p´ginas web podr´n ser analizadas a nivel de contenidos y se
a a
podr´, a su vez, buscar en diferentes bases de datos las diferentes URLs de
a
dichas p´ginas que se consideran, bien de forma legal, como moral, como
a
empresarial, etc., p´ginas que deben ser filtradas. Mediante el escrutinio de
a
estas URLs, el software podr´ crear una lista de direcciones que deber ser
a
filtradas (lista negra) o bien una lista de las direcciones que tendr´n permi-
a
tido el acceso (lsita blanca). Dicha lista, como el modo de tratarla (negra o
blanca) ser´ comunicada al sistema hardware en modo de direcciones IP, el
a
cual realizar´ un primer filtrado basado en dichas direcciones IP a altas tasas
a
mediante el uso de la tecnolog´ FPGA. Debido a que el n´mero de direccio-
ıa u
nes a filtrar es muy peque˜o, el porcentaje que el hardware deja pasar a la
n
red sin que la aplicaci´n software tenga constancia de ello es de entorno al
o
90 %. Esta disminuci´n de tr´fico que el hardware proporciona al software,
o a
hace que ´ste pueda emplear su capacidad de procesamiento en tareas m´s
e a
complejas, como puede ser la inspecci´n en mayor profundidad, como es en
o
este caso la comprobaci´n de URLs.
o
La soluci´n llevada a cabo en este Trabajo Final de M´ster ofrece un
o a
filtrado por contenidos en redes 10 GbE. Esto supone un filtrado de 14,9
millones de paquetes por segundo (Mpps). En el enlace a 10 Gbps se inserta
el 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 aquella
parte del tr´fico que no se considera sospechosa. Se puede realizar en
a
base a patrones en la cabecera o campo de datos de los paquetes. En
esta trabajo estar´ basado en las direcciones IP de los paquetes.
a
8

10. Trabajo Final de Master
Filtrado: en esta parte entra el software ya desarrollado por Optenet,
donde se realiza un an´lisis m´s en profundidad buscando contenidos
a a
indeseados o posibles ataques. Al recibir esta parte software un tr´fico
a
pre-filtrado, no necesita procesar a la velocidad del enlace. De ese modo
es posible realizar el procesado en una plataforma PC de prestaciones
medias.
2.2. Objetivos del sistema software
El software, proporcionado por OPTENET, empresa espa˜ola de solucio-
n
nes de filtrado y seguridad en la red, es el encargado de realizar el filtrado
final del tr´fico que el hardware ha filtrado, o reencaminado, a ´ste. Para ello
a e
utiliza una aplicaci´n llamada CCOTTA. Tiene como colaboradores impres-
o
cindibles las diferentes bases de datos de p´ginas web con contenido il´
a ıcito
o indeseado por ciertos grupos de usuarios. Como adici´n a ello, realiza un
o
seguimiento y comprobaci´n de los contenidos de las p´ginas web que son
o a
visitadas por los usuarios con la finalidad de poder analizar si deben, o no,
ser filtradas. Esto tiene como consecuencia la constante actualizaci´n de la
o
base 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 conocido
que le de acceso a dichos recursos. Como objetivos en relaci´n a este software
o
de este trabajo se consideran los siguientes puntos.
Desarrollo de un driver que gestione la comunicaci´n por PCIe con los
o
m´dulos pertinentes de la FGPA y controle la actualizaci´n de reglas.
o o
Implementaci´n de un interfaz conocido por las aplicaciones que per-
o
mita el acceso a la funcionalidad del driver.
Creaci´n de una API que facilite la comunicaci´n entre las aplicaciones
o o
software y el hardware.
2.3. Objetivos del sistema hardware
Debido a las capacidades del software actual, su rendimiento no es capaz
de alcanzar las tasas necesarias de filtrado que se requieren en las redes 10
GbE. Es por esta raz´n por la cual se debe realizar un sistema h´
o ıbrido entre
el software y el hardware. El sistema hardware, que es el implementado e
integrado en este trabajo debe cumplir los siguientes requisitos, planteados
como objetivos primarios:
9

11. Jaime J. Garnica
Desarrollo en lenguaje RTL para FPGA, f´cilmente portable a otras
a
tarjetas y escalable a velocidades superiores a los 10GbE.
Filtrado de paquetes seg´n sus direcciones IP a 10Gbps tasa real, in-
u
cluso con paquetes de tama˜o peque˜o (64 bytes).
n n
Actualizaci´n din´mica (sin cortar el tr´fico de red y sin p´rdida de
o a a e
paquetes) de la lista de direcciones IP que se debe filtrar.
Integraci´n en plataforma PC de prop´sito general y comunicaci´n con
o o o
el software a trav´s del bus PCI-Express de forma transparente para el
e
software.
2.4. Objetivo HLS
La introducci´n de lenguajes de alto nivel en el campo de la s´
o ıntesis de
sistemas hardware est´ cobrando una gran importancia en los ultimos a˜os
a ´ n
por dos razones principales. Por un lado, los diferentes fabricantes y desarro-
lladores de hardware han implementado compiladores cada vez m´s potentes
a
y con mejores modelos de computaci´n. Por otro lado, y como consecuencia
o
de la aclaraci´n anterior, la necesidad de expertos en lenguajes de bajo nivel
o
se ve reducida con el uso de estas nuevas herramientas basadas en lenguajes
de prop´sito general bien conocidos como son C, C++ o Java.
o
Debido a la gran familiarizaci´n con los lenguajes de prop´sito general por
o o
los desarrolladores de sistemas inform´ticos y de telecomunicaciones, se pue-
a
de pensar como en una consecuencia directa el uso de lenguajes HLS (High
Level Synthesis) debido a que dichos lenguajes implican un menor tiempo
de aprendizaje y desarrollo en las aplicaciones con un menor nivel de espe-
cializaci´n. A´n as´ para conseguir que un sistema hardware funcione a´n
o u ı, u
es necesario el desarrollo previo de un entorno de desarrollo que se encar-
gue de los m´dulos m´s espec´
o a ıficos del hardware. Por lo tanto, los objetivos
relacionados con el uso de lenguajes HLS son:
Aprendizaje y desarrollo de m´dulos hardware con lenguaje HLS para
o
FPGA.
Integraci´n y validaci´n de m´dulos creados con lenguajes HLS dentro
o o o
de sistemas FPGA ya validados.
Evalucaci´n de los lenguajes HLS empleados para concretar sus carac-
o
ter´
ısticas y aportaciones a la creaci´n de hardware.
o
10

12. Trabajo Final de Master
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 ´stos, los basados en FPGA est´n tomando una gran
e a
importancia. A continuaci´n se expone el estado del arte de los sistemas de
o
filtrado y de las diferentes soluciones a los problemas u objetivos indicados
en los apartados anteriores con el fin de establecer una base de partida sobre
la que comenzar el trabajo.
3.1. Sistemas de filtrado
Los m´todos de filtrado se han realizado tradicionalmente con soluciones
e
basadas en sistemas software [9, 8, 16]. Las principales ventajas de estas solu-
ciones son su flexibilidad y la posibilidad de implementar m´todos complejos
e
de b´squeda en tablas, as´ como la posibilidad de actualizarse de manera
u ı
sencilla, lo cual es esencial en el campo de la seguridad debido a la r´pida
a
evoluci´n de los ataques. Estos m´todos no s´lo son usados en aplicaciones
o e o
de filtrado, sino tambi´n en motores de b´squeda [9], web caching [8] o redes
e u
de distribuci´n de contenidos [16]. Sin embargo, como desventaja, las solu-
o
ciones basadas en software tienen un consumo de tiempo por petici´n del o
orden de milisegundos [26]. Para mejorar el rendimiento de los m´todos de
e
filtrado basados en la URL hay cuatro aproximaciones. La primera de ellas
es mejorar el algoritmo de b´squeda de la URL [26]. En segundo lugar, la
u
implementaci´n de algoritmos que se puedan paralelizar para aprovechar las
o
posibilidades que nos ofrecen los las arquitecturas multi-core [6, 25]. Otra
mejora posible es partir el tr´fico entrante en m´ltiples m´quinas. Y por
a u a
ultimo, reducir el consumo de la CPU en la captura de paquetes mediante
´
hardware dedicado [7].
El hardware dedicado se puede definir como el sistema basado en hard-
ware que se implementa para cumplir un objetivo concreto, normalmente
resuelto de forma previa por sistemas software. Normalmente este fen´menoo
es debido a que los procesadores no son capaces de alcanzar las tasas necesa-
rias. Estos sistemas pueden ser NICs (Network Interface Card) de prop´sito o
especial como las Endace DAGs, procesadores de red tales como Cavium, o
tarjetas con un chip FPGA [3]. La mayor ventaja de la tecnolog´ FPGA es
ıa
que su hardware puede ser programado ad-hoc para una cierta aplicaci´n y o
m´s tarde ser reprogramado para cumplir los nuevos requisitos del sistema o
a
de la aplicaci´n. Hasta el momento, se puede decir que la unica v´ existente
o ´ ıa
para implementar algoritmos que alcancen tasas de l´ ınea de 100Gbps [12] es
11

13. Jaime J. Garnica
mediante el empleo de hardware dedicado [18], bien sea FPGA o network
processors, como Cavium.
3.2. Aplicaciones de seguridad de red en FPGA
Un recurso muy habitual para el manejo o desarrollo de aplicaciones en
las redes de alta velocidad son las FPGA, debido a su capacidad de reprogra-
maci´n para una aplicaci´n nueva, proporcionan flexibilidad y posibilidad de
o o
actualizaci´n del sistema. Estas caracter´
o ısticas son esenciales en sistemas de
seguridad, 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 soluciones
principales como podemos encontrar en la compilaci´n mostrada en [3]. La
o
clasificaci´n de las mismas se resume en las categor´ de: , , P y detecci´n
o ıas o
de anomal´ ıas.
Clasificaci´n de paquetes [13, 18, 1], donde cada uno de los paquetes
o
es analizado, o bien sus cabeceras (Ethernet, IP, TCP, etc.), o bien sus
datos, o bien ambas, de manera que dependiendo de los valores que se
est´n buscando se realizan diferentes acciones que conllevan clasificar el
a
paquete dentro de unas condiciones iniciales, bien para crear estad´ticas
s
de tipos de paquetes y flujos, o bien reenviarlos por diferentes interfaces,
o bien filtrarlos, etc..
Reconocimiento de patrones [2], si el objeto de la soluci´n es encontrar
o
un patron, o cadena de bytes, dentro de las cabeceras o de los datos
del paquete (DPI, Deep Packet Inspection) para realizar una acci´n o
determinada 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.
Detecci´n de anomal´ estudiando las diferentes condiciones y carac-
o ıas,
ter´
ısticas del tr´fico, como puede ser la frecuencia de ciertos paquetes
a
(tama˜o, cabeceras, protocolo, etc.), la cantidad de los mismos, el com-
n
portamiento, etc., se consigue realizar una base sobre la cual contrastar
el comportamiento en tiempo real del tr´fico futuro sobre la misma red
a
y detectar cualquier comportamiento an´malo que pueda indicar que
o
hay un ataque.
El filtrado de tr´fico se puede entender como un tipo de clasificaci´n de
a o
paquetes, ya que dependiendo de una serie de reglas se clasifica el car´cter
a
12

14. Trabajo Final de Master
de los paquetes como filtrados o no filtrados. Dentro de esta clasificaci´n o
hay muchos art´
ıculos que presentan diferentes soluciones. Las soluciones m´s
a
comunes son:
Tecnolog´ de TCAM [13], donde se emplean memorias ternarias, es
ıas
decir, que presentan 3 valores posibles, uno de ellos indica que el bit
corresponde con el valor buscado, otro indica que no y otro es indefinido.
Este ultimo valor se puede emplear para realizar reconocimiento de
´
reglas que coinciden en ciertos bits, pero en otros no, ahorrando espacio.
Binary Tries [18, 1], mediante la creaci´n de arboles binarios basados en
o ´
conjuntos de reglas conocidos, se consigue crear un sistema de b´squeda
u
realizables en tiempos peque˜os o que permitan la implementaci´n de
n o
un pipeline y, por lo tanto, alcancen las tasas requeridas por la red.
Bloom Filters [19], o sistemas de m´ltiples hash, donde se genera una
u
cadena 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 sobre
la regla que proporciona la direcci´n dentro de la cadena de valores,
o
accediendo as´ al bit que indica si la regla ha sido reconocida o no. Para
ı
la creaci´n de dicha cadena se emplean m´ltiples hashes sobre cada una
o u
de las reglas del conjunto inicial que se quiere contrastar.
Sin embargo, las TCAM, o memorias ternarias, han quedado obsoletas
debido a su alto coste y consumo, por lo que se han descartado para este
trabajo. En cuanto a las soluciones basadas en Binary Tries y Bloom Filters,
presentan el impedimento de tener que volver a crear el sistema de b´squeda
u
de reglas una vez que el conjunto de las mismas ha cambiado. Lo cual requiere
el corte del tr´fico y del filtrado del mismo, siendo incompatible con los
a
objetivos presentados en este trabajo.
3.3. Lenguajes de alto nivel para s´
ıntesis hardware
El principal problema de las soluciones basadas en hardware dedicado es
la necesidad de una preparaci´n espec´
o ıfica de los ingenieros y desarrolladores
que tienen como objetivo llevarlas a cabo. Debido a ello se ha abierto un cam-
po de investigaci´n en los ultimos a˜os que intenta paliar dicho problema.
o ´ n
Para ello, uno de los caminos que se siguen es el empleo de compiladores basa-
dos en lenguajes de alto nivel para generaci´n de c´digo RTL. Los lenguajes
o o
de alto nivel que m´s se han empleado son los basados en C y Java.
a
13

15. Jaime J. Garnica
El art´
ıculo [2] presenta una soluci´n para FPGA implementada en un
o
derivado de lenguaje Java para el reconocimiento de patrones basados en
expresiones regulares. En el caso de los lenguajes basados en C, es decir,
lenguajes que o bien emplean C para compilar o emplean un subconjunto
de mismo junto a modificaciones en la sintaxis para especificar comporta-
mientos propios del hardware. Diferentes soluciones se han presentado como
HandelC [14] y AutoESL [4], proporcionando herramientas para la compi-
laci´n a partir de C, ´sta es una buena base de partida para estudiar los
o e
mismos.
4. An´lisis de requisitos
a
Como est´ indicado en la Secci´n 2.3 del trabajo, hay cuatro requisitos
a o
esenciales que deben cumplirse por el sistema hardware:
Sistema portable a otras tarjetas de forma r´pida y escalable a veloci-
a
dades superiores a los 10GbE.
Filtrado de paquetes seg´n sus direcciones IP a 10Gbps tasa real, in-
u
cluso con paquetes de tama˜o peque˜o (64 bytes).
n n
Actualizaci´n de forma din´mica (sin cortar el tr´fico de red y sin
o a a
p´rdida de paquetes) de la lista de direcciones IP que se debe filtrar.
e
Integraci´n en una plataforma PC de prop´sito general, comunic´ndose
o o a
con el software a trav´s del bus PCI-Express. Permitiendo as´ al softwa-
e ı
re correr en una plataforma de prop´sito general, con sistema operativo
o
Linux.
Proporcionar un interfaz conocido para que el programa de filtrado
software sea capaz de definir filtros din´micamente y agregarlos a la
a
tarjeta FPGA.
Analiz´ndolos en profundidad, cada uno de ellos implica los siguientes
a
requisitos espec´ıficos del sistema hardware, es decir de la implementaci´n
o
sobre la tarjeta FPGA.
4.1. Sistema portable y escalable
Para que el sistema sea portable a otras plataformas debe generarse un
envoltorio de los m´dulos que forman parte de la aplicaci´n cuyas interfaces
o o
sean las est´ndares correspondientes al manejo de paquetes, de reglas y de
a
14

16. Trabajo Final de Master
comunicaci´n con el software. Este envoltorio, junto con los m´dulos de apli-
o o
caci´n debe ser f´cilmente portable a otros sistemas que tengan configuradas
o a
sus interfaces con los perif´ricos de manera id´ntica a la de dicha aplicaci´n.
e e o
El m´todo empleado en el dise˜o de la arquitectura debe ser modular, es
e n
decir, los componentes de la arquitectura deben presentar una serie de inter-
faces est´ndar de manera que sean intercambiables e integrables de manera
a
r´pida y sencilla. Dichas interfaces de comuniaci´n pueden seguir protocolos
a o
ya definidos.
Conseguir que el sistema sea escalable a arquitecturas superiores a los
10Gbps puede llevarse a cabo mediante el cambio de anchos de palabras en
las 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 paquetes
peque˜ os
n
El filtrado de paquetes de tama˜o peque˜o (64 bytes) a una tasa de
n n
10Gbps implica que la frecuencia de llegada de paquetes es de un paquete
cada 67 nanosegundos. Esto implica la necesidad de ser capaces de procesar
un paquete en un tiempo menor al indicado o, al menos, que la salida de
los paquetes se cumpla con dicha frecuencia. Para obtener la tasa de sali-
da deseada, se debe crear un sistema en pipeline que, a˜adiendo un retardo
n
aceptable, sea capaz de consultar las reglas indicadas y reenviar un paquete
sin retrasar la recepci´n de los sucesivos. Una de las tareas m´s importantes
o a
en este aspecto es seleccionar un tipo de memorias que presente una tem-
porizaci´n que habilite el pipeline, es decir, que tenga un tiempo de acceso
o
determinista para cada una de las peticiones que se realizan y as´ asegurar
ı
el mismo tiempo de acceso a cada una de las peticiones que se realizar´n a
durante el filtrado.
Como requisito hardware, la comunicaci´n a 10Gbps se debe realizar me-
o
diante un sistema que pueda funcionar a dicha tasa. Para ello es necesario
encontrar una frecuencia de trabajo y un ancho de palabra en la llegada de
los 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 pueden
filtrar ambos sentidos de la red.
4.3. Actualizaci´n din´mica de direcciones IP
o a
Con el fin de asegurar el continuo filtrado de la comunicaci´n, uno de los
o
aspectos a m´s cr´
a ıticos a tener en cuenta es la actualizaci´n de las reglas
o
15

17. Jaime J. Garnica
por parte de la aplicaci´n software. Para actualizar de forma din´mica la
o a
lista de las direcciones IP sospechosas se deben almacenar en un recurso
modificable durante el funcionamiento del sistema, evitando precargar la lista
al programar la FPGA y de ese modo la reprogramaci´n de la misma para
o
su modificaci´n. La reprogramaci´n del sistema implicar´ un corte en el
o o ıa
flujo de datos entrante. Dicha modificaci´n din´mica se puede solventar con
o a
memorias accesibles para su escritura durante la ejecuci´n del sistema.
o
Para que el filtrado del tr´fico no se vea interrumpido se debe crear un
a
sistema de acceso al recurso que, tanto permita realizar escrituras al mismo
tiempo que se realizan lecturas, como funcione a una frecuencia suficiente de
accesos que permita intercalar las lecturas y escrituras sin perjudicar la tasa
de la l´
ınea. Las especificaciones t´cnicas para que este requisito se cumpla
e
pasan por la integraci´n de memorias accesibles a alta velocidad y con una
o
capacidad suficiente para almacenar las direcciones IP.
4.4. Integraci´n en una plataforma PC de prop´sito
o o
general
Para facilitar la cooperaci´n entre el software y el hardware es necesario
o
crear un sistema mediante el cual ambas partes puedan comunicarse. Para
que tenga el car´cter de ser una plataforma de prop´sito general, como un PC
a o
se debe emplear un recurso com´n, como es el caso de PCI-Express (PCIe).
u
Este recurso se encuentra en la mayor´ de los ordenadores que se venden
ıa
actualmente en el mercado y la forma m´s com´n de comunicar las tarjetas
a u
de red, en este caso las tarjetas con FPGA. Para acceder a dicho recursos
ambas partes del sistema deben introducir en sus arquitecturas un acceso
al mismo. Desde el punto de vista del software basado en Linux se puede
acceder mediante la implementaci´n de drivers para el sistema operativo.
o
En el caso del sistema hardware ser´ necesario adjuntar alg´n tipo de core
a u
(m´dulo hardware) que maneje el recurso de la tarjeta.
o
La comunicaci´n a trav´s del PCIe deber´ permitir al hardware propor-
o e a
cionar dos servicios fundamentales al software. El primero de ellos es el env´
ıo
de paquetes que cumplan las reglas de filtrado que el hardware ha recibido.
En segundo lugar, la comunicaci´n de esas reglas de filtrado para mantener
o
la 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 hardware
se puede dividir ´ste en dos puntos esenciales. En primer lugar la tarjeta
e
16

18. Trabajo Final de Master
ha de mostrarse al sistema operativo como si de una NIC convencional se
tratase. En segundo lugar implementar una serie de controladores de entrada-
salida (IOCTL, Input Output ConTroLler) a trav´s de los cuales la aplicaci´n
e o
correspondiente pueda acceder a la memoria de reglas de la tarjeta.
La importancia de proporcionar un interfaz conocido reside en facilitar
la integraci´n de las aplicaciones que se van ejecutar empleando el desarrollo
o
del filtrado, tanto las que ya se encuentran desarrolladas como las posibles
futuras aplicaciones. Esto es importante ya que, como ha sido explicado an-
teriormente, la evoluci´n de las actividades maliciosas es continua y esto im-
o
plica que el cambio de aplicaciones software, o la actualizaci´n de las mismas,
o
sea constante. Por lo tanto, el sistema debe ser compatible con soluciones ya
existentes.
5. Entornos de desarrollo
Las tarjetas basadas en FPGA no son todas iguales, por lo que debe
seleccionarse una entre las diferentes opciones del mercado. Dicha tarjeta
debe presentar unas especificaciones que permitan cumplir con los requisitos
de la soluci´n. Por ello, como especificaciones m´
o ınimas deben tener, al menos,
dos interfaces 10GbE. Tambi´n deben presentar memorias accesibles durante
e
el funcionamiento del sistema, las cuales deben tener una capacidad lo mayor
posible. Por ultimo, dichas tarjetas deben conectarse a trav´s del PCIe, de
´ e
manera que se puedan enviar los paquetes filtrados por la FPGA al software.
5.1. Plataforma b´sica
a
La plataforma elegida para el desarrollo ha sido desarrollada por la empre-
sa INVEA-Tech, de origen checo. Esta plataforma ofrece un ventaja esencial
sobre el resto de las plataformas planteadas como es la incorporaci´n de o
un entorno de trabajo ya desarrollado. INVEA-TECH proporciona un servi-
dor pre-configurado (Figura 2). El servidor es una m´quina de montaje en
a
bastidor 2U dise˜ado a medida de la tarjeta COMBO-LXT, que viene con
n
un sistema operativo CentOS 5.2 precargado con los drivers y librer´ de ıas
NetCOPE.
5.1.1. Especificaciones
La tarjeta basada en FPGA proporcionada por INVEA Tech es la llamada
COMBO-LXT. ´sta es una tarjeta PCIe x8 GEN1 que incluye una FPGA
e
de la familia Virtex-5 de Xilinx, en particular la XC5VLXT155. Sobre esta
17

19. Jaime J. Garnica
Figura 2: Servidor NetCope de INVEA-Tech [15]
tarjeta se pueden conectar m´dulos de interfaz, existiendo en la actualidad
o
el COMBOI-1G4 que proporciona 4 interfaces ´pticas gigabit Ethernet tipo
o
SFP, y el COMBOI-10G2 que dispone de dos interfaces ´pticas 10 GbE
o
implementadas mediante m´dulos XFP. Esta ultima es la que se ha empleado
o ´
en 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 configuraci´n PCIe x8
o
GEN1 que alcanza velocidades efectivas (una vez que se tiene en cuenta la
sobrecarga a nivel f´
ısico y de enlace) de m´s de 12 Gbps full-duplex. La FP-
a
GA tiene disponible dos memorias QDR-II tipo CY7C1513AV18 de 72 Mbits,
organizadas como 4Mx18, y tambi´n est´ conectada a un z´calo para memo-
e a o
rias SODIMM tipo DDR2, hasta 2 GBytes. La placa dispone de dos tipos
de 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

20. Trabajo Final de Master
FPGA.
Figura 4: Arquitectura de la tarjeta LXT de INVEA-Tech [15]
19

21. Jaime J. Garnica
La configuraci´n de la FPGA Virtex-5 se hace a trav´s de una FPGA
o e
secundaria tipo Spartan-3, que tiene asociada una memoria Flash. La ven-
taja de este esquema es que se puede reconfigurar la FPGA sin perder la
conexi´n PCIe con el host, y sin necesitar de un rearranque del sistema. Adi-
o
cionalmente, la placa ofrece un conector JTAG donde enchufar el cable de
programaci´n de Xilinx, que permite por ejemplo usar las herramientas de
o
depuraci´n en sistema (ChipScope).Finalmente, la placa dispone de varios
o
generadores de reloj, y de los conversores DC/DC necesarios para alimentar
los diferentes dispositivos. Toda la alimentaci´n se obtiene a trav´s de la l´
o e ınea
de +12V de PCIe, no siendo necesario usar alimentaciones adicionales.
5.1.2. Firmware INVEA Tech
El dise˜o FPGA de la plataforma NetCOPE contiene todos los bloques
n
necesarios 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 configuraci´n de la aplicaci´n desde el host
o o
Estos bloques se ofrecen bien como c´digo fuente VHDL, como cores que se
o
pueden generar con la herramienta Xilinx Coregen, o como netlists presin-
tetizadas. En la Figura 5 se puede ver la estructura del dise˜o FPGA de la
n
plataforma NetCOPE.
Figura 5: Firmware de INVEA Tech [15]
En el lado de la izquierda se pueden observar las interfaces de red, que
dependiendo de la tarjeta de interfaz que se use pueden ser 4 interfaces gigabit
Ethernet o 2 interfaces 10 GbE. En este proyecto solo se va a considerar el
segundo de los caso, 10 GbE. El chip de medio f´ ısico asociado a cada conector
20

22. Trabajo Final de Master
XFP (Vitesse VSC8486) proporciona una interfaz XAUI a la FPGA. Dentro
de la FPGA, el bloque Network module implementa los cores 10 GbE y ofrece
hacia la aplicaci´n 2 streams por interfaz de red, uno de transmisi´n y otro
o o
de recepci´n. Estos streams siguen el formato FrameLink, que se describe en
o
la Secci´n 6.3.3. Asociado al bloque Network module esta el bloque Pacodag
o
module. Pacodag significa PAcket COntrol DAta Generator, y es un modulo
que b´sicamente se encarga de poner una cabecera a cada trama que se recibe
a
con la longitud, interfaz de llegada y timestamp, aunque futuras versiones de
NetCOPE se podr´ usar en para a˜adir m´s informaci´n.
ıa n a o
Por el lado de la derecha est´ la interfaz PCIe. NetCOPE es una tarjeta
a
PCIe x8 GEN1. El bloque cv2 PCI debe estar compuesto principalmente por
el core PCIe de Xilinx, aunque esta informaci´n es dif´ de confirmar puesto
o ıcil
que se ofrece como una netlist presintetizada. A trav´s de una conexi´n de
e o
streaming tipo Internal Bus se conecta con el m´dulo NetCOPE base, que es
o
el que se encarga de procesar y generar los TLPs (transaction layer packets)
de PCIe. El m´dulo NetCOPE base proporciona dos interfaces, Internal Bus
o
y Local Bus (Secci´n 6.3.1). Internal Bus es una interfaz de alta velocidad
o
tipo streaming, mientras que Local Bus es una conexi´n m´s sencilla, similar
o a
a los buses cl´sicos, pero con prestaciones limitadas puesto que no permite
a
pipelining. Internal Bus est´ pensado para la transferencia de grandes blo-
a
ques de datos, mientras que Local Bus se orienta al acceso de registros de
configuraci´n. Ambos buses acaban en dos switches: IB switch y LB switch.
o
Esto se debe a que DMA module necesita ambos buses, lo mismo que la
aplicaci´n.
o
Finalmente aparece el bloque Application, que es donde el usuario puede
a˜adir su aplicaci´n de red. Este bloque tiene acceso a trav´s de conexiones
n o e
FrameLink a las interfaces 10 GbE y a las colas DMA para la transferencia de
paquetes hacia el host. Tambi´n tiene acceso a los buses Internal Bus y Local
e
Bus, y se proporcionan unos endpoints (IB endpoint y LB endpoint) para
simplificar a´n m´s el acceso a estos buses. La modularidad de la arquitectura
u a
que rodea el bloque Aplicaci´n y, por lo tanto, la interfaz de la misma, junto
o
a los protocolos empleados en la comunicaci´n de los perif´ricos, hace que
o e
sea sencillo seguir el dise˜o modular que se especificaba en la Secci´n 4.1.
n o
5.1.3. Escenario t´
ıpico
El escenario t´
ıpico que se puede implementar con esta plataforma es el
descrito en el objetivo de este Trabajo Final de M´ster, es decir, un filtrado
a
que se implante entre dos extremos de una comunicaci´n, empleado una
o
interfaz para la comunicaci´n entre el filtro y el cliente y otra entre el filtro
o
y la comunicaci´n con Internet tal y como muestra la Figura 6.
o
21

23. Jaime J. Garnica
Security
management
server
User Filtering
Internet
appliance
Figura 6: Escenario para una tarjeta con 2 interfaces de red
5.2. Plataforma avanzada
Una vez desarrollada la soluci´n en la plataforma y durante el transcurso
o
de la misma, se han estudiado nuevas opciones a las que migrar el desarrollo.
La soluci´n m´s atractiva es una placa desarrollada en la Universidad de
o a
Stanford, 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, tiene
conectadas tres memorias QDR-II tipo CY7C1515JV18, de 72Mbits en or-
22

24. Trabajo Final de Master
ganizaci´n 2Mx36. Por el otro, tiene tambi´n 4 memorias RLDRAM tipo
o e
MT49H64M9, de 576Mbits en organizaci´n 64Mx9 en 8 bancos. Las memo-
o
rias RLDRAM se sit´an a medio camino entre las QDR y las DDR2/3 tanto
u
en tiempo de acceso aleatorio como tama˜o. El tiempo de acceso para un
n
dato cualquiera es de 4 ciclos de reloj (12 ns a 333 MHz), lo que resulta muy
adecuado para hacer b´squedas en tablas a alta velocidad.
u
Con respecto a la configuraci´n, usa dos memorias PlatformFlash XL
o
conectadas a la FPGA a trav´s de un CPLD que hace que aparezcan como si
e
fuesen un unico dispositivo del doble de capacidad. La alimentaci´n es mixta
´ o
entre el bus PCIe y un conector externo tipo IDE, y dispone adem´s de un
a
par de conectores de alta velocidad que podr´ usarse para conectar placas
ıan
secundarias con m´s puertos de red. El mayor problema de esta tarjeta es que
a
a diferencia de la COMBO-LXT no se ofrece ninguna plataforma de desarrollo
r´pido de aplicaciones, como NetCOPE. Por ello, es necesario hacer todo el
a
desarrollo tanto de drivers como interfaces 10 GbE y PCIe. Sin embargo,
ser´ posible reutilizar el trabajo hecho para NetCOPE a nivel de prueba de
ıa
concepto.
5.2.2. Escenario t´
ıpico
Bajo estas condiciones, un posible entorno de prueba ser´ el que describe
ıa
la Figura 8, donde la tarjeta de HiTech Global hace de puente entre dos
redes, y el tr´fico que no puede ser reenviado se manda a dos instancias de
a
CCOTTA, una para filtrar tr´fico en cada sentido:
a
Red Interna
Red Externa
Tarjeta
HitechGlobal
Dos servidores
CCOTTA
Figura 8: Escenario para una tarjeta con 4 puertos 10GbE
23

25. Jaime J. Garnica
5.3. Metodolog´
ıa
5.3.1. Lenguajes RTL
La implementaci´n del fichero que ser´ cargado en la FPGA, llamado
o a
bitstream, se lleva a cabo mediante las herramientas de Xilinx. En primer
lugar, para el desarrollo de la aplicaci´n que correr´ en la FPGA se utiliza
o a
la herramienta Xilinx ISE. En dicha herramienta, se crean proyectos basados
en c´digo RTL, en esta caso el lenguaje VHDL. Estos lenguajes basan su
o
organizaci´n en m´dulos, los cuales siguen una jerarqu´ dependiendo de la
o o ıa
forma en la que se instancian los unos a los otros, a partir de un modo gene-
ral, o top-level. No obstante, cierto m´dulos no es necesario generarlos al ser
o
m´dulos muy comunes y previamente generador por la herramienta Xilinx
o
Coregen, o Core Generator, que crea dichos m´dulos a partir de unos par´me-
o a
tros establecidos por el desarrollador. Una vez realizada la implementaci´n o
del bitstream, este fichero se descarga a la placa mediante la herramienta
Xilinx iMPACT.
5.3.2. Simulaci´n de m´dulos
o o
Para realizar tanto las pruebas unitarias como las de integraci´n, se em-
o
plea un entorno de simulaci´n en modo de caja blanca, de manera que se
o
puedan comprobar las diferentes se˜ales y su comportamiento dentro del
n
m´dulo. La herramienta de simulaci´n que se ha empleado para este trabajo
o o
es la llamada ModelSim de Modeltech. Esta herramienta emplea un script de
simulaci´n en el que se cargan el/los m´dulos que se van a probar. Una vez
o o
cargados dichos m´dulos se lanza el llamado testbench (del ingl´s, banco de
o e
pruebas), escrito tambi´n VHDL, en el que se instancian las diferentes prue-
e
bas o caso de uso que se desean comprobar, generando las entradas, incluidas
las de reloj y reset. Una vez llevado a cabo el procesamiento de las se˜ales
n
se pueden comprobar las salidas.
5.3.3. Validaci´n en placa
o
Una vez se ha comprobado que las simulaciones funcionan correctamen-
te, se debe llevar a cabo la comprobaci´n del funcionamiento en placa. Para
o
ello se debe implementar, antes de la s´
ıntesis, el sistema con los m´dulos de
o
validaci´n que permitan comprobar ciertas se˜ales preseleccionadas mientras
o n
el dise˜o esta corriendo en placa. Para la verificaci´n con tr´fico real se pro-
n o a
pone el uso de la herramienta ChipScope, tal como muestra la Figura 9, que
permite implementar un analizador l´gico dentro de la propia FPGA, usando
o
sus recursos libres. De esta manera se pueden ver en tiempo real el estado
24

26. Trabajo Final de Master
de las se˜ales internas a la FPGA, usando la herramienta Analyzer, que a
n
trav´s del puerto JTAG de configuraci´n se conecta con los cores ChipScope
e o
que hay instanciados dentro de la FPGA. Para crear los cores ChipScope,
en particular el ILA (Integrated Logic Analyzer), que es el adecuado en este
caso, se propone el uso de la herramienta CoreGen de Xilinx. Una vez gene-
rado, se instancia dentro de la descripci´n VHDL del m´dulo que se desea
o o
verificar, y se le conectan las se˜ales que se quiere monitorizar. Se pueden
n
instanciar hasta 15 de estos bloques ILA dentro de la FPGA, y todos ellos
deben estar conectados a un bloque ICON (Integrated Controller) que es el
que 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 comunicaci´n entre el hardware y las
o
aplicaciones software. Estos controladores se sit´an en el Kernel de Linux
u
en forma de m´dulos. Para el desarrollo de los controladores, o drivers, se
o
requiere una codificaci´n en leguaje C y la ejecuci´n de diferentes comandos
o o
del sistema para cargar dichos m´dulos.
o
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

27. Jaime J. Garnica
la codificaci´n de dichos lenguajes se realiza de forma similar, sin embargo,
o
dichos lenguajes tienen configuraciones y comandos propios. En el caso de
este 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 ha
modificado ligeramente, a˜adiendo nueva sintaxis y funciones que permiten
n
controlar la temporizac´n y compilaci´n del c´digo. La segunda, proporcio-
o o o
nada por Xilinx, es un compilador que proporciona un entorno de codificaci´n o
para C y C++. No modifica la codificaci´n del lenguaje, sin embargo, permi-
o
te incluir una serie de directivas que afectan al procesamiento del compilador
para optimizar la creaci´n el lenguaje RTL y, por lo tanto, del comportamien-
o
to del software (e.g. pipeline en bucles, tipo de interfaces de los par´metros).
a
Una vez generado el c´digo RTL, ´ste es incluido en el proyecto hardware
o e
como si de cualquier otro m´dulo se tratase.
o
6. Arquitectura FPGA
El dise˜o de la arquitectura que se integra en la FGPA se basa princi-
n
palmente en el uso de perif´ricos que contiene la placa para llevar a cabo la
e
funcionalidad deseada. Tal como se puede ver en la Figura 10, en el exterior
de la FPGA est´n los diferentes perif´ricos que se van a emplear y, dentro
a e
de la misma, la forma en que se comunican con la aplicaci´n de filtrado.
o
Figura 10: Arquitectura general de la FPGA
26

28. Trabajo Final de Master
Los perif´ricos de este sistema son el PCIe para realizar la comunicaci´n
e o
con el software con el fin, tanto de actualizar la tabla de reglas como de
gestionar el sistema, y recibir los paquetes filtrados; interfaces 10GbE para
recoger y reenviar la comunicaci´n en ambos sentidos de la red, conectando
o
un extremo a Internet y otro al equipo subscriptor; y el conjunto de memo-
rias QDR-II que almacenen las reglas de filtrado. El m´dulo llamado Filtering
o
Engine (del ingl´s, motor de filtrado) es el envoltorio que permite aislar la
e
aplicaci´n de filtrado de los m´dulos que gestionan los perif´ricos. De esa
o o e
manera, cambiar de aplicaci´n no requiere modificar el sistema completo,
o
sino s´lo modificar el contenido de dicho m´dulo, consiguiendo as´ habilitar
o o ı
la reutilizaci´n de la plataforma para diferentes soluciones y del m´dulo pa-
o o
ra diferentes plataformas. Mediante esta soluci´n se cumple el requisito de
o
portabilidad planteado en la secci´n 4.1.
o
6.1. Perif´ricos
e
El manejo de perif´ricos desde el hardware se realiza con la implementa-
e
ci´n e integraci´n de cores espec´
o o ıficos. Dichos cores llevan a cabo la configu-
raci´n, manejo e interpretaci´n de la comunicaci´n mediante el perif´rico y
o o o e
el resto del sistema. A continuaci´n se presentan los perif´ricos que se van a
o e
emplear en el trabajo.
6.1.1. PCI-Express
El PCIe se emplea para establecer una comunicaci´n entre el sistema
o
software (el servidor) y el sistema hardware (la tarjeta FPGA). Esta co-
municaci´n ser´ esencial para las diferentes partes del trabajo como son la
o a
funcionalidad, el control, la depuraci´n y la verificaci´n.
o o
En cuanto a la funcionalidad, podemos caracterizar dos puntos impor-
tantes. En primer lugar, se debe poder enviar los paquetes filtrados por la
tarjeta al servidor de forma transparente a ´ste, como si de una NIC (Net-
e
work Interface Card) se tratase, cumpliendo el requisito mencionado en la
Secci´n 4.4. Esta comunicaci´n se realizar´ mediante DMA (Direct Memory
o o a
Access), de forma que se pueda alcanzar una tasa alta paquetes por segun-
do. En segundo lugar, la actualizaci´n de reglas de direcciones IP mediante
o
escrituras y lecturas por el PCIe y una debida gesti´n de las mismas en la
o
tarjeta, as´ como diferentes opciones de lista blanca o negra, puenteado de
ı
interfaces, ect..
La gesti´n y control del sistema mediante la consulta de registros es asi-
o
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

29. 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 de
registros, junto a otros m´s espec´
a ıficos, ser´n empleados durante la depura-
a
ci´n y verificaci´n del sistema.
o o
El motivo que antepone el empleo de PCIe en lugar de PCI convencional
es, principalmente la tasa de datos que se consigue en las transferencias. en
el caso del PCI convencional la tasa de datos m´xima que se obtiene por
a
l´
ınea des es de 500Mbps. En el caso del PCIe la tasa obtenida depende de la
generaci´n que se emplee del mismo. Por ejemplo en el caso de la generaci´n
o o
PCIe 1.0 la tasa de l´
ınea obtenida es de 2,5×0,8×(0,75/0,85) = 0,88Gbps por
cada l´ınea de transmisi´n. Al tratarse, ´ste, de un trabajo en redes de 10Gbps
o e
conviene que la tasa que se obtenga no impida que el sistema trabaje a dicha
tasa en el caso de las redes de comunicaci´n. Por ello y por lo explicado en
o
este p´rrafo el sistema de comunicaci´n que se adopta en el trabajo debe ser
a o
igual 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 de
cada paquete debe ser almacenado en memorias, principalmente para poder
realizar su actualizaci´n din´mica. Para ello se debe llevar a cabo la selecci´n
o a o
correcta de las memorias que se van a emplear bas´ndose en los diferentes
a
aspectos que debemos tener en cuenta como son, esencialmente, el tama˜o n
del conjunto de reglas y el tiempo de acceso a cada regla. Las reglas sobre
las que se va a actuar es todo el conjunto de reglas IP posibles en la red, es
decir, 232 reglas si hablamos de IPv4. Para almacenar un bit para cada una
de las reglas de todo el conjunto deber´ obtenerse una memoria de 4Gbits,
ıa
es decir 512MBytes.
Las unicas memorias accesibles desde una FPGA en la actualidad que
´
alcanzan la capacidad de 512MBytes son las memorias DDR [10]. Este tipo
de memorias tienen una temporizaci´n de acceso particular. Para acceder
o
a un dato se debe cargar previamente la p´gina en la que se encuentra el
a
mismo, eso tiene como consecuencia que si un dato no est´ en la p´gina
a a
precargada en ese momento se deber´ perder un tiempo extra de acceso para
a
cargar dicha p´gina. Puesto que la llegada de las direcciones IP al sistema es
a
aleatoria esto conllevar´ un tiempo excesivo de acceso y no determinista a
ıa
la memoria, mucho mayor que el tiempo entre llegada de los paquetes. Por
estas razones se descarta el uso de este tipo de memorias.
El tipo de memoria que tiene un acceso inmediato en las tarjetas basadas
en FPGA son las BlockRAM. Estas memorias tienen un tiempo de acceso de
un ciclo (pocos nanosegundos). Sin embargo, el problema principal de estas
28

30. Trabajo Final de Master
memorias es la capacidad que ofrecen al sistema, la cual no llega a los Mbits.
Hay, por lo tanto, un trade-off (del ingl´s, compromiso) que se debe estudiar
e
sobre el tama˜o de las memorias y su temporizaci´n de acceso a datos.
n o
Un tercer tipo de memorias que se encuentra en las tarjetas con FPGA
actuales son las llamadas QDR y QDR-II [17]. Este tipo de memorias presen-
tan una temporizaci´n determinista, es decir, el tiempo de acceso a los datos
o
es constante par cualquiera que sea la direcci´n, y una capacidad de Mbits de
o
almacenamiento. Concretamente llegan hasta las decenas de Mbits. Para que
el trade-off no se vea comprometido por la capacidad de almacenamiento se
emplea un m´todo de almacenamiento de datos basado en direccionamiento
e
hash con colisiones, empleando una funci´n de hash de menos longitud que
o
26
el tama˜o de una direcci´n IP (e. g. 2 direcciones para un hash de 26 bits,
n o
es decir, una memoria de 64Mbits de capacidad).
6.1.3. Interfaces 10GbE
Para que la tarjeta tenga una comunicaci´n con Internet y el resto de
o
redes, a la tasa de datos que se desea obtener, se requiere el uso de interfaces
de red 10GbE (Gigabit Ethernet). Muchos son los tipos de conectores y
de sistemas que se pueden emplear en estos casos. La principal distinci´n o
entre los mismos es su medio de transporte, encontrando dos tipo esenciales
como son el cable de cobre y la fibra ´ptica. En este trabajo se ha pensado
o
principalmente en el uso de conectores XFP, que proporcionan una interfaz
optica. Sin embargo tambi´n se puede llevar a cabo la comunicaci´n mediante
´ e o
cable de cobre empleando transceptores del tipo CX4.
6.2. Aplicaci´n
o
La aplicaci´n implementa dos puentes, bridge01 y bridge10, tal como se
o
repesenta en la Figura 11. El puente bridge01 recoge tr´fico por la interfaz
a
0 y lo reenv´ a la interfaz 1 si sus direcciones IP no est´n restringidas. En
ıa a
caso contrario, el tr´fico se env´ a la cola DMA asociada con el dispositivo
a ıa
/dev/ceth0 del host. De la misma manera, el puente recoge las tramas que
env´ el host a trav´s de la cola DMA asociada al dispositivo /dev/ceth1, y
ıa e
las reenv´ a la salida de la interfaz1. Alternativamente, el puente bridge10
ıa
recoge tr´fico por la interfaz 1 y lo reenv´ a la interfaz 0 si sus direcciones
a ıa
IP no est´n restringidas. En caso contrario, el tr´fico se env´ a la cola DMA
a a ıa
asociada con el dispositivo /dev/ceth1 del host. De la misma manera, el
puente recoge las tramas que env´ el host a trav´s de la cola DMA asociada
ıa e
al dispositivo /dev/ceth0, y las reenv´ a la salida de la interfaz0.
ıa
29

31. Jaime J. Garnica
DMA1
BRIDGE01
IF0 IF1
BRIDGE10
DMA0
Figura 11: Puentes de filtrado
La Figura 12 muestra la arquitectura global de la aplicaci´n de filtrado,
o
integrada en el dise˜o FPGA. Las l´
n ıneas finas son se˜ales, las l´
n ıneas de grosor
medio son buses, y las l´ıneas gruesas representan conexiones FrameLink.
Los puentes se implementan mediante los bloques IF CTRL. Este bloque
recoge el tr´fico proveniente de la interfaz de red a trav´s de la interfaz Fra-
a e
meLink FROM NET, y lo reenv´ hacia el filtro por la interfaz TO FILTER.
ıa
El filtro mira las direcciones IP fuente y destino de los paquetes, de tal ma-
nera que se clasifica el tr´fico en dos clases: el que se puede reenviar sin
a
problema, 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 tr´fico del puer-
a
to FROM FILTER 1 se env´ hacia la interfaz de red a trav´s del puerto
ıa e
TO NET, junto con el tr´fico proveniente del host que entra por el puer-
a
to FROM DMA. Por otro lado, el tr´fico del puerto FROM FILTER 2 se
a
reenv´ directamente hacia el host a trav´s del puerto TO DMA.
ıa e
La pieza clave de toda esta estructura es el filtro FILTER, que es quien
implementa los clasificadores de tr´fico. El filtro tiene dos puertos de entrada
a
NI0 IN y NI1 IN, correspondientes con las dos interfaces de red. El tr´fico a
proveniente de cada una de estas dos interfaces es clasificado en reenviable, o
no reenviable, de acuerdo a las direcciones IP origen y destino de los paque-
tes. Si es reenviable, se devuelve respectivamente por los puertos NI0 NET
y NI1 NET, y si no se puede reenviar, se manda respectivamente por los
puertos NI0 DMA y NI1 DMA. Para hacer esta clasificaci´n, el filtro tiene
o
que acceder a las memorias donde se almacenan las direcciones restringidas
30

32. Trabajo Final de Master
Figura 12: Arquitectura general de la aplicaci´n hardware
o
31

33. Jaime J. Garnica
para el reenv´ (o m´s concretamente, los hashes de las direcciones, como
ıo a
se describe en la Secci´n 6.3.2. Hay dos memorias, una para las direcciones
o
externas (Internet) y otra para las direcciones internas (subscriptores). El
acceso a las memorias se hace a trav´s del protocolo Local Bus.
e
6.3. Comunicaciones
Tanto los m´dulos del sistema como los cores que manejan los diferentes
o
perif´ricos necesitan comunicarse entre s´ Muchas son las formas de comuni-
e ı.
caci´n, pero en cuanto a sistemas de escritura y lectura con direcciones o en
o
streaming (flujo de datos) lo m´s habitual es definir una serie de protocolos
a
que determinen esa comunicaci´n.o
En la Figura 13 se muestra el flujo de los datos a lo largo de los m´du-
o
los de la arquitectura, distinguiendo dos flujos como son los paquetes y las
peticiones de acceso a las memorias. El flujo de paquetes comienza en las
comunicaciones externas, DMA e Interfaz de Red, y atraviesa los diferen-
tes m´dulos de filtrado, los cuales deciden el siguiente m´dulo por el que
o o
ser´ dirigido dicho flujo. En cuanto al flujo de peticiones de b´squeda, ´stas
a u e
comienzan cuando un paquete atraviesa el m´dulo de parseo de direcciones
o
IP y es enviado a los m´dulos de consulta y comprobaci´n de reglas, los
o o
cuales redirigen al m´dulo de acceso a las memorias QDR. Por ultimo, las
o ´
peticiones desde el PCIe, es decir, desde el software, son gestionadas por un
m´dulo que decide si son peticiones de registros y devuelve sus valores, o
o
si se refieren a actualizaci´n/consulta de reglas y en ese caso son dirigidas
o
tambi´n al m´dulo de acceso a las memorias QDR.
e o
QDR Packet
memories Input IF0 IP parsing Output IF0
FIFO
Updating QDR-II Filtering Packet
Matching DMA
Request FIFO Manager Request FIFO
Packet
Rule Updating Input IF1 IP parsing Output IF1
FIFO
Module
PCI Main modules Data flows
Packet Filtering Module Rule data flow
QDR-II Access Module Packet flow
Figura 13: Flujo de datos del sistema
En la arquitectura propuesta se emplean hasta 3 tipos de protocolo den-
tro de la aplicaci´n de filtrado (un mayor n´mero si tenemos en cuenta las
o u
32

34. Trabajo Final de Master
comunicaciones entre los cores y sus respectivos perif´ricos). El primero de
e
ellos, el protocolo Local Bus, es el protocolo que se ha empleado para manejar
datos con direccionamiento a lo largo de los m´dulos del sistema. Es un pro-
o
tocolo sencillo. En segundo lugar se emplea el conocido protocolo LocalLink,
o mejor dicho, su variante FrameLink, el cual se emplear´ para el streaming
a
a lo largo del dise˜o. Por ultimo, el protocolo de control de memoria, o MIG,
n ´
que ser´ el empleado para accedes a las memorias QDR-II.
a
6.3.1. Protocolo Local Bus
El Local Bus es un bus cuya mayor ventaja es la sencillez. Aunque tambi´n
e
es un bus segmentado, por lo que permite transferir una palabra por ciclo de
reloj, a diferencia del Internal Bus no est´ preparado para transferir grandes
a
r´fagas de datos ni para transferencias DMA. Es tambi´n un bus s´
a e ıncrono, y
el endpoint proporciona estas se˜ales para acceder a ´l:
n e
MI DWR: Input Data, datos de escritura
MI ADDR: Address, direcci´n de acceso
o
MI RD: Read Request, bandera de lectura
MI WR: Write Request, bandera de escritura
MI BE: Byte Enable, indexador de bytes v´lidos
a
MI DRD: Output Data, datos de lectura
MI ARDY: Address Ready, bandera de confirmaci´n
o
MI DRDY: Data Ready, bandera de respuesta
La Figura 14 presenta una lectura t´ ıpica de varias posiciones de la apli-
caci´n por parte del endpoint. Cuando el endpoint quiere leer una posici´n,
o o
pone la direcci´n y el byte enable, y activa la se˜al RD. Se ordena una lectura
o n
cada ciclo de reloj salvo que la aplicaci´n quiera introducir estados de espera
o
mediante la se˜al ARDY. Cuando la aplicaci´n tiene los datos disponibles,
n o
los devuelve por el bus DRD, indicando que hay un dato v´lido mediante la
a
se˜al DRDY. Los datos se devuelven consecutivamente, siguiendo el mismo
n
orden que fueron solicitados por el endpoint. Si la aplicaci´n no es capaz de
o
devolver datos a la tasa que permite el reloj, introduce estados de espera
desactivando la se˜al DRDY.
n
La Figura 15 muestra una transferencia de escritura t´ ıpica desde el end-
point hacia la aplicaci´n. El endpoint indica que quiere escribir datos acti-
o
vando la se˜al WRITE, y al mismo tiempo pone la direcci´n, dato y byte
n o
33

35. Jaime J. Garnica
Figura 14: Lectura LocalBus [15]
enable de la posici´n a escribir. Se produce una escritura en la aplicaci´n con
o o
cada flanco de reloj, salvo que la aplicaci´n no est´ preparada para recibir
o e
datos y meta un estado de espera desactivando la se˜al ARDY.
n
Figura 15: Escritura LocalBus [15]
6.3.2. Direccionamiento y funciones hash
El protocolo Local Bus es empleado en la b´squeda de direcciones IP,
u
tanto antes como despu´s de realizar el hash, por los m´dulos de entrada,
e o
salida y procesamiento de tramas. Es empleado tambi´n en la comunicaci´n
e o
34

36. Trabajo Final de Master
con el PCI-Express y por lo tanto con el software. Tanto en el manteni-
miento de las reglas como en la comprobaci´n y modificaci´n de registros
o o
de configuraci´n y de estado. De esta manera, mediante un traductor del
o
protocolo PCI-Express a este protocolo se pueden manejar dichas peticiones
del software de manera sencilla.
La actualizaci´n de reglas se realiza mediante escrituras por parte del
o
software hacia la tarjeta mediante el protocolo de LocalBus. En dichas es-
crituras el direccionamiento hace referencia al resultado de la funci´n hash
o
sobre una o varias direcciones IP y los datos a escribir son los valores de
filtrado deseados para dichas direcciones IP. La b´squeda de reglas se rea-
u
liza de forma an´loga a la escritura. En este caso, la direcci´n de escritura
a o
hace referencia a los datos que se desean leer y estos son devueltos por el
sistema que contiene dichas reglas. Normalmente, el tama˜o de las memo-
n
rias es menor que el tama˜o necesario para las reglas, por lo que funci´n de
n o
hash presentar´ colisiones, dando falsos positivos, que ser´n resueltas por el
a a
software finalmente.
6.3.3. Protocolo FrameLink
La transmisi´n de las tramas se realiza mediante el protocolo FrameLink,
o
mostrado en la Figura 16, variante del LocalLink capaz de diferenciar las
partes por las que esta constituido el mismo. El ancho de los datos es de
128bits y la frecuencia de transmisi´n es de 125MHz.
o
Figura 16: Transferencia FrameLink [15]
35