OpenFlow

OpenFlow es una tecnología de switching que surgió a raíz del proyecto de Investigación: “OpenFlow: Enabling Innovation in Campus Networks” de 2008 en la Universidad de Stanford. Se define como un protocolo emergente y abierto de comunicaciones que permite a un servidor de software determinar el camino de reenvío de paquetes que debería seguir en una red de switches. Con el protocolo OpenFlow, una red puede ser gestionada como un todo, no como un número de dispositivos que gestionar individualmente, es el propio servidor el que dice a los switches dónde deben enviar los paquetes. Con esta tecnología, las decisiones que impliquen el movimiento de paquetes están centralizadas, por lo que la red puede ser programada independientemente de los switches. En un switch convencional, el reenvío de paquetes Datapath y el encaminamiento de alto nivel (control path) se realizan en el mismo dispositivo, sin embargo en los switches OpenFlow ambos se separan. Con OpenFlow, una parte del datapath reside en el mismo switch, pero es un controlador el que realiza las decisiones de encaminamiento de alto nivel. Ambos elementos se comunican por medio del protocolo OpenFlow. Esta metodología, conocida como SDN permite una mayor efectividad en el uso de los recursos de la red que en una red convencional. OpenFlow está pensada para afrontar la movilidad de máquinas virtuales (VM), redes con misiones críticas o redes NGN móviles.

Historia

El Open Flow Switch Consortium ha mantenido la especificación hasta hace poco, cuando la Open Networking Foundation anunció que asumiría esa responsabilidad. En 2011 la ONF (Open Networking Foundation ) se fundó con el objetivo de estandarizar las tecnologías emergentes impulsando el software a la vanguardia de la gestión de red y de los centros de datos. Mientras que la primera versión del protocolo OpenFlow (versión 1.1) se lanzó en febrero de 2011, la segunda (versión 1.2) fue supervisada por la ONF que tiene el control sobre la especificación. Actualmente la versión en vigor es la 1.4.0. Miembros fundadores que podemos citar son Google, Facebook y Microsoft, a los que se han ido añadiendo: Allied Telesis, Citrix, Cisco, Dell, HP, F5 Networks, IBM, NEC, Huawei, Juniper Networks, Oracle y VMware, todas ellas grandes empresas del sector de las telecomunicaciones.

Propuesta

Lo que propone OpenFlow: una manera para que los investigadores puedan experimentar con protocolos en las redes que se usan a diario. Además supone un compromiso pragmático: por una parte permite a los investigadores experimentar con switches heterogéneos de manera uniforme a la velocidad de la línea y con una densidad de puertos muy alta. Por otra parte, los fabricantes no tienen que exponer los procesos internos de sus switches. La propuesta de OpenFlow es muy clara: permitir que los investigadores puedan evaluar sus ideas en un entorno de trabajo real y ser un componente muy útil en los bancos de pruebas a gran escala.

Antecedentes

Las redes se han convertido en una parte crítica de la estructura de negocios, casas, escuelas… Este éxito presenta dos caras: por una parte es bueno para los investigadores, su trabajo es más relevante, pero sus posibilidades de realizar grandes avances y experimentos son más remotas. No hay ninguna manera práctica de experimentar con nuevos protocolos de encaminamiento, alternativas a IP) con configuraciones lo suficientemente realistas. El gran obstáculo que presentan las redes actuales es la incapacidad de poder trabajar con tráficos reales. Para que una tecnología se despliegue extensamente se debe ganar la confianza suficiente por parte de los especialistas. La idea de este tipo de plataforma no es original, aunque con OpenFlow se pretende obtener un rendimiento mayor. Como antecedente tenemos a la red GENI , una red cuya propuesta es facilitar el poder experimentar con nuevas arquitecturas de red y sistemas distribuidos. Estas redes programables llaman a routers/switches programables que, usando la virtualización, pueden procesar paquetes de experimentos aislados entre sí simultáneamente. Introducimos por tanto un nuevo término en las redes, que está cobrando mucho protagonismo en los últimos tiempos.

El Switch OpenFlow

