SDN PDF

UNIVERSITAT POLITCNICA DE CATALUNYA
Master en Ingeniera Telemtica
Software Defined Networking
Autor:scar Roncero Hervs

Director: Jaume Comellas
-Software Defined Networking-
2
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 -
3
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-
-Se implanta el llamado Cloud Computing, de forma que aplicaciones y datos

residan de forma remota y no haya que preocuparse de su disponibilidad y
almacenamiento.
-Aparece la virtualizacin: una forma de implementar diferentes servidores en un

mismo hardware, de forma que se aprovechen mejor los recursos fsicos
disponibles.
ste ltimo punto produce que si antes un puerto de un switch soportaba

conectado un servidor, ahora soporta muchos ms, decenas de ellos. De la misma
manera, un servidor virtualizado en un hardware determinado puede ser
trasladado a otra mquina en cuestin de segundos. ste rpido cambio de
ubicacin de una mquina virtual debe verse correspondido con un rpido cambio
de configuracin de la red para soportarlo.
Por otra parte, se busca ligar las caractersticas de la red a los servicios
(aplicaciones) que se ofrecen, de forma que sta pueda responder de una u otra
forma dependiendo de la aplicacin que lo demande.
Todas estas caractersticas se busca que sean definibles por software,

centralizando el control y eliminando la necesidad de configurar cada equipo de
red por separado, minimizando los errores y el tiempo necesario para ello.
ste es el propsito del paradigma introducido por Software Defined Networking.

En este Trabajo Fin de Master se intentar explicar cules son los principios y
objetivos de Software Defined Networking, as como su implementacin y un
estado del arte. Adems se harn una serie de demostraciones con un entorno de
simulacin de SDN (a modo de tutorial) en diferentes casos, para ilustrar las
ventajas y funcionamiento de esta tecnologa.
-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-
En 2011, Scott Shenker y Nick McKeown fundaron la Open Networking Foundation

(ONF), organizacin que buscaba fomentar el uso de OpenFlow, la creacin de
estndares y la implantacin de SDN ms all de las universidades.
En julio de 2012 VmWare, una de las compaas lderes en virtualizacin de
servidores, dio un paso hacia la incorporacin de la virtualizacin de redes en su
gama de productos y compr Nicira por 1260 millones de dlares. Martn Casado
pas a ser el "arquitect networking" en jefe de VMware. [8]
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.
2.4.-Arquitectura de red tradicional
Bsicamente, una red tradicional consiste en un conjunto de medios de

transmisin ( fibra ptica, par de cobre, aire, etc) mas un conjunto de elementos
de conmutacin (switches, router, etc).
Fig 1.- Arquitectura de red tradicional.
-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-
Fig. 2.-Arquitectura SDN.
2.6.-Capas de SDN
Conceptualmente, una red SDN se puede dividir en diferentes capas lgicas, como
muestra la siguiente figura:
Fig. 3.- Arquitectura de capas de SDN.
Ms detalladamente, el modelo de arquitectura SDN es el siguiente:
-8-
Fig. 4.- Arquitectura SDN [7]
La capa inferior la componen la infraestructura de red, hosts, switches/routers y

medios de transmisin. La capa intermedia la forma el Controlador SDN, quien
tiene una visin global de la red e incorpora el sistema operativo de red (NOS),
que toma las decisiones y programa las tablas de flujo de los elementos de la capa
inferior.
Estas dos capas se comunican por medio de las llamadas SouthBound APIs .
Bsicamente, la funcin de estas APIs es permitir al Controlador comunicarse con
los elementos de conmutacin de la red y programar la lgica de las
comunicaciones en el hardware. Hay varias implementaciones de estas APIs, entre
ellas OpenFlow (al que nos referiremos posteriormente) y VxLAN (ms utilizadas
en virtualizacin de redes, para definir capas intermedias o overlays).
La capa superior es la capa de aplicacin. Esta capa la componen las aplicaciones
de usuarios, que incorporan las llamadas NorthBound APIs. Y es aqu donde
cambia totalmente la filosofa respecto a las redes tradicionales. Estas Northbound
APIs incorporan los patrones de uso de la red de cada aplicacin, y su funcin es
comunicar esos patrones a la capa de control, donde se toman las decisiones
oportunas. Y aqu se cierra el crculo: las aplicaciones definen el uso que se va a
dar a la red, lo comunican al controlador SDN, el cul toma las decisiones
oportunas y las comunica a la infraestructura de red (capa inferior) mediante las
SouthBound APIs.
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-
Al conjunto de tablas de flujos y a un canal hacia un controlador se le llama switch

OpenFlow. Consta de tres partes:
-Una tabla de flujos que indica cmo debe procesar el switch los flujos que le
lleguen.
-Un canal necesario para comunicar el switch con el controlador. Esta

comunicacin se efecta por medio del protocolo OpenFlow.
-El protocolo OpenFlow en s. Consiste en un estndar abierto mediante el cul se

especifican las entradas en la tabla de flujos. OpenFlow es una Southbound API, o
un protocolo de comunicacin entre la capa de control y la capa de infraestructura
de red.
Fig. 5.- OpenFlow Switch
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 -
Fig. 6.- Procesado de un paquete en un switch openFlow
2.9.-Procesado de un paquete en un switch openFlow
Cuando un paquete entra en un switch OpenFlow, se examina comenzando por la

primera tabla en busca de coincidencias. Si las hay, se apuntar la accin definida
en la tabla en el Action Set, y se pasar a evaluar el paquete en la siguiente tabla. El
Action Set es el conjunto de acciones a ejecutar definidas en el switch. Cuando se
evalan todas las tablas, se ejecutar el contenido del Action Set, en el orden
determinado. En caso de no hallar coincidencias en las tablas de flujo, el paquete
ser devuelto al Controlador, que indicar al switch qu hacer con l.
Cada entrada en la tabla de flujos tiene una accin asignada. Hay tres tipos de
acciones bsicas que todos los tipos de switches OpenFlow deben soportar. Estos
tres tipos son:
-Reenviar el paquete a travs de un puerto. Esta accin permite enviar los
paquetes a travs de la red.
-Encapsular y reenviar el paquete al controlador. Tpicamente es la accin que se

ejecutar al recibir un paquete de un nuevo flujo. De esta manera, el controlador
puede decidir si instaurar una nueva entrada en una tabla de flujos y una accin
asociada, o si procesar de alguna otra manera el paquete.
-Eliminar el paquete. De esta forma, el controlador puede actuar como un firewall,

y bloquear paquetes sospechosos, por ejemplo.
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 -
El protocolo OpenFlow consta de tres tipos diferentes de mensajes:

-Mensajes del controlador al switch:
Lo inicia el controlador, y su funcin es conocer y actuar sobre el estado del switch.

Se enva una peticin de caractersticas al switch, y ste debe responder con las
capacidades de las que dispone.
Dentro de este mensaje se pueden distinguir cuatro tipos:
Modify-State: su principal propsito es aadir y eliminar entradas en las
tablas de flujo y fijar caractersticas de los puertos.
Read-State: interroga al switch sobre estadsticas del trfico ( contadores de

las tablas de flujo)
Send-Packet: enva paquetes por un puerto especfico en el switch.
Barrier request/reply: usado para recibir notificaciones para operaciones

completadas.
-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:
Packet-in: enviado al controlador al recibir cualquier paquete que no tenga
coincidencias en las tablas de flujo, o si la accin que corresponde a la
entrada coincidente es reenviar el paquete al controlador.
Flow-modify: se enva cuando una entrada es aadida a la tabla de flujos de

