Anlisis del estado de Border Gateway Protocol (BGP)

Ana Mara Ospina Bolaos, IEEE Member

Facultad de Ingeniera Informtica y Telecomunicaciones Universidad Pontificia Bolivariana Medelln, Colombia ana.ospina@upb.edu.co

Jackson Reina Alzate, IEEE Member, ACM Member

Facultad de Ingeniera Informtica y Telecomunicaciones Universidad Pontificia Bolivariana Medelln, Colombia jackson.reina@upb.edu.co

ResumenEn este artculo se presentan las caractersticas ms importantes de BGP (Border Gateway Protocol), su operacin, tipos de bases de datos, mensajes y timers. Tambin se describen los principales problemas que se han presentado luego de su implementacin, como el crecimiento de las tablas de enrutamiento, baja escalabilidad, inestabilidad (oscilacin de rutas) y congestin. Adems, se mencionan algunas de las soluciones que se han propuesto a cada uno de ellos, como agregacin de rutas y comunidades, reflectores de ruta y confederaciones, Route Flap y Route Flap Damping, y el balanceo de carga de trfico. Se verifica el impacto del empleo de BGP sobre las redes de los ms importantes ISPs de Colombia mediante el anlisis de resultados de una encuesta y, finalmente, se presentan conclusiones. Aunque en los ltimos aos los investigadores, fabricantes y operadores han propuesto algunas estrategias diversas de solucin que an no han sido implementadas debido a retrasos en los procesos de estandarizacin. Los temas sugeridos para realizar futuros desarrollos relacionados con BGP son sistemas multihomed, balanceo de carga, e ingeniera de trfico aplicada a la calidad de servicio. Palabras clave-BGP; enrutamiento; internet; mulithomed; trfico.

caracterizan a las diferentes conexiones existentes entre los nodos terminales, debe determinar cul es el mejor camino que deben seguir los paquetes de informacin que se intercambian entre ASs (Autonomous System). Para cumplir con este objetivo BGP define elementos caractersticos como tipos de routers, bases de datos, atributos, mensajes y timers que son fundamentales para su buen funcionamiento. En este artculo se realiza una revisin de las condiciones actuales de BGP, as como los problemas y soluciones que han sido planteados en los ltimos aos y cmo esto ha afectado a los ISPs colombianos.. En la siguiente seccin se realiza una descripcin general sobre Internet y BGP, y en la seccin III se definen los principales problemas que ha presentado BGP al ser implementado, y algunas soluciones propuestas. En el numeral IV se describen algunos RFC (Request For Comments) complementarios. El anlisis de resultados de una encuesta aplicada a varios proveedores de Internet en Colombia se muestra en el numeral V, y finalmente, en la seccin VI se presentan algunas conclusiones sobre los temas tratados. II. BORDER GATEWAY PROTOCOL (BGP)

I.

INTRODUCCIN

Internet esta conformado por millones de redes de carcter privado, pblico, investigativo, acadmico, econmico, social y gubernamental que comparten recursos y servicios. La rpida evolucin y crecimiento de estas redes, principalmente se debe a los cambios permanentes de las necesidades de los usuarios. Entre sus requerimientos se deben considerar conexiones con altas capacidades, enlaces continuos, soporte de diferentes tipos de trfico (audio, datos, video), altos niveles de seguridad, privacidad, y adecuados niveles de calidad de servicio. Actualmente el nico protocolo utilizado en Internet para realizar el intercambio de informacin entre los ISPs (Internet Services Provider) es conocido como BGP (Border Gateway Protocol). BGP es el protocolo externo que teniendo en cuenta no slo las relaciones econmicas, sociales y tcnicas que se establecen entre ISPs y que definen la poltica de enrutamiento propia de cada uno, sino tambin basado en los atributos que

La estructura jerrquica de Internet esta conformada por varios elementos, ubicado en el nivel ms bajo el primero de ellos es el cliente o usuario (generalmente organizaciones), se caracteriza principalmente por tener una direccin IP, el cliente debe estar conectado a un proveedor local o ISP para asegurar su conectividad a la red, y de esta manera poder enviar y recibir datos o informacin a otros usuarios. Los ISP pueden clasificarse en varias categoras, cada Tier ISP tiene como objetivos principales, concentrar el trfico para alcanzar cada vez mayores velocidades al aumentar de nivel, mejor aprovechamiento del ancho de banda y generar el menor retardo posible [1]. La divisin de los ISPs en varias categoras esta directamente relacionada con el rea geogrfica que cubren, es decir, nivel internacional, nivel regional o nivel local. El Tier 1es la primera categora en donde se encuentra el ISP con mayor jerarqua. Los Tier 1 cuentan con su propio ASN (AS

Number) y se diferencian de los dems tipos debido a que contiene las redes de una regin geogrfica amplia, que puede extenderse a varios pases (nivel internacional). Esta red es conocida generalmente como el backbone de Internet, en donde se pueden alcanzar velocidades muy altas, del nivel de los Gbps. Es necesario que varios Tier de tipo 1 se conecten para asegurar el intercambio de trfico entre regiones, para realizarlo se cuenta con dos alternativas para realizar la interconexin. La primera de ellas consiste en agrupar a los Tier 1 en un NAP (Network Access Point) o tambin conocido como IXP (Internet Exchange Point), EP (Exchange Point) o MAE (Metropolitan Area Exchanges). Un NAP es un punto neutral y pblico que cuenta con polticas bien definidas para el establecimiento de conexiones y relaciones de intercambio de trfico, sin costo entre varios ASs. La segunda opcin se basa en una conexin privada que enlaza directamente a dos Tier 1, mediante el establecimiento de un acuerdo entre ambos entes, algunas veces este tipo de enlace es utilizado generalmente como backup [2], [4], [10]. Los Tier 1 prestan el servicio de conectividad a los Tier 2, es decir, los de tipo 1 ofrecen el servicio de trnsito o de trfico a varios de tipo 2 que tienen una cobertura regional o nacional (reas reducidas) y stos a su vez se conectan en los POP(Point of Presence). Los Tier 3 son ISP que establecen relaciones de tipo privado, es decir, no les prestan conectividad a los usuarios y requieren los servicios de trfico prestados por los Tier 2 o Tier 1. Finalmente la ltima categora son los Tier 4, que tienen conexin directa con los Tier 3. Los ISPs de tipo 4 se encargan de proveer el acceso local hacia Internet de sus diferentes clientes, que pueden ser organizaciones, empresas, instituciones, centros de educacin y usuarios residenciales [2], [4]. BGP es el protocolo utilizado por los ISPs para realizar el intercambio de informacin con otros proveedores de mayor jerarqua, con sus pares, y con los usuarios. BGP est clasificado dentro de los EGPs (Exterior Gateway Protocol) porque su objeto es permitir el enrutamiento entre ASs, que a su vez conforman lo que se conoce como Internet. Los ASs son grupos de routers que se encuentran bajo una administracin que define algunas polticas especficas. Estos lineamientos permiten crear relaciones entre dominios basados en necesidades econmicas, sociales y tcnicas para garantizar el establecimiento de sesiones entre peers [2]. Los elementos que hacen parte de un AS tambin deben intercambiar informacin, tanto de usuario como inherentes a su funcionamiento por medio de un lenguaje comn establecido mediante un IGP (Interior Gateway Protocol). Los protocolos de enrutamiento interno ms conocidos son: RIP v1 y RIP v2 (Routing Information Protocol), OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System), IGRP (Interior Gateway Routing Protocol) y EIGRP (Enhanced Interior Gateway Routing Protocol) [2], [3], [4], [5], [6], [7], [8]. Los protocolos de enrutamiento, ya sean internos o externos, pueden clasificarse en tres modelos de enrutamiento:

vector distancia (distance vector), estado de enlace (link state) y vector trayectoria (path vector) que definen aspectos como, qu tipo de informacin se intercambia, de que fuente se obtiene, cmo se transmiten las actualizaciones, cmo se reacciona frente a un cambio y los algoritmos empleados para calcular el mejor camino. Estos modelos utilizan algoritmos como el Bellman-Ford y/o el Dijkstra, que les permiten calcular los trayectos que se almacenan dentro de la tabla de enrutamiento [2], [3], [4], [5], [9], [10]. A. Historia de BGP BGP tiene sus orgenes en los aos 80s. Los cambios, adiciones y complementos que se le han realizado han sido publicados a partir de su aceptacin como el nico estndar de enrutamiento externo, los RFC que han especificado el estndar para Internet de BGP son: RFC 1105: primera versin definida originalmente en 1989, en el cual se establecan relaciones entre routers hacia arriba, abajo y horizontales, que eran configuradas de forma manual. RFC 1163: conocida como la versin dos de BGP, super las limitaciones presentes en la versin uno y adicionalmente realiz algunos cambios en el formato de los mensajes. RFC 1267: conocido tambin como BGP-3, defini el establecimiento de sesiones entre routers. RFC 1654: define la primera publicacin sobre el protocolo actual, data del ao 1994. RFC 4271: fue definida en el ao 2006, reemplaz al RFC 1771 del ao 1995, es la ltima versin que se adopto como estndar BGP-4. Otros RFCs relacionados con algunos temas relacionados con el funcionamiento de BGP son: RFC 4632: publicado en agosto de 2006, trata el tema de la agregacin CIDR (Classless Inter-Domain Routing), para reducir el tamao de las tablas de enrutamiento, y las superredes. Reemplaz al RFC 1519. En este RFC se elimina el concepto de clases y se define el de grupos o destinos determinados por un prefijo IP. RFC 4893: donde se define el concepto de ASN, publicado en mayo de 2007 [2], [3], [5], [6], [11]. B. Caractersticas de BGP BGP se considera un protocolo escalable (maneja una estructura jerrquica que se puede alcanzar por medio de la utilizacin de atributos), robusto y estable, que se caracteriza por evitar loops. Se basa en el esquema de enrutamiento de path vector. Un AS construye un grafo (rbol) de los diferentes sistemas a los que est conectado teniendo en cuenta la informacin de enrutamiento aprendida de los routers vecinos con los cuales pueda establecer comunicacin de acuerdo a sus polticas o criterios [2], [4], [5], [10], [12], [13].

C. Operacin de BGP BGP establece una sesin TCP (Transport Control Protocol) para crear una ruta de acceso entre ASs. La tabla de enrutamiento incluye el mejor trayecto y, adicionalmente, ms de un camino alternativo para un destino. Una de las caractersticas ms importantes es que slo se enva la actualizacin utilizando el BGP route redistribution, que bsicamente consiste en el anuncio inmediato de rutas nuevas al presentarse un cambio, sin enviar la actualizacin al mismo router por el que se recibi la informacin. El aprendizaje de rutas puede realizarse de dos formas: dinmica o estticamente. El caso dinmico ocurre cuando el conocimiento de un trayecto se logra mediante el intercambio de informacin con otros routers, mientras que el esttico se refiere a los caminos que son establecidos o definidos por el administrador de la red. Para permitir la comunicacin entre routers BGP es necesario intercambiar informacin de enrutamiento como la direccin IP (Internet Protocol) y el ASN al cual pertenece el router, que son los parmetros que especficamente caracterizan a cada uno de los nodos que se encuentran dentro de la red. Con esta informacin se alimentan las tres bases de datos o RIBs (Routing Information Base) manejadas dentro de BGP: Adjacent-RIB-In, Loc-RIB, y Adjacent-RIB-Out. Posteriormente, es posible contar con la informacin de atributos de los diferentes nodos (mtrica) y, finalmente, determinar las mejores rutas hacia los diferentes destinos aplicando el algoritmo de best path de forma independiente en cada AS. La mtrica de cada uno de los posibles trayectos de salida se pueden clasificar en cuatro grupos: Well-known mandatory, Well-known discretionary, Optional Transitive, Optional Nontransitive [2], [5], [6], [10]. D. Tipos de routers en BGP Existe una clasificacin para los routers que hacen parte de un AS. Esta diferenciacin se basa directamente en las funciones que cada uno puede cumplir dentro de la red en cualquier momento. De esta manera se pueden agrupar routers en tres tipos: Speakers, Border Gateways y Peers. Speakers: son todos los routers que hacen parte de un AS (todos los que hablen BGP). El administrador de la red establece el ASN al cual pertenece cada uno de ellos, y a su vez asocia cada una de las direcciones IP dentro del AS al que pertenece el router [6], [13]. Border Gateways: comunican dos o ms ASs que se encuentren en Internet, y es posible que dentro de un AS se cuente con ms de un Border Gateway. Su funcin bsica consiste en anunciar a los routers externos de tipo speaker con los que se pueden comunicar, las rutas posibles que existen dentro del AS al cual pertenecen [6]. Peers: son los speakers que establecen una conexin directa o sesin BGP basada en un acuerdo. sta es una conexin lgica TCP que garantiza la entrega de la informacin de enrutamiento entre peers y que puede visualizarse como una malla [6].