La idea básica es simple: explotar el hecho de que la mayoría de los switches Ethernet contienen tablas de flujos (Flow-Tables), que trabajan a la velocidad de la línea para implementar firewalls, NAT, QoS y recolectar estadísticas. Aunque las Tablas de Flujos que maneja cada fabricante son propias, se han aprovechado características observadas y comunes a todas ellas. Precisamente eso es lo que ofrece OpenFlow, un protocolo abierto para poder programar las tablas de flujo en diferentes switches y routers. Los administradores de la red solo necesitarían dividir el tráfico entre producción y el dedicado a la investigación. De esta manera, se conseguiría experimentar con nuevos protocolos, nuevos modelos de seguridad, esquemas de direccionamiento, incluso alternativas para IP y en definitiva una innovación mayor. Visto de esta manera, OpenFlow podría ser una generalización de las VLAN´s. El tráfico de producción no se vería afectado ya que está aislado y se procesaría de la misma manera que se ha estado realizando hasta hoy día. Las acciones que pueden soportar los switches OpenFlow son extensibles, si bien es necesario tener unas características mínimas y comunes a todos ellos.

Partes de un Switch OpenFlow

Un switch OpenFlow consiste en al menos tres partes:

Tabla de flujos: con una acción asociada a cada entrada de la tabla, indicando al switch cómo debe procesar ese flujo
Canal seguro que conecte el switch a un proceso de control remoto (controlador), permitiendo comandos y paquetes se puedan enviar entre el switch y el controlador usando el protocolo OpenFlow
Controlador: Un controlador añade y elimina entradas en la tabla de flujos para poder permitir los experimentos.

Un controlador estático podría ser una simple aplicación funcionando en un PC que añadirá estáticamente flujos y que puede interconectarse a su vez a una serie de ordenadores con funciones de analizadores de tráfico. Existen también controladores más sofisticados que dinámicamente añaden/eliminan flujos. De esta manera, un Administrador de Red será capaz de gestionar todos los flujos y cómo serán procesados. Un controlador de estas características podría ser soportado por varios investigadores, cada uno con diferentes cuentas y permisos, permitiendo que todos ellos puedan realizar múltiples experimentos con diferentes conjuntos de flujos. El protocolo del controlador del switch trabaja sobre la capa TLS (Transport Layer Security) o conexiones TCP sin seguridad.

Tipos de Switches

Existen dos tipos de switches: aquellos switches OpenFlow-only (solo OpenFlow) que no son compatibles con las capas 2 y 3 convencionales y los híbridos.

Switches OpenFlow-only Un switch que soporta OpenFlow, contiene múltiples tablas de flujos, y cada flujo contiene múltiples entradas de flujo. El procesado define cómo los paquetes interactuarán con estas tablas de flujos. Requiere que tenga al menos una tabla de flujo y opcionalmente más. Cuantas menos entradas más simplificado será el procesado.

La figura muestra un ejemplo de un switch OpenFlow:

En este contexto los flujos están ampliamente definidos, solo están limitados por la capacidades de una determinada implementación de la Tabla de Flujo. Por ejemplo un flujo puede ser una conexión TCP, o todos los paquetes de una determinada dirección MAC o IP, todos los paquetes con la misma etiqueta VLAN, o todos los paquetes de un mismo puerto del switch. Para experimentos que no incluyen paquetes IPv4 , un flujo podría ser definido para que todos los paquetes cumplan una cabecera específica (no estándar). En la sección ejemplos se explicará más ampliamente este concepto.

Switches OpenFlow-híbridos Switches que soportan tanto la operación OpenFlow como el Switching Ethernet convencional. Operaciones habituales pueden ser: Switching Ethernet de Capa 2, aislamiento de tráfico con VLAN, nivel 3 o de routing (IPV4, IPV6), listas de acceso o QoS. Estos switches deberán proveer un mecanismo de clasificación fuera de OpenFlow que enrute el tráfico o bien ser procesado por OpenFlow. Por ejemplo, un switch deberá usar una etiqueta VLAN o puerto de entrada para decidir si se procesa el paquete de una manera u otra o debe redirigirlos hacia el procesador OpenFlow. Este mecanismo de clasificación sale fuera del ámbito de la especificación. El protocolo OpenFlow permite que el switch sea controlado por dos o más controladores para incrementar el rendimiento y la robustez del sistema. A continuación se muestra una posible configuración de este tipo de switches, en el que todas las tablas de flujos se gestionan por el mismo controlador.

Como funciona OpenFlow