un switch.
Port-status: se enva al cambiar el status de un puerto determinado.
Error.
-Mensajes simtricos:
Son enviados sin solicitud en cualquier direccin. Se pueden distinguir tres tipos:
Hello: mensajes intercambiados durante la negociacin de una conexin.
Echo request/reply: puede ser enviado indistintamente por el switch o el

controlador, a fin de comprobar la comunicacin entre ellos. Puede ser
enviado para indicar diferentes parmetros de una conexin. Debe ser
respondido con un mensaje echo reply.
Vendor message: proporciona una manera a los switches OpenFlow de

ofrecer caractersticas adicionales. Est pensado para futuras revisiones de
OpenFlow.
- 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).
-Comportamiento: dos tipos, reactivo, donde el primer paquete de un flujo

desencadena que el controlador inserte las entradas en las tablas de flujo y el
proactivo, donde el controlador completa las tablas de flujos a priori. En el
comportamiento reactivo cada flujo tiene un tiempo de setup la primera vez que
aparece en la red y en el que si la conectividad con el controlador decae el switch
ver limitada su conectividad. En el comportamiento proactivo no hay tiempo de
setup ni prdida de conectividad del switch si falla la comunicacin con el
controlador.
Hay diferentes implementaciones de controladores. Desde un simple software que

dinmicamente aada y suprima flujos, donde el administrador controla toda la
red de switches OpenFlow y es el responsable del proceso de todos los flujos hasta
una implementacin con mltiples administradores, cada uno con diferentes
cuentas y passwords, que les permite gestionar diferentes conjuntos de flujos. Es lo
que se podra asimilar a virtualizar una red con mltiples propietarios.
- 13 -
Los principales Controladores OpenFlow que hay disponibles hoy en da son:
Controller Principal Caracterstica

NOX/POX OpenFlow Controller open-source que
proporciona una plataforma para escribir
software de control de la red en C++ o Python.
Beacon Controller basado en Java que soporta
operacin basado en eventos y multi-hilo.
Trema Completa plataforma OpenFlow para Ruby/C.
Maestro Plataforma de control escalable escrita en Java.
SNAC OpenFlow Controlador que usa una interfcie
web para gestionar la web.
2.12.-Estandarizacin, ONF, Open Daylight
Debido a la trascendencia que se adivinaba en el cambio a SDN, seis compaas que

posean algunas de las redes ms importantes del mundo anunciaron en 2011 la
formacin de la ONF (Open Networking Foundation). Se trata de una organizacin
dedicada a la promocin y a la mejora y adopcin del networking a travs de SDN.
Estas seis compaas fueron: Deutsche Telekom, Facebook, Google, Verizon,
Microsoft y Yahoo!. Junto a estas empresas se unieron 17 empresas ms,
incluyendo fabricantes de equipamiento, software de virtualizacin, networking,
etc.
Esta organizacin promueve la investigacin, promocin y desarrollo de OpenFlow
como primer standard de SDN y elemento ms ampliamente difundido de esta
tecnologa.
ONF consta de diferentes grupos de trabajo que se ocupan de las reas ms
relevantes de SDN. Algunos de estos grupos son: configuracin y gestin,
migracin, educacin, optical transport, wireless and mobile, etc.
A finales de 2013, la organizacin constaba de ms de 100 miembros.
En su junta directiva figuran ejecutivos de diferentes compaas tecnolgicas:
Facebook, Yahoo!, NTT, Microsoft... as como dos de los creadores de SDN: los
profesores Shenker y McKeown. Como curiosidad citar que tambin forman parte
de la direccin dos ejecutivos de Goldman Sachs, lo que da una idea de la
importancia econmica que se le pronostica a esta tecnologa.
Otra organizacin dedicada a la promocin y adopcin de SDN es el proyecto
OpenDaylight. Esta organizacin est promovida por The Linux Foundation y est
ntimamente ligada a la virtualizacin de redes (NFV). Los miembros fundadores
fueron Arista Networks, Big Switch Networks, Brocade, Cisco, Citrix, Ericsson, HP,
IBM, Juniper Networks, Microsoft, NEC, Nuage Networks, PLUMgrid, Red Hat y
VMware. Alcanzaron un compromiso de dedicar dinero y recursos para
proporcionar una plataforma open source SDN.
- 14 -
2.13.-Ventajas de SDN
La arquitectura SDN proporciona una serie de beneficios a una red:

-Independencia del fabricante. Como los elementos de conmutacin ya no han de
incorporar ningn software de gestin, se pueden combinar equipos de diferentes
fabricantes sin temer por ninguna incompatibilidad. Se deja de estar ligado a
hardware propietario y dispositivos dedicados.
-Mejora de la seguridad. La seguridad pasa a ser controlada por el Controlador, de

forma que no habr agujeros de seguridad en las configuraciones de los
switches/routers.
-Facilidad de innovacin. Una red SDN es ms flexible y configurable, por lo que es

posible experimentar con nuevas aplicaciones, configuraciones, etc...
-Administracin centralizada. La administracin de la red se centraliza en un nico

punto , focalizando la responsabilidad y eliminando mltiples puntos de decisin,
que frecuentemente llevaban a agujeros de seguridad, errores de configuracin,
cuellos de botella, etc...
-Redes dinmicas y adaptables a cambios. Una red SDN se puede reconfigurar en

poco tiempo, evitando engorrosos procesos de configuracin remota de cada
equipo de conmutacin.
-Agilidad y velocidad de aprovisionamiento de servicios y recursos. Efectivamente,

se puede reservar ancho de banda para nuevos servicios rpidamente.
-Reduccin de costes. El ahorro en equipos de conmutacin es incuestionable. Se

pasa de dispositivos propietarios a equipos fabric. Por otro lado, se discute si ste
ahorro se trasladar al controlador y al software. Otro punto a discutir es el ahorro
de costes operativos debidos al aumento de la eficiencia en la gestin de la red. Por
ejemplo, NEC, con su arquitectura Programmable Flow, muestra las siguientes
predicciones de reduccin tanto en costes financieros (CAPEX) como en costes
operativos (OPEX) [12]:
- 15 -
Fig. 7.- Ahorro estimado gracias a SDN. [12]
En la figura 7, se pueden observar las proyecciones de la empresa NEC, respecto a

los costes de una red tradicional comparada con su arquitectura
ProgrammableFlow. Se calcula un ahorro de un 50% en equipamiento, respecto a
una solucin clsica. Si se entra en el detalle de dicho ahorro las previsiones son
de un ahorro de un 50% en diseo/configuracin de la red, un 30% en la gestin y
un 60% en cambios y escalabilidad. Estas previsiones estn hechas en base a un
sistema compuesto de 1000 hosts.
- 16 -
3.-Estado del Arte de SDN

SDN ha suscitado un gran inters en la industria de las redes de computadores. Ya
sea como una amenaza o como una oportunidad, prcticamente todas las empresas
fabricantes de equipos, muchas de las creadoras de software, empresas dedicadas
a soluciones de virtualizacin, computacin en la nube, etc., han desarrollado sus
propias soluciones o adoptado el estndar openFlow.
Son los fabricantes de equipos los que ms rpido han reaccionado al