E. Tipos de BGP BGP puede ser utilizado para intercambiar actualizaciones de forma interna o externa. Es as como las conexiones que se dan entre routers que pertenecen a un mismo AS se definen como iBGP (internal BGP), y las conexiones externas (entre AS) se establecen por medio de eBGP (external BGP) [2], [4], [5], [6]. iBGP: permite realizar una conexin entre un par de speakers dentro de un AS. Un speaker identifica si el peer con el que establece comunicacin es interno o externo teniendo en cuenta el ASN que es enviado dentro del mensaje OPEN. iBGP es implementado cuando dentro de un AS se tienen mltiples speakers eBGP [5], [6]. eBGP: tpicamente es el BGP que se habla entre ISPs y POP (Point Of Presence) o entre una empresa y sus sucursales. Se utiliza para establecer comunicacin entre speakers que se encuentran en diferente AS [5], [6]. F. Bases de Datos en BGP Un BGP speaker debe tener la informacin de enrutamiento necesaria para comunicarse con algunos nodos especficos de la red. Para esto cuenta con tres bases de datos que almacenan los datos que se reciben, se seleccionan, y se envan. Estas bases de datos son [5], [13]: Adjacent-RIB-In: almacena la informacin de enrutamiento que resulta del intercambio inicial con los routers vecinos. Estos datos no han sido procesados y, por lo tanto, no se pueden anunciar a otros routers BGP. [5], [13]. Loc-RIB: aqu se encuentran los datos de enrutamiento definitivos, es decir, las rutas locales que se han seleccionado o determinado como las mejores para realizar sobre ellas todo el procedimiento de enrutamiento entre nodos [5], [13]. Adjacent-RIB-Out: contiene las rutas locales que cumplen con la poltica local establecida por la administracin, y que pueden ser anunciadas a los routers BGP vecinos [5], [13]. G. Mensajes de BGP Para asegurar el intercambio de informacin se definen cuatro tipos de mensajes que se intercambian al inicio, durante, y al final de una sesin BGP: Open: es el primer mensaje que enviado por los BGP speakers para solicitar el inicio de una sesin entre peers luego del establecimiento de la conexin TCP, este es el primer mensaje enviado por cada uno de los routers.. En el se coloca informacin como la versin de BGP usada y el ASN [2], [3], [5], [6], [10], [13]. Update: se usa para el envo de informacin de enrutamiento entre peers. Permite establecer las relaciones entre ASs (construccin de grafo) y realizar cambios dentro de las bases de datos. Mediante este tipo de mensaje es posible conocer y anunciar la disponibilidad o no disponibilidad de una ruta (incluso de

forma simultnea, es decir, una ruta que debe eliminarse junto con la nueva que se utilizar). Dentro de la informacin que se encuentra dentro de este mensaje se encuentra el prefijo de la direccin IP y los atributos de los trayectos [2], [3], [5], [6], [10], [13]. Keepalive: este mensaje peridico se emplea para confirmar que la sesin debe continuar de forma activa. Esta condicin depende del establecimiento de un Hold Timer, que es simplemente un reloj. El keepalive se enva tambin luego del mensaje OPEN para aceptar la solicitud de establecimiento de conexin [2], [3], [5], [6], [10], [13]. Notification: es usado para indicar un error o una condicin especfica, es decir, puede ser generado por incompatibilidad entre peers e incluso por configuracin (el administrador establece que no se puede mantener la conexin bajo cierto tipo de condiciones). Inmediatamente despus de su envo se cierra o termina la sesin. Este mensaje se caracteriza internamente porque es posible conocer un cdigo del error que indica finalmente cul es la razn del error, por ejemplo, de paquete, en la conexin, en los atributos, de autenticacin [2], [3], [5], [6], [10], [13].

H. Atributos (mtrica) en BGP Dentro de BGP es muy comn encontrar varios trayectos diferentes hacia un mismo destino, por esta razn para el establecimiento de la mejor ruta, BGP utiliza propiedades, parmetros o atributos que le permiten a cada nodo tomar decisiones sobre un camino hacia cada uno de los destinos. Dentro de BGP todos los atributos se han clasificado en dos categoras: Well-known y Optional, y stos a su vez se dividen en otros dos grupos. Los Well-known se caracterizan porque deben ser reconocidos por todas las implementaciones BGP y se propagan en las actualizaciones, mientras que los Optional son reconocidos por algunas implementaciones y no son obligatorios. Los Well-known se dividen en Mandatory y Discretionary. Los Mandatory deben estar presentes en todos los mensajes de actualizacin de rutas, y los Discretionary pueden o no estar presentes en los mensajes de actualizacin de trayectos. A su vez, los Optional se clasifican en Transitive y Nontransitive. Los Transitive se envan a los vecinos as no sean reconocidos, y los Nontransitive se descartan o se eliminan inmediatamente al no ser reconocidos [2], [5], [6], [12], [13]. Well-known Mandatory: este grupo de atributos se consideran obligatorios, es decir, siempre deben aparecer dentro de un mensaje UPDATE y deben ser reconocidos por cualquier router que hable BGP [2], [5]. Los parmetros pertenecientes a este tipo son: ORIGIN, AS_PATH y NEXT_HOP. a) ORIGIN: es un atributo que identifica cmo fue aprendida una ruta o de dnde proviene, en otras palabras establece la fuente que origina la informacin b) AS_PATH: consiste en una lista de los diferentes ASs que se deben pasar para llegar a un destino.

