Memoria SDN
Memoria SDN
Memoria SDN
Acrnimos y trminos ............................................................................................... - 2 1.-Introduccin .......................................................................................................... - 3 2.-Caractersticas de SDN ........................................................................................ - 5 2.1.-Introduccin. .................................................................................................. - 5 2.2.-Antecedentes ................................................................................................. - 5 2.3.-Definicin ....................................................................................................... - 6 2.4.-Arquitectura de red tradicional ........................................................................ - 6 2.5.-Arquitectura SDN ........................................................................................... - 7 2.6.-Capas de SDN ............................................................................................... - 8 2.7.-OpenFlow....................................................................................................... - 9 2.8.-OpenFlow Switch ......................................................................................... - 10 2.9.-Procesado de un paquete en un switch openFlow ....................................... - 11 2.10.-Protocolo OpenFlow ................................................................................... - 11 2.11.-Controlador ................................................................................................ - 13 2.12.-Estandarizacin, ONF, Open Daylight ........................................................ - 14 2.13.-Ventajas de SDN ........................................................................................ - 15 3.-Estado del Arte de SDN ...................................................................................... - 17 3.1.-Brocade........................................................................................................ - 18 3.2.-IBM .............................................................................................................. - 19 3.3.-Hewlett-Packard ........................................................................................... - 21 3.3.1.-HP Virtual Application Network .............................................................. - 21 3.3.2.-HP Virtual Application Networks SDN Applications ................................ - 23 3.4.-Cisco ............................................................................................................ - 24 3.4.1.-Open Network Environment (ONE) ........................................................ - 24 3.4.2.-Cisco eXtensible Network Controller (XNC) ........................................... - 26 3.4.3.-Application Centric Infrastructure (ACI) .................................................. - 27 3.5.-Vmware ........................................................................................................ - 27 3.5.1.-NSX ....................................................................................................... - 28 3.6.-Red de CPDs de Google .............................................................................. - 30 4.-Mininet ................................................................................................................ - 33 4.1.-Elementos necesarios. ................................................................................. - 34 4.2.-Mininet CLI ................................................................................................... - 37 4.3.-Tests ............................................................................................................ - 41 4.4.-Wireshark ..................................................................................................... - 42 4.5.-Controladores............................................................................................... - 44 4.5.1.-Ejemplo :Creacin de una topologa bsica. .......................................... - 45 4.6.-Controlador POX .......................................................................................... - 50 4.7.-Learning-Switch con seguridad por puerto. .................................................. - 50 4.8.-Funcionalidad ............................................................................................... - 55 5.-Conclusiones ...................................................................................................... - 59 Anexo ..................................................................................................................... - 61 6.-Bibliografa ......................................................................................................... - 65 -
Acrnimos y trminos
AAA.- (Authentication, Authorization and Accounting) Autenticacin, autorizacin
y registro.
API.- (Application Programming Interface) En este contexto, protocolo que
comunica dos capas diferentes.
ASIC.-(Application Specific Integrated Circuit.) Circuito integrado especfico para
una aplicacin.
CAPEX.- Costes financieros.
CPD.- Centro de Procesado de Datos.
Fabric.-En este contexto, electrnica bsica que implementa su funcin principal,
sin ningn aadido extra.
GUI.-(Graphical User Interface) Interfaz grfica de usuario.
Ipv4, Ipv6.- Protocolo IP version 4/6
ISP.- (Internet Service Provider). Proveedor de Servicio de Internet.
LAN.- (Local Area Network) Red de rea local.
MAC address.- (Medium Access Control address).Direccin de nivel OSI 2, de
acceso al medio.
NAT.- (Network Address Translation).Recurso utilizado para permitir el uso de
una determinada direccin IP por diferentes ordenadores.
NFV.- (Network Functions Virtualization). Virtualizacin de redes.
ONF.- Open Networking Foundation.
OPEX.- Costes operativos.
OSPF.-(Open Shortest Path First). Protocolo de enrutamiento OSPF.
QoS.- (Quality of Service) Calidad de servicio.
RBAC.-(Role Based Access Control). Control de acceso basado en el rol del
solicitante.
RFC.- (Request For Comment.)
SDDC.- (Software Defined Data Center.)
SDK.-(Software Developer Kit). Kit para el desarrollador de software.
SDN.- Software Defined Networking.
Spanning Tree.-Protocolo de resolucin de bucles.
(Virtual) Overlay.- Capa intermedia que sirve para gestionar de una manera
abstracta los recursos existentes por debajo de ella.
VLAN.- Virtual LAN.
WAN.- (Wide Area Network) Red de rea extensa.
-2-
1.-Introduccin
Las tecnologas de la informacin, la computacin, la electrnica al servicio de la
informacin irrumpen en nuestras vidas a partir de la segunda mitad del siglo XX.
Como muchos avances de la tcnica, primero en el mbito militar , despus en el
resto de la sociedad.
Desde el principio, fueron tecnologas estticas, asociadas a grandes mainframes,
engorrosos mtodos de programacin, soportes de almacenamiento , y costosos
dispositivos.
El advenimiento del PC a principio de los 80 marca el inicio de una gran revolucin.
Los dispositivos informticos empiezan a popularizarse en las empresas y el
ciudadano comn. En la misma poca comienzan a desarrollarse las redes de
ordenadores con el objetivo de compartir informacin y recursos en las
compaas, al principio, y con la popularizacin de internet, en todo el mundo.
El trabajo de estandarizacin de la multitud de protocolos necesarios para
interconectar equipos de diferentes fabricantes y redes de diferentes organismos
ha sido titnico. Existen aproximadamente 5500 RFCs creadas para controlar,
hacer viable y ofrecer una funcionalidad tolerable a internet.
Sin embargo, toda esta tecnologa, aunque en la mayora de casos funciona, se ha
quedado obsoleta. Algunos aspectos que muestran esta rigidez son:
-software desarrollado para ejecutarse en una mquina determinada.
-costosos sistemas operativos con pago por licencia.
-sistemas de almacenamiento propensos a fallos ante los que la nica estrategia
son los sistemas de backup y la redundancia.
-servidores de red alojados en costosos ordenadores.
-hardware de red de mltiples fabricantes, que implementa diferentes protocolos,
ideados cada vez que surge un problema.
En los ltimos aos hay una tendencia a flexibilizar todos los campos de la
computacin, y hay una serie de hitos que van sealando el camino que sigue la
industria:
-Aparecen iniciativas de software libre y Open Source, como forma de abaratar el
software.
-Se desarrolla Java, como lenguaje de programacin que permite ejecutar
aplicaciones en diferentes sistemas sin necesidad de reescribirlas.
-3-
-4-
2.-Caractersticas de SDN
2.1.-Introduccin.
En este primer captulo se establecern las principales caractersticas de SDN, as
como sus orgenes y antecedentes. Tambin se hablar de OpenFlow, parte
integrante del paradigma SDN que , errneamente, ha fagocitado el trmino
original, cuando en realidad es uno de sus componentes. De esta manera se
sentarn las bases para entender el porqu se est considerando la mayor
revolucin de los ltimos 30 aos en el mundo de las redes de comunicacin.
No es de extraar que, siendo relativamente nuevo, hayan surgido multitud de
startups, o compaas emergentes , que, a su vez, hayan protagonizado
operaciones corporativas (como la compra de Nicira por parte de VMWare), y que
la mayora de consultoras tecnolgicas citen dichas startups como las ms
prometedoras de entre la multitud que se forman cada ao.
2.2.-Antecedentes
La idea de programar redes no es nueva, segn [1] hay varias contribuciones
anteriores a SDN. Una de ellas es SOFTNET [4], all por los primeros 80, una red
multisalto, semejante a las a las actuales WSN (Wireless Sensor Networks) cuya
innovacin fue que en el campo de datos de cada paquete se incluan comandos
que los nodos iban ejecutando a medida que los iban recibiendo. De esta manera, la
red poda irse modificando de forma dinmica y en tiempo real. Fue un intento de
definir una red auto-organizable destinada a permitir la experimentacin y la
innovacin con diferentes protocolos. No hubo desarrollo posterior, pero su idea
fue el embrin de las posteriores Active Networks [5].
Las Active Networks presentaban una arquitectura consistente en llevar embebido
en los paquetes pequeos programas que podan ser ejecutados por los nodos que
stos atraviesan. Esto haca posible que los switches y routers de la red procesaran
los paquetes de datos, hacindoles partcipes de los mensajes y no solo meros
espectadores que se limitaban a enviar mensajes de un puerto a otro, de una forma
pasiva. De ah el nombre de Active Networks.
El rea de Active Networks fue una tendencia en investigacin hace tiempo,
aunque ltimamente ha decado.
Tanto SOFTNET como Active Networks concibieron una red innovadora, dinmica
y partcipe de los datos que transportaban. El mecanismo era bsicamente el
mismo: aadir lneas de cdigo a los paquetes de datos para que los nodos
intermedios las ejecutarn. No incorporaban un elemento software como control
de los elementos de conmutacin, como s hace la filosofa SDN.
En 2007, un grupo de trabajo de la Universidad de Standford formado por los
profesores Nick McKeown, Scott Shenker y el estudiante de doctorado Martn
Casado desarrollaron OpenFlow y fundaron Nicira, una compaa de virtualizacin
de redes. Es a partir de este momento donde se sita el nacimiento de SDN.
-5-
2.3.-Definicin
SDN es un cambio de paradigma en la forma de gestionar una red. Su principal
caracterstica es separar la gestin de la conmutacin. Dicho as, no parece un
cambio demasiado revolucionario, pero sin embargo lo es.
Su objetivo es desacoplar la infraestructura de la red de las aplicaciones y servicios
que sta proporciona. La red ser vista como una entidad lgica separada e
independiente de ellas . De esta manera, el administrador puede definir
completamente el comportamiento de la red, sin estar ceido al cors que le
imponen los fabricantes de elementos de conmutacin, que por otra parte, suelen
ser muy costosos.
La implementacin de SDN permite redes ms flexibles, escalables, eficientes y
ceidas en la medida que se desee a los patrones de trfico del usuario.
Esto se consigue mediante la centralizacin del control de la red. Un elemento
llamado Controlador SDN implementa las reglas de comportamiento de los
elementos de conmutacin en base a las reglas definidas por el administrador de la
red.
-6-
En las redes tradicionales, la gestin es distribuida. Esto quiere decir que cada
elemento de conmutacin incorpora un firmware que toma sus propias decisiones
en funcin de determinados campos de las tramas y paquetes recibidos.
Estas redes han demostrado sus buenas prestaciones en el pasado, y lo siguen
haciendo. Pero presentan varios problemas:
No son flexibles. Se comportan en base a las reglas(protocolos) que incorporen
los fabricantes de dispositivos. Lgicamente, cuanto ms configurables sean stos,
ms costosos sern.
Estn basadas en multitud de reglas predefinidas. Los protocolos actuales
estn basados en ms de 5000 RFCs , y cualquier modificacin que se sugiera ha de
pasar un tedioso proceso de estudio y aprobacin por parte de los organismos
competentes (IETF principalmente).
Coartan la investigacin y el desarrollo. Evidentemente, los fabricantes y
administradores de redes, son reticentes a experimentar y desarrollar nuevos
paradigmas en redes que ya funcionan de una forma satisfactoria. Es el clebre
si funciona no lo toques.
Es muy complicado introducir nuevas propuestas. Este punto enlaza
directamente con el anterior. Cualquier innovacin, aunque ya est aprobada en su
RFC, es muy complicado. Las actuales redes de comunicaciones en su mayora
derivan de las viejas redes telefnicas. Aunque evolucionadas, su filosofa es de los
60 [2]. Sin embargo, las comunicaciones han cambiado radicalmente desde
entonces. Los viejos protocolos se parchean para que sigan funcionando (por
ejemplo NAT), y se mantienen en el tiempo. Un ejemplo claro de esto es la baja
implementacin de Ipv6, a pesar del tiempo que hace que est aprobado. Si Ipv4
con NAT funciona, para qu tocarlo?
2.5.-Arquitectura SDN
En una red SDN hay un hecho clave: la separacin del plano de control del plano de
datos. As pues, podramos verla como un conjunto de medios de transmisin
conectados mediante elementos de conmutacin (capa fsica, como la arquitectura
tradicional), mas una capa de control (capa software) por encima de ella. Esta capa
software est compuesta del Controlador ( o Controller), que es quien llevar la
gestin de la red.
-7-
2.6.-Capas de SDN
Conceptualmente, una red SDN se puede dividir en diferentes capas lgicas, como
muestra la siguiente figura:
-8-
2.7.-OpenFlow
Hay bastante confusin con el trmino OpenFlow. Hay quien se refiere a l como
sinnimo de SDN. Tambin se refieren a l como a un tipo de controlador, o a la
ausencia de ste: a enviar manualmente mensajes a la infraestructura para escribir
los flujos en las tablas de flujos de cada dispositivo.
-9-
2.8.-OpenFlow Switch
Un switch OpenFlow puede tener diferentes tablas de flujos, en las cuales se realiza
la bsqueda de coincidencia con los paquetes entrantes. Cada entrada en una tabla
de flujos consta de tres campos:
-Cabecera, que define el flujo.
-Contadores, que contabilizan la coincidencia de paquetes. Se actualizan por flujo,
por tabla, por puerto y por cola.
-Acciones a realizar cuando se encuentra una coincidencia entre un paquete y una
tabla de flujos.
El procesado de un paquete por parte de un OpenFlow Switch es el siguiente:
- 10 -
2.10.-Protocolo OpenFlow
El protocolo OpenFlow define el protocolo de comunicacin entre el switch
OpenFlow y el controlador. El switch establece la comunicacin con el controlador
en una direccin IP, usando un determinado puerto, habitualmente el 6634. Si el
switch conoce la IP del controlador, iniciara una sesin TCP estndar.
Cuando una conexin es establecida, cada lado enva un mensaje HELLO con la
versin mas alta del protocolo OpenFlow soportado. Tras la recepcin de este
mensaje, el receptor calcula la versin del protocolo a usar como la ms pequea
entre la que se envi y la que se recibi en los mensajes HELLO. Si la versin
negociada es soportada, la conexin ser iniciada, de lo contrario se enviar un
mensaje HELLO-FAILED y se terminar la conexin.
- 11 -
-Mensajes asncronos:
Los switches envan mensajes al controlador a la llegada de un paquete, tras un
error o tras un cambio de estado. Existen cuatro tipos:
Error.
-Mensajes simtricos:
Son enviados sin solicitud en cualquier direccin. Se pueden distinguir tres tipos:
- 12 -
2.11.-Controlador
El controlador es el dispositivo principal en la arquitectura SDN. Es l quien toma
las decisiones, implementa las reglas de la red, ejecuta las instrucciones que le
proporcionan las diferentes aplicaciones y las distribuye a los diferentes
dispositivos de capa fsica de la red. Es quien determina como manejar los
paquetes que no encajan en ninguna de las entradas de las tablas de flujo y quien
gestiona dichas entradas, aadiendo o eliminando a travs del canal seguro a los
dispositivos OpenFlow. Esencialmente centraliza la inteligencia de la red, que es
la principal caracterstica de SDN. Existen diferentes tipos de controlador
atendiendo a diferentes caractersticas:
-Emplazamiento: se pueden distinguir dos tipos de configuraciones. Una
centralizada donde un solo dispositivo gestiona todos los dems equipos y otra
donde hay un controlador para un conjunto de switches.
-Tipo de flujo: se puede distinguir entre enrutamiento por flujo, donde cada
entrada define un flujo determinado, y agregado, donde cada entrada en la tabla
corresponde a una categora de flujos (las entradas se configuran mediante
wildcards o comodines). El primer tipo sera adecuado para redes pequeas, tipo
campus, y el segundo para redes con mltiples flujos ( tipo backbone).
- 13 -
Beacon
Trema
Maestro
SNAC
Principal Caracterstica
OpenFlow
Controller
open-source
que
proporciona una plataforma para escribir
software de control de la red en C++ o Python.
Controller basado en Java que soporta
operacin basado en eventos y multi-hilo.
Completa plataforma OpenFlow para Ruby/C.
Plataforma de control escalable escrita en Java.
OpenFlow Controlador que usa una interfcie
web para gestionar la web.
- 14 -
2.13.-Ventajas de SDN
- 15 -
- 16 -
- 17 -
3.1.-Brocade
Brocade es una compaa estadounidense especializada en gestin de datos y
productos de almacenamiento en red. Posee una divisin especializada en
virtualizacin de redes y equipos de networking basado en software. Fue un
miembro inicial cuando la ONF fue fundada. En 2010 fue uno de los primeros
fabricantes en aprobar openFlow, y como miembro de la ONF participa en su
desarrollo y su estandarizacin. [14]
A travs de la familia Brocade VCS Fabric Technology proporciona equipos de red
compatibles tanto con soluciones propietarias tipo VMware NSX como con
controladores basados en OpenFlow.
- 18 -
tenga los das contados, ya que est formando un equipo especializado en SDN y
NFV. Su ltima contratacin ha sido la del creador de la arquitectura de Cisco
OnePK, Kevin Woods.
3.2.-IBM
IBM es una de los fabricantes lderes de equipamiento de red. Tradicionalmente ha
estado ligada a los estndares abiertos y proyectos Open Source. Como miembro
fundador de ONF y de OpenDaylight, ha incorporado a su propuesta el modelo SDN
open-source, con las particularidades que veremos.
En general, hay dos aproximaciones a SDN [19]:
- Virtual Network Overlays: pensado para clientes que no desean hacer una gran
inversin en nuevos routers y switches. En estas implementaciones, se disea una
red virtual sobre una infraestructura ya existente. El desacoplamiento de la red
virtual y la red fsica se consigue mediante un elemento llamado hypervisor.
Diferentes nodos en el Overlay se conectan mediante enlaces virtuales, que pueden
atravesar varios enlaces fsicos. De esta manera, nuevos servicios, nodos, enlaces,
rutas, pertenecientes a diferentes usuarios pueden ser implementados va
software y ser separados, a pesar de compartir una infraestructura comn.
- Redes OpenFlow: pensadas para clientes que implementan nuevas redes e
infraestructuras. Esto permite seguir el modelo open-source SDN basado en
OpenFlow, independizarse de los diferentes planos de control de los fabricantes y
conseguir todas las ventajas ya mencionadas de SDN.
IBM ha incorporado ambas soluciones a su gama de productos, como se puede ver
en la siguiente figura:
- 19 -
Sobre la solucin IBM SDN basada en Virtual Overlay (IBM SDN VE), en ella se
define una Virtual Overlay que utiliza la infraestructura existente, aislando
completamente el trfico entre las diferentes redes virtuales definidas. El esquema
sera el siguiente:
- 20 -
3.3.-Hewlett-Packard
Hewlett-Packard (HP) es otro de los grandes fabricantes de dispositivos presentes
en el mercado. Pero a diferencia de Cisco, sta no es su actividad bsica. Est
presente en el mercado de ordenadores personales, soluciones empresariales,
consultora, impresin, grandes servidores, etc. Respecto a las redes, en sus
propias palabras, son el nico proveedor de ISPs tier-1 que ha sido capaz de
presentar una solucin integral y basada en lo que hasta ahora ms se parece a un
standard: OpenFlow. [25]
- 21 -
- 22 -
- 23 -
3.4.-Cisco
Cisco es uno de los fabricantes de elementos de infraestructura de red ms
importantes . De hecho, ostenta la posicin dominante en el mercado de
dispositivos. De acuerdo a informes de la consultora Synergy Group, cerca de un
70% de los equipos que se venden a empresas, son suyos [32]. En palabras de
ejecutivos de la compaa, el advenimiento de SDN podra disminuir la cifra de
negocio de 43000 a 22000 millones de dlares[32].No es de extraar que se haya
llamado a SDN el anti-cisco, ya que en teora , sera el principal damnificado de
una revolucin como propone SDN.
Por tanto, Cisco ha diseado una estrategia tanto hardware como software para
enfrentarse a este "problema".Veamos primero la solucin software.
3.4.1.-Open Network Environment (ONE)
Cisco One es la solucin que propone Cisco para implementar la programabilidad
de la red, uno de los objetivos de SDN. Intenta incorporar sus soluciones a
diferentes arquitecturas de la red. Estas arquitecturas son las siguientes:
En ellos podemos ver desde el modelo puro SDN (2A), hasta modelos hbridos
(2B) y modelos semejantes a los tradicionales (1). Con su producto, Cisco intenta
mejorar la programabilidad de la red, creando una solucin vlida para cualquiera
que sea el modelo de red que se escoja implementar.
La solucin propuesta es el Open Network Environment. En sus propias palabras,
es una aproximacin holstica para aproximar la red a las aplicaciones. [28]
Se ofrece la ONE Platform Kit (onePK). Se trata de un kit de desarrollo especfico
para tecnologa (de Cisco) que incorpora una arquitectura propia de Cisco, como se
muestra en la siguiente figura:
- 24 -
- 25 -
- 26 -
3.5.-Vmware
Vmware es una filial de la empresa EMC. Su principal producto es un software de
virtualizacin de ordenadores compatibles x86.
Un sistema de virtualizacin por software es un programa que toma un sistema
fsico existente, con unos determinados recursos (memoria RAM, almacenamiento,
microprocesadores, etc.) como un pool y lo divide entre una serie de mquinas
virtuales (VM). En otras palabras, permite implementar mltiples mquinas
virtuales que trabajan dividindose entre ellas los recursos disponibles en el
sistema fsico anfitrin. Evidentemente, la velocidad de ejecucin de una VM ser
menor que si tuviera asignados recursos fsicos en exclusiva, pero ser suficiente
para mantener la funcionalidad del servicio que presta.
- 27 -
MQUINA VIRTUAL
SOFTWARE DEFINED
DATA CENTER
Cloud
Fig. 18.- Virtual Machine-Software defined Data Center-Cloud Computing-Network Function Virtualization-Software
Defined Networking.
Siendo VMware el lder en virtualizacin es lgico que est interesado en SDN. Por
esto, en julio de 2012 compr la empresa fundada por los creadores de OpenFlow,
NICIRA, por la cifra de 1260 millones de dlares. [8]
3.5.1.-NSX
Justo un ao despus de la adquisicin de Nicira, Vmware presenta su plataforma
para la virtualizacin de redes, llamada NSX.
En palabras de Brad Hedlund, ingeniero arquitecto de VMware, el propsito de
NSX es ser capaz de desplegar una red virtual para una aplicacin con la misma
velocidad y eficiencia que se implementa una mquina virtual. [35]
- 28 -
- 29 -
- 30 -
peticiones a los CPDs, que las atienden. Esta red tiene unos requerimientos muy
especiales: debe poder interpretar mltiples protocolos, al interactuar con miles
de usuarios; debe poseer una topologa especialmente densa, para poder soportar
miles de conexiones simultneamente; finalmente, debe estar dotada de una muy
alta disponibilidad.
-Una WAN interna (B4) que interconecta los CPDs de la empresa. Esta red soporta
diferentes tipos de trfico: volcados de datos asncronos, bsquedas por ndices
para los servicios interactivos y finalmente copias de seguridad de los datos de
usuario para conservacin/alta disponibilidad. Se calcula que aproximadamente el
90% del trfico interno de Google circula por esta red.
Esta red interna tiene la siguiente estructura: una docena de CPDs diseminados por
el mundo e interconectados entre s de forma redundante.
Esta red posee unas caractersticas especialmente indicadas para el despliegue del
paradigma SDN. Por ejemplo, todas las aplicaciones, servidores y redes locales
estn controladas por Google totalmente, hasta el borde de la red. Las aplicaciones
realizan copias de ingentes volmenes de datos de un CPD a otro, y se pueden
beneficiar ms de un alto nivel de ancho de banda medio. Adems, su tasa de
transmisin puede ser modulada en base a la capacidad disponible. Y finalmente,
los sitios que han de interconectarse son limitados, por lo que se pueden gestionar
fcilmente tablas de flujos no muy grandes.
Las motivaciones de Google para implementar SDN fueron que el rpido
crecimiento del ancho de banda de Internet, a pesar del crecimiento que se
imprimi a la red B4 (incluso ms rpido), llevaron a la empresa a pensar que no
podran mantenerse sus niveles de escalabilidad, tolerancia a fallos, control y
costes con tecnologas de WAN tradicionales. Por ejemplo, en cuanto a costes, las
aproximaciones tradicionales llevan a aprovisionar un ancho de banda al 30-40% (
2 o 3 veces ms costosa que un enlace utilizado al 100%) para prevenir fallos y
prdida de paquetes, lo que unido a las tasas de crecimiento de trfico previstas
hacan las proyecciones de costes insostenibles.
Sin entrar en detalles de la implementacin , ya proporcionados en [36], se puede
decir que Google implement nuevos protocolos usando principios de SDN y el
- 31 -
- 32 -
4.-Mininet
A fin de experimentar con las caractersticas de SDN, desarrollar aplicaciones y
fomentar su uso, un grupo de profesores de Stanford crearon el entorno Mininet.
Mininet es un emulador de red. Ejecuta un conjunto de hosts, switches, routers,
links y controladores sobre un simple kernel Linux. Utiliza tcnicas de
virtualizacin para simular una red completa sobre una mquina virtual. Se puede
acceder a cada host individualmente, se le puede hacer una conexin ssh, y cada
host podr ejecutar individualmente las aplicaciones instaladas en el sistema
Linux. Se podrn enviar paquetes entre los diferentes hosts a travs de lo que
parecern enlaces Ethernet, y dotar a estos enlaces de diferentes caractersticas,
como baud-rate, delay, etc.
Por tanto, es posible simular topologas tan complejas como se quiera, a travs de
componentes virtuales ejecutados en un nico kernel Linux.
Mininet posee una serie de caractersticas que le hacen un entorno adecuado para
el desarrollo, tests, docencia, etc en el mbito de SDN:
-Es rpido. Implementar una red y probar su conectividad lleva apenas unos
segundos.
-Se pueden ejecutar aplicaciones en cada host, individualmente. Desde un servidor
web a herramientas de monitorizacin, como wireshark.
-Se pueden crear topologas a medida. Es posible simular redes con mltiples
switches, hosts, etc, fcilmente implementables mediante scripts Python.
-Se pueden modelar las caractersticas de los enlaces: delay, baud-rate. Incluso se
pueden modelar fallos de red conectando/desconectando enlaces.
-Es un proyecto Open Source. Viene incorporado en la distribucin Ubuntu 12.10 y
hay mquinas virtuales mininet creadas.
-Como Open Source es un proyecto en constante evolucin: se puede examinar su
cdigo, modificarlo, corregir errores, comentarios, etc.
Sin embargo, mininet tiene algunos inconvenientes, entre los cuales cabe destacar:
- Comparticin de recursos. Como toda virtualizacin, se comparten los recursos
del sistema "padre", por lo que el tamao y la operatividad de la red simulada
vendr condicionada por dichos recursos.
-No se hace NAT al exterior, por lo que un host virtual no se podr conectar con
Internet. Aunque se pueden programar componentes para lograr dicha
conectividad.
- 33 -
-Todos los hosts comparten el mismo sistema de archivos y los mismos PIDs, por lo
que hay que tener precauciones al instalar daemons que requieran configuracin
en /etc y no eliminar procesos por error.
4.1.-Elementos necesarios.
Para trabajar con mininet, se necesitan una serie de elementos:
-Software de virtualizacin. Se utilizar VirtualBox, de Oracle.
-Un cliente telnet/SSH. Se utilizar Putty.
-Un X server para Windows. Se utilizar Xming.
-Una mquina virtual mininet, formato vdi para ser ejecutada en VirtualBox.
Todas estas herramientas son gratuitas y fcilmente obtenibles en internet, por lo
que en poco tiempo podemos disponer del entorno de trabajo mininet.
Sobre la configuracin de la mquina virtual, hay que hacer dos puntualizaciones:
-Configurarla con suficiente memoria RAM. En los tutoriales se mencionan 512 Mb,
aunque este trabajo se ha realizado utilizando 2 Gb. A ms memoria para
compartir, mas complejas podrn ser las topologas a estudiar.
-Configurar la VM con dos interfaces de red. Uno de ellos tipo NAT, a fin de poder
acceder a internet. El otro tipo host-only-interface, a fin de comunicarse con la
mquina host. Cuando se establezcan sesiones ssh, es con la IP de esta ltima
interfaz con la que se establecer comunicacin.
Se diferenciarn los diferentes entornos de trabajo mediante el prompt que
presenten:
-$ es el prompt indicado en la VM de mininet.
-mininet> es el prompt que presenta la CLI de mininet.
Se puede optar por trabajar directamente en la shell de la VM o abrir sesiones ssh a
la IP de la interfaz host-only-interface (opcin ms conveniente).
Primeramente, hay que verificar que las interfaces de la VM estn correctamente
configuradas. Ejecutar
$ ifconfig -a
- 34 -
En este caso las interfaces estn correctamente configuradas: tanto eth0 como eth1
disponen de direccin IP. Caso que alguna de ellas careciera de IP ejecutar el
comando:
$ sudo dhclient ethX
donde ethX corresponde a la interfaz cada.
Mediante la direccin MAC de la interfaz y la configuracin de VirtualBox se puede
identificar qu interfaz corresponde con la interfaz tipo NAT y cul con la hostonly-interface. Habitualmente la IP 10.0.0.X corresponde con NAT.
- 35 -
Para abrir la sesin SSH hay que ejecutar la utilidad Putty , dirigirse a la interfaz
host-only y habilitar la emulacin X11 por si hay que ejecutar el sistema de
ventanas.
- 36 -
4.2.-Mininet CLI
Una vez funcionando la mquina virtual, desde su shell o desde una sesin SSH,
para entrar en el entorno mininet el comando a ejecutar es:
$ sudo mn
El prompt cambiar a "mininet>" y ya se est dentro del entorno. Sin embargo el
comando mn admite una gran variedad de parmetros. Lo habitual es ingresar en
mininet utilizando alguno de estos parmetros. Por partes:
Ingresar a mininet:
$ sudo mn [parmetros]
Salir de mininet:
mininet> exit
Tras salir de mininet es conveniente realizar un borrado del entorno, de modo que
est listo para volver a ser utilizado, sin residuos de anteriores usos. Ejecutar:
$ sudo mn -c
Para mostrar una pequea ayuda de los diferentes comandos y opciones que
soporta mn:
$ sudo mn -h
Lo habitual es implementar la topologa a la vez que se invoca al entorno mininet.
Si no se especifica nada, se implementar la topologa "minimal". Esto es
$ sudo mn
- 37 -
- 38 -
Por ejemplo:
$ sudo mn --topo tree,depth=3
- 39 -
- 40 -
4.3.-Tests
El CLI de mininet admite una serie de tests bsicos, a fin de probar la conectividad
entre los hosts virtuales:
mininet> h1 ping -c2 h2
Este comando enva dos ICMP-request del host 1 al host 2.
Se puede realizar una prueba de conectividad completa mediante el comando
pingall:
Este comando enviar mensajes ICMP (ping) entre todas las parejas de hosts de la
red.
Pero ping no es el nico comando que se puede ejecutar en un host. Cualquier
aplicacin presente en el linux que corre en la mquina virtual puede ser
ejecutado. Se puede, por ejemplo, instalar un servidor web en un host y hacer
peticiones al puerto 80 desde otro:
mininet> h1 python -m SimpleHTTPServer 80 &
mininet> h2 wget -O - h1
al acabar la simulacin se elimina el proceso de h1:
mininet> h1 kill %python
Mininet tambin incorpora la herramienta Iperf. Es una herramienta que establece
sesiones TCP (o UDP) para calcular el ancho de banda entre dos hosts. Su sintaxis
es:
mininet> iperf src dst
si se obvian src y dst se medir entre el primer y ltimo host.
Una forma de acceder a un terminal para cada componente de la red es abrir un
emulador de terminal Xterm desde mininet. Para ello tiene que estar corriendo un
gestor de ventanas X11 (Xming para Windows).
- 41 -
4.4.-Wireshark
Una de las aplicaciones ms tiles para analizar redes es Wireshark. La forma de
ejecutarlo en mininet es la siguiente:
-El interprete de ventanas X11 (Xming) ha de estar funcionando.
-Desde una sesin ssh ejecutar:
$ sudo wireshark &
-Ignorar el error que comunica Xming (validarlos pulsando OK)
-Seleccionar la interfaz lo (127.0.0.1) para poder examinar todos los mensajes de
los integrantes de la red virtual.
-En el campo "Filter" de Wireshark aplicar un filtro de tipo "of". De esta manera se
mostrarn los mensajes entre cualquier componente de la red y el controlador.
Por ejemplo, vamos a inspeccionar un mensaje ICMP en una topologa simple con
Wireshark a fin de ver diferentes tipos de mensajes OpenFlow.
-Arrancamos VirtualBox y la mquina virtual mininet
-Caso de no tenerlas configuradas, configuramos las interfaces de la mquina
virtual.
-Arrancamos el gestor de ventanas X11 Xming
-Establecemos dos sesiones ssh con la ip de la interfaz VirtualBox host-only.
- 42 -
-Desde una de las sesiones ssh entramos en el modo mininet con la siguiente
topologa:
$ sudo mn --link tc,bw=100,delay=10ms --mac
Hay que hacer algunas puntualizaciones:
Esta es la topologa por defecto (1 switch con dos hosts). Establecemos los links de
100 Mbps con un delay de 10 ms. Esto para que wireshark capture todos los
mensajes, sin ningn problema de tiempos.
-Desde la otra sesin ssh arrancamos wireshark.
-Establecemos un filtro para los paquetes OpenFlow y comenzamos a capturar en
la interfaz lo (127.0.0.1)
-Enviamos un ping de h1 a h2 : mininet> h1 ping -c1 h2
- 43 -
4.5.-Controladores
Si no se especifica, mininet utiliza el controlador que incorpora por defecto. La
distribucin OpenFlow de referencia incorpora un controlador que acta como un
switch clsico. En lenguaje OpenFlow, se le denomina Ethernet Learning Switch. Su
funcionamiento es el de un switch tradicional : segn vaya recibiendo tramas ir
creando una tabla donde se asociarn direcciones MAC con puertos. ste
controlador bsicamente al asociar una MAC con un puerto, enviar un mensaje
OpenFlow al switch, instaurando una nueva entrada en la tabla de flujo. Ms
adelante se muestra un ejemplo de funcionamiento.
No admite componentes creados por el usuario, por lo que su uso es til
bsicamente para entender el flujo de mensajes y la separacin del plano de
decisin y el plano de conmutacin.
Este controlador acta en combinacin con un switch virtual OpenFlow. Este tipo
de switch bsicamente es el plano de conmutacin, una tabla de flujos y un
intrprete de mensajes OpenFlow.
- 44 -
- 45 -
mininet> nodes
-Vamos a probar la utilidad dpctl. Es una utilidad incorporada en OpenFlow que
permite inspeccionar y controlar la tabla de flujos de un switch.
Abrimos otra sesin SSH con putty a la direccin 192.168.56.101 desde la nueva
consola:
Para mostrar todas las opciones de dpctl:
$ dpctl --help
Veamos todas las caractersticas del switch OpenFlow que hemos creado. Para
comunicarnos con el switch OpenFlow hemos de enviar mensajes al puerto 6634.
$ dpctl --show tcp:127.0.0.1:6634
Veamos la salida de este comando:
Aqu vemos las interfaces del switch, junto con sus direcciones MAC y sus
caractersticas fsicas.
Como se ha dicho, hemos implementado una topologa sin ningn tipo de
controlador, por lo que la tabla de flujos debera estar vaca. Lo comprobamos con
el siguiente comando:
$dpctl dump-flows tcp:127.0.0.1:6634
- 46 -
Como se ve, no hay ningn flujo instalado en la tabla de flujos del switch. La
conectividad en esta red es nula. Comprobmoslo:
En la consola mininet ejecutamos un ping entre el host 1 y el 2 por ejemplo,
enviando 3 paquetes de datos.
mininet> h1 ping -c3 h2
La salida es la siguiente:
- 47 -
Aqu podemos ver dos flujos instalados. Se observan varios parmetros, pero se
pueden distinguir los puertos a los que se refiere (in_port) y la accin a ejecutar
(output:1). Otro parmetro importante es el idle_timeout. Este parmetro indica el
tiempo de vida de ese flujo. Si antes de que expire ese tiempo ejecutamos una
prueba de conectividad entre h1 y h2, como anteriormente:
mininet> h1 ping -c3 h2
- 48 -
Si ejecutamos otro ping entre otros hosts, por ejemplo entre h2 y h3:
Como se ve, no hay comunicacin entre h2 y h3, mientras s hay entre h1 y h2.
En esencia, vemos que tenemos un switch controlado por software. En un switch
real, con los tres hosts correctamente configurados no sera posible eliminar la
conectividad entre dos de ellos sin eliminar el cable o sin intervenir en el firmware
del switch.
- 49 -
4.6.-Controlador POX
POX es un controlador derivado de NOX, que fue desarrollado por NICIRA y
destinado a la comunidad cientfica. Proporciona un marco de desarrollo para la
investigacin sobre protocolos de comunicacin y componentes en redes SDN.
POX es una plataforma de cdigo abierto especialmente pensada para la
investigacin y el desarrollo de controladores OpenFlow. Est desarrollado y
permite la programacin de componentes en Phyton. Los componentes
desarrollados son los que dotan de funcionalidad al controlador. Es donde
verdaderamente se pueden incorporar caractersticas que proporcionen "valor
aadido" a una red. Forman la esencia de SDN.
Viene incorporado en las ltimas versiones de la mquina virtual mininet. De todas
maneras se puede instalar ejecutando:
$ git clone http://github.com/noxrepo/pox
La forma de llamar al controlador POX es, desde una sesin SSH ejecutar
$ cd pox
$ ./pox.py nombre_componente
donde nombre_componente es el nombre de un archivo python (.py) que contiene
la implementacin de un componente. Se pueden invocar mltiples componentes,
siempre que sean compatibles.
Hay componentes desarrollados que proporcionan un punto de partida para
futuros desarrollos. Desde la implementacin de un hub , componentes que
descubren la topologa de la red, componentes para eliminar bucles (diferente de
Spanning Tree), hasta servidores dhcp.
Y no olvidemos que no hay lmite, el objetivo es poder crear componentes que
hagan que la red se comporte como se desee, sin estar sujeto a los estrictos RFC ni
al firmware propietario de los fabricantes de equipos.
- 50 -
- 51 -
simulacin, sea posible controlar las direcciones MAC asignadas a cada host
virtual. En un caso real, las direcciones MAC son fijas por dispositivo.
En el archivo mac.txt se han aadido 11 direcciones MAC correlativas, de la
00:00:00:00:00:01 a la 00:00:00:00:00:0B, por lo que slo dispositivos con esta
MAC estn habilitados para el uso de la red.
En otra sesin ssh ejecutaremos el controlador con el componente seg_port:
$ ./pox.py seg_port
Se puede observar la conexin de los switches al controlador:
- 52 -
En el caso de conectividad con un host cuya MAC no est habilitada (h14, por
ejemplo):
- 53 -
- 54 -
4.8.-Funcionalidad
Como se ha visto, la funcin del controlador es procesar los paquetes que no
encuentran correspondencia en ninguna entrada de la tabla de flujos del switch. En
base a este procesamiento, se establecer (o no) una nueva entrada en una tabla.
Adems, esta funcin se ejerce idealmente para toda la red, proporcionando un
control centralizado de la red.
El procesado de un paquete y el establecimiento de un flujo requiere un tiempo.
Cuntos flujos por segundo es capaz de gestionar un controlador? Cual es el
tiempo que se tarda en establecer un flujo? Ser capaz un slo controlador de
gestionar de forma eficaz una red, o por el contrario significar un cuello de
botella? Cul debe ser el tamao mximo de una red para que pueda cumplir el
paradigma de la centralizacin de SDN?
Las mtricas tiles para evaluar el rendimiento de un controlador son el tiempo de
establecimiento de un flujo y el nmero de flujos por segundo que un controlador
puede establecer. En base a esta ltima mtrica, si los switches de una red inician
ms flujos de los que un controlador determinado puede gestionar, se debern
aadir ms controladores.
La manera en que se establecen los flujos puede influenciar de forma determinante
la funcionalidad de un controlador. Existen dos formas: proactivamente o
reactivamente.
Proactivamente significa que el controlador pre-rellena las tablas de flujos de cada
uno de los switches hasta el mximo grado posible. De esta manera, cuando un
paquete llega a un switch, ya existe en su tabla una entrada adecuada para dicho
paquete. Aqu no cabe hablar de tiempo de establecimiento de flujo ni de lmite
mximo de flujos.
La manera reactiva se da cuando un switch recibe un paquete que no encuentra
correspondencia en la tabla de flujos. El paquete es derivado al controlador,
procesado y si el controlador lo decide, un nuevo flujo ser instalado en la tabla del
switch.
El tiempo de establecimiento de un flujo ser: el tiempo que se tarda en reenviar el
paquete del switch al controlador, mas el tiempo de proceso en el controlador, ms
el tiempo que lleva enviar el mensaje openFlow de modificacin de la tabla de
flujos, ms el tiempo que se tarde en instalar el nuevo flujo en la tabla.
Factores que pueden afectar al tiempo de establecimiento de un flujo son, por
ejemplo, la potencia de los procesadores de los switches (tiempo de instalacin de
un nuevo flujo, tiempo de comparacin de la tabla con el paquete, I/O del paquete
hacia el controlador), la potencia del procesador del controlador (procesado del
paquete, I/O del paquete, I/O del mensaje openFlow). Como ejemplo, si el software
del controlador est escrito en C, ser ms rpido que si est escrito en Java.
- 55 -
Flows/s
674,75
1101,75
1540,75
2441,88
3763,22
3925,13
4524,68
4630,89
4544,92
4585,12
4631,33
- 56 -
Flows/s
1
10005,11
2
9383,65
3
9370,86
5
9207,34
10
9413,37
20
8518,15
50
6139,64
100
4867
200
793,24
500 1000 -
Grficamente :
- 57 -
Con esta simulacin se puede ver como a medida que se va aumentando el nmero
de switches el nmero de flujos por segundo decae. Lgicamente, ya que se
producen ms peticiones de flujos por segundo y los buffers del controlador se
saturan antes. A partir de 100 switches el throughput decae significativamente.
Sera conveniente aadir otro controlador.
Vemos que con la herramienta cbench es posible, en cierto modo, evaluar el
rendimiento de un controlador determinado. Nos puede servir de gua para saber
el tamao de una red que vamos a poder gestionar de forma centralizada o si
hemos de aadir ms controladores. De todas maneras, es conveniente disponer de
ms de un controlador, por razones de disponibilidad y para evitar puntos de nico
fallo.
La funcionalidad y la posibilidad de crear un cuello de botella para el desempeo
adecuado de una red es un rea sobre el que hay que profundizar an ms. Se
percibe como uno de los inconvenientes principales para la implantacin de SDN,
depende de mltiples variables (mquina sobre la que se instale, topologa de la
red, nmero de switches y hosts, etc).
- 58 -
5.-Conclusiones
Hemos visto como Software Defined Networking es un nuevo paradigma en las
redes de comunicaciones. De hecho, este cambio se produjo tambin en los
sistemas operativos, lenguajes de programacin, centros de procesado de datos,
etc.
Las motivaciones son tanto operativas (flexibilizacin de las redes, necesidad de
influir en su comportamiento de manera ms determinante), como econmicas
(abaratamiento de la infraestructura, optimizacin de costes, bsqueda de nuevos
modelos de negocio). Incluso, en determinadas circunstancias, se puede hablar de
ahorro de energa, al poder influir en el gasto energtico de los equipos al
determinar su uso.
SDN consiste en separar el control de la red (centralizndolo) de la conmutacin
de los paquetes de datos. De esta manera los equipos tales como switches, routers,
etc... simplemente conmutan los datos en funcin de las instrucciones que reciben
del plano de control de la red. Este plano de control, a su vez, recibe instrucciones
de las aplicaciones del usuario. De esta forma las aplicaciones definen el
comportamiento de la infraestructura.
Este modelo es visto por la industria de diferentes maneras, en funcin de los
riesgos y oportunidades que perciben sobre la posicin que ocupan en este
mercado en la actualidad. No es igual cmo se percibe SDN por el fabricante lder
(Cisco), como por otro menos relevante, como por una compaa enfocada al
software pero que aspira a tomar protagonismo en la industria de las redes.
Los diferentes actores implementan SDN de diferentes maneras, en la mayora de
casos primando el uso de sus equipos (precisamente lo que se quiere evitar con la
arquitectura estndar propuesta por la ONF), proponiendo modelos de red
propios y adaptados a sus intereses, en algunos casos implementando el modelo
estndar (basado en openFlow). Incluso se proponen nuevos modelos de negocio
como las tiendas de aplicaciones, al estilo de lo que podra ser la App Store de
Apple o la Google Play.
No cabe duda que, sobre el papel, el cambio a una red que no est sujeta a la
"tirana" de las RFCs y del firmware propietario de los fabricantes de equipos es
beneficioso en trminos de optimizacin de la red. Como ejemplo se ha descrito la
implementacin de SDN que ha hecho Google en su red que comunica los CPDs de
la compaa y el beneficio econmico que obtiene al provisionar ancho de banda.
Sin embargo, hay temas pendientes sobre los que se han de profundizar los
estudios. Uno de ellos es la funcionalidad del controlador, el nmero de hosts y/o
switches que puede controlar un equipo de forma que se eviten cuellos de botella y
bajo rendimiento de la red. Otro tema controvertido es la seguridad. Al centralizar
el control de la red, se crea un punto de nico fallo, por tanto se expone la
funcionalidad completa de la red a ataques a un nico equipo.
- 59 -
- 60 -
Anexo
Este es el listado del componente seg_port, realizado para este TFM. Esta realizado
en python, y programado para ser usado con el controlador POX.
from pox.core import core
import pox
from pox.lib.util import dpid_to_str
from pox.lib.packet.ethernet import ethernet, ETHER_BROADCAST
from pox.lib.packet.ipv4 import ipv4
from pox.lib.packet.arp import arp
from pox.lib.addresses import IPAddr, EthAddr
from pox.lib.util import str_to_bool, dpidToStr
from pox.lib.recoco import Timer
import pox.openFlow.libopenFlow_01 as of
import pox.openFlow.of_01
from pox.lib.revent import *
import time
log = core.getLogger()
ARP_TIMEOUT = 60 * 2
FLOW_IDLE_TIMEOUT = 100
- 61 -
- 62 -
- 63 -
- 64 -
6.-Bibliografa
Caractersticas de SDN:
[1] A revolution (Revelation?) in Networking- Presentation by Dan Pitt, Executive
Director. Open Networking Foundation.
[2] Ofelia Project. Collaborative project within the European Commissions FP7 ICT
Work Programme.
[3] Ofelia Project. Collaborative project within the European Commissions FP7 ICT
Work Programme.
[4] SOFTNET- Packet Radio in Sweden.-Jens Zander- 1st Amateur Radio Computer
Networking Conference, Gaithersburg, MD, October 16-17 1981.
[5] Towards an Active Network Architecture -David L. Tennenhouse, David J.
Wetherall- Telemedia, Networks and Systems Group, MIT.
[6] Five SDN Benefits Enterprises Should Consider- Serdar Yegulap- Network
Computing- Next Generation Data Center.
[7] Software-Defined Networking : The New Norm For Networks.- ONF White
Paper, April 2012.
[8] From Clean Slate to SDN Haisang Wu- Huawei Corp.
[9] Entrevista Martn Casado Norberto Gallego- Suplement Diners La
Vanguardia 19-01-2014
[10] Evaluation of OpenFlow Controllers - Guillermo Romero de Tejada Muntaner Msc Thesis
[11] Emulacin de una red definida por software utilizando mininet - Whasington
A. Velasquez Vargas - ETSIT-UPM
[12] The Networking Revolution - NEC Corporation - 2013
Estado del Arte de SDN:
Brocade:
[13] Exploring Software Defined Networking with Brocade- White Paper
[14]Brocade SDN - Frequently Asked Questions
[15] The Top Five Virtualization Mistakes - Brocade Corp.
[16] The Road to SDN: Software-Based Networking and Security from BrocadeBrocade Corp.
[17] Brocade VCS Fabrics: The Foundation for Software-Defined NetworksBrocade Corp.
[18] Network Transformation with Software-Defined Networking and Ethernet
Fabric - Brocade Corp.
- 65 -
IBM:
[19] IBM Software Defined Networking: Two Approaches to Network
Virtualization and Centralized Network Management - Research Report - Clabby
Analytics.
[20] IBM Software Defined Network for Virtual Environments - IBM Systems and
Technology Data Sheet
Hewlett-Packard:
[22] Get Started Developing SDN Apps Now - HP corp.
[23] HP Virtual Application Network SDN Controller - HP corp.
[24]Solutions for HP Virtual Application Networks - HP Corp.
[25]Realizing the power of SDN with HP Virtual Applications Network- HP Corp.
[26] Next Generation Enterprise LANs: Unified Networking and SDN - Fairpoint
Group White Paper.
Cisco:
[27]The promise of SDN - Network World - May 2013
[28]Cisco Open Network Environment: Bring the Network Closer to Applications White Paper - Cisco Corp.
[29] Application Centric Infrastructure Overview: Implement a Robust Transport
Network for Dynamic Workloads - White Paper - Cisco Corp.
[30] Software Defined Networking: The Cisco approach - Scott Mateson www.TechRepublic.com
[31] Insieme at last! SDN fabric with Cisco ACI and Nexus 9000 switches - Rivka Gewirtz
Little - searchsdn.techtarget.com
[32] Cisco Launches Its Secret Startup Insieme, Then Buys It For $863 Million Julie Bort - www.businessinsider.com
VMware:
[33] VMware NSX : The Platform for Network Virtualization - Data Sheet- VMware
Corp.
[34] VMware NSX Network Virtualization Design GuideT
[35] SDN showdown: Examining the differences between VMware's NSX and
Cisco's ACI - Ethan Banks - www.networkworldnews.com
Red de CPDs de Google:
[36] Use Cases and Migration Methods- Migration Working Group - ONF Open
Networking Foundation
- 66 -
Mininet:
[37]Mininet Walkthrough - http://mininet.org/walkthrough
[38]Openflow Tutorial-OpenFlow Wiki[39] OpenFlow Tutorial with POX - Part 1 | Python for Network Engineers [40] Emulacin de una red definida por software utilizando MiniNet- Washington
A. Velasquez Vargas - ETSIT-UPM
[41] Fast, Accurate Simulation for SDN Prototyping - Mukta Gupta, Joel Sommers,
Paul Barford.
[42] Evaluation of OpenFlow Controllers-Guillermo Romero de Tejada Muntaner
[43] OpenFlow Switch Specification v1.1.0 Implemented
[44] OpenFlow: Enabling Innovation in Campus Networks-Nick McKeown,Tom
Anderson,Hari Balahkrishnan,Guru Parulkar,Larry Peterson,Jennifer Rexford,Scott
Shenker,Jonathan Turner.
Otros:
[45] ETSI - Network Functions Virtualisation Introductory White Paper -October
22-24, 2012 at the SDN and OpenFlow World Congress, Darmstadt-Germany
[46] A Survey of Software-Defined Networking: Past, Present, and Future of
Programmable Networks - Marc Mendonca, Bruno Astuto A. Nunes, Xuan-Nam
Nguyen, Katia Obraczka, and Thierry Turletti
[47] Software-Defined Networking: The New Norm for Networks - ONF White
Paper April 13, 2012
[48] OpenFlow Inventor Martin Casado on SDN, VMware, and Software Defined
Networking Hype - Enterprise Networking Planet
[49]SDN: Software Defined Networks- Thomas D.Nadeau , Ken Gray OReilly
ISBN: 978-1-449-34230
[50]Introduction to SDN OpenFlow & VxLAN Vishal Shukla ISBN: 978-1-48267813-0
NetworkVirtuali
- 67 -