Cuando se diseñó Internet cuatro décadas atrás, si por un problema un paquete de datos no podía pasar por algún punto de la Red, se desviaba por otro hasta que diera con un camino que le permitiera seguir. Los pequeños e-mails difícilmente colapsaban la Red y eran pocos los problemas que surgían. Pero hoy, los grandes camiones con sus tráilers en forma de vídeos en streaming circulan por todas partes y han dejado anticuada esta organización.
Anticipación. Foto cortesía de Michael Patrick
Cuando hay cortes en algún punto del recorrido de un camión, lo más eficiente sería informar al conductor cuanto antes e indicarle la mejor alternativa posible. Se ahorraría combustible y se descongestionaría el tráfico al impedir que se encuentre el problema e improvise otro itinerario en el momento. La manera como esto comienza a aplicarse en la redes, tanto en las pequeñas (por ejemplo, de empresas) como en las grandes (que conforman Internet), se llama Software Defined Networks (SDN, redes definidas por software).
LAS SOFTWARE DEFINED NETWORKS (SDN)
Como quizás su nombre sugiere, las SDN son redes gestionadas remotamente y de forma centralizada por un programa informático. Un software que genera un mapa esquematico de la red y sobre el que puede controlarse el tráfico. En las redes actuales, si por ejemplo queremos cambiar la manera como un dispositivo (un router, o un switch) gestiona cierto tráfico, debe intervenirse físicamente sobre él, manualmente. Como un guardia que acude a cambiar una señal de tráfico, en lugar de que ésta se actualice a distancia. Con las SDN, no es necesario y pueden cambiarse las señales desde un control centralizado, lo que agiliza y optimiza el tráfico.
Para que el programa informático y los dispositivos de la red puedan comunicarse deben compartir un lenguaje común, un protocolo. El que más éxito ha tenido por el momento es el protocolo OpenFlow, que se creó en el 2008 tras una investigación de seis años de un equipo de la Universidad de Stanford al que pronto se unió otro grupo de la de Berkeley.
EL OPENFLOW
La idea original surgió de un proyecto de doctorado de Martín Casado. El objetivo era que un investigador pudiera experimentar fácilmente con una parte de la red de la universidad sin que afectara al funcionamiento normal de la misma. La primera definición del protocolo se publicó en el 2008.
Arquitectura de una red SDN. Fuente: OpenFlow White Paper (PDF)
Las potencialidades de este protocolo llamaron la atención de las empresas, que lo respaldaron al crear en el 2011 la OpenFlow Foundation (ONF), que ahora cuenta con más de 60 miembros. También un grupo de investigación con las universidades. El objetivo de la ONF es extender el uso de este protocolo y las redes SDN. Hay dos operadores entre las siete empresas de la junta directiva: Verizon y Deustche Telekom. Como simples miembros también figuran: Orange, Telecom Italia y las coreanas SK Telecom y KT. El presidente de la ONF es Urs Hölzle, vicepresidente senior de Infraestructura Técnica de Google y uno de los primeros diez empleados del buscador.
LA RED DE GOOGLE
Google es uno de los nombres claves de la historia. Hasta hace no mucho las SDN eran un proyecto interesante pero con poco desarrollo real. Sin embargo, el pasado 17 de abril, Urs Hözle anunció que Google había implementado el OpenFlow en toda su red interna, uno de los mayores impulsos a las SDN y el OpenFlow hasta el momento. El anuncio del directivo fue en el encuentro Open Networking Summit 2012, que tuvo lugar en la californiana ciudad de Santa Clara, en pleno centro de Silicon Valley.
Urs Hözle, de Google, en el Open Networking Summit 2012. Fuente: YouTube/OpenNetSummit
Hözle contó que cuando en el 2010 comenzaron a convertir la red de Google a la SDN no existían equipos preparados para ello, por lo que tuvieron que construirlos. Empezaron a implementarlo en la red interna, la que llaman G-Scale Network, que comunica entre ellos los datacenters de todo el mundo, y no se relaciona directamente con el usuario (para evitarle problemas). Se hizo en paralelo a la red convencional. Funcionó bien y a principios de este año toda la red interna de Google ya utilizaba OpenFlow.
La red interna de Google (Wide Area Network), gestionada con OpenFlow. Fuente: Google
Hözle destacó que el OpenFlow les permite ajustar la red según las necesidades de cada momento, según el tipo de tráfico o la hora del día, algo que que antes resultaba difícil al tener que reconfigurar los dispositivos manualmente. Por ejemplo, pueden priorizar unos servicios sobre otros (el tráfico de GMail sobre el de YouTube) o elegir los servidores adecuados para unas tareas concretas. Subrayó especialmente la posibilidad de ensayar falllos para responder más rápido a los problemas que pudieran surgir. De momento, con el OpenFlow han conseguido reducir el coste de la red en un 8%. Esperan mejorar los resultados al encontrarse aún en una primera fase, pero de momento su valoración es que la red es estable y ha cumplido con sus expectativas.
OTRAS POSIBILIDADES
Las aplicaciones del OpenFlow son variadas y ambiciosas. En el artículo original del 2008 se menciona posibilidad de un usuario que se conecta simultáneamente a diferentes puntos WiFi vecinos a medida que se mueve y mientras reproduce un flujo continuo de datos, muy sensible a los cortes de conexión. Conociendo las posiciones del usuario, un sistema basado en OpenFlow se encargaría de gestionar las conexiones y el tráfico de tal modo que no se produjeran en ningún momento cortes en el flujo mientras se conecta a los distintos puntos. Esto puede ser útil en servicios sensibles como las llamdas VoIP o el vídeo en streaming.
En el artículo también se apunta a una Red sin direcciones IP, el identificador básico de Internet. Podrían utilizarse las direcciones MAC (la matrícula que los fabricantes acuñan en cada uno de sus dispositivos de redes) o identificadores nuevos. Como hemos comentado, la idea inicial del OpenFlow era modificar la pequeña intranet de una facultad, pero acabará cambiando la manera como nos movemos en en Internet y puede que hasta como nos llamamos en ella.
Me temo que no es que quieran cambiar el código de circulación, sino que más bien lo que quieren es cambiar las autovías de libre acceso por autopistas de pago, acabando definitivamente con la neutralidad de la red.
Suscribo lo que dice Lauren Weinstein sobre este tema:
«While the stated possible positives of such technology are real enough, the same mechanisms could be used to impose exactly the sorts of walled gardens, service degradations, and ‘pay to play’ limits that are at the heart of Net Neutrality concerns, as dominant ISPs in particular would be tempted to leverage this technology to further restrict user applications to the benefit of their own profit centers,»
Más o menos: «Mientras que los aspectos positivos de esta tecnología están suficientemente claros, esos mismos mecanismos pueden utilizarse para traspasar los límites que están en el núcleo de la Neutralidad de la Red, imponiendo el jardín vallado, la degradación del servicio y el «pago por jugar», pues los ISP dominantes se verán tentados en utilizar esta tecnología para restringir en el futuro las aplicaciones del usuario con vistas a mejorar sus propios beneficios».
Cogido de: http://www.informationweek.com/news/infrastructure/management/229400191
Un saludo.
Buena analogía.
Gracias por animar el debate, José.
Es cierto que una mala utilización del OpenFlow podría amenazar la neutralidad de la Red. De hecho, en la entrada enlazaba a un artículo de IP Carrier donde se habla de esta posibilidad. Igualmente, ahora he añadido al texto una frase que explicita esta amenaza y la he enlazado con el comentario de Lauren Weinstein en NNSquad que citan en InformationWeek.
De todas maneras, hay que tener en cuenta que el OpenFlow puede ya conseguir una mejora en la gestión del tráfico incluso sin mirar el contenido. Por ejemplo, al indicar a un paquete (sin importar de qué tipo sea) cuál es el mejor camino en lugar de esperar a que éste lo encuentre él mismo a fuerza de prueba y error cuando hay un problema.
La gestión por contenido puede ser también buena. Por ejemplo, en el caso que comenta Hözle, puede evitarse que el vídeo en streaming ralentice la circulación de correos electrónicos. El peligo está en que esto lo utilicen los proveedor para priorizar sus propios servicios (o de alguna manera que ponga en riesgo la neutralidad). En tal caso, me remito a la opinión de Weinstein en NNSquad:
Un saludo y gracias por vuestos enriquecedores comentarios.
La verdad llamarse OpenFlow y que puede hacerse precisamente para lo contrario como bien expone el compañero José G. Arribas en su comentario, es irónico.
De la misma forma que cuando ves un programa privativo que pone «Free», y no es que sea Freeware sino que es «Free» durante 30 días. Es el uso del idioma para atraer a la gente, algo muy típico de la publicidad y que acaba trayendo problemas (como bien saben en la OCU, FACUA o AUTOCONTROL, entre otras)
Siempre digo que en España se sigue la ley del mínimo esfuerzo y máximo beneficio. Pero lo cierto es que es así en todo el Mundo. Dejando del lado temas como la censura política o censura por defender intereses privados (principalmente el copyright). Tenemos que los operadores si controlan el tráfico, quitando de un lado y poniendo de otro, no tienen que invertir tanto. Pero esa falta de inversión pasa factura a los clientes, en este caso a los internautas. Bien en pérdidas de velocidad, malas comunicaciones de voz, cortes,…
Y por otro lado que pretenden invertir, casi lo mismo teniendo 10 millones de clientes que teniendo 100 millones. Y lo normal, es que si se hace esto, existan problemas de saturación.
Salu2
[…] "CRITEO-300×250", 300, 250); 1 meneos Un nuevo código de circulación para internet blogcmt.com/2012/06/22/un-nuevo-codigo-de-circulacion-par… por Jorge_Negro_deSaliceta […]
Control centralizado, priorizar un servicio sobre otro, suena a censura y falta de respeto por la neutralidad de la red.
Para una intranet tiene sentido pero para el conjunto de internet ni de broma.
Mas inversión en infraestructura y menos llantos por no ganar tantos millones es lo que hace falta…
Hola Legion.
Como he comentado antes, no tiene por qué significar necesariamente censura. Puede quedarse en eficiencia. Y una mejora en la eficiencia equivale a, además de mayor fluidez, un ahorro en el coste energético (y por tanto, ambiental) de las redes.
Un saludo.
Un dato importante que no comentasteis de la red interna de Google es que con Open Flow se han acercado mucho a tener un 100% de utilización efectiva de toda la red. El tema es que migrar su red interna ha tenido un coste muy elevado según ellos mismos han declarado. Supongo que la reducción del 8% en costes será en mantenimiento de red ¿no? porque si se tiene en cuenta la inversión inicial el coste es bastante elevado. Estas mejoras a la hora de operar la red sin duda son importantes pero no sé hasta que punto se trasladarán al usuario final o se quedarán en mejorar los márgenes de beneficio de las operadoras y permitir «seguir tirando» más años con la misma infraestructura mejor operada.
Hola Manchitas84.
Aunque no lo comenté, es un dato muy significativo, sí.
Si se queda en la red interna de Google, obviamente el usuario final poco notará. Sí, en cambio, si se implementa en las redes que se relacionan directamente con el usuario. El tráfico será -en teoría- más fluido, sobre todo en los momentos en los que la Red esté más cargada. De todas maneras, creo que la eficiencia energética y ambiental es por sí sola relevante, más allá de si afecta directamente al usuario o no.
Un saludo!
IMHO:
1.- Se confunde las SDN con Openflow y no son sinónimos.
2.- La tecnología sirve para hacer cosas. Si son correctas o no son temas éticos y no tecnológicos. Sirve para cortar la libertad de expresión y para proteger a los niños de los pederastas.
3.- La tecnología SDN ya se ha intentado desde 1996 y ha ido dando ciertos pasitos como por ejemplo FORCES o PCE.
4.- SDN fomenta un control centralizado introduciendo competencia en el mercado frente a los planos de control propietarios de los fabricantes.
5.- Hace que el hardware se especialice en enviar paquetes. Pudiéndose hacer mas barato.
6.- No hace DPI.
7.- La diferenciación de tráfico basado en las cabeceras de los paquetes L2, L3, L4 ya sucede en las redes. Por ejemplo prefieres que el skype funcione bien priorizándolo sobre otros tráficos.
8.- Openflow es un protocolo que debe interpretarse como un «juego de instrucciones» similar a lo que es «x86» en los microprocesadores.
Hola IMHO.
Gracias por tu comentario, muy aclarador.
Sobre la diferencia entre SDN y OpenFlow, he intentado que se entendiera así en el texto. No sé si con éxito.
Te hago una pregunta. Dices que el OpenFlow no hace DPI. ¿Cómo sabe entonces Google que un paquete corresponde a YouTube o a GMail? En este folleto anuncian un switch con OpenFlow con el que puede hacerse DPI.
Un saludo.