c) NEXT_HOP: permite identificar la direccin IP de la interfaz fsica del prximo router a la que se debe saltar para alcanzar el destino. Well-known Discretionary: deben ser reconocidos pero no necesariamente deben ser enviados dentro de un mesaje UPDATE [2], [5]. Dentro de esta categora se destacan: LOCAL_PREF y ATOMIC_AGGREGATE. a) LOCAL_PREF: determina la predileccin de un punto de salida o router, teniendo en cuenta la poltica que se maneje dentro del AS. b) ATOMIC_AGGREGATE: se relaciona con la ruta de salida para la que se realiza supernetting (agregar varias rutas para ser anunciadas a un peer). Optional Transitive: pueden ser o no ser soportados (no reconocidos), pero sin embargo pueden llegar a ser aceptados y, de esta forma, deben ser enviados a los peers [2], [5]. Un ejemplo de este tipo de atributo es AGGREGATOR. a) AGGREGATOR: es un parmetro que indica el speaker donde fue realizada la agregacin de rutas. Optional Nontransitive: son los parmetros intransitivos opcionales, es decir, es un atributo no soportado que se ignora y, adems, no se intercambia (no se pasa de peer a peer) [2], [5]. Aqu puede clasificarse el MULTI_EXIT_DISC. a) MULTI_EXIT_DIS: tambin conocido por sus siglas MED, es utilizado para discriminar entre mltiples enlaces o conexiones externas que se tienen hacia un AS. I. Timers de BGP Para asegurar un correcto funcionamiento de BGP, tambin es necesario establecer varios relojes que cumplen objetivos claros y especficos. Connect Retry Timer: es el intervalo de tiempo que debe pasar para volver a enviar una solicitud de conexin. Se recomienda un valor de 120 segundos para este parmetro [2], [5]. Hold Timer: este reloj establece el tiempo mximo que debe esperar un peer para la llegada sucesiva de un mensaje UPDATE o KEEPALIVE. Si el timer expira, quiere decir que el router es inalcanzable, es decir, el enlace se ha cado. Este reloj se establece teniendo como referencia el tiempo de duracin del intercambio inicial (envo del mensaje OPEN), por esta razn, se sugiere una duracin de 90 segundos y un valor mnimo de 3 segundos. Si el Hold Timer se establece como 0, no se enviarn mensajes tipo KEEPALIVE [2], [5], [13]. Keepalive Timer: indica la frecuencia con la que se debe originar un mensaje tipo KEEPALIVE. Puede tomar un valor de 1/3 del Hold Timer. Teniendo en cuenta el valor recomendado, este reloj tendra una duracin de 30 segundos [2], [5], [13]. Min Route Advertisement Interval Timer: define el tiempo mnimo que debe transcurrir antes de anunciar rutas que deben ser eliminadas. Para un peer intraAS se manejara un valor de 5 segundos y para el caso interAS el parmetro es de 30 segundos [5].

Min AS Origination Interval Timer: se refiere al tiempo mnimo que debe pasar antes de reportar un cambio dentro de un AS por medio de un mensaje UPDATE. El valor que puede establecerse es de 15 segundos [5]. III. PROBLEMAS Y SOLUCIONES AL IMPLEMENTAR BGP