Los switches tradicionales usan STP, SPB, TRILL para determinar cómo se reenvían los paquetes. OpenFlow traslada esta decisión de reenvío de los switches a los controladores, típicamente un servidor o una estación de trabajo. Una aplicación de gestión se ejecutará en las interfaces del controlador que une todos los switches en la red, facilitando la configuración de caminos de reenvío que utilizarán todo el ancho de banda disponible. La especificación define el protocolo entre el controlador y los switches y un conjunto de operaciones que se pueden realizar entre ellos. Las instrucciones de reenvío se basan en el flujo, que consiste en que todos los paquetes comparten una serie de características comunes. Existen infinidad de parámetros que pueden especificarse para definir un flujo. Entre los posibles criterios podemos incluir los puertos por donde se reciben los paquetes cuando llegan, el puerto Ethernet de origen, la etiqueta VLAN, el destino Ethernet o el puerto IP y otro número de características de los paquetes. Un nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna coincidencia con ninguna entrada de la tabla. El switch debería tener configurado un descartado de paquetes para el flujo que no haya sido definido, pero en la mayoría de los casos, el paquete será enviado al controlador. El controlador entonces define un nuevo flujo para ese paquete y crea una o más entradas para la tabla. Este envía la entrada o entradas al switch para que sean añadidas a las tablas de flujo. Finalmente, el paquete se envía de vuelta al switch para ser procesado con las nuevas entradas creadas.

Flujos

Cada flujo de entrada tiene asociada una acción simple. Las tres básicas son:

Reenvío de flujo de paquetes a un puerto dado (o puertos). Esto permite que los paquetes sean encaminados a través de la red. En la mayoría de los switches sucede a la velocidad de la línea.
Encapsulación y reenvío de este flujo de paquetes al controlador. El paquete será enviado al Canal Seguro, donde se encapsula y se envía al controlador. Típicamente se usa para el primer paquete en un nuevo flujo, para que el controlador pueda decidir si el flujo debe ser añadido a la tabla de flujos. También se puede usar para reenviar todos los paquetes al controlador para que sean procesados.
Descartar este flujo de paquetes. Puede ser usado por seguridad , para parar ataques de denegación de servicio o reducir el falso tráfico de descubrimiento broadcast desde los hosts finales.

Tablas de Flujos

Una entrada de flujo tendrá este formato:

Se identifica principalmente por sus coincidencias y prioridad. Ambos campos identifican un flujo único en la Tabla de Flujos. Podemos citar 3 campos principales:

La cabecera del paquete que define el flujo.
La acción, que define como deben ser procesados los paquetes.
Las estadísticas que llevan la monitorización del número de paquetes y los bytes de cada flujo y el tiempo desde el cual el último paquete coincidió el flujo (esto permite el borrado automático de flujos inactivos).

Match fields: puerto y cabecera. Opcionalmente metadatos especificados en una tabla anterior.
Priority: coincidencia con el flujo de entrada.
Counters: Se actualiza cuando se encuentra una coincidencia.
Instructions: para modificar el conjunto de acciones.
Timeouts: tiempo máximo antes de que el switch descarte el flujo.
Cookie: Valor que elige el controlador para filtrar las estadísticas, las modificaciones y el borrado de los flujos. No se usa: cuando se procesan los paquetes.

Matching

En la siguiente figura se ilustra el proceso de "matching" o búsqueda de coincidencias:

Cuando se recibe un paquete el Switch OpenFlow realiza las acciones que se ven en la figura. El switch comienza haciendo una búsqueda en la primera tabla de flujo. Las tablas de flujos se numeran empezando por el cero, y basado en esta primera búsqueda realizara búsquedas en otras tablas de flujo.

A los campos que coinciden con alguna entrada se les extrae del paquete. Los campos que se utilizan para buscar coincidencias dependen del tipo del paquete y típicamente incluyen varios campos de cabecera, las coincidencias también se pueden hacer en base al puerto de entrada o por campos de metadatos.

Los metadatos se usarán para poder mandar información entre las tablas en un switch. Un paquete coincide con una entrada de la tabla de flujos si los valores de los campos del paquete que se usan para la búsqueda están definidos en la misma.