advenimiento de SDN. No en vano, en principio son los que ms tienen que perder
ya que las redes podran pasar de caros equipos con firmware propietario a
equipos genricos, que simplemente conmutarn seales, interpretarn mensajes
openFlow y gestionarn sus tablas de flujos. SDN ha sido rebautizado como el anti-
cisco, ya que la evolucin anterior mermara enormemente la cuenta de resultados
de esta compaa.
Sin embargo, la reaccin de estas empresas no es homognea: prcticamente todas

implementan la solucin openFlow, pero algunas de ellas la sitan como un
"segmento bajo" de su gama de productos, y reservan caractersticas avanzadas
para su propia implementacin. De esta forma SDN se volvera una solucin
propietaria e incluso ms ligada a un solo fabricante que las redes tradicionales.
Seguidamente se analizarn algunas de las soluciones propuestas por algunas de

las compaas ms relevantes. Adems, se comentar uno de los ejemplos de
migracin ms comentados, la red interna que conecta los Centros de Proceso de
Datos de Google.
- 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.
Fig. 8.- OpenFlow-based SDN stack.[13]
Inicialmente, Brocade implement OpenFlow en equipos destinados a grandes

carriers como la serie MLX de routers y los switches/routers Netron CES/CER
2000. La capacidad de estos equipos es hasta 100Gbps y son capaces de manejar
128k flujos.
Una innovacin que ha incorporado Brocade es su modo hbrido de gestin de los

puertos. En este modo un puerto puede implementar routing y/o switching
tradicional y OpenFlow al mismo tiempo [13]. De esta manera se pueden
implementar redes SDN simultneamente con redes tradicionales sin necesidad de
que haya una separacin de puertos.
Brocade es uno de los fabricantes ms comprometidos con SDN y otro de los

conceptos ligados con l, NFV (Networks Function Virtualization). No ha
desarrollado una arquitectura propietaria, sino que ha adoptado los estndares
openFlow y openStack en sus equipos, y ha desarrollado componentes virtuales a
fin de implementar overlays sobre infraestructuras existentes. [14] Estos
componentes son por ejemplo la familia Brocade Vyatta vRouter 5X00. [13]
De todas maneras, es muy posible que esta ausencia de una solucin integral y
propietaria, ms all de la implementacin de openFlow en determinados equipos,
- 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:
Fig. 9. Solucin propuesta por IBM [19]
- 19 -
En la figura se pueden identificar las diferentes capas de SDN: en el centro el

controlador de SDN, que se comunica con las aplicaciones ( y servicios de red),
mediante las Unified Northbound APIs. Como Southbound APIs se pueden
observar OpenFlow y IBM SDN VE, dependiendo de que tipo de red se est
implementando ( una Virtual Overlay, para redes ya existentes o una red
OpenFlow).
Respecto la solucin OpenFlow, IBM ofrece una completa gama de productos:
-Switches que incorporan OpenFlow ( G8052, G8264, G8264T, G8316, EN4093/R):

soportan tanto el controlador propio de IBM (IBM Programmable Network
Controller) como otros controladores OpenFlow (NEC pFlow, Floodlight ,
BigSwitch, y otros ).
-IBM Programmable Network Controller (PNC). Controlador de red capaz de

definir las polticas de flujos en cualquier entorno OpenFlow.
La solucin OpenFlow de IBM se puede resumir en la siguiente figura:
Fig.10.- IBM OpenFlow Solution [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:
Fig. 11.- Solucin IBM SDN VE.[19]
- 20 -
En l se pueden observar los diferentes componentes del sistema. Sin entrar en

detalles, hay que centrarse en la filosofa, que es la definicin de diferentes redes
virtuales en una infraestructura existente. IBM argumenta una serie de
mejoras[19] [20]:
-Acelera la implementacin de aplicaciones y nuevos servicios de red (de das a

minutos).
-Mejora la escalabilidad, eliminando el lmite de VLANs (4096) y permitiendo

definir hasta 16000 redes virtuales.
-Permite la creacin de redes virtuales desde un punto de vista central , sin haber
de reconfigurar multitud de switches (control centralizado de la red, una de las
caractersticas de SDN).
-Movimiento y configuracin automatizado de Mquinas Virtuales .
-Simplificacin y reduccin del nmero de errores en la configuracin de polticas

de seguridad, firewalls, balanceo de carga, etc.
-Reutilizacin de esquemas de direccionamiento IP y MAC ya existentes.
-Soporta Hypervisors de VMware, as como de KVM.
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]
3.3.1.-HP Virtual Application Network
La estrategia de HP es la llamada HP Virtual Application Network. Como miembro

de la Open Networking Foundation sigue una arquitectura semejante a la definida
por sta:
- 21 -
fig 12.-Entorno HP Virtual Application Networks[24]
Su estrategia va dirigida a hacer girar la red en torno a las aplicaciones, de forma

que esta plataforma HP Virtual Application Networks Manager se integra en forma
de plugin en su HP Intelligent Management Center, su centro de comandamiento
centralizado de redes. Han desarrollado un controlador (HP Virtual Application
Networks SDN Controller[23]) , del que se puede disponer en forma de software o
de dispositivo. Este controlador , como se ve en la figura, se podra decir que
reproduce fielmente la arquitectura SDN :
Fig. 13.- Arquitectura HP SDN[24]
- 22 -
La comunicacin con la infraestructura (SouthBound APIs) es compatible con

OpenFlow, y la comunicacin con las aplicaciones es a travs de REST APIs, otras
APIS de uso muy extendido. Soporta aplicaciones residentes en el dispositivo, as
como la incorporacin de aplicaciones externas. HP da un gran nfasis a la
seguridad del controlador, de forma que incorpora polticas de AAA (autorizacin-
autenticacin-registro) , a fin de preservar la integridad y seguridad de la red. [24]
3.3.2.-HP Virtual Application Networks SDN Applications
HP ha desarrollado aplicaciones para ser integradas en su arquitectura, como por

ejemplo:
-Virtual Cloud Network, un gestor de overlays sobre redes.
-Sentinel Security, una aplicacin de seguridad.
Con el foco puesto en las aplicaciones, y de la misma manera que Apple desarroll
su App Store y Google su Google Play, HP ha desarrollado una tienda de
aplicaciones SDN donde el cliente pueda navegar, buscar e instalar directamente
en el controlador diferentes aplicaciones desarrolladas por terceros o por la propia
HP. [22]
De la misma manera, HP ha desarrollado el llamado HP SDN Developer KIT (SDK).