agregar campos dentro del contenido del atributo para manejar comunidades extendidas [18], [19]. B. Escalabilidad: Reflectores de ruta y Confederaciones Dentro de un AS (donde se utiliza iBGP) era y es muy comn encontrar configuraciones de tipo fully mesh (todos conectados), es decir, cada router deba establecer relaciones de peering para asegurar intercambio de informacin con todos sus peers o nicamente con los que quiera establecer comunicacin. Es all donde surga un problema debido a que al aumentar el nmero de routers aumentaba tambin el nmero de conexiones directas que se deban manejar, consumiendo gran cantidad de memoria y procesamiento. Es as como se tienen problemas de escalabilidad [5], [14]. Se propusieron entonces dos soluciones: route reflectors o reflectores de ruta, y confederaciones. Route reflectors (RR) consiste bsicamente en tener un router como reflector para distribuir las rutas que han sido aprendidas, o simplemente para realizar actualizaciones. Esto logra la reduccin del nmero de conexiones fsicas que antes eran necesarias al presentar una configuracin de tipo fully mesh. El grupo de RR y los route reflector clients es conocido como cluster [2], esta alternativa para mejorar la escalabilidad de la red esta definida en el RFC 4456 de abril de 2006 titulado BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) [5], [6], [20]. Confederaciones es otro mtodo que puede implementarse para evitar el problema de escalabilidad sin implicar una disminucin en el nmero de speakers. Bsicamente consiste en dividir un AS de gran tamao en pequeos grupos que sean ms manejables, es decir, una confederacin BGP es un subgrupo dentro de un AS bajo el mismo ASN, con la caracterstica de que a cada uno se le asigna un identificador de confederacin y adicionalmente se seleccionan routers como confederation peers. Estos speakers a su vez hablan eBGP pero intercambian rutas de forma interna. Es as como se eliminan conexiones fsicas directas y nicamente sobreviven las necesarias para permitir la comunicacin entre confederaciones. El RFC complementario que define las confederaciones para BGP es el numero 5065 de agosto de 2007 denominado Autonomous System Confederations for BGP [2], [5], [6], [21]. C. Inestabilidad (Oscilaciones de Ruta): Route Flap y Route Flap Damping La oscilacin de ruta o el route flap ocurre cuando uno o varios routers reciben informacin sobre una ruta que empieza a oscilar, es decir, est disponible en un instante y no disponible en el siguiente. Si ocurre esto con la mejor ruta, un router puede tomar la decisin de no eliminarla de la lista de las rutas dentro de la tabla de enrutamiento y dejarla como segunda opcin, pero si vuelve a recibir informacin de que es la mejor ruta, la colocar de nuevo en primer lugar y esto ocurrira de forma cclica. Este cambio de estado tiene algunos efectos como inestabilidad dentro de la red, ya que los routers realizan procesamiento de la informacin (sobrecarga

En general, los protocolos de enrutamiento en redes de datos han presentado problemas en su implementacin y operacin, y BGP no ha sido la excepcin. Como es el nico protocolo encargado de establecer relaciones entre los elementos que hacen parte de Internet (Tiers, IXP (Internet eXchange Point), POP, ISP, y usuarios finales) para permitir el intercambio de informacin, se han propuesto soluciones a algunos de los problemas que han surgido. Por esta razn, se encuentran RFCs complementarios al 4271, en donde se especifican recomendaciones para superar los inconvenientes. A. Crecimiento del tamao de la tabla de enrutamiento: Agregacin de rutas y Comunidades Cada vez que a un segmento de red se conecta un nuevo elemento con el que debe establecerse comunicacin, hay que trazar necesariamente un camino para llegar hasta l. Este trayecto debe aparecer dentro de las tablas de enrutamiento, las cuales crecan sin control de la misma manera que el nmero de nuevos nodos. Este fue uno de los primeros problemas que se gener al poner en funcionamiento el protocolo BGP. Una de las primeras opciones para mejorar este aspecto fue route aggregation (que es una habilidad nata de BGP-4, numeral 9.2.2.2 del RFC 4271). Esta funcionalidad consiste en la asociacin de varias direcciones IP que corresponden a diferentes ASs por medio de supernetting, para finalmente anunciar slo una. Realizando este procedimiento se disminuye el nmero de entradas que deben mantenerse y manejarse dentro de la tabla de enrutamiento para su posterior envo, y adicionalmente tambin se reduce el espacio de memoria requerido para el almacenamiento de las direcciones IP [5], [14]. Los RFC 2519 (A Framework for Inter-Domain Route Aggregation, febrero de 1999) y RFC 4632 (Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, agosto de 2006) son complementarios al BGP-4 y en ellos se encuentran aspectos adicionales sobre el tema de agregacin de rutas [15], [16]. Una extensin realizada al protocolo BGP fue la implementacin de un atributo conocido como Communities. El RFC que la define es el 1997 de agosto de 1996, titulado BGP Communities Attribute. Las comunidades son grupos de destinatarios que surgen para permitir la distribucin de informacin adicional o asegurar de una manera ms simple la restriccin de trfico hacia vecinos y pares remotos. Este atributo se clasifica dentro del grupo opcional y transitivo [5], [14], [17]. En el ao 2006 se establecieron dos RFC adicionales: el RFC 4360 BGP Extended Communities Attribute y el RFC 4384 BGP Communities for Data Collection, relacionados con nuevos atributos y etiquetas para la distribucin de la informacin dentro de comunidades, y

computacional) y luego enviarn una gran cantidad de mensajes de actualizacin (cascading storm) de forma constante, que pueden ser no vlidos. La inestabilidad puede conducir a unos tiempos de convergencia muy grandes y un consumo adicional de ancho de banda (para el masivo intercambio de informacin de cambios) dentro de la red. Puede considerarse que este ltimo aspecto ha sido subsanado por la creciente alza de las capacidades de los enlaces [2], [5], [14]. La solucin a este problema se plante en el RFC 2439 de noviembre de 1998 denominado BGP Route Flap Damping. Este mtodo no previene a un router sobre la recepcin de rutas inestables, sino que se centra nicamente en que esta informacin no siga siendo enviada a los dems. Es as como se establece una figura de mrito dinmica que refleja la estabilidad, y de esta forma se marca la ruta y posteriormente se elimina debido a su comportamiento variable. En el RFC 3345 del ao 2000 titulado Border Gateway Protocol (BGP) Persistent Route Oscillation Condition se establecen unas condiciones en las que se generan oscilaciones y algunas consideraciones que se deben tener para evitar que este evento ocurra [2], [5], [6], [14], [22], [23]. D. Congestin: Balanceo de Carga El protocolo BGP no detecta congestin dentro de la red, este problema tiene su origen en el proceso de seleccin de la mejor ruta, ya que es probable que un trayecto sea visto como el mejor por varios routers. Esto hace que todo el trfico sea enviado o recibido por el mismo enlace [14]. Al considerar redes multihomed dentro de BGP, se esta haciendo referencia a la posibilidad de que un ISP maneje varias conexiones o redundancia hacia uno o varios Tiers 3, otros ASs y sus usuarios. Algunas ventajas de tener varios trayectos hacia otros elementos dentro de la jerarqua podran ser: disminuir la congestin, manejar un mayor ancho de banda (al poder tener ms de un camino hacia un destino) y, para algunos investigadores, realizar balanceo de carga [6], es decir, dividir el trfico entrante y/o saliente a travs de los diferentes caminos teniendo en cuenta aspectos como la capacidad del enlace. En este el momento, los ISPs utilizan estas conexiones como enlaces de reserva para utilizarlos en el momento en el que ocurran fallas, es decir, manejan conexiones de backup. Los temas relacionados con multihomed estn en pleno desarrollo debido a su aceptacin y altos niveles de penetracin dentro de las redes BGP. En [5], por ejemplo, se propone la adicin de campos dentro de los mensajes intercambiados entre peers BGP para identificar los sistemas multihomed. Hacia un futuro no muy lejano, y teniendo en cuenta aspectos como la diferencia entre el trfico entrante y saliente hacia y desde un AS (que generalmente son asimtricos), algunos investigadores han propuesto que mediante las decisiones tomadas por los administradores de red sea posible influenciar en la seleccin de las rutas que deben tomar los paquetes. De esta forma se podra distribuir el trfico en flujos segn el tipo (datos, video, u otro) y/o su destino para que cada uno tome una ruta especfica (una especie de

enrutamiento esttico) y de esta manera se utilice el mejor trayecto o el ms ptimo para cada uno de los casos. Lo anterior implica que se debe compartir un enlace de forma permanente con otro AS para envo de informacin. Esta es una solucin que disminuira los niveles de congestin dentro de la red, ya que obligara al trfico a seguir ciertos trayectos de forma continua [2], [14]. El balanceo de trfico, como una de las estrategias para mejorar la congestin de las redes BGP, an no se propone dentro de un RFC pero es uno de los temas de mayor inters para los investigadores, fabricantes y operadores, y se encuentra relacionado directamente con las labores de ingeniera de trfico y con los niveles de QoS (Quality of Service) que deber establecerse para el protocolo BGP. E. Otros RFC Complementarios Route Refresh: adicionalmente a los cuatro mensajes establecidos en el RFC 4271, se defini un mensaje opcional en el RFC 2918 de septiembre del 2000 llamado route refresh (podra traducirse como actualizacin de ruta). Es una capacidad que permite el intercambio dinmico de actualizaciones de rutas entre speakers BGP mediante el anuncio de la tabla Adj-RIB-Out [5], [24]. Extensin Multiprotocolo: este RFC complementario RFC 4760 de enero de 2007 denominado Multiprotocol Extensions for BGP-4 establece la posibilidad de tener BGP-4 sobre otros protocolos de la capa de red como IPv6 (IP version 6), IPx (Internetwork Packet Exchange), L3VPN (Layer 3 Virtual Private Networks), entre otros [2], [5], [25]. Extensin de ASN: debido al crecimiento de Internet, es necesario tener la disponibilidad de ms numeracin de ASs. Es por ello que de utilizar dos octetos se pasa al manejo de cuatro. Esta caracterstica est incluida en el RFC Complementario 4893 de mayo de 2007 titulado BGP Support for Four-octet AS Number Space [26]. Parmetro Optional Capabilities: en el RFC 5492 de febrero de 2009 denominado Capabilities Advertisement with BGP-4, que deja obsoleto al RFC 3392 de 2002, se establece una nueva funcionalidad que tiene como fin permitir el anuncio de este parmetro sin necesidad de que haya terminado una sesin. Esto surge debido al inconveniente de que la sesin deba cerrarse al recibir un parmetro opcional no reconocido en un mensaje OPEN [27], [28]. Seguridad en BGP-4: las primeras extensiones que se encuentran datan de agosto de 1998 y estn relacionadas con la utilizacin de TCP MD5 (TCP Message-Digest algorithm 5) como opcin para establecer, por medio de una firma (considerada como mtodo de autenticacin), algn nivel de confiabilidad a la hora de establecer sesiones entre routers terminales. Esto se defini entonces en el RFC 2385 titulado Protection of BGP Sessions via the TCP MD5 Signature Option. Le prosiguieron algunos RFC adicionales como el RFC 3562 (Key Management Considerations for the TCP MD5 Signature Option) de

julio de 2003, y el RFC 4808 (Key Change Strategies for TCP-MD5) de marzo de 2007 [2]. De forma complementaria, el RFC 4272 de enero de 2006 denominado BGP Security Vulnerabilities Analysis, trata el tema de vulnerabilidad de la seguridad de BGP-4, ya que se tienen consideraciones de proteccin muy bajas para la informacin que se transmite. Internamente no hay manejo de un mecanismo que evite modificaciones, eliminacin, falsificacin, o cambio de datos [29], [30], [31], [32]. Trfico en BGP-4: en el RFC 5543 de mayo de 2009 titulado BGP Traffic Engineering Attribute, se crea un nuevo atributo opcional y no transitivo relacionado con la ingeniera de trfico, para permitir el envo de informacin sobre este aspecto [33]. IV. BGP Y LOS ISPS COLOMBIANOS

Para identificar el impacto que ha trado la utilizacin del protocolo BGP en las redes de los proveedores de Internet en nuestro pas, se realiz una encuesta a los integrantes del NAP Colombia durante los meses de mayo y julio de 2009, con el fin de verificar el conocimiento del protocolo e identificar los problemas que presenta la puesta en marcha de redes que usan el BGP en el pas. Como resultado a las preguntas relacionadas con conocimiento bsico, se obtuvo un 86% de respuestas tericas correctas por parte de los siete proveedores consultados. En cuanto al uso de multihomed dentro de sus redes, los operadores colombianos s estn empleando este tipo de configuracin. El nmero de conexiones que los ISPs poseen hacia los Tiers 3 varan entre 4 y 13, y generalmente emplean todos o la mayora de los enlaces hacia su proveedor de servicios primario. Totalizando el nmero de conexiones tipo multihomed pertenecientes a los siete proveedores encuestados se obtiene un valor aproximado de 57 enlaces a proveedores de mayor jerarqua. No obstante, cinco de los siete integrantes consultados del NAP Colombia utilizan actualmente el multihomed nicamente para conexiones de backup, es decir, todava no se realizan implementaciones para realizar balanceo de carga de trfico en la red. Tambin debe considerarse que al disponer de varias conexiones de salida, seis de los siete ISPs no presentan mayores inconvenientes, es decir, al tener inhabilitado un enlace los dems permanecen en funcionamiento. Se puede decir que la mayora cuenta con redes confiables, sin embargo, el mtodo utilizado por el nico proveedor que presenta este problema dentro de su red es pedirle al Tier 3 que no anuncie ms la ruta problemtica mientras se configura el proveedor de backup. Con respecto al tiempo de convergencia en la red, seis ISPs no presentan problemas relacionados con este tema y la estrategia de solucin presentada por el nico proveedor que afirm la presencia de este problema en su red es verificar el dampening con el Tier 3. Tambin se indag sobre las oscilaciones de ruta y, aunque slo dos de los proveedores presentan este problema de una

manera frecuente, los cinco ISPs restantes comentaron que es un problema muy eventual dentro de sus redes. Para finalizar, la ltima pregunta estaba relacionada con la asignacin de rutas y con la posibilidad de tener como mejor ruta una que no presenta las caractersticas para que sea la primera opcin dentro de la tabla de enrutamiento. Se observ que para los ISPs este es un problema presente dentro de sus redes, ya que tres de los siete lo experimentan y actualmente es solucionado por los Tiers 3 a los que se encuentran conectados, o por medio de la modificacin de parmetros de los equipos que hacen parte de sus redes. Aunque no se detectaron problemas graves por el momento, en [34] los autores describen a Amrica Latina como el ms grande contribuyente al crecimiento y dinmica de la tabla de enrutamiento global de BGP, pues es la regin del mundo que presenta el factor ms grande de desagregacin de prefijos IP dentro de los registros de Internet. Adicionalmente, gran parte del trfico latinoamericano y de trnsito se intercambia fuera de la Regin en los NAPs de Estados Unidos debido al reducido nmero de conexiones peers en los dominios locales, lo que lleva a la conclusin de que en Amrica Latina el uso de de ASs multihomed por parte de los ISPs locales es creciente y genera problemas de escalabilidad y gestin de trfico en los NAPs a los cuales se encuentran conectados los proveedores locales. Segn la encuesta, la mayora de los integrantes del NAP Colombia solicitan a sus Tiers 3 que realicen procedimientos para solucionar problemas como cada en los enlaces de salida, tiempo de convergencia, oscilacin, y asignacin de rutas. Por esta razn, es importante y necesario que los proveedores agreguen a sus procesos de gestin de infraestructura tareas que incluyan la realizacin de mediciones dentro de sus redes para permitir la verificacin del desempeo de BGP, apoyados en conceptos como nivel de confiabilidad, disponibilidad, estabilidad y seguridad de redes, adems de la caracterizacin del trfico que permita establecer posibles problemas y soluciones a sus casos particulares. De esta manera, sera interesante que tanto operadores como investigadores y fabricantes generen alternativas de solucin y realicen aportes significativos en el rea de arquitecturas de red, enrutamiento, ingeniera de trfico, calidad de servicio, y en temas como planeacin de capacidad, estabilidad, escalabilidad y convergencia, ya que la manera como se establecen las infraestructuras de red a nivel local y regional influyen directamente en el comportamiento de la red a nivel mundial. V. CONCLUSIONES