Si tiene un valor ANY (omitido), coincidirá con todos los valores posibles en la cabecera. Si el switch trabaja con máscaras arbitrarias para campos específicos se podrá afinar mucho más las coincidencias. El paquete solo coincidirá también tiene la prioridad más alta Los contadores asociados a la tabla seleccionada deben ser actualizados y el set de instrucciones incluido en el flujo seleccionado, será aplicado.

Si hay múltiples coincidencias y todas tienen configuradas la misma prioridad, la entrada de flujo seleccionada esta explícitamente indefinida. Está especificación no tiene en cuenta si el switch recibe un paquete corrupto o con un formato que no es el adecuado.

Los requerimientos técnicos se encuentran en “Open Flow Switch Specification”

Tablas de Grupos

Los grupos proveen una eficiente manera de indicar que el mismo conjunto de acciones deben ser llevadas a cabo por múltiples flujos. Por ello, es útil para implementar multicast y unicast.

Cada entrada consiste en su identificador, el tipo de grupo, un contador y un set de action buckets.

Identificador de grupo: entero sin signo que define unívocamente el grupo.
Tipo de Grupo: para determinar la semántica del grupo.
Contadores: Actualizados cuando los paquetes son procesados por el grupo.
Set de acciones (action buckets): lista ordenada de acciones, donde cada acción contiene un conjunto de acciones a ejecutar y unos parámetros asociados.

Meter Tables

Con estas tablas, se mide la tasa de paquetes asignadas a ellas y se facilita el control de la tasa de esos paquetes. Están unidas directamente a las entradas de flujo (al contrario que las colas que están relacionadas con los puertos). Consiste en entradas de medidas, definiendo medidas por flujo. Habilitan a OpenFlow para poder implementar operaciones de QoS simples, como limitar el tráfico, y pueden ser combinadas con colas por puerto de entrada, para implementar configuraciones de QoS complejas como DiffServ.

Una tabla tiene los siguientes campos:

Identificador de la medida: entero sin signo de 32 bits que lo define unívocamente.
Meter bands: lista ordenada de ellas, donde cada una especifica el valor de la banda y la manera de procesar el paquete.
Contadores: Se actualizan cuando el paquete es procesado por alguna de ellas.

Instrucciones

Cada tabla de flujo contiene un set de instrucciones que se ejecutan cuando el paquete encuentra una coincidencia con la entrada. Estas instrucciones dan lugar a cambios en el paquete, en el conjunto de acciones y en el procesamiento.

Un switch no tiene por qué soportar todos los tipos de instrucciones, solo las que se marcan como requeridas y son: Instrucción de escritura (Write-Actions “action”): Si la acción del tipo dado existe, se sobrescribe, si no, se añade. Ir a la tabla (Goto-Table “next-table-id”): Indica la siguiente tabla en el procesado. El identificador de la siguiente tabla debe ser mayor que el de la actual. Las entradas del flujo de la última tabla no pueden incluir esta instrucción. Solo se permite una instrucción por cada tipo. Los switches OpenFlow con una tabla no lo necesitarán.

Las instrucciones de la tabla de flujos modifican la acción asociada a cada paquete. Los paquetes empiezan a procesarse con un conjunto de acciones vacío. Las acciones pueden especificar que el paquete que se va a reenviar a través de un puerto específico, modificar el TTL, VLAN, etiqueta MPLS o la QoS.

Además, una instrucción puede especificar un identificador de grupo. Se pueden definir en el switch mediante entradas en la tabla de grupo. Las instrucciones de la primera tabla deberán realizar una acción en el paquete o añadir acciones que se realizarán después. Las instrucciones asimismo, deberán permitir que el procesado de paquetes continúe comparándolos con las entradas de otras tablas de flujos.

Conjunto de acciones

Un conjunto de acciones estará asociado con cada paquete. Este conjunto está vacío por defecto.

Mensajes del Protocolo Openflow

El protocolo consiste en 3 tipos de mensajes: controlador a switch, asíncrono y simétrico.

Controlador a switch se envían para:

Especificar modificar o borrar definiciones de flujos.
Solicitar información acerca de las capacidades del switch.
Obtener información como los contadores del switch.
Enviar paquetes de vuelta al switch para su procesamiento después de que un nuevo flujo se ha creado.

Mensajes asíncronos se envían al switch para:

