Minimización del consumo de energía en redes SDN bajo restricciones TCAM

ThisworkislicensedunderaCreativeCommons4.0InternationalLicense(CCBY-NC-ND4.0) Minimizaci´ on del consumo de energ´ ıa en redes SDN bajo restricciones TCAM Jaime Gal´ an-Jim´ enez, Javier Berrocal, Marino Linaje, Crist´ obal G´ omez Escuela Polit´ ecnica de C´ aceres Universidad de Extremadura Avda. de la Universidad, S/N, C´ aceres, Espa˜ na {jaime, jberolm, mlinaje, cgomezx}@unex.es Resumen—Tanto la comunidad investigadora como la industria han realizado grandes esfuerzos para proponer soluciones al problema de consumo de energ´ ıa en las redes de comunicaciones. La irrupci´ on del nuevo paradigma de interconexi´ on de redes, denominado SDN (Software-Defined Networking) abre las puertas para proponer nuevas t´ ecnicas que aprovechen el conocimiento global que el controlador SDN posee acerca de la red que gestiona. Sin embargo, los trabajos existentes en este ´ ambito no tienen en cuenta la restricci´ on del tama˜ no limitado que tienen las tablas de flujos de los switches SDN. En este trabajo se propone el algoritmo ETAR (Energy and TCAM-Aware Routing), que minimiza el consumo de energ´ ıadeunaredSDNyasuvezaplica t´ ecnicas de compresi´ on para reducir el n´ umero de reglas instaladas en las tablas de flujos. Los resultados obtenidos sobre topolog´ ıas de red reales indican que es posible conseguir un ahorro de energ´ ıa significativo, respetando a su vez el l´ ımite establecido para el n´ umero m´ aximo de reglas que se pueden instalar. Palabras Clave—Eficiencia energ´ etica, SDN, TCAM, Energy-Aware Routing. I. INTRODUCCI ´ ON Estudios recientes han demostrado que las TIC son responsables del 2% al 10% del consumo total de energ´ ıa el´ ectrica en todo el mundo [1], [2]. De hecho, se estima que el sistema de telecomunicaciones europeo puede llegar a requerir 35,8 TWh en 2020 [3]. Por ello, la atenci´ on sobre el green networking ha ido creciendo en los ´ ultimos a˜ nos [4], [5]. El consumo de energ´ ıa se debe principalmente a elementos activos de los routers IP como el chasis o los puertos, mientras que la carga de tr´ afico tiene una influencia m´ ınima sobre ´ este [6]. Bas´ andose en esta observaci´ on, el enfoque denominado energy-aware routing (EAR) tiene como objetivo reducir al m´ ınimo el n´ umero de elementos de red utilizados, mientras que todas las demandas de tr´ afico se encaminan procurando que ning´ un enlace de la red se sobrecargue de tr´ afico [1], [7]. Precisamente, el apagado o puesta en standby de routers o tarjetas de l´ ınea puede traducirse en un importante ahorro energ´ etico. Sin embargo, no es f´ acil hacerlo desde un punto de vista pr´ actico, ya que, en primer lugar, la acci´ on de encender o apagar routers y tarjetas de l´ ınea necesita de un determinado tiempo de acci´ on que, a la larga, puede traducirse en una reducci´ on en el ciclo de vida de los dispositivos. Por otro lado, la irrupci´ on de las redes SDN (SoftwareDefined Networking) y la utilizaci´ on del protocolo OpenFlow [8] ha permitido a los investigadores proponer nuevas soluciones que permitan reducir el consumo de energ´ ıa de la red aprovechando la filosof´ ıa centralizada de esta aproximaci´ on. En las redes tradicionales, los dispositivos de red tales como switches y routers act´ uan como sistemas cerrados. Los usuarios s´ olo pueden controlarlos a trav´ es de interfaces limitadas y espec´ ıficas del proveedor en cuesti´ on. Por otra parte, la capa de datos y la capa de control est´ an integrados en cada dispositivo, haciendo bastante dif´ ıcil la tarea de implementar nuevos protocolos de red. Por su parte, SDN es un nuevo paradigma de redes que separa la capa de control de la capa de datos. Proporciona flexibilidad para desarrollar y probar nuevos protocolos y pol´ ıticas de red en redes reales. De hecho, muchas aplicaciones se han construido utilizando la API de OpenFlow [8] en los ´ ultimos a˜ nos. Por ejemplo, B4 es uno de los primeros trabajos realizados en este ´ ambito, donde se aplica SDN en la red del data center de Google [9]. B4 ha estado en desarrollo durante tres a˜ nos y durante ese tiempo ha demostrado que puede satisfacer de manera eficiente las demandas tr´ afico, que es compatible con el r´ apido despliegue de nuevos servicios de control de la red y que es robusto frente a posibles fallos. Existen varios trabajos en los que han utilizado OpenFlow para desplegar EAR en una red SDN, pero en la mayor´ ıa de ellos se da por hecho que las tablas de flujos de cada switch tienen un n´ umero infinito de reglas. Sin embargo, en la pr´ actica esta hip´ otesis no es cierta, y el espacio de las tablas para reglas se convierte en un cuello de botella significativo para escalar las redes SDN. Adem´ as, estas tablas de flujos se implementan utilizando memorias TCAM, que son relativamente caras y consumen Actas de las XIV Jornadas de Ingeniería Telemática (JITEL 2019), Zaragoza (España), 22-24 de octubre de 2019. ISBN: 978-84-09-21112-8 Gal´ an-Jim´ enez et al., 2019. Fig. 1. Tabla de flujos llena antes de la compresi´ on. gran cantidad de energ´ ıa. El tama˜ no de estas memorias puede albergar entre cientos y miles de entradas [10]– [12], lo que supone una restricci´ on importante a la hora de implementar soluciones EAR. Una asignaci´ on ineficiente de reglas puede llevar a una soluci´ on de enrutamiento inesperada, causando congesti´ on de la red y afectando a la QoS (Quality of Service). En este trabajo se propone una soluci´ on que no s´ olo tiene en cuenta el ahorro energ´ etico, sino que se considera tambi´ en la limitaci´ on del tama˜ no de las memorias TCAM, asignando rutas de manera eficiente. Para ello, se ha implementado un algoritmo que cumple con todos estos requisitos en un controlador SDN y se han realizado distintos tipos de pruebas sobre topolog´ ıas de red reales con el objetivo de extraer una serie de conclusiones. El resto del art´ ıculo se describe como sigue. El algoritmo propuesto, denominado ETAR (Energy and TCAMAware Routing), junto con su pseudoc´ odigo correspondiente se explica en la Secci´ on 2. Las herramientas utilizadas y el entorno sobre el que se han desarrollado las pruebas se indican en la Secci´ on 3. La Secci´ on 4 describe la metodolog´ ıa de las pruebas realizadas, adem´ as de un an´ alisis de los resultados obtenidos. Finalmente, la Secci´ on 5 presenta una serie de conclusiones extra´ ıdas tras realizar el trabajo presentado. II. ENERGY AND TCAM-AWARE ROUTING El prop´ osito principal de nuestro trabajo es proponer un algoritmo que, teniendo en cuenta el tama˜ no de las memorias TCAM de los switches SDN, sea energ´ eticamente eficiente, es decir, minimice el consumo de energ´ ıa global de la red SDN. A. Pseudoc´ odigo El c´ odigo del algoritmo se puede dividir en dos fases: 1) Parte 1: empezamos a calcular todas las posibles rutas de la red teniendo en cuenta las limitaciones de capacidad de los enlaces y el m´ aximo n´ umero de reglas de las tablas de flujos de los nodos (algoritmos 1, 2 y 3). Para cada router u∈V, tenemos dos colecciones Fu yGuque van a contener flujos normales y flujos por defecto, respectivamente. Cuando la tabla de rutas est´ e llena, trataremos de comprimir la tabla de flujos (Fig. 1 y Fig. 2). La idea de comprimir la tabla, consiste en establecer por defecto el puerto que aparezca en el mayor n´ umero de reglas. Gracias a esto, tendremos un menor n´ umero de reglas instaladas y m´ as espacio disponible para instalar nuevas reglas. 'HIDXOW Fig. 2. Tabla de flujos despu´ es de aplicar la compresi´ on. Un ejemplo de la compresi´ on de una tabla de flujos se puede observar en la Fig. 1 (antes de comprimir) y en la Fig. 2 (despu´ es de comprimir). En este caso, podemos observar que el tama˜ no de la tabla de flujos ser´ ıa de 6 reglas o flujos. Una vez se haya llenado, podemos proceder a comprimirla. Para ello: 1) Buscamos el puerto de salida m´ as usado, el puerto n´ umero 1 en este ejemplo. 2) Borramos todos los flujos que utilicen ese puerto de salida. 3) A˜ nadimos un nuevo flujo por defecto, en el que el puerto de salida se corresponde con el m´ as usado, sacado en el paso 1. As´ ı, ya tendr´ ıamos espacio para instalar nuevos flujos y, a partir de ahora, todas los paquetes que no coincidan con ninguno de las flujos de la tabla, se enviar´ an usando la regla por defecto. 2) Parte 2: en esta fase se intentan borrar los enlaces menos cargados (algoritmo 4). La idea de esto, es apagar los enlaces menos cargados y pasar su tr´ afico a otros enlaces. De esta manera se consigue ahorrar energ´ ıa reduciendo el n´ umero de enlaces activos. Antes de pasar a explicar el pseudoc´ odigo, es conveniente explicar el significado de los s´ ımbolos utilizados: •G=(V,E): grafo no dirigido formado por VyE. •V: conjunto de v´ ertices (en nuestro caso switches). •E: conjunto de enlaces. •Ce: capacidad del enlace e. •Re: capacidad residual del enlace e. •Cu: capacidad de la tabla de flujos del switch u. •u: switch. •D: conjunto de demandas de tr´ afico a enviar. •Dst ∈D: demanda de tr´ afico del nodo sat. •Fu: conjunto de flujos normales instalados en el switch u. •Gu: conjunto de flujos por defecto instalados en el switch u. •G: grafo dirigido. •we: peso del enlace e. •Pst: camino m´ as corto desde shasta t. A continuaci´ on, se va a exponer el pseudoc´ odigo dividido en cuatro partes/algoritmos con su correspondiente explicaci´ on: 1) Algoritmo 1 (Encontrando una ruta factible): este algoritmo recibe c´ omo par´ ametros de entrada un grafo no dirigido compuesto por el conjunto de enlaces y nodos de la red, la capacidad de cada ThisworkislicensedunderaCreativeCommons4.0InternationalLicense(CCBY-NC-ND4.0) Minimizaci´ on del consumo de energ´ ıa en redes SDN bajo restricciones TCAM Algoritmo 1 Encontrando una ruta factible Input: un grafo no dirigido G=(V,E), capacidad del enlace Ce∀e∈E, tama˜ no de la tabla de flujos Cu∀u∈V y una matriz de demandas de tr´ afico D. Output: soluci´ on de direccionamiento sobre el grafo G. 1: Capacidad Residual Re=Ce∀e∈E 2: Inicialmente, Fu=∅yGu=∅∀u∈V 3: Creamos un grafo dirigido G=(V,E)partiendo de G donde ∀(u, v)∈E,a ˜ nadimos ambas direcciones (u, v)y (v,u)aE. El peso inicial del enlace we=1∀e∈E 4: while Dst ∈Dno tiene asignada una ruta do 5: encontramos el camino m´ as corto Pst en Gtal que Re≥Dst ∀e∈Pst 6: asignamos la ruta Pst a la demanda Dst 7: actualizamos Re:= Re−Dst ∀e∈Pst 8: actualizamos el peso de los enlaces en proporci´ on al tama˜ no de |Fu|como en el Algoritmo 2 9: if |Fu|== Cuthen 10: encogemos la tabla de flujos en u∀u∈Pst 11: end if 12: actualizamos FuyGu∀u∈Pst usando el Algoritmo 3 13: end while 14: return soluci´ on de direccionamiento (si existe) asignada a D enlace, el espacio de las tablas de flujos de cada nodo y el conjunto de demandas de tr´ afico a enviar. Para empezar, inicializamos la capacidad residual de cada enlace con el valor de la capacidad que tiene cada uno de ellos, las listas de flujos normales y por defecto de cada nodo est´ an vac´ ıas y creamos un grafo dirigido a partir del grafo no dirigido (a˜ nadiendo los ejes en ambas direcciones), asignando al peso de cada enlace el valor 1. Para cada demanda de tr´ afico, calculamos su ruta mediante el algoritmo del camino m´ ınimo en el grafo dirigido, teniendo en cuenta que la demanda en cuesti´ on no supere la capacidad residual de ninguno de los enlaces que conforman la ruta. Despu´ es, instalamos las reglas necesarias seg´ un la ruta que se acaba de calcular. A continuaci´ on, actualizamos el valor de la capacidad residual de cada uno de los enlaces de la ruta, para ello, le restamos el valor de la demanda al actual valor de la capacidad residual del enlace. Tambi´ en, actualizamos el peso de los enlaces conforme al tama˜ no actual de las tablas de flujos de los nodos como se explica en el Algoritmo 2. Para terminar, si el tama˜ no de la tabla de flujos de los nodos que conforman la ruta calculada es igual al n´ umero m´ aximo de reglas que se pueden instalar en ellos, reducimos el n´ umero de reglas de la tabla del nodo que cumpla esa condici´ on como se indica en el Algoritmo 3. 2) Algoritmo 2 (Actualizando el peso de los enlaces): este algoritmo lleva a cabo el c´ alculo de los pesos de los enlaces. Los par´ ametros de entrada que recibe son un grafo no dirigido formado por el conjunto de nodos y enlaces de la red, la lista de flujos normales (Fu) instalados en los nodos y el valor del n´ umero de flujos que se pueden instalar en el nodo de la red que tenga la mayor capacidad de reglas en su tabla Algoritmo 2 Actualizando el peso de los enlaces Input: un grafo no dirigido G=(V,E), un conjunto de flujos normales Fu∀u∈Vyelm ´ aximo valor de capacidad de las tablas de flujos Cmax =max(Cu)∀u∈ V. Output: pesos de los enlaces de Gajustados. 1: Creamos un grafo dirigido G=(V,E) 2: for (u, v)in Edo 3: calculamos el uso del flujo v:Uv=Cmax ×|Fv|/Cv 4: actualizamos wuv =max(Uv,1) 5: end for Algoritmo 3 Actualizando las listas de flujos normales y por defecto Input: un grafo no dirigido G=(V,E), el camino m´ as corto Pst encontrado en el Algoritmo 1, el conjunto de flujos normales Fuy el conjunto de flujos por defecto Gu∀u∈Pst y el puerto por defecto de cada nodo d(u) ∀u∈Pst. Output: FuyGu∀u∈Vactualizados. 1: for u∈Pst do 2: for v∈G.neighbour(u)do 3: if (u, v)∈Pstand v == d(u)then 4: Gu=Gu∪gst uv 5: else if (u, v)∈Pstand v =d(u)then 6: Fu=Fu∪fst uv 7: end if 8: end for 9: end for de flujos (Cmax). Primero, creamos un grafo dirigido a partir del grafo no dirigido. Para cada enlace (u, v) de ese grafo dirigido, calculamos el peso utilizando la Ec. 1. Para finalizar, actualizamos el valor del peso de los enlaces con el valor m´ aximo entre el peso que hemos calculado y 1. Uv=Cmax ×|Fv|/Cv(1) La idea del c´ alculo de pesos, ser´ ıa conseguir un balanceo de reglas (compartir las reglas) entre los nodos de la red. 3) Algoritmo 3 (Actualizando las listas de flujos normales y por defecto): en este algoritmo se realiza la actualizaci´ on de las listas de flujos normales Fu y la lista de flujos por defecto Gude los nodos que forman parte de la ruta calculada en el Algoritmo 1. Recibe como par´ ametros de entrada un grado dirigido, la ruta calculada, FuyGude todos los nodos de la ruta y el puerto por defecto de cada router que forma parte de la ruta. Simplemente, a˜ nadimos los flujos por defecto instalados a las listas Guy los flujos normales instalados a las listas Fu de los routers. 4) Algoritmo 4 (Eliminando los enlaces menos cargados): en este algoritmo se borran los enlaces de la red menos utilizados tras calcular las rutas para todas las demandas de tr´ afico. Recibe como par´ ametros de entrada un grafo dirigido, adem´ as de la capacidad Ce y la capacidad residual Rede todos los enlaces de la red. Primero calculamos todas las rutas. Despu´ es ThisworkislicensedunderaCreativeCommons4.0InternationalLicense(CCBY-NC-ND4.0) Gal´ an-Jim´ enez et al., 2019. Algoritmo 4 Eliminando los enlaces menos cargados Input: un grafo no dirigido G=(V,E), capacidad del enlace Cey capacidad residual Re∀e∈E Output: soluci´ on de direccionamiento teniendo en cuenta los enlaces activos. 1: while enlaces puedan ser borrados do 2: eliminamos el enlace eque no ha sido ya elegido y tiene el menos valor re=Ce/Re 3: calculamos una ruta factible con el Algoritmo 1 4: if no existe una ruta factible, ponemos eotra vez en G 5: end while 6: return ruta factible (si existe) borramos el enlace que tenga el menor valor dado por la Ec. 2 (el enlace que menos cargado est´ ede tr´ afico) y comprobamos que se puedan calcular todas las rutas sin ese enlace, si no se puede calcular alguna de ellas, volvemos a poner el enlace en el grafo; si s´ ı se pueden calcular todas volvemos a borrar el siguiente enlace con el menor valor dado por la Ec. 2 y calcularemos las rutas, lo repetiremos hasta que al borrar un enlace no se pueda calcular la ruta para alguna de las demandas. re=Ce/Re(2) III. HERRAMIENTAS UTILIZADAS En este apartado se muestran las herramientas utilizadas durante el desarrollo del presente trabajo. Todas ellas se han utilizado en un equipo con las siguientes especificaciones: CPU Intel Core i7-3632QM a 2.20 GHz, memoria RAM de 8GB y Sistema Operativo Ubuntu 16.04. A. OpenDaylight OpenDaylight [13] es el controlador SDN que se ha seleccionado y, por tanto, es el controlador en el que se ha desarrollado la aplicaci´ on que ejecuta el algoritmo ETAR. La versi´ on utilizada es la Hydrogen Base Edition [14], ya que, esta versi´ on del controlador permite instalar en el controlador nuevos paquetes OSGI. Nuestro inter´ es radica en instalar nuevos m´ odulos en el controlador que ejecuten el algoritmo propuesto. B. Mininet Mininet [15] es una herramienta que permite crear una red virtual realista (con kernel, switches y aplicaciones reales) en una sola m´ aquina, en unos segundos y con un solo comando. Se puede interactuar f´ acilmente con la red, personalizarla o implementarla en hardware real, utilizando para ello la consola de comandos CLI de Mininet o la API. Con Mininet simularemos las topolog´ ıas de red, llevaremos a cabo la ejecuci´ on del algoritmo propuesto y enviaremos las demandas de tr´ afico obteniendo estad´ ısticas de la red gracias al uso de la herramienta Iperf. C. Iperf Iperf [16] es una herramienta que permite medir el m´ aximo ancho de banda disponible en una red IP. Soporta la configuraci´ on de diversos par´ ametros relacionados con &RQVWUXLPRVHOSUR\HFWR EXQGOH 0$9(1 23(1'$</,*+7 0,1,1(7 ,QLFLDPRVHOFRQWURODGRU ,QLFLDPRVHOVFULSW S\WKRQFRQODWRSRORJtD \SDUDPRVODHMHFXFLyQ ,QVWDODPRVHOEXQGOHHQ HOFRQWURODGRU 3DUDPRVODHMHFXFLyQGH EXQGOHVFRQIOLFWLYRV (MHFXWDPRVQXHVWUR EXQGOH 5HQDXGDPRVOD HMHFXFLyQHQYLDQGRHO WUiILFRFRUUHVSRQGLHQWH XWLOL]DQGR,3HUI *XDUGDPRVHVWDGtVWLFDV HQIRUPDWR&69 +2-$'(&È/&8/2 7UDWDPRVODVHVWDGtVWLFDV Fig. 3. Metodolog´ ıa de las pruebas. los tiempos, buffers y protocolos (TCP, UDP, SCTP con IPv4 y IPv6). Iperf se utiliza junto a Mininet para enviar la matriz de demandas de tr´ afico y obtener reportes de la red que nos permitan medir el jitter, la p´ erdida de paquetes o el ancho de banda. D. Maven Maven [17] es una herramienta de gesti´ on y comprensi´ on de proyectos de software. Basado en el concepto POM (Project Object Model, es la representaci´ on XML de un proyecto Maven), Maven puede gestionar la construcci´ on de un proyecto, la generaci´ on de informes y la documentaci´ on de un proyecto a partir de una pieza central de la informaci´ on. IV. RESULTADOS EXPERIMENTALES Las pruebas que se han realizado consisten en ejecutar el algoritmo de optimizaci´ on del consumo energ´ etico y tama˜ no de las tablas de flujos en dos topolog´ ıas diferentes, cada una de ellas con una matriz de demandas de tr´ afico y una matriz de capacidades de los enlaces de la red. La metodolog´ ıa llevada a cabo para cada prueba se puede observar en la Fig. 3. En resumen, se debe construir el paquete que incluye el algoritmo, lanzar el controlador e instalar dicho paquete en ´ el. Despu´ es de esto, se carga la topolog´ ıa y se inicia el env´ ıo de tr´ afico entre cada par origen-destino de la red (Fig. 4). Por ´ ultimo, se obtienen los resultados para ser analizados. En la Fig.4 se muestra el env´ ıo de tr´ afico con IPerf. Para empezar, contamos con una matriz de tr´ afico para la topolog´ ıa en cuesti´ on, de la que el controlador tiene conocimiento y que transformamos en directivas de env´ ıo de tr´ afico Iperf. Para terminar, ejecutamos esas directivas y se produce el env´ ıo de tr´ afico en la topolog´ ıa. A. Topolog´ ıas Como se ha mencionado anteriormente, se han utilizado dos topolog´ ıas para poder probar el algoritmo implementado: Abilene y Nobel-Germany. Ambas topolog´ ıas se han extra´ ıdo de la librer´ ıa SNDLib [18]. En la Tabla I se muestra una comparativa entre ambas. ThisworkislicensedunderaCreativeCommons4.0InternationalLicense(CCBY-NC-ND4.0) Minimizaci´ on del consumo de energ´ ıa en redes SDN bajo restricciones TCAM 0DWUL]GH7UiILFR &RQWURODGRU 6'1 7RSRORJtD Fig. 4. Env´ ıo de tr´ afico usando IPerf. Tabla I COMPARATIVA TOPOLOG´ IAS USADAS. Topolog´ ıa Nodos Enlaces Abilene 12 15 Nobel−Germany 17 26 B. An´ alisis de Resultados Antes de pasar a ver y analizar las gr´ aficas de los resultados obtenidos, se define un nuevo par´ ametro, α, que hace referencia al n´ umero m´ aximo de reglas que pueden instalarse en las tablas de flujos de los nodos de la red (Ec. 3), siendo del n´ umero total de demandas de tr´ afico que se van a enviar en la red. Por ejemplo, si α=0.1, quiere decir que en dicha prueba el n´ umero m´ aximo de reglas que se pueden instalar es igual al 10% del n´ umero total de demandas que se van a enviar en la red (132 en Abilene y 272 en Nobel-Germany). Cu=(α∗d)(3) Entre los resultados obtenidos se encuentran aqu´ ellos que proporciona iPerf directamente: jitter, paquetes perdidos y paquetes out of order. Por otro lado, se ha calculado el tiempo de c´ omputo requerido para ejecutar el algoritmo, as´ ı como el ahorro de energ´ ıa obtenido y el n´ umero de reglas instaladas en las tablas de flujos de los switches SDN. Para cada par´ ametro analizado se proporciona una explicaci´ on basada en los resultados mostrados en las siguientes gr´ aficas. 1) Porcentaje de Paquetes Perdidos: La Fig. 5 muestra el porcentaje de paquetes perdidos en funci´ on de αpara las dos topolog´ ıas consideradas. En ella, se puede observar que ETAR obtiene mejores resultados para Abilene que para Nobel y que, en general, se trata de un valor bajo de paquetes perdidos. De hecho, el porcentaje de paquetes perdidos en Nobel no llega a superar nunca el 12% y los picos m´ as altos los obtiene para α=0.3yα=0.6.Es en este valor de α=0.6donde Abilene presenta su valor pico, aunque no llega a sobrepasar el 10%. 2) Jitter Medio: La Fig. 6 muestra el valor de jitter medio en funci´ on de αpara las dos topolog´ ıas consideradas. En general, se puede observar que se obtienen valores bajos en t´ erminos de jitter, inferiores a 0.5segundos en la mayor´ ıa de los casos, y que son similares para ambas topolog´ ıas. 3) Porcentaje de Paquetes Out of Order: La Fig. 7 muestra el porcentaje de paquetes out of order en funci´ on de αpara las dos topolog´ ıas consideradas. El valor obtenido para la topolog´ ıa Abilene ronda entre el 3% Fig. 5. Porcentaje de Paquetes Perdidos. Fig. 6. Jitter Medio. y el 8% de paquetes, mientras que para Nobel es algo superior, entre el 3% y el 11%. En ambos casos, los valores m´ aximos se obtienen para α=0.4. 4) N´ umero de Reglas Instaladas: La Fig. 8 muestra el porcentaje de reglas instaladas en el nodo m´ as cargado de la red en funci´ on de αpara las dos topolog´ ıas consideradas. En α=0,eln ´ umero (y por ende el porcentaje) de reglas instaladas es 0, ya que, el n´ umero m´ aximo de reglas que se pueden instalar es Cu=0. Para valores de α<0.5, el porcentaje de reglas instaladas es creciente. Sin embargo, para 0.5≤α≤1,eln ´ umero de reglas instaladas se mantiene durante todo el intervalo. Esto es debido a que a partir de α=0.5el n´ umero m´ aximo de reglas instaladas no llega a superar el l´ ımite establecido, por tanto, aunque sigamos aumentando el l´ ımite, las reglas se van a instalar de la misma manera en todas las pruebas. Adem´ as, aunque los valores obtenidos son similares para ambas topolog´ ıas, se realiza una compresi´ on de las tablas de flujos m´ as eficiente en Nobel que en Abilene para el rango 0.5≤α≤1. 5) Tiempo de C´ omputo: En la Tabla II se puede observar que el tama˜ no de la red influye en gran manera en el tiempo de c´ omputo requerido para ejecutar ETAR. De hecho, se tarda casi el qu´ ıntuple de tiempo en ejecutar el algoritmo en la topolog´ ıa Nobel-Germany con respecto a la topolog´ ıa Abilene (5 nodos y 11 enlaces de diferencia, Tabla I). 6) Ahorro de Energ´ ıa: En la Tabla III se muestra el ahorro de energ´ ıa obtenido por el algoritmo propuesto para las dos topolog´ ıas consideradas. Teniendo en cuenta ThisworkislicensedunderaCreativeCommons4.0InternationalLicense(CCBY-NC-ND4.0) Gal´ an-Jim´ enez et al., 2019. Fig. 7. Porcentaje de Paquetes Out of Order. Fig. 8. Porcentaje del n´ umero de reglas instaladas. el tr´ afico correspondiente a la matriz de tr´ afico utilizada, es posible conseguir un 11.5% de ahorro para la topolog´ ıa Nobel-Germany, mientras que para Abilene se consigue un mayor ahorro de energ´ ıa, en concreto un 20%. V. CONCLUSIONES Este trabajo estudia el problema de consumo de energ´ ıa en redes SDN. Aunque existen varios trabajos que tratan de dar soluci´ on aprovechando la filosof´ ıa centralizada de este nuevo paradigma, en ning´ un caso se tiene en cuenta la restricci´ on del tama˜ no limitado de las tablas de flujo de los switches SDN (memorias TCAM). Por ello, en este trabajo se propone el algoritmo ETAR (Energy and TCAMAware Routing), que minimiza el consumo de energ´ ıa de una red SDN y aplica t´ ecnicas de compresi´ on para reducir el n´ umero de reglas instaladas en las tablas de flujos. Los resultados obtenidos sobre topolog´ ıas de red reales indican que es posible conseguir un ahorro de energ´ ıa significativo, respetando a su vez el l´ ımite establecido en el n´ umero m´ aximo de reglas que se pueden instalar. AGRADECIMIENTOS Este trabajo ha sido financiado, en parte, por los proyectos 4IE (0045-4IE-4-P) y 4IE+ (0499 4IE PLUS 4 E) financiados por el programa Interreg V-A Espa˜ na-Portugal (POCTEP) 2014-2020, por el Ministerio de Ciencia, Innovaci´ on y Universidades (RTI2018-094591-B-I00), por la Consejer´ ıa de Econom´ ıa e Infraestructuras de la Junta de Extremadura (IB18030, GR18112) y por el Fondo Europeo de Desarrollo Regional (FEDER). Tabla II TIEMPO DE C´ OMPUTO Topolog´ ıa Tiempo C´ omputo Medio (ms) Abilene 2418 Nobel −Germany 10857 Tabla III AHORRO ENERG´ ETICO Topolog´ ıa Enlaces Enlaces Eliminados % Ahorro Abilene 15 3 20% Nobel −Germany 26 3 11.5% REFERENCIAS [1] L. Chiaraviglio, M. Mellia, F. Neri, ”Minimizing ISP Network Energy Cost: Formulation and Solutions”, IEEE/ACM Transaction in Networking 20 (2011) 463 - 476. [2] Global Action Plan. http://globalactionplan.org.uk. ´ Ultimo acceso: 15/09/2019. [3] R. Bolla, F. Davoli, R. Bruschi, K. Christensen, F. Cucchietti, S. Singh, ”The Potential Impact of Green Technologies in Nextgeneration Wireline Networks: Is There Room for Energy Saving Optimization?”, IEEE Communications Magazine 49 (2011) 80 - 86. [4] A. P. Bianzino, C. Chaudet, D. Rossi, J. Rougier, ”A Survey of Green Networking Research”, IEEE Communication Surveys and Tutorials 14 (2012)3-20. [5] R. Bolla, R. Bruschi, F. Davoli, F. Cucchietti, ”Energy Efficiency in the Future Internet: A Survey of Existing Approaches and Trends in Energy-Aware Fixed Network Infrastructures”, IEEE Communication Surveys and Tutorials 13 (2011) 223 - 244. [6] P. Mahadevan, P. Sharma, S. Banerjee, ”A Power Benchmarking Framework for Network Devices”, en la International Conferences on Networking (IFIP NETWORKING), 2009, pp. 795 - 808. [7] M. Gupta, S. Singh, ”Greening of the Internet”, en la ACM Special Interest Group on Data Communication (SIGCOMM), 2003, pp. 19 - 26. [8] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, J. Turner, ”Openflow: Enabling Innovation in Campus Networks”, ACM Computer Communication Review 38 (2008) 69 - 74. [9] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Holzle, S. Stuart, A. Vahdat, ”B4: Experience with a GloballyDeployed Software Defined WAN”, en la ACM Special Interest Group on Data Communication (SIGCOMM), 2013. [10] N. Kang, Z. Liu, J. Rexford, D. Walker, ”Optimizing the ”One Big Switch” Abstraction in Software-Defined Networks”, en la ACM Conference on Emerging Networking Experiments and Technologies (CoNEXT), 2013. [11] Y. Kanizo, D. Hay, I. Keslassy, ”Palette: Distributing Tables in Softwaredefined Networks”, en la IEEE INFOCOM Mini-conference, 2013. [12] B. Stephens, A. Cox, W. Felter, C. Dixon, J. Carter, ”PAST: Scalable Ethernet for Data Centers”, en la ACM Conference on Emerging Networking Experiments and Technologies (CoNEXT), 2012. [13] OpenDaylight Controller. https://www.opendaylight.org/. ´ Ultimo acceso: 15/09/2019. [14] Downloads OpenDaylight. https://www.opendaylight.org/downloads. ´ Ultimo acceso: 15/09/2019. [15] Mininet An Instan Virtual Network on your Laptop (or other PC) http://mininet.org/. ´ Ultimo acceso: 15/09/2019. [16] iPerf the TCP, UDP and SCTP network bandwith measurement tool. https://iperf.fr/. ´ Ultimo acceso: 15/09/2019. [17] Apache Maven Project. https://maven.apache.org/. ´ Ultimo acceso: 15/09/2019. [18] SNDlib. http://sndlib.zib.de/. ´ Ultimo acceso: 15/09/2019. ThisworkislicensedunderaCreativeCommons4.0InternationalLicense(CCBY-NC-ND4.0)