Dentro de los temas ms concurrentes en artculos cientficos que se consultaron para la realizacin de este estado de arte, fueron la convergencia y la seguridad de BGP, ya que luego del despliegue de redes que utilizan este protocolo han sido problemas que se presentan de forma frecuente. Sin embargo, varios centros de investigacin y desarrollo, algunos proveedores, y fabricantes han propuesto algunas estrategias de solucin. Los mecanismos presentados son tan diversos como el tipo de soluciones que se ofrecen. Entre ellas se encuentran nuevos algoritmos, cambios en los

elementos de red, simuladores, y arquitecturas optimizadas que todava no han sido aprobadas por los grupos encargados de la estandarizacin. De esta forma, se puede observar cmo se ha retrasado la adopcin e implementacin de soluciones a los inconvenientes presentados por BGP. En este momento, los temas sugeridos para realizar desarrollos son especficamente dos: todo lo relacionado con sistemas multihomed, e ingeniera de trfico aplicada a la calidad de servicio. El tema de ambientes multihomed dentro de BGP est relacionado con el manejo de varias conexiones tanto a la entrada como a la salida de un AS, y la forma como el trfico se empieza a distribuir entre estos enlaces. Es as como se relacionan los dos temas, ya que BGP debe empezar a identificar los servicios que los usuarios requieren para realizar la clasificacin de los diversos tipos de trfico y establecer el tipo de tratamiento que puede darse a cada uno de ellos dentro de la red. Debido al gran nmero de investigaciones que se encontraron relacionadas con el tema de seguridad de BGP-4, es evidente que es un rea en la cual los esfuerzos deben concentrarse ms en las estrategias de implementacin de las soluciones ms que en su formulacin, pues hay muchas alternativas. La implementacin de redes que cuenten con balanceo de trfico no es tan comn debido a la inestabilidad en las conexiones, la cual puede verificarse en dos situaciones muy comunes dentro de las infraestructuras de red. La primera de ellas es en redes que presentan cada de los enlaces por los que se establecen mltiples sesiones y que requieren, dentro de sus enlaces, conexiones configuradas para trabajar como backup. Otro escenario es la presencia de switching dentro de las tablas de enrutamiento, que se debe a las variaciones de las entradas de la tabla. Por esta razn, antes de aplicar el balanceo de carga de trfico, debe asegurarse la estabilidad en los enlaces y sesiones de BGP. En cuanto a la funcionalidad de balanceo de trfico (que se hace posible por el uso de este tipo de AS), se deben tener en cuenta las caractersticas de los paquetes para encontrar similitudes como la pertenencia a un flujo que se dirige hacia un mismo destino, de modo que al enviar el primero de los paquetes los dems puedan seguirlo de manera inmediata y evitar el incremento en el tamao de las colas, es decir, se manejaran rutas estticas dentro de la tabla de enrutamiento hacia varios destinos, adems de considerar las rutas alternativas que se deberan tomar en caso de falla. Otro mecanismo que se podra implementar, es el anlisis del establecimiento de sesiones que permita encontrar patrones de tipo peridico en el tiempo y tambin de uso de trayectos coincidentes para realizar la comunicacin. Estos aspectos podran ser utilizados para tomar decisiones dentro de los elementos de red y finalmente tener un proceso de enrutamiento ms eficiente, ya que el comportamiento de algunas sesiones entre peers ocurre de forma repetitiva, es decir, el intercambio de informacin se genera en horas especficas del da, con un trfico similar y empleando los mismos enlaces. Al conocer estas tres caractersticas de la sesin sera posible determinar cambios en la forma como se

realiza el enrutamiento (dinmico o esttico) dentro de la red y optimizar el proceso. Es necesario tener en cuenta el permanente cambio de los requerimientos de los usuarios de Internet para establecer, desde este momento, propuestas que generen estrategias o mecanismos que permitan dar un buen tratamiento a la diversidad de tipos de trfico generado por los usuarios, que a su vez, exigirn conexiones con altas capacidades, enlaces continuos y sin ningn tipo de interrupcin, altos niveles de seguridad, privacidad, y adecuados niveles de calidad de servicio. Es as como permanentemente las infraestructuras de red y los protocolos que se ejecutan sobre ellas requerirn una constante verificacin de su funcionamiento, y de esta manera se generarn nuevas propuestas de solucin y actualizacin constante. Dentro de los factores que influyen e influirn directamente en el funcionamiento de la red pueden encontrarse: el cambio constante de polticas que se manejan entre peers, algunas veces definidas de manera restrictiva afectando la manera como debe realizarse el enrutamiento; el desacuerdo entre fabricantes de equipos en relacin al establecimiento de los valores numricos para asignacin de los parmetros, lo que genera incompatibilidades a la hora de tomar de decisiones en cuanto a la seleccin de rutas. Tambin deben considerarse algunas variables a la hora de integrar la ingeniera de trfico y el concepto de QoS dentro de las redes BGP. Dentro de los parmetros a tener en cuenta estn los cambios topolgicos, las fallas de los equipos, los cambios en el trfico, la planeacin y realizacin de mantenimiento y, los errores de software y sincronizacin, entre otros [35]. AGRADECIMIENTOS Los autores agradecen a las empresas ETB, IFX Colombia, Global Crossing, Internexa S.A., Red Uno, UNE-EPM.NET y Synapsis por su colaboracin en el desarrollo del proyecto. REFERENCIAS
[1] Cisco Systems, Routing TCP/IP, Volume II (CCIE Professional Development), 1ra ed, Cisco Press, 2001. [2] S. Halabi, D. McPherson, Arquitecturas de enrutamiento en Internet, 2da ed, Pearson Educacin, Madrid, 2001. [3] I. Beijnum, BGP, 1ra ed, O'Reilly & Associates, 2002. [4] J. Beasley, Networking, 2da ed, Prentice Hall, Boston 2008. [5] D. Medhi, K. Ramasamy, Network Routing, Algoritms, Protocols and Architectures, 1ra ed, Morgan Kaufmann Publishers, San Francisco, 2007. [6] H. Osterloh, IP Routing, Primer Plus, 1ra ed, Sams Publishing, Indiana, 2002. [7] Cisco Systems, Interconnecting Cisco Network Devices (ICND), Student Guide, vol 1, v2.3, Cisco Press, 2006. [8] B. Forouzan, Transmisin de Datos y Redes de Comunicaciones, 4ta ed, McGraw-Hill, 2007. [9] A. Tanenbaum, Computer networks, 4ta ed, Prentice Hall, Boston 2003. [10] F. Halsall, Computer Networking and the Internet, 5ta ed, AddisonWesley Pearson Education, 2005. [11] BGP: the Border Gateway Protocol Advanced Internet Routing Resources, http://www.bgp4.as/, 2009.