Enviar al controlador el paquete que no coincide con los flujos existentes.
Informar al controlador que el flujo ha sido eliminado porque su parámetro TTL o el timer de inactividad han vencido.
Informar al controlador de un cambio en el estado de un puerto o de un error que ha ocurrido en un switch. Ejemplos de estas circunstancias son: cuando los links se caen o cuando un paquete llega con una instrucción de reenvío no especificada.

Mensajes simétricos

Pueden ser enviados por los dos: el switch o el controlador y se usan para:
Los mensajes de hello que se intercambian el controlador y el switch al comienzo.
Mensajes de echo usados para determinar la latencia de la conexión controlador-switch y para verificar que esta conexión sigue operativa.
Mensajes experimentales para proveer un camino para futuras extensiones de la tecnología OpenFlow.

Experimentos en la red de producción

Los investigadores quieren probar un nuevo protocolo en una red que usan cientos de personas. Queremos por lo tanto que la red tenga dos propiedades adicionales:

Los paquetes que pertenecen a otros usuarios deben ser encaminados siguiendo un protocolo de encaminamiento estándar, trabajando en un switch comercial y convencional.

Cada investigador solo será capaz de añadir flujos a las entradas de su tráfico, o cualquier tráfico que el administrador de la red haya permitido que controle.

La propiedad uno se consigue con Switches OpenFlow híbridos. La propiedad dos depende del controlador. El controlador debe ser visto como una plataforma que permite que los investigadores puedan implementar varios experimentos, y las restricciones se pueden conseguir con el apropiado uso de permisos u otras maneras de limitar el poder de controlar el flujo de cada persona que quiera realizar experimentos las entradas de flujos.

La naturaleza de estos mecanismos que posibilitan de alguna manera obtener el permiso dependerán de como el controlador este implementado. A continuación se listan ejemplos de redes que en un primer momento se pueden usar para implementar OpenFlow, pero al tratarse de una tecnología emergente, muchos más escenarios se pueden valorar y estudiarse.

Ejemplo 1

Gestión de red y Control de Acceso Ethane Archivado el 10 de mayo de 2012 en Wayback Machine. es el primer ejemplo, ya que fue el descubrimiento que inspiró OpenFlow. De hecho, OpenFlow se puede tomar como la generalización del datapath del switch que proponía Ethane. Esta tecnología usa una implementación específica de controlador ideal para el control y la gestión , que gestiona la admisión y el encaminamiento de los flujos. La idea básica de Ethane es permitir que los administradores de red definan una política de red en el controlador central, lo cual les fuerza directamente a la realización de una decisión de control de admisión para cada nuevo flujo.

Ejemplo 2

VLAN´s OpenFlow puede proveer a los usuarios su propia red aislada, como hacen las VLAN. La manera más simple de conseguirlo es declarar estáticamente un conjunto de flujos que especifican los puertos accesibles por tráfico dado por una VLAN ID. El tráfico que se identifique como entrante de un solo usuario (por ejemplo , el originando desde un puerto específico o de una dirección MAC) es etiquetado por los switches (mediante una acción) con la VLAN ID correspondiente. Una aproximación más dinámica podría ser usar un controlador para poder gestionar la autenticación de los usuarios, utilizando el conocimiento de la ubicación de los mismos para etiquetar el tráfico a tiempo real.

Ejemplo 3

Clientes móviles de VoIP inalámbricos Para este ejemplo se considerará un experimento con una nueva llamada. En el experimento los clientes establecerán una nueva conexión a través de la red habilitada con OpenFlow. Se implementa el controlador para monitorizar la ubicación de los clientes, reencaminado de conexiones (reprogramando las tablas de control) a medida que los usuario se mueven por la red, permitiendo una transferencia continua de un punto de acceso a otro sin pérdida de servicio.

Ejemplo 4

Una red no IP En los ejemplos anteriores se ha asumido que eran sobre redes IP, pero realmente OpenFlow no requiere que sean paquetes de este tipo. Lo único que se necesita es la capacidad de encontrar coincidencias de la cabecera del paquete con nuestra tabla de flujos. Esto posibilitaría la investigación y experimentación usando nuevos nombres, direccionamiento y esquemas de encaminamiento. Maneras de identificar los flujos sin ser red IP: mediante la cabecera Ethernet (MAC origen and destino), un nuevo valor Ethertype, y ya en el nivel IP una nueva versión del protocolo.

Ejemplo 5