Se trata de una herramienta abierta para crear, probar validar aplicaciones
ideadas para SDN y para ser instaladas en su controlador, por supuesto. El SDK
proporciona APIs y documentacin, guas de programacin, Graphical User
Interface (GUI), ejemplos de cdigo y aplicaciones y un entorno de simulacin. De
esta forma, HP quiere tomar una posicin de dominio en el incipiente mercado
SDN y posicionar su dispositivo en base a un entorno abierto de creacin y
suministro de aplicaciones.
Fig. 14.-Simulation Suite de HP. [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:
Fig. 15.- Modelos de desarrollo para Open Networking. [28]
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 -
Fig. 16.- Cisco onePK Software Architecture. [28]
Los elementos principales son los siguientes:
-Programas escritos en Java o C (otros lenguajes en el futuro).
-Una capa de presentacin, o conjunto de APIs que enlazan las diferentes

funciones y libreras de cada dispositivo y a travs de cada sistema operativo de
red.
-Un canal de comunicacin entre la capa de presentacin y una capa de

infraestructura, que accede a los diferentes elementos de la red.
-La capa de infraestructura, que implementa el cdigo especfico de cada

plataforma.
-Las implementaciones de las libreras Cisco onePK en las diferentes plataformas.

Esta arquitectura no especifica separacin fsica entre plano de control y plano de
datos. De hecho, los diferentes SO de red pertenecen a los dispositivos de Cisco. En
palabras de la propia Cisco, ofrece la aproximacin ms cercana a las redes
programables , incluyendo los controladores SDN, APIs abiertas y redes virtuales a
travs de una gran variedad de modelos.
A fin de aprovechar las funcionalidades de esta arquitectura y mostrar cmo

onePK proporciona mejores prestaciones y mayor flexibilidad que otras
implementaciones de SDN, Cisco ha desarrollado el Cisco Unified Access Data
Plane (UADP). Se trata de un ASIC que soporta las APIs onePK, y que ha sido
incorporado en switches de la compaa (concretamente el Catalyst 3850 Unified
Access). Este ASIC proporciona acceso a mtricas de bajo nivel de la red, as como
una disminucin del time-to-market de aplicaciones onePK.
Como punto a favor de esta arquitectura, se puede mencionar que no es una

arquitectura cerrada. Por ejemplo, nuevos protocolos, como OpenFlow, se pueden
incorporar como agentes a onePK, permitiendo la transicin a modelos estrictos de
SDN.
- 25 -
3.4.2.-Cisco eXtensible Network Controller (XNC)
De todas maneras, como miembro fundador de la ONF, Cisco no poda dejar de

introducir un Network Controller que cumpliera las especificaciones de un
Controlador SDN. Este es el Cisco XNC. Est diseado para soportar OpenFlow y
funcionar con dispositivos de Cisco y de otros fabricantes. [28]
-Soporta OpenFlow y onePK.
-Posee funciones avanzadas tales como descubrimiento de topologa de red ( al

estilo de Cisco Discovery Protocol), gestin de la red, acceso a mtricas de anlisis,
programabilidad, etc.
-Interfaz grfica de comunicacin con las aplicaciones ( o en su defecto, mediante

Northbound APIs estndar)
-Caractersticas de seguridad (RBAC), polticas de AAA, y protocolos de control

seguros. [28]
El controlador XNC puede coexistir con los tradicionales planos de control de los
diferentes dispositivos, a fin de implementar un modelo de red hbrido (ya descrito
por la ONF). De esta manera, los dispositivos podran continuar ejecutando los
protocolos (por ejemplo) OSPF o Spanning Tree, y ser complementado por las
funcionalidades de OpenFlow.
La interfaz grfica de comunicacin con las aplicaciones (GUI) ha sido construida

de tal manera que todo lo que se implemente mediante ella es accesible a otras
aplicaciones externas. Su aspecto es el siguiente:
Fig. 17.- Cisco XNC GUI. [28]
Como fabricante de equipos, Cisco ha incorporado agentes OpenFlow a diferentes

modelos de sus familias de switches Catalyst y Nexus, permitiendo de esta manera
- 26 -
la utilizacin de sus chasis en diferentes modelos de SDN. Asimismo, soportan la

incorporacin de nuevos protocolos (como por ejemplo Interface to Routing
Systems (IR2S), desarrollado por el IETF) permitiendo mayor flexibilidad a los
desarrolladores de aplicaciones SDN.
3.4.3.-Application Centric Infrastructure (ACI)
Como ya se ha mencionado, Cisco obtiene sus beneficios de la venta de unos

equipos que proporcionan unos enormes mrgenes, por tanto, no renunciar a
incorporar SDN al hardware.
A pesar de que SDN es eminentemente una solucin software , la idea de Cisco es

que no es suficiente con el software para implementarla de una forma eficiente.
Para ello, y a travs de una extraa maniobra consistente en la fundacin y
posterior compra de una startup llamada Insieme, desarrolla una familia de
productos llamada Application Centric Infraestructure (ACI). ACI est compuesta
de tres grandes ramas:
-Una nueva lnea de switches de la familia Nexus 9000.
-Un controlador llamado APIC (Application Policy Infrastructure Controller).
-Un sistema operativo de red (NX-OS), residente en el switch.
Hay crticos que argumentan que el hardware implementa dos ASICs, uno
fabricado por Broadcom y otro propio de Cisco. Si se utiliza el de Broadcom, se
pueden usar otras soluciones de SDN basadas en estndares. Si se utiliza el de
Cisco, se obtienen funcionalidades extra y una mejor funcionalidad de la red.
Tambin se argumenta que esta solucin no es compatible con el antiguo
equipamiento, por lo que se ha de renovar toda la red con dispositivos Cisco
compatibles. [31]
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 -
El concepto de virtualizacin ha sido una revolucin en el mundo de la informtica:

permite desligar el espacio disponible del nmero de servidores. En un solo
hierro es posible disponer de decenas de servidores. Produce un evidente ahorro
en hardware, consumo de energa, etc. Entronca directamente con el concepto de
software defined data center (SDDC) y cloud computing.
La virtualizacin de servidores es exactamente el mismo concepto que

virtualizacin de redes: definir redes virtuales sobre un pool de capacidad de
transmisin disponible fsicamente. De hecho existe otra rama de investigacin
llamada NFV (Network Function Virtualization) que estudia diferentes soluciones a
esta cuestin. Si estas redes virtuales se definen por software en base a
requerimientos de las aplicaciones, ya tenemos lo que queramos: SDN.
As se relacionan varias de las nuevas disciplinas de la computacin:
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 -
La arquitectura desarrollada de NSX es la siguiente:
fig 19 .- Arquitectura NSX. [33]
La estrategia de VMware es extender el concepto de tecnologas de virtualizacin a

la red. Se podra realizar la siguiente analoga:
Fig. 20.- Analoga de virtualizacin de Servidores y Red. [34]
En el papel de hypervisor, VMware implementa un virtual Switch (vSwitch), que es

quien controla los enlaces entre las mquinas virtuales. Si es necesario acceder a
un recurso remoto, vSwitch proporciona acceso a la red fsica. De esta manera,
- 29 -
proporciona los servicios de capa de red 2 a 7 (switching, routing, firewalling, QoS,

balanceo de carga, etc.).
El controlador NSX es el cerebro del sistema. Como ya se ha comentado varias

veces a lo largo de esta memoria, es el middleware entre las aplicaciones y la capa
de conmutacin. En este caso, entre aplicaciones y el vSwitch, el hypervisor. Se
comunica con las aplicaciones mediante las northbound APIS y con el hypervisor
mediante southbound APIS, entre ellas OpenFlow. En general, VMware, como los
dems fabricantes, no priorizan el uso de OpenFlow, aunque implementado,
proporcionan otras soluciones propias.
NSX va un paso ms all de SDN, su propsito es virtualizar la red, por lo que

ofrece soporte a mltiples hypervisores y overlays, pudiendo incorporar, por
ejemplo, control de un firewall virtual que est distribuido entre varios overlays.
De esta manera, se podran incorporar redes virtualizadas mediante hypervisores
de Citrix o KVM, otros actores importantes en la virtualizacin de redes. Tambin
ofrece conexin a redes no-NSX a travs de un gateway NSX.
Por ejemplo, en una arquitectura tradicional, un balanceador de carga o un firewall

han de tener el trfico redirigido hacia ellos para procesarlo. Esto significa que el
camino directo (en un data center) entre dos servidores debe ser ignorado a favor
de un camino que pase por el elemento en cuestin. NSX coloca estos elementos en
el hypervisor, de forma que el trfico pasar por ellos obligatoriamente.
Mediante NSX, VMware proporciona una solucin integral a plataformas de cloud

computing y software defined data centers, siendo perfectamente integrable con
los otros productos de virtualizacin que proporciona la compaa.
Evidentemente, su solucin ha despertado crticas. La excesiva confianza en otra

capa intermedia, el hypervisor, que evita la comunicacin directa entre el
controlador NSX y el hardware de la red. Otro aspecto criticable es ,
evidentemente, el coste adicional de aplicar una solucin de VMware, que puede
ser percibido como una barrera. [35]
3.6.-Red de CPDs de Google
Uno de los casos ms paradigmticos de implantacin de SDN es el caso de Google.

Esta empresa se encuentra entre los ms grandes proveedores de contenido
(entendindose por contenido bsquedas, cloud computing, video, datos de
usuario, aplicaciones empresariales, etc...) que existen. Sus servicios se
proporcionan a travs de unos Centros de Proceso de Datos diseminados por los
cinco continentes, de forma que proporcionan redundancia y alta disponibilidad.
La arquitectura de la red de Google es la siguiente:
-Una WAN que interacta con mltiples dominios de Internet. Esta es la red que
intercambia trfico con los usuarios. stos envan sus consultas, bsquedas, y
acceden a sus datos guardados en la nube, a Google, y ste gestiona estas
- 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.
Fig. 21 .- Red de CPDs de Google. [36]
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 -
protocolo openFlow. Otro de sus objetivos fue simultanear la utilizacin de

tecnologas tradicionales y una aplicacin de Traffic Engineering centralizada.
Esta aplicacin permita a Google gestionar las peticiones de ancho de banda ms

eficientemente en perodos de alta utilizacin, as como reposicionar
dinmicamente el ancho de banda en funcin de la demanda de las distintas
aplicaciones.
Estas caractersticas permitieron que la red B4 de Google funcione con una ratio de
utilizacin cercana al 100% y de media un 70% en largos perodos de tiempo, ratio
que se corresponde con un incremento de la eficiencia de dos a tres veces,
comparndola con las tecnologas de gestin estndares.
En la actualidad, la red SDN de Google sirve ms trfico que su red "pblica", y

tiene una ratio de crecimiento mayor.
Sin embargo, tambin han experimentado inconvenientes. Uno de ellos es que se

han experimentado "bottlenecks" o cuellos de botella, especialmente al enviar
paquetes del plano de control al plano de datos. Estos cuellos de botella tienen que
ver con el rendimiento o capacidad del controlador, tema al que nos referiremos
ms adelante.
Del caso de Google se pueden extrapolar ideas a un gran nmero de

implementaciones de SDN en la vida real. A pesar de las particularidades de su red
interna hay una serie de prcticas a considerar. Una de ellas es la aproximacin
hbrida, que consiste en que la red soporte los protocolos tradicionales a la vez que
openFlow, de forma que la transicin no es traumtica y elimina suspicacias a la
hora de adoptar SDN.
Definitivamente, y por la magnitud y relevancia de la compaa, ste es un caso

paradigmtico en la implementacin de SDN , un "acelerador" de esta tecnologa y
un ejemplo a seguir por otras muchas compaas.
- 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 -
Fig. 22.-Configuracin de interfaces.
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 host-
only-interface. Habitualmente la IP 10.0.0.X corresponde con NAT.
Fig. 23.- Configuracin VirtualBox
- 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.
Fig. 24.- Configuracin Putty
- 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
$ sudo mn --topo minimal
Fig. 25 .- Topologa mnima.
- 37 -
Esta topologa consta de un controlador ( si no se especifica, se selecciona el

controlador por defecto que implementa OpenFlow), un switch OpenFlow y dos
hosts conectados al switch.
Hay una serie de topologas sencillas que se pueden especificar directamente en la

llamada a mininet. Estas topologas son:
$ sudo mn --topo single , [n]
donde n es el nmero de hosts deseados. Consta de n hosts conectados a un switch.
Fig. 26.- Topologa Single
$ sudo mn --topo linear, [n]
donde n es el nmero de switches. Consta de n switches conectados entre s. En

cada switch hay , adems, un host conectado.
Fig. 27.- Topologa Linear
$ sudo mn --topo tree, depth=n
implementa una topologa en rbol, con una profundidad de n niveles. El nivel

superior es de un switch, y cada switch conecta con dos en el nivel inferior. En el
nivel n-simo, cada switch conecta dos hosts.
- 38 -
Por ejemplo:
$ sudo mn --topo tree,depth=3
Fig. 28.- Topologa Tree
Se pueden implementar topologas tan complejas como se desee. Sin embargo,

topologas customizadas han de implementarse a partir de scripts python. Por
ejemplo, para implementar una topologa formada por dos switches
interconectados y dos host en cada switch:
- 39 -
y la forma de invocarlo sera:
$ sudo mn --custom ~/mininet/custom/topo-2sw-4host.py --topo mytopo
siendo ~/mininet/custom/topo-2sw-4host.py el nombre y ruta del script.
Una vez en mininet con una topologa a simular, hay una serie de comandos
sencillos que muestran informacin de la red:
mininet> nodes
muestra los nodos disponibles
mininet>net
muestra informacin sobre la red, nodos y enlaces disponibles.
mininet>dump
muestra informacin sobre las direcciones IP de cada nodo.

Dentro de mininet es posible ejecutar comandos en cada nodo, por ejemplo:
mininet> h1 ifconfig -a
ejecutar el comando ifconfig -a desde el host h1.
Otro parmetro til es --mac: al aadirlo a la llamada a mininet har que las
direcciones mac de los hosts coincidan con sus direcciones IP. Esto es:
IP: 10.0.0.2 -> MAC: 00:00:00:00:00:02
Mininet permite ajustar valores de los enlaces, mediante el parmetro --link. Por
ejemplo:
$ sudo mn --link tc, bw=100, delay=20ms
Con estos valores, se limita la velocidad de los enlaces a 100 Mbps, con un delay de
20 ms.
Tambin es posible habilitar/inhabilitar un enlace determinado:
mininet> link s1 h1 down

mininet> link s1 h1 up
- 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:
Fig. 29.- Resultados del test 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 -
aadir el parmetro -x a la lnea $ sudo mn .... de esta manera se abrirn ventanas

xterm para cada elemento definido en la red ( controlador, switches y hosts).
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.
Fig.30 .- Filtro "of" en wireshark
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
Fig. 31.- Mensajes de un ping en wireshark
Se pueden observar varios tipos de mensajes:
-Mensajes protocolo OFP Echo Request/Reply: estos mensajes se envan del/al

controlador al/del openFlow switch. No confundir con los mensajes de eco ICMP
(ping).
-Mensajes protocolo OFP+ARP: estos mensajes son las peticiones/respuestas ARP
de los hosts, que al no coincidir con ninguna entrada de la tabla de flujos del
switch, son encapsulados en paquetes openFlow y enviados al controlador.
-Mensajes protocolo OFP+ICMP: es la peticin/respuesta de ping de los hosts, que
al no coincidir con ninguna entrada de flujo del switch, es enviado al controlador.
-Mensajes protocolo OFP FlowMod: es el mensaje que se enva al switch desde el

controlador para asociar un puerto del switch con una direccin MAC.
- 43 -
Si a continuacin eliminamos el delay y efectuamos cinco peticiones de eco de h1 a

h2:
Fig. 32 .- Respuestas a un ping.
Podemos observar como el primer ping consume ms de treinta veces ms tiempo

que los siguientes. Esto es debido a que esta primera comunicacin es derivada al
controlador y la tabla de flujos es modificada. Las siguientes peticiones de eco ya
coinciden con entradas de la tabla del switch, por lo que no es necesaria la
actuacin del controlador.
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 -
El parmetro que permite seleccionar otro controlador distinto es --controller
Por ejemplo,
$ sudo mn --topo single, 3 --controller remote
La sintaxis general es del parmetro --controller es
--controller remote, ip=[controller IP], port=[controller port]
De esta manera, se podra instalar un controlador en cualquier lugar del mundo. Si

no se especifican, se toman los valores IP 127.0.0.1 port 6633. Estos valores se
corresponden con la mquina virtual, por lo que , desde otra sesin SSH podemos
ejecutar el controlador deseado.
Desde otra sesin SSH ejecutamos el controlador de referencia:
$ controller ptcp:
stas dos rdenes son equivalentes a ejecutar:
$ sudo mn single,3
4.5.1.-Ejemplo :Creacin de una topologa bsica.
En este ejemplo, se crear una topologa de red bsica y se mostrar la

funcionalidad de SDN.
-Arrancamos VirtualBox y la mquina virtual con mininet que se ha creado

anteriormente.
-Podemos optar por trabajar en la consola abierta en VirtualBox o abrir una sesin
SSH, es indiferente.
-Definimos una topologa bsica. En este caso un switch, conectado a tres hosts y a
un controlador. La particularidad es que no implementamos ningn controlador, lo
haremos a mano.
$sudo mn --topo single,3 --mac --switch ovsk --controller remote
Este comando crea una topologa simple, con un switch OpenFlow (--switch ovsk)
conectado a tres hosts. Por simplicidad haremos que la direccin mac sea igual a la
direccin IP (--mac) y un controlador remoto (--controller remote).
En la consola utilizada arrancar el entorno mininet. Se distingue por el prompt

mininet>
-Para comprobar la topologa creada se puede ejecutar el comando:
- 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:
Fig. 33 .- Comando dpctl
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 -
Fig. 34 .- Comando dpctl
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.
La salida es la siguiente:
- 47 -
Se observa como no se ha obtenido respuesta. El switch acta como una simple

plataforma de conmutacin. Al no haber ningn flujo instalado en su tabla de flujos
no hay respuesta del host 2.
Vamos a proceder a instalar manualmente los flujos necesarios para esta

comunicacin. En el terminal SSH abierto ejecutamos:
$ dpctl add-flow tcp:127.0.0.1:6634 in_port=1,actions=output:2

$ dpctl add-flow tcp:127.0.0.1:6634 in_port=2,actions=output:1
Volvemos a comprobar la tabla de flujos con dpctl dump-flows:
Fig. 35 .- Tabla de flujos creados
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:
- 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 -
Este sencillo ejemplo nos muestra en esencia la potencia de SDN. Mediante

software, hemos definido la conectividad en nuestra red. Esto es lo que realizar
automticamente el controlador, en base a las instrucciones que le proporcione las
aplicaciones.
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.
4.7.-Learning-Switch con seguridad por puerto.
A modo de ejemplo se ha desarrollado un componente que incorpora una

caracterstica de seguridad presente en la mayora de puntos de acceso WI-FI. Un
- 50 -
control de acceso realizado en base a la direccin MAC de la mquina conectada a

la red.
El funcionamiento es el siguiente:
Un cliente enva un paquete destinado a otro cliente. Los switches virtuales

contrastan dicho paquete con su tabla de flujos. Caso de encontrar coincidencia se
ejecutar la accin que se asociada a dicha entrada. Si no se encontraran
coincidencias el paquete es derivado al controlador. El controlador examinar la
MAC de destino de dicho paquete y enviar un mensaje openFlow al switch
implicado instalando una entrada en la tabla de flujos. Esta entrada asociar la
MAC de destino con el puerto donde est ubicada. Los siguientes mensajes
dirigidos a esta MAC , al coincidir con una entrada de la tabla, no sern derivados al
controlador, al menos durante el tiempo de vigencia de la entrada en la tabla de
flujos (tambin programable).
La caracterstica aadida es la siguiente:
Al llegar el paquete IP al componente diseado, ste examinar la MAC de destino,

confrontndola con las de un fichero mac.txt. Si esta direccin MAC no figura en el
archivo, el paquete se perder.
El efecto es el de una white-list, una lista de direcciones MAC que tienen permitido
su acceso a la red.
Este tipo de seguridad es utilizado principalmente en redes WIFI, donde se quiere

tener control sobre los dispositivos que se conectan a ella. En redes cableadas es
raro su uso, el propio acceso a las instalaciones ya se considera suficientemente
privativo.
Sin embargo, imaginemos una empresa con varios edificios y una wifi desplegada
por ellos. Con este componente se podra centralizar la seguridad de dicha wifi y
pasar de un esquema de acceso mediante usuario y contrasea a un acceso por
dispositivo, o combinar ambos, reforzando la seguridad de la red.
Y la principal ventaja es que el control de este archivo est centralizado. No es

necesario acceder a la CLI de varias decenas de Puntos de Acceso WiFi y
aadir/suprimir MACs autorizadas. Simplemente manteniendo el control sobre un
archivo se puede gestionar esta caracterstica.
En el anexo se incluye el listado de esta aplicacin.
Probaremos el componente con la siguiente topologa:
$sudo mn --topo linear,15 --mac --switch ovsk --controller remote
Esta topologa consiste en 15 switches, conectados en cascada, con un host

conectado a cada switch. Se selecciona un controlador remoto (en este caso ser
POX) y un switch OpenFlow. El parmetro --mac servir para que, en nuestra
- 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:
Fig. 36.- Creacin de la topologa de prueba en mininet.
Desde la sesin donde est ejecutndose el entorno mininet probamos la

conectividad entre dos hosts con MAC permitida:
En la sesin del controlador se pueden ver los mensajes de las distintas peticiones
y respuestas ARP, as como el mensaje openFlow de instalacin de una entrada en
la tabla del switch 1 para llegar a la IP del host 2:
- 52 -
En el caso de conectividad con un host cuya MAC no est habilitada (h14, por
ejemplo):
- 53 -
Fig. 37.- Intento de comunicacin de una MAC no autorizada.
Se puede observar como el controlador deniega la conectividad, en base a la no

pertenencia de la MAC de h14 (00:00:00:00:0d) al pool de MACs permitidas. Este
dispositivo no tendr acceso a la red.
- 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 -
Para intentar cuantificar el rendimiento de un controlador, los profesores Rob

Sherwood y Kok-Kiong Yap crearon una herramienta, cbench, que posteriormente
se integr en las distribuciones de mininet.
Cbench emula varios openFlow switches conectados a un controlador

determinado. Cada switch emulado enva un nmero configurable de nuevas
peticiones de flujo al controlador y computa el tiempo de establecimiento de dicho
flujo. Soporta dos tipos de operacin: latencia y throughput. En modo latencia, cada
switch mantiene una peticin de flujo, esperando la respuesta antes de emitir la
siguiente. Este modo medira el tiempo de proceso del controlador en condiciones
de bajo trfico. En modo throughput, cada switch mantiene tantas peticiones
pendientes como sus buffers le permiten. Este modo servira para evaluar la ratio
mxima de establecimiento de flujos que un controlador puede mantener.
Por ejemplo, examinemos la funcionalidad del controlador POX. Para esto

utilizaremos el componente l2_learning, que pertenece a los ejemplos
suministrados con POX, en el directorio pox/forwarding . Dicho componente
realiza la funcin clsica de un switch. Ejecutamos el controlador:
$ ./pox.py forwarding.l2_learning
En otra sesin SSH ejecutamos el test cbench. Supongamos que tenemos 100k
MACs (o hosts diferentes). Iremos aumentando el nmero switches y veremos
cundo saturamos el controlador en modo latencia.
$ cbench -c localhost -p 6633 -s X -M 100000 -m 1000 -l 5
X representa el nmero de switches de la red. Este ejemplo realiza 5 tests de

duracin 1000 ms. El primer y ltimo test son despreciados.
Se obtienen los siguientes resultados:
Switches Flows/s
1 674,75
2 1101,75
3 1540,75
5 2441,88
10 3763,22
20 3925,13
50 4524,68
100 4630,89
200 4544,92
500 4585,12
1000 4631,33
- 56 -
Fig. 38.- Flujos vs nmero de switches en modo latencia
Observamos que al llegar aproximadamente a 4500 flujos/segundo el controlador

se satura, ya no ser capaz de establecer los flujos a la misma velocidad que se
generan peticiones. Posiblemente a partir de aqu ya se pierdan flujos y los
resultados sean menos fiables. Sera conveniente aadir otro controlador. Esto
significa una red con 50 switches, aproximadamente.
Si realizamos el mismo test pero en la opcin throughput:
$ cbench -c localhost -p 6633 -s X -M 100000 -m 1000 -l 5 -t
Switches 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 -
Fig. 39.- Flujos vs nmero de switches en modo throughput
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 -
En este sentido, se han desarrollado herramientas acadmicas que permiten

realizar estudios sobre cuestiones relacionadas con SDN. Una de estas
herramientas es el entorno Mininet, desarrollado por la universidad de Stanford.
Este entorno proporciona una potente herramienta de simulacin de redes SDN,

permitiendo implementar topologas tan complicadas como se desee, con un
elevado nmero de hosts y switches . Permite ejecutar cualquier aplicacin
disponible en el Linux anfitrin y, asimismo, permite incorporar cualquier
controlador externo que se desarrolle, local o remotamente. De esta forma se
puede simular el comportamiento de una red distribuida en todo el mundo, y cuyo
funcionamiento es gestionado de manera centralizada desde una localidad
determinada. Dicho podra ser el caso de la ya comentada red de CPDs de Google.
Tambin hemos comentado el caso de un controlador open-source, desarrollado

expresamente para la comunidad cientfica, POX. Este controlador proporciona una
plataforma para el desarrollo de componentes e investigacin en protocolos de
comunicaciones. A modo de ejemplo, se ha desarrollado un componente simple
que incorpora una caracterstica de seguridad a nivel de puerto.
No cabe duda de que SDN significa una revolucin en el mundo de las redes de
comunicaciones. Y como tal se est percibiendo en la industria e instituciones
acadmicas. Multitud de empresas emergentes est surgiendo incorporando
diferentes soluciones, es campo de estudio en universidades de todo el mundo, la
industria consolidada implementa sus propias arquitecturas. Ahora bien, este
modelo no va a sustituir a las redes tradicionales, ms bien convivir con ellas en
un futuro no muy lejano. A medida que los trabajos de estandarizacin avancen y
se profundice en las investigaciones sobre temas pendientes (seguridad,
resiliencia, rendimiento del controlador, etc...) se ver si dicho modelo se impone
en las redes de ordenadores de toda organizacin.
- 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
class Entry (object):

def __init__ (self, port, mac):
self.timeout = time.time() + ARP_TIMEOUT
self.port = port
self.mac = mac
def __eq__ (self, other):

if type(other) == tuple:
return(self.port,self.mac)==other
else:
return(self.port,self.mac)==(other.port,other.mac)
def __ne__ (self,other):

return not self.__eq__(other)
def isExpired (self):

if self.port == of.OFPP_NONE: return False
return time.time() > self.timeout
def dpid_to_mac (dpid):

return EthAddr("%012x" % (dpid & 0xffFFffFFffFF,))
class MyComponent (EventMixin):
- 61 -
def __init__ (self, fakeways = []):

self.fakeways = set(fakeways)
# buffer de IPs a Entradas, una por Switch (identificado por dpid)
self.arpTable = {}
# buffer (dpid,IP) que no podemos entregar porque no sabemos donde va
self.lost_buffers = {}
self.authorized_mac = []
f=open("ext/mac.txt")
line=f.readline()
while line !="":
# print(" MAC LEIDA: %s" %(line))
mac_addr=EthAddr(line)
self.authorized_mac.append(mac_addr)
# print("%s" %(mac_addr))
line=f.readline()
f.close()
self.listenTo(core)
def _handle_GoingUpEvent (self, event):

self.listenTo(core.openFlow)
print("System Start-up")
def _handle_ConnectionUp (self, event):

print("Switch %i ha arrancado." %(event.dpid))
def _send_lost_buffer (self, dpid, ipaddr, macaddr, port):

if (dpid,ipaddr) in self.lost_buffers:
bucket = self.lost_buffers[(dpid,ipaddr)]
del self.lost_buffers[(dpid,ipaddr)]
for _,buffer_id,in_port in bucket: #hasta que vaciamos el buffer
po = of.ofp_packet_out(buffer_id=buffer_id,in_port=in_port)
po.actions.append(of.ofp_action_dl_addr.set_dst(macaddr))
po.actions.append(of.ofp_action_output(port=port))
core.openFlow.sendToDPID(dpid, po)
def _handle_PacketIn (self, event):

dpid = event.connection.dpid # identificacion del switch
inport = event.port # identificacion del puerto
packet = event.parsed # paquete recibido
# print ("Paquete recibido en switch %i puerto %i" %(dpid,inport))
if dpid not in self.arpTable:

print("Nuevo Switch detectado")
self.arpTable[dpid] = {} # crea una nueva tabla
for fake in self.fakeways:
self.arpTable[dpid][IPAddr(fake)] = Entry(of.OFPP_NONE,dpid_to_mac(dpid))
else:
print("Switch Conocido")
#print (" Tipo de paquete: %s" % (packet.type))
if packet.type == ethernet.IP_TYPE:
print( " Recibido IP")
elif packet.type == ethernet.ARP_TYPE:
- 62 -
print( " Recibido ARP")
if isinstance(packet.next, ipv4): #paquete a enviar tipo IP

# print("Enviando paquete IP de SWITCH %i PORT %i IP: %s => %s #
"%(dpid,inport,packet.next.srcip,packet.next.dstip))
self._send_lost_buffer(dpid,packet.next.srcip,packet.src,inport)
#actualiza la tabla MAC

if packet.next.srcip in self.arpTable[dpid]:
if self.arpTable[dpid][packet.next.srcip]!=(inport,packet.src):
print ("Re-Aprendida IP %s en Switch %i Port %i"
%(packet.next.srcip,dpid,inport))
else:
print("Aprendida IP %s en Switch %i Port %i"
%(packet.next.srcip,dpid,inport))
self.arpTable[dpid][packet.next.srcip] = Entry(inport,packet.src)
# envia paquete
dstaddr = packet.next.dstip
if dstaddr in self.arpTable[dpid]: #IP destino en la tabla ARP
prt = self.arpTable[dpid][dstaddr].port
mac = self.arpTable[dpid][dstaddr].mac
if prt != inport: #no enviamos por el mismo puerto!!!

if mac in self.authorized_mac:
print("Instalando NUEVO FLUJO en Switch %i para %s Port %i"
%(dpid,dstaddr,prt))
actions = []
actions.append(of.ofp_action_dl_addr.set_dst(mac))
actions.append(of.ofp_action_output(port = prt))
match = of.ofp_match.from_packet(packet,inport)
match.dl_src = None
msg = of.ofp_flow_mod(command=of.OFPFC_ADD,
idle_timeout=FLOW_IDLE_TIMEOUT,
hard_timeout=of.OFP_FLOW_PERMANENT,
buffer_id=event.ofp.buffer_id,
actions=actions,
match=of.ofp_match.from_packet(packet,
inport))
event.connection.send(msg.pack())
else:
print("MAC no autorizada")
elif isinstance(packet.next, arp): #paquete a enviar tipo ARP

a = packet.next
print("Recibiendo ARP de Switch %i Port %i %s => %s "
%(dpid, inport, {
arp.REQUEST:"REQUEST",arp.REPLY:"REPLY"}.get(a.opcode,
'op:%i' % (a.opcode,)), str(a.protodst)))
# vamos a suponer que el paquete dentro de ARP es IP

# y que el hardware es Ethernet
if a.protosrc != 0: #si la IP no es nula actualizamos tabla ARP
- 63 -
self.arpTable[dpid][a.protosrc] = Entry(inport, packet.src)
# self._send_lost_buffer(dpid, a.protosrc, packet.src, inport)
if a.opcode == arp.REQUEST: # peticion ARP,

if a.protodst in self.arpTable[dpid]: # IP destino en tabla ARP
if not self.arpTable[dpid][a.protodst].isExpired(): #es reciente
r = arp()
r.hwtype = a.hwtype
r.prototype = a.prototype
r.hwlen = a.hwlen
r.protolen = a.protolen
r.opcode = arp.REPLY
r.hwdst = a.hwsrc
r.protodst = a.protosrc
r.protosrc = a.protodst
r.hwsrc = self.arpTable[dpid][a.protodst].mac
e=ethernet(type=packet.type,src=dpid_to_mac(dpid),dst=a.hwsrc)
e.set_payload(r)
print(" Respondiendo peticion ARP de %s a Switch %i Port %i"
%(str(r.protosrc),dpid,inport))
msg = of.ofp_packet_out()
msg.data = e.pack()
msg.actions.append(of.ofp_action_output(port=of.OFPP_IN_PORT))
msg.in_port= inport
event.connection.send(msg)
return
# como no tenemos la direccion, haremos un flooding del ARP
print(" FLOODING ARP a Switch %i %s => %s ? " %

(dpid,{arp.REQUEST:"REQUEST",arp.REPLY:"REPLY"}.get(a.opcode,'op:%i' % (a.opcode,)),
str(a.protodst)))
msg = of.ofp_packet_out(in_port=inport , action=of.ofp_action_output(port = of.OFPP_FLOOD))
if event.ofp.buffer_id is of.NO_BUFFER:
msg.data = event.data
else:
msg.buffer_id = event.ofp.buffer_id
event.connection.send(msg.pack())
def launch ():

core.registerNew(MyComponent)
- 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 Brocade-
Brocade Corp.
[17] Brocade VCS Fabrics: The Foundation for Software-Defined Networks-
Brocade 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-48267-
813-0
NetworkVirtuali
- 67 -

SDN PDF

Cargado por

Copyright:

Formatos disponibles

SDN PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SDN PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSITAT POLITCNICA DE CATALUNYA

Master en Ingeniera Telemtica

Software Defined Networking

Autor:scar Roncero Hervs

Acrnimos y trminos ............................................................................................... - 2 -

Las tecnologas de la informacin, la computacin, la electrnica al servicio de la

Desde el principio, fueron tecnologas estticas, asociadas a grandes mainframes,

El advenimiento del PC a principio de los 80 marca el inicio de una gran revolucin.

El trabajo de estandarizacin de la multitud de protocolos necesarios para

Sin embargo, toda esta tecnologa, aunque en la mayora de casos funciona, se ha

-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

-servidores de red alojados en costosos ordenadores.

-hardware de red de mltiples fabricantes, que implementa diferentes protocolos,

-Aparecen iniciativas de software libre y Open Source, como forma de abaratar el

-Se desarrolla Java, como lenguaje de programacin que permite ejecutar

-Se implanta el llamado Cloud Computing, de forma que aplicaciones y datos

-Aparece la virtualizacin: una forma de implementar diferentes servidores en un

ste ltimo punto produce que si antes un puerto de un switch soportaba

Todas estas caractersticas se busca que sean definibles por software,

ste es el propsito del paradigma introducido por Software Defined Networking.

En este primer captulo se establecern las principales caractersticas de SDN, as

La idea de programar redes no es nueva, segn [1] hay varias contribuciones

En 2011, Scott Shenker y Nick McKeown fundaron la Open Networking Foundation

SDN es un cambio de paradigma en la forma de gestionar una red. Su principal

2.4.-Arquitectura de red tradicional

Bsicamente, una red tradicional consiste en un conjunto de medios de

Fig 1.- Arquitectura de red tradicional.

Estn basadas en multitud de reglas predefinidas. Los protocolos actuales

Coartan la investigacin y el desarrollo. Evidentemente, los fabricantes y

Fig. 2.-Arquitectura SDN.

Fig. 3.- Arquitectura de capas de SDN.

Ms detalladamente, el modelo de arquitectura SDN es el siguiente:

Fig. 4.- Arquitectura SDN [7]

La capa inferior la componen la infraestructura de red, hosts, switches/routers y

Al conjunto de tablas de flujos y a un canal hacia un controlador se le llama switch

-Un canal necesario para comunicar el switch con el controlador. Esta

-El protocolo OpenFlow en s. Consiste en un estndar abierto mediante el cul se

Fig. 5.- OpenFlow Switch

-Contadores, que contabilizan la coincidencia de paquetes. Se actualizan por flujo,

-Acciones a realizar cuando se encuentra una coincidencia entre un paquete y una

El procesado de un paquete por parte de un OpenFlow Switch es el siguiente:

Fig. 6.- Procesado de un paquete en un switch openFlow

2.9.-Procesado de un paquete en un switch openFlow

Cuando un paquete entra en un switch OpenFlow, se examina comenzando por la

-Encapsular y reenviar el paquete al controlador. Tpicamente es la accin que se

-Eliminar el paquete. De esta forma, el controlador puede actuar como un firewall,

El protocolo OpenFlow define el protocolo de comunicacin entre el switch

El protocolo OpenFlow consta de tres tipos diferentes de mensajes:

Lo inicia el controlador, y su funcin es conocer y actuar sobre el estado del switch.

Read-State: interroga al switch sobre estadsticas del trfico ( contadores de

Send-Packet: enva paquetes por un puerto especfico en el switch.

Barrier request/reply: usado para recibir notificaciones para operaciones

Los switches envan mensajes al controlador a la llegada de un paquete, tras un

Flow-modify: se enva cuando una entrada es aadida a la tabla de flujos de

Port-status: se enva al cambiar el status de un puerto determinado.

Echo request/reply: puede ser enviado indistintamente por el switch o el

Vendor message: proporciona una manera a los switches OpenFlow de