[12] Cisco Systems, Internetworking Technologies Handbook, 4ta ed, Cisco Press, 2003. [13] Y. Rekhter, T. Li, S. Hares, RFC 4217 A Border Gateway Protocol 4 (BGP-4), http://www.rfc-archive.org/getrfc.php?rfc=4271&tag=ABorder-Gateway-Protocol-4-(BGP-4), 2006. [14] Wikipedia, Border Gateway Protocol, http://en.wikipedia.org/wiki/Border_Gateway_Protocol, 2009. [15] E. Chen, Cisco Systems, J. Stewart, Juniper, RFC 2519 A Framework http://www.rfcfor Inter-Domain Route Aggregation, archive.org/getrfc.php?rfc=2519, 1999. [16] V. Fuller, Cisco Systems, T. Li, Tropos Networks, RFC 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, http://www.rfcarchive.org/getrfc.php?rfc=4632, 2006. [17] R. Chandra, P. Traina, Cisco Systems, T. Li, RFC 1997 - BGP Communities Attribute, http://www.rfcarchive.org/getrfc.php?rfc=1997&tag=BGP-Communities-Attribute, 1996. [18] S. Sangli, D. Tappan, Cisco Systems, Y. Rekhter, Juniper Networks, RFC 4360 BGP Extended Communities Atribute, http://www.rfcarchive.org/getrfc.php?rfc=4360, 2006. [19] D. Meyer, RFC 4384 - BGP Communities for Data Collection, http://www.rfc-archive.org/getrfc.php?rfc=4384, 2006. [20] T. Bates, E. Chen, Cisco Systems, R. Chandra, Sonoa Systems, RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP), http://www.rfc-archive.org/getrfc.php?rfc=4456, 2006. [21] P. Traina, Blissfully Retired, D. McPherson, Arbor Networks, J. Scudder, Juniper Networks, RFC 5065 Autonomous System http://www.rfcConfederation for BGP, archive.org/getrfc.php?rfc=5065, 2007. [22] C. Villamizar, ANS, R. Chandra, Cisco Systems, R. Govindan, ISI, RFC 2439 BGP Route Flap Damping, http://www.rfcarchive.org/getrfc.php?rfc=2439, 1998. [23] D. McPherson, TBC, V. Gill, AOL Time Warner Inc., D. Walton, A. Retana, Cisco Systems, RFC 3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition, http://www.rfcarchive.org/getrfc.php?rfc=3345, 2002. [24] E. Chen, Redback Networks, RFC 2918 Route Refresh Capability for BGP-4, http://www.rfc-archive.org/getrfc.php?rfc=2918&tag=RouteRefresh-Capability-for-BGP-4, 2000. [25] T. Bates, Cisco Systems, R. Chandra, Sonoa Systems, D. Katz, Y. Rekhter, Juniper Networks RFC 4760 Multiprotocol Extensions for BGP-4, http://www.rfcarchive.org/getrfc.php?rfc=4760&tag=Multiprotocol-Extensions-forBGP-4, 2007. [26] Q. Vohra, Juniper Networks, E. Chen, Cisco Systems, RFC 4893 BGP Support for Four-octect AS Number State, http://www.rfcarchive.org/getrfc.php?rfc=4893, 2007. [27] J. Scudder, Juniper Networks, R, Chandra, Sonoa Systems, RFC 5492 Capabilites Advertisement with BGP-4, http://www.rfcarchive.org/getrfc.php?rfc=5492, 2009. [28] R. Chandra, Redback Networks, J. Scudder, Cisco Systems, RFC 3392 Capabilities Advertisement with BGP-4, http://www.rfcarchive.org/getrfc.php?rfc=3392, 2002. [29] A. Heffernan, Cisco Systems, RFC 2385 Protection of BGP Sessions http://www.rfcvia the TCP MD5 Signature Option, archive.org/getrfc.php?rfc=2385&tag=Protection-of-BGP-Sessions-viathe-TCP-MD5-Signature-Option, 1998. [30] M. Leech, Nortel Networks, RFC 3562 Key Management Considerations for the TCP MD5 Signature Option, http://www.rfcarchive.org/getrfc.php?rfc=3562&tag=Key-ManagementConsiderations-for-the-TCP-MD5-Signature-Option, 2003. [31] S. Bellovin, Columbia University, RFC 4808 - Key Change Strategies for TCP-MD5, http://www.rfc-

[32]

[33]

[34]

[35]

archive.org/getrfc.php?rfc=4808&tag=Key-Change-Strategies-for-TCPMD5, 2007. S. Murphy, Sparta Inc., RFC 4272 - BGP Security Vulnerabilities Analysis, http://www.rfc-archive.org/getrfc.php?rfc=4272&tag=BGPSecurity-Vulnerabilities-Analysis, 2006. H. Ould-Brahim, Nortel Networks, D. Fedyk, Alcatel Lucent, Y. Rekhter, Juniper Networks, RFC 5543 - BGP Traffic Engineering Attribute, http://www.rfc-archive.org/getrfc.php?rfc=5543&tag=BGPTraffic-Engineering-Attribute, 2009. M. Yannuzzi, X. Masip-Bruin, E. Grampn, R. Gagliano, A. Castro, M. Germn, Managing Interdomain Traffic in Latin America: A New Perspective Based on LISP, IEEE Communications Magazine, 2009, pag. 40-47. W. Li, Inter-Domain Routing: Problems and Solutions, State University of New York, 2003. 39p.

A. Ospina es Ingeniera Electrnica de la Universidad del Quindo (2005) y estudiante de la Especializacin en telecomunicaciones de la Universidad Pontificia Bolivariana (UPB). Actualmente se desempea como Docente es esta Institucin y colabora como voluntaria de la Subseccin Medelln del IEEE, en la que se desempea como Coordinadora de Captulos Tcnicos. reas de inters enrutamiento, networking, comunicaciones inalmbricas.

J. Reina es Ingeniero Electrnico de la Universidad Pontificia Bolivariana (1992) y Especialista en Telecomunicaciones de la misma Institucin (1998). Actualmente es estudiante del Doctorado en Ingeniera de la misma Universidad, en la cual se desempea adems como Docente e Investigador. reas de inters networking, enrutamiento, optimizacin, simulacin.