Procesado de paquetes en vez de flujos En los ejemplos anteriores se usaban los flujos para poder realizar decisiones. Habrá situaciones en las que necesitemos que cada paquete sea procesado. Ejemplo: IDS (Sistema de detección de intrusiones) necesitan inspeccionar cada paquete, un mecanismo de control de congestión, o cuando se modifican los contenidos de los paquetes, como cuando convertimos un protocolo en otro. Hay dos maneras básicas de procesar los paquetes en una red OpenFlow: La primera (más simple) es que hay que forzar que todos los flujos de paquetes pasen a través del controlador. Para hacer esto, el controlador no necesita añadir un nuevo flujo de entrada en la tabla de flujos del Switch. Solo se permite que el switch, por defecto, reenvíe todos los paquetes al controlador. Esto tiene la ventaja de la flexibilidad al coste del rendimiento. La segunda manera de procesar los paquetes es encaminarlos a un router programable que hace procesado de paquetes. Por ejemplo un router programable (NetFPGA). La ventaja es que se pueden procesar a la velocidad de la línea y pueden ser definidos por el usuario.

Beneficios

OpenFlow permite que las redes evolucionen dando a un controlador que funciona mediante software y lógicamente centralizado, el poder de modificar el comportamiento de los dispositivos de red a través de un conjunto de instrucciones de reenvío bien definidas. Modificando en cierto modo la red, los beneficios de OpenFlow-basado en SDN genera los siguientes beneficios:

Crea flexibilidad en como la red se usa, se opera en ella y se vende. El software que lo controla puede ser escrito por empresas y proveedores de servicio usando un entorno de software común.
Los operadores de red pueden implementar características que quieran en el software que controlan, en vez de tener que esperar que los fabricantes los ponga en marcha en sus propios productos.
Reduce el gasto de operación, lo que conlleva menos errores y menor inactividad (frente a fallos) ya que permite la configuración automatizada de la red y reduce la configuración manual.
Habilita la virtualización de la red y por lo tanto la integración de la Red con la Informática y el almacenamiento. Permite que la operación de las TIC sea controlada de manera más brillante con un solo punto de vista y con las mismas herramientas.
Se puede integrar fácilmente con la informática para los recursos de gestión y mantenimiento OAM
Reúne requisitos beneficiosos para las empresas
Al tratarse de una manera estándar de transmitir la información de las Tablas de Flujos a los dispositivos de red, acoge a mercados abierto y diversos.

Debido a todos estos beneficios que se han creado, OpenFlow ha sido usado en ámbitos tan diversos como los centros de datos a gran escala, los centros de datos de empresas, proveedores públicos y privados de servicios en la red, redes de telecomunicaciones, redes de conmutación de circuitos, redes ópticas. También se está utilizando para variedad de servicios de virtualizacion de redes, seguridad, control de acceso para equilibrado de carga, Ingeniería de Tráfico y gestión de la energía.

Referencias

Especificación: https://www.opennetworking.org/sdn-resources/onf-specifications/OpenFlow
White Paper https://web.archive.org/web/20170804124630/http://archive.openflow.org/wp/learnmore/
OpenFlow Config https://www.opennetworking.org/sdn-resources/onf-specifications/OpenFlow-config

Enlaces externos

Key Benefits of OpenFlow-Based SDN https://www.opennetworking.org/?p=321&option=com_wordpress&Itemid=471&lang=en
Noticia actual http://searchsdn.techtarget.com/news/2240207100/NEC-unveils-first-OpenFlow-13-controller-Scalability-at-last Archivado el 21 de diciembre de 2013 en Wayback Machine.
Introduction to OpenFlow...for Network Engineers https://web.archive.org/web/20131218003833/http://www.jedelman.com/1/post/2011/11/introduction-to-openflowfor-network-engineers.html
OpenFlow protocol primer: Looking Under the Hood http://searchsdn.techtarget.com/feature/OpenFlow-protocol-primer-Looking-under-the-hood Archivado el 20 de octubre de 2013 en Wayback Machine.
Cómo configurar OpenFlow https://web.archive.org/web/20170720011715/http://archive.openflow.org/wp/deploy-labsetup/

Véase también

GENI
TRILL
SDN
ETHANE Archivado el 10 de mayo de 2012 en Wayback Machine.

Datos: Q4045918