DESARROLLO DE MODELO PARA ESTANDARIZAR LA...
52
1 DESARROLLO DE MODELO PARA ESTANDARIZAR LA CONFIGURACION DNS EN ROUTERS DE DOS DIFERENTES PROVEEDORES JONATHAN ANDRES RODRIGUEZ ROBINSON GONZALEZ ROJAS UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELECOMUNICACIONES BOGOTÁ D.C. 2016
Transcript of DESARROLLO DE MODELO PARA ESTANDARIZAR LA...
1
DESARROLLO DE MODELO PARA ESTANDARIZAR LA CONFIGURACION
DNS EN ROUTERS DE DOS DIFERENTES PROVEEDORES
JONATHAN ANDRES RODRIGUEZ
ROBINSON GONZALEZ ROJAS
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA EN TELECOMUNICACIONES
BOGOTÁ D.C.
2016
2
DESARROLLO DE MODELO PARA ESTANDARIZAR LA CONFIGURACION
DNS EN ROUTERS DE DOS DIFERENTES PROVEEDORES
JONATHAN ANDRES RODRIGUEZ
ROBINSON GONZALEZ ROJAS
DIRECTOR DE PROYECTO
ING. GUSTAVO ADOLFO HIGUERA CASTRO
Trabajo de grado para optar al título de profesional en Ingeniería en
Telecomunicaciones
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA EN TELECOMUNICACIONES
BOGOTÁ D.C.
2016
3
INDICE DE CONTENIDO.
1. INTRODUCCION .....................................................................................................................6
2. JUSTIFICACIÓN .....................................................................................................................7
3. ANTECEDENTES ...................................................................................................................8
2.1 Francisco Luna Valero. (Abril de 2008). Metaheurísticas avanzadas para problemas reales
en redes de telecomunicaciones. Universidad de Málaga, Departamento de Lenguajes y
Ciencias de la Computación. Málaga, España [1]. ......................................................................8
2.2 Juan Camilo Araque Alvarez, Sindy Lorena Espinosa Torres. (2015). Desarrollo de un
modelo para la configuración vlan de switch de las plataformas cisco y huawei. Universidad
Distrital Francisco José de caldas. Bogotá, Colombia [2]. ...........................................................8
2.3 John Camilo Solano Arenas, Leonardo Andres Jaimes Fajardo. (2008) Implementación en
Java del modelo de propagación Andino UIS® para planificación y análisis de redes celulares
sobre CellGis. Universidad Industrial de Santander, Facultad de ingenierías físico – mecánicas,
Escuela de ingeniería eléctrica, electrónica y telecomunicaciones. Bucaramanga, Colombia [3].
...................................................................................................................................................8
2.4 Juan Bernardo Quintero, Raquel Anaya. (Diciembre 2007). MDA Y EL PAPEL DE LOS
MODELOS EN EL PROCESO DE DESARROLLO DE SOFTWARE. EIA, ISSN 1794-1237 Número 8,
131-146 [4]. ................................................................................................................................9
2.5 Carlos Johany Sierra Guzman. (2016). Desarrollo de un algoritmo para la configuración de
dos tecnologías de routers utilizando MDA. Universidad Distrital Francisco José de caldas.
Bogotá, Colombia [7]. .................................................................................................................9
4. OBJETIVOS ...........................................................................................................................11
3.1 Objetivo General ................................................................................................................11
3.2 Objetivos Específicos ..........................................................................................................11
5. MARCO TEORICO ...............................................................................................................12
4.1 Router.................................................................................................................................12
4.1.1. Configuraciones en los Routers ......................................................................................13
4.1.2 DNS ..................................................................................................................................16
4.1.3 Aplicaciones de los lenguajes de dominio específico ......................................................18
4.1.4 Ingeniería dirigida por modelos (MDE) ............................................................................19
6. METODOLOGÍA ....................................................................................................................22
5.1 Selección de tecnologías router a usar. ..............................................................................22
4
5.2 Conexión entre dispositivos y selección de protocolos de conexión. .................................22
5.3 Creación de diagramas de análisis. .....................................................................................22
5.4 Creación de modelo UML. ..................................................................................................23
5.5 Selección de detalles técnicos para la correcta programación del router. .........................23
5.6 Envío de comandos para configuración DNS y pruebas del modelo. ...........................23
7. EVALUACIÓN DE PROVEEDORES .................................................................................23
6.1 Características de dispositivos. ...........................................................................................27
8. ESTANDARIZACIÓN DE MODELO DE CONFIGURACIÓN DE BUSQUEDA DNS
EN DISPOSITIVOS ROUTERS ...................................................................................................28
7.1 Análisis de Componentes del modelo de configuración DNS para Routers ........................28
7.2 Algoritmos de configuración de Router CISCO y Router .....................................................30
7.3 Estandarización de los componentes .................................................................................32
7.4 Desarrollo de un modelo UML basado en algoritmos para la configuración de dos
diferentes routers. ...................................................................................................................33
7.4.1 Desarrollo de algoritmo para la configuración de DNS en dispositivos de diferentes
proveedores. ............................................................................................................................34
7.4.2 Desarrollo de algoritmo para la configuración de registros en base de datos de acuerdo
a los parámetros propios de cada dispositivo router a implementar. ......................................36
7.4.3 Desarrollo de algoritmo para la actualización de registros en base de datos de acuerdo a
los parámetros propios de cada dispositivo router a implementar. .........................................37
7.4.4 Casos de uso ....................................................................................................................39
7.4.5 Interfaz grafica.................................................................................................................39
Luego de desarrollar la lógica contenida en los casos de uso se obtiene una interfaz gráfica
que funciona como se define en el documento anexo. ............................................................39
7.4.6 Diagrama de clases ..........................................................................................................40
7.5 Selección de lenguajes de programación ...........................................................................46
9. PRUEBAS UNITARIAS ........................................................................................................46
10. RESULTADOS OBTENIDOS ..........................................................................................47
11. CONCLUSIONES ..............................................................................................................48
12. AGRADECIMIENTOS.......................................................................................................49
13. REFERENCIAS .................................................................................................................50
5
INDICE DE FIGURAS
Figura 1. Ejemplo de nombres de dominio DNS.
Figura 2. Arquitectura en Cuatro Capas MDA.
Figura 3. Diagrama de flujo de metodología aplicada.
Figura 4. Imagen de Routers Cisco series 1900/1941.
Figura 5. Imagen de Router Linksys e900.
Figura 6. RouterBoard 750GL.
Figura 7. Diagrama de contexto de configuración DNS en Router.
Figura 8.Algoritmo de Configuración DNS Router Cisco.
Figura 9.Algoritmo de Configuración DNS Router MikroTik.
Figura 10. Diagrama de actividades configuración DNS.
Figura 11. Diagrama de actividades registro en base de datos.
Figura 12. Diagrama de actividades Actualización en base de datos.
Figura 13. Diagrama de casos de uso general.
Figura 14. Diagrama de clase Init.
Figura 15. Diagrama de clase Conector.
Figura 16. Diagrama de clase ConfDNS.
Figura 17. Diagrama de clase ConfRouter.
Figura 18. Diagrama de clase ModDNS.
Figura 19. Diagrama de clase AtributosIP.
Figura 20. Diagrama de clase IpConfig.
Figura 21. Diagrama de clase Constantes.
Figura 22. Diagrama de clase ConexionDAO.
Figura 23. Diagrama de clase ServiciosBD.
Figura 24. Diagrama de clases.
INDICE DE TABLAS
Tabla 1. Funciones configurables en los router ------------------------------------------ 13.
Tabla 2. Tipos de nombres de dominio DNS --------------------------------------------- 17.
Tabla 3. Comparativa de dispositivos por proveedor ----------------------------------- 24.
Tabla 4. Elementos que inciden en proceso para estandarización------------------ 29.
Tabla 5. Elementos de estandarización del modelo ------------------------------------- 32.
Tabla 6. Resultados obtenidos en las pruebas unitarias ------------------------------- 46.
6
1. INTRODUCCION
A lo largo de la historia se han podido observar las grandes evoluciones que han tenido los sistemas de telecomunicaciones y en los últimos tiempos se observa como el auge de la tecnología en cualquier ámbito crece de gran manera; la implementación de sistemas de telecomunicaciones se hace una actividad cada vez más común y cotidiana.
El creciente uso de redes para telecomunicaciones ha planteado a su paso nuevos desafíos, los cuales deben ser en gran parte resueltos por la industria y el sector educativo con el fin de estandarizar procesos para globalizar el uso de las redes y expandir el conocimiento en los temas referentes a la interacción entre dispositivos y terminales con el usuario, teniendo en cuenta que muchas veces el usuario no tiene los conocimientos técnicos suficientes para realizar configuración de este tipo de dispositivos manualmente.
Debido a esto se pretende desarrollar e implementar un modelo que permita a partir de los algoritmos tradicionales de configuración de búsqueda DNS en dispositivos tipo routers de dos diferentes proveedores, seleccionando estos de acuerdo a sus características más relevantes y necesarias para la configuración mencionada.
7
2. JUSTIFICACIÓN
Uno de los principales factores para que la implementación de redes de
comunicaciones o de datos sea eficiente es que los dispositivos que la conforman
se encuentren debidamente configurados y adaptados para lograr el mejor
desempeño en la implementación.
En algunas ocasiones la configuración de dispositivos routers para una red, se
lleva a cabo por personas que no tienen la suficiente experiencia o capacitación
sobre el tema y se realiza de manera manual, esto conlleva a extensos gastos de
tiempo y esfuerzo, que pueden traducirse en pérdidas de ganancia para una
compañía o en desgaste de personas del común que pretenden realizar
configuraciones particulares en sus redes, respecto a lo anterior se requiere
ahondar en el tema y realizar la implementación de nuevas tecnologías que
permitan dar solución a esta problemática, y estandarizar la configuración de
búsquedas DNS en dispositivos router de distintos proveedores, generando un
modelo que pueda ser extendido a demás protocolos de configuración.
Con lo anteriormente mencionado se puede generar una ayuda para las personas
que se desempeñan en el área de redes, personas que no cuentan con
conocimientos avanzados sobre las diferentes tecnologías o dispositivos de
diferentes proveedores, el sector educativo y en general, puesto que, les
proporcionara una herramienta de fácil uso y poco tiempo de adaptación,
permitiendo que ellos empiecen a enfocarse en otros ítems de mucha importancia
como seguridad informática y desarrollo de aplicaciones.
8
3. ANTECEDENTES
2.1 Francisco Luna Valero. (Abril de 2008). Metaheurísticas avanzadas para problemas reales en redes de telecomunicaciones. Universidad de Málaga, Departamento de Lenguajes y Ciencias de la Computación. Málaga, España [1].
El objetivo de esta tesis de doctorado es aplicar técnicas meta heurísticas a
problemas de optimización reales en redes de telecomunicaciones, analizar los
resultados para comprender el comportamiento de estos algoritmos y proponer
nuevos métodos para resolver los problemas de manera más eficaz y eficiente,
todo esto enfocado al mejoramiento y optimización de los sistemas y redes de
telecomunicaciones basados en estudios científicos de modelos de software y
algoritmos debidamente aplicados en el estudio de problemas[1].
2.2 Juan Camilo Araque Álvarez, Sindy Lorena Espinosa Torres. (2015). Desarrollo de un modelo para la configuración vlan de switch de las plataformas cisco y huawei. Universidad Distrital Francisco José de caldas. Bogotá, Colombia [2].
Por medio de este trabajo de tesis como opción de grado en la universidad Distrital
Francisco Jose de Caldas se desarrolló un modelo que permite la configuración de
Vlans (Redes de área local virtuales) para dispositivos de las plataformas Cisco y
Huawei, específicamente en dispositivos de red como lo son los switches.
Esta tesis nos aporta enormemente en el enfoque que tiene, ya que la idea
principal de la tesis es común y coincide con facilitar el trabajo de una manera más
sencilla e interactiva, la principal diferencia se debe a que los ponentes trabajaron
con VLAN y este trabajara con dispositivos switch de plataformas cisco y Huawei.
2.3 John Camilo Solano Arenas, Leonardo Andres Jaimes Fajardo. (2008) Implementación en Java del modelo de propagación Andino UIS® para planificación y análisis de redes celulares sobre CellGis. Universidad Industrial de Santander, Facultad de ingenierías físico – mecánicas, Escuela de ingeniería eléctrica, electrónica y telecomunicaciones. Bucaramanga, Colombia [3].
Este proyecto diseño e implemento un aplicativo desarrollado en tecnología Java,
que fue adaptado a la herramienta de planificación de redes celulares CellGis, a
fin de implementar modelos que permiten calcular perdidas por propagación de
9
señal electromagnética para sistemas de telefonía celular que operan sobre
entornos urbanos con superficies irregulares, enfocado principalmente al estudio y
planteamiento de soluciones para problemas de redes móviles en la ciudad de
Bucaramanga.
2.4 Juan Bernardo Quintero, Raquel Anaya. (Diciembre 2007). MDA Y EL PAPEL DE LOS MODELOS EN EL PROCESO DE DESARROLLO DE SOFTWARE. EIA, ISSN 1794-1237 Número 8, 131-146 [4].
El reúso de software es una de las estrategias que se considera promisoria para que la industria de software pueda enfrentar el reto de desarrollar productos con niveles de calidad y productividad adecuados en un contexto de negocio altamente complejo y dinámico y con acelerados cambios tecnológicos. El uso de plantillas, componentes de granularidad gruesa, patrones de diseño, arquitecturas de referencia, frameworks, entre otros, son mecanismos cada vez más utilizados por los desarrolladores de software. El objetivo de dichas prácticas es lograr que el reúso se integre de forma sistémica en las diferentes etapas del desarrollo, de tal manera que su impacto en los diferentes artefactos resultantes del proceso de desarrollo sea efectivo y, en lo posible, medible [5]. Mejorando las herramientas que apoyan el desarrollo de software (IDE1, compiladores, generadores de código. Trabajando más ágilmente: analizando, evaluando y mejorando la forma de trabajar (SPI2), se pueden mejorar magnitudes de hasta dos dígitos porcentuales. Trabajando menos: cambiando la forma de trabajar, maximizando el reúso, no desgastándose en diseño, codificación y pruebas exhaustivas, realizando programación en el nivel de ingeniería de modelos y requisitos, de esta forma se pueden mejorar magnitudes de hasta tres dígitos porcentuales. Dieron como conclusiones: La abstracción, la estandarización y la automatización son los tres pilares en los que se apoya MDA. Los estándares promovidos por medio de QVT han favorecido la definición de diversas aproximaciones de transformación y han dinamizado el papel de las herramientas CASE alrededor de funcionalidades particulares que requiere este enfoque. La transformación de modelos es el mecanismo central que promueve MDA, sin embargo, no es exclusivo de MDA. Este tema se está estudiando desde la perspectiva de la Ingeniería de Modelos (MDE14) y abarca enfoques que van más allá de MDA como lenguajes de dominio específico o lenguajes de transformación [6]. • Profundizar en aspectos como los roles, los flujos de trabajo y las etapas, en el marco de la propuesta para el desarrollo dirigido por modelos bosquejada en este trabajo.
2.5 Carlos Johany Sierra Guzman. (2016). Desarrollo de un algoritmo para la configuración de dos tecnologías de routers utilizando MDA. Universidad Distrital Francisco José de caldas. Bogotá, Colombia [7].
10
En este proyecto se desarrolló un algoritmo para llevar a cabo la configuración de un dispositivo de red como lo es un Router. Para la implementación del algoritmo diseñado se utilizaron dos lenguajes de programación específicos, Java y Python. El principal objetivo del algoritmo tratado en esta tesis es reducir el tiempo que toma un usuario sin conocimientos avanzados en redes, en configurar unos parámetros específicos a un router. Este algoritmo permite al usuario configurar dos tecnologías de Router, la Tecnología de Cisco Systems y Mikrotīks Ltd. (comúnmente llamada Mikrotik), donde la comunicación entre los routers y los equipos terminales se realiza por un protocolo de acceso remoto, llamado Secure Shell Versión 2 (SSH V2), para encriptar los datos en formato MD5 y dar mayor seguridad con respecto a otros protocolos de red como Telnet. En la creación del algoritmo se tuvo en cuenta la arquitectura dirigida por Modelos MDA, arrojando los diferentes diagramas de caso de uso, diagrama de clase y diagramas de secuencias. A diferencia de los proyectos anteriormente mencionados, el proyecto que se pretende desarrollar contempla el estudio concienzudo de un solo dispositivo de red, el desarrollo de un algoritmo basado en un modelo UML o inclusive una herramienta DSL soportado por análisis y estudios hechos previamente; la solución final resultante, pretende optimizar y facilitar la configuración del dispositivo de red seleccionado de una manera ágil y rápida para cualquier persona que desee optimizar tiempos de configuración del dispositivo [7].
11
4. OBJETIVOS
3.1 Objetivo General
Desarrollar y aplicar un modelo de estandarización para dos diferentes proveedores de dispositivos router para la configuración de Búsqueda DNS en ellos, con base a los algoritmos tradicionales de administración.
3.2 Objetivos Específicos
Estimar cuales proveedores se deben aplicar, dependiendo de un estudio de características, costos comerciales, aplicabilidad de configuración de Búsqueda DNS, entre otras.
Establecer un modelo para configurar Búsqueda DNS en dispositivos router, basado en los algoritmos de configuración aplicados por los proveedores seleccionados.
Documentar resultados de mejora respecto a tiempos y procesos de configuración de Búsquedas DNS al momento de operacionalizar el modelo basado en una herramienta de administración.
12
5. MARCO TEORICO
4.1 Router
Definición
Un router es un dispositivo de red que permite el enrutamiento de paquetes entre redes independientes. Este enrutamiento se realiza de acuerdo a un conjunto de reglas que forman la tabla de enrutamiento. Es un dispositivo que opera en la capa 3 del modelo OSI y no debe ser confundido con un conmutador (capa 2) [8].
Funciones Principales
El router realiza dos funciones principales, la conmutación en entorno de tráfico y servicio el que opera. Ambas funciones se pueden implementar en el mismo procesador, pero no es necesario. A menudo, la conmutación del tráfico proporciona un procedimiento separado procesador interfaz o procesamiento interrumpir el núcleo, mientras que el proceso se realiza en el entorno de servicio de fondo [9].
Arquitectura de un Router
En un router se pueden identificar cuatro componentes:
Puertos de entrada
Los puertos de entrada efectúan diversas funciones. Implementan la funcionalidad de la capa física, es decir, el extremo de un enlace físico entrante a un router o saliente del mismo. Realizan la funcionalidad de la capa de enlace de datos (representada por las cajas de la zona media en los puertos de entrada y salida), que es requerida para interoperar con la funcionalidad de la contraparte del enlace entrante. También realizan una función de búsqueda y encaminamiento (la caja más a la derecha del puerto de entrada y la caja más a la izquierda del puerto de salida), de forma que un paquete encaminado hacia el entramado de conmutación del router emerja en el puerto de salida correcto. En la práctica, los diversos puertos se reciben conjuntamente sobre una única tarjeta de línea dentro del router.
Entramado de conmutación
El entramado de conmutación conecta los puertos de entrada del router con sus puertos de salida. Este entramado de conmutación se encuentra alojado por completo dentro en el router (una red dentro de un router de red).
13
Puertos de salida
Cada puerto de salida almacena los paquetes que han sido encaminados hacia él provenientes del entramado de conmutación, y así puede transmitir los paquetes hacia el enlace saliente. El puerto de salida efectúa la función inversa en la capa de enlace de datos y en la capa física que el puerto de entrada. Cuando un enlace es bidireccional (es decir, lleva tráfico en ambas direcciones), cada puerto de salida sobre el enlace se empareja usualmente con el puerto de entrada para ese enlace sobre la misma tarjeta de línea.
Procesador de ruteo
El procesador de ruteo ejecuta los protocolos de ruteo, mantiene la información de ruteo y las tablas de encaminamiento, y lleva a cabo las funciones de gestión de red dentro del router [10].
4.1.1. Configuraciones en los Routers
Sobre los equipos router se puede configurar una amplia variedad de funciones que permiten asegurar el funcionamiento normal y en caso de fallas, además de asegurar la calidad del servicio y la seguridad. En la Tabla 1 se enumeran las configuraciones en los routers [11].
FUNCIONES CONFIGURABLES EN LOS ROUTER
Routing Se configura las distintas posibilidades de protocolos de routing: RIP, IGRP, SPF, BGP, etc. Se pueden configurar rutas estáticas, direccionamiento secundario o filtrado de rutas.
Multicast Se configura las funciones de multicast para grupos de usuarios. Se dispone de protocolos de gestión de grupos IGMP (Internet Control Message Protocol) y los de routing asociados (PIM, DVMRP o CMF).
Direcciones Se configura las funciones NAT/PAT para la traslación automática de direcciones IP y portsde TCP entre la Internet y el sistema autónomo AS. Se configura la función de asignación de direcciones IP automática mediante DHCP (Dynamic Host Configuration Protocol).
Caching Se refiere a la conexión de una memoria Cache al router de borde de la red para reducir el tráfico de paquetes web (http). Se configura el protocolo WCCP (Web Cache Control Protocol) para la conexión entre router y cache.
14
Protección hot-standby HSRP (Hot Standby Routing Protocol). Este protocolo de Cisco entrega una protección hot standby automática entre dos routers. Cuando el router de trabajo falla el otro toma el control. Un router configurado con HSRP posee 4 estados posibles: activo, standby, speaking (recibe y emite mensajes hello) y listening (solo recibe mensajes hello). HSRP trabaja mediante el intercambio de 3 tipos de mensajes multicast: -Hello. Este mensaje se envía cada 3 seg para indicar información de estado y prioridad. El router con mayor prioridad es el que trabaja en un instante; los otros se encuentran en hot standby. -Coup. Este mensaje indica que un router pasa de la función standby a la función activo. -Resign. Este mensaje es emitido por el router activo cuando pasa al estado Shutdown o cuando un router de mayor prioridad ha enviado un mensaje hello.
Protección EtherChannel De carácter similar al Switch. CALIDAD DE SERVICIO QoS
Control de congestión Se trata de mecanismos de control de colas de espera en buffer. Se dispone de las variantes: -FIFO (First In, First Out). El primer mensaje en entrar es el primero en salir. Este es el mecanismo de QoS por Default y es válido solo en redes con mínima congestión. -PQ (Priority Queuing). Este mecanismo de control de congestión se basa en la prioridad de tráfico de varios niveles. Se configuran las prioridades y se monitorea la cola de espera. -CQ (Custom Queuing). Este mecanismo se basa en garantizar el ancho de banda mediante una cola de espera programada. Se reserva un espacio de buffer y una asignación temporal a cada tipo de servicio. -WFQ (Weighted Fair Queuing). Este mecanismo asigna una ponderación a cada flujo de forma que determina el orden de tránsito en la cola de paquetes. La ponderación se realiza mediante discriminadores disponibles en TCP/IP (dirección de origen y destino y tipo de protocolo en IP, número de Socket -port de TCP/UDP-) y por el ToS en el protocolo IP.
Control de tráfico Se trata de mecanismos para descarte de paquetes en caso de congestión en la red. -WRED (Weighted Random Early Detection). Trabaja monitoreando la carga de tráfico en algunas partes de las redes y descarta paquetes en forma random si la congestión aumenta (TCP se encarga del control de flujo reduciendo la velocidad de transferencia). -GTS (Generic Traffic Shaping). Provee un mecanismo para el control del flujo de tráfico en una interfaz en particular. Trabaja reduciendo el tráfico saliente limitando el ancho de banda de cada tráfico específico y enviándolo a una cola de espera.
15
Políticas de enrutamiento El PBR (Policy-Based Routing) permite mejorar la QoS mediante la determinación de políticas. Se debe configurar un mapa de rutas para verificar la adaptación del paquete. Se basa en dirección IP, port TCP, protocolo, tamaño del paquete, etc.
CAR (Committed Access Rate) permite generar una política de QoS basada en los bits de precedencia de IP. Se denomina señalización en banda.
Reservación de banda La señalización fuera de banda se logra mediante el uso de un protocolo externo denominado RSVP (Resource Reservation Protocol). Sobre el mismo se configura su habilitación y la operación multicast.
Fragmentación-interleaving Se trata de fragmentar un paquete extenso en pequeños y el intercalado de los mismos para reducir la ocupación prolongada por parte de un paquete. Trabaja con el protocolo MLP (Multilink point-to-point Protocol) sobre enlaces con PPP.
Compresión en tiempo-real Comprime el encabezado de paquetes para la operación con RTP (Real-Time Protocol). SEGURIDAD
Ipsec Provee seguridad entre pares en túnel. Permite la autentificación de acceso, integridad de datos, privacidad, etc.
Firewall El módulo de firewall se instala como un software sobre el router o en un servidor de acceso. Permite realizar las siguientes funciones: -Control de acceso. Crea un perímetro de defensa diseñado para proteger las reservas corporativas. Acepta, rechaza y controla el flujo de paquetes basado en identificadores de capa 3 o aplicaciones. El principio de funcionamiento es: "todas las conexiones son denegadas a menos que estén expresamente autorizadas". -Logging. Es el inicio de las conexiones entrantes y salientes. El uso de un sistema proxy y cache incrementa la velocidad de respuesta de estas operaciones. -Funciones de NAT (Network Address Translator) para direcciones públicas y privadas. -Autentificación. Involucra a 3 componentes: el servidor, el agente y el cliente. -Reportes. Ofrece un punto conveniente para monitorear (Audit and log) y generar alarmas.
AAA (Authentication, Authorization, Accounting). Se configuran las opciones de autentificación (login y password), autorización (RADIUS, etc) y cuentas (billing y reportes).
Tabla 1. Funciones configurables en los router [11].
16
4.1.2 DNS
Definición DNS es una abreviatura para Sistema de nombres de dominio, un sistema para asignar nombres a equipos y servicios de red que se organiza en una jerarquía de dominios. La asignación de nombres DNS se utiliza en las redes TCP/IP, como Internet, para localizar equipos y servicios con nombres descriptivos. Cuando un usuario escriba un nombre DNS en una aplicación, los servicios DNS podrán traducir el nombre a otra información asociada con el mismo, como una dirección IP [12]. Funciones Principales El DNS se utiliza con distintas funciones. Los más comunes son:
Resolución de nombres: Dado el nombre completo de un host (por ejemplo blog.smaldone.com.ar), obtener su dirección IP (en este caso, 208.97.175.41).
Resolución inversa de direcciones: Es el mecanismo inverso al anterior. Consiste en, dada una dirección IP, obtener el nombre asociado a la misma.
Resolución de servidores de correo: Dado un nombre de dominio (por ejemplo gmail.com) obtener el servidor a través del cual debe realizarse la entrega del correo electrónico (en este caso, gmail-smtp-in.l.google.com).
Por tratarse de un sistema muy flexible, es utilizado también para muchas otras funciones, tales como la obtención de claves públicas de cifrado asimétrico y la validación de envío de e-mails (a través de mecanismos como SPF) [13].
Arquitectura DNS utiliza sistema de nombres de dominio que se implementa como una base de datos jerárquica y distribuida que contiene varios tipos de datos, incluidos los nombres de host y nombres de dominio. Los nombres en una base de datos DNS forman una estructura de árbol jerárquico denominada el espacio de nombres de dominio. Los nombres de dominio constan de etiquetas individuales separadas por puntos, por ejemplo: midominio.Microsoft.com. El espacio de nombres de dominio DNS, se basa en el concepto de un árbol de dominios con nombre. Cada nivel del árbol puede representar una rama o una hoja del árbol. Una rama es un nivel donde se utiliza más de un nombre para identificar una colección de recursos con nombre. Una hoja representa un nombre único que se utiliza una vez en ese nivel para indicar un recurso específico. Un ejemplo de nombres de dominio DNS se puede ver en la figura 1 [14].
17
Figura 1. Eejemplo de nombres de dominio DNS [14].
Tipos de nombres de dominio DNS Las cinco categorías que se utiliza para describir los nombres de dominio DNS según su función en el espacio de nombres se describen en la tabla 2, junto con un ejemplo de cada tipo de nombre [14].
Tipo de nombre
Descripción Ejemplo
Dominio raíz
Se trata de la parte superior del árbol, que representa un nivel sin nombre; a veces se muestra como dos comillas vacías (""), que indica un valor nulo. Cuando se utiliza en un nombre de dominio DNS, se indica mediante un punto (.) para designar que el nombre se encuentra en la raíz o el nivel más alto de la jerarquía de dominios. En este caso, el nombre de dominio DNS se considera completo y apunta a una ubicación exacta en el árbol de nombres. Los nombres indicados de esta manera son FQDN.
Un punto (.) o un punto al final de un nombre, como, por ejemplo, "ejemplo.Microsoft.com."
Dominio de nivel superior
Un nombre que se utiliza para indicar un país o región o el tipo de organización que usa un nombre.
"".com", que indica un nombre registrado para un negocio para uso comercial en Internet.
18
Dominio de segundo nivel
Nombres de longitud variable registrados a un individuo u organización para su uso en Internet. Estos nombres siempre se basan en un dominio de nivel superior apropiado, dependiendo del tipo de organización o ubicación geográfica donde se utiliza un nombre.
"microsoft.com". ", que es el nombre de dominio de segundo nivel registrado para Microsoft por el registrador de nombres de dominio DNS de Internet.
Subdominio
Nombres adicionales que puede crear una organización que se derivan del nombre de dominio de segundo nivel registrado. Estos incluyen los nombres agregados para crecer el árbol DNS de nombres en una organización y se divide en departamentos o ubicaciones geográficas.
"ejemplo.Microsoft.com". ", que es un subdominio ficticio asignado por Microsoft para su uso en los nombres de ejemplo de documentación.
Nombre de host o un recurso
Nombres que representan una hoja en el árbol DNS de nombres e identifican un recurso específico. Normalmente, la etiqueta de la izquierda de un nombre de dominio DNS identifica un equipo específico de la red. Por ejemplo, si un nombre en este nivel se utiliza en un registro de recursos de host (A), se utiliza para buscar la dirección IP del equipo según su nombre de host.
"" host-a.ejemplo.Microsoft.com. ", donde la primera etiqueta ("host-a") es el nombre de host DNS de un equipo específico en la red.
Tabla 2. Tipos de nombres de dominio DNS [14].
4.1.3 Aplicaciones de los lenguajes de dominio específico
Los lenguajes de dominio específico pueden ser considerados como argumentos escritos en un lenguaje de programación más general. El lenguaje de programación “real” ejecuta el parser sobre el código del DSL, para luego trabajar sobre él. Generalmente, las funciones del DSL sólo se centran en lo que se quiere hacer, y el sistema más grande resuelve el cómo hacerlo. Son muchos los DSL existentes actualmente, suficiente como para cubrir gran parte de las aplicaciones que se puedan necesitar. Los DSL más populares incluyen todos los lenguajes de consulta (query), todos los lenguajes plantilla, Shell scripts, lenguajes de almacenamiento e intercambio de datos como XML, o lenguajes para documentos como LaTex, CSS o HTML [15]. Tres ejemplos destacados de DSL son:
- Structure Query Language – SQL:
Este DSL aparece por primera vez en 1974, como sucesor de SEQUEL (Structured English Query Language), el lenguaje de IBM para acceder a datos basado en el cálculo de predicados. Fue diseñado por Donald D. Chamberlin en los laboratorios de IBM y lanzado oficialmente al mercado en 1986, año en el cual fue estandarizado por ANSI y un año después por ISO, creando así la primera versión del lenguaje. Se desarrolla con el fin de poder acceder a bases de datos
19
relacionales y especificar diferentes tipos de operaciones en ellas. Se caracteriza por el uso de álgebra y cálculo relacional para recuperar y modificar información en las bases de datos [16].
- Unified Modeling Language – UML:
Es el ejemplo más claro de lenguajes de dominio específico gráficos. Se utiliza para modelar sistemas de software. Permite la visualización, especificación, construcción y documentación de un sistema. Algunos miembros de la comunidad científica no consideran a UML como un DSL debido a que sus funciones son netamente de modelado y no sigue los ideales de la programación estructurada. Sin embargo, sus funciones de modelado son lo que lo hace precisamente un lenguaje de dominio específico, y son de gran importancia para implementar los procesos de la ingeniería de requerimientos y en la programación orientada a objetos. En 2005 se lanza como un estándar aprobado por la ISO, respaldado por el OMG (Object Management Group), aunque su primera aparición es en 1997 como propuesta de “Los tres amigos” (James Rumbaugh, Grady Booch, Ivar Jacobson) para el OMG [17].
- Extensible Markup Language – XML:
Es un lenguaje de marcas utilizado para almacenar datos de manera legible. Permite definir la gramática de lenguajes específicos, al igual que HTML, para estructurar documentos, con la gran diferencia que XML soporta bases de datos, permitiendo la comunicación de aplicaciones e integración de información. Fue desarrollado por el W3C (World Wide Web Consortium) como subconjunto del SGML (Standard Generalized Markup Language), la normalización del GML (Generalized Markup Language) de IMB hecha por ISO en 1986. XML ha servido como base para la creación de más lenguajes como XSL, XLINK y de tecnologías como Xades, Xpath, XQuery y XLT, entre otros [18].
4.1.4 Ingeniería dirigida por modelos (MDE)
La Ingeniería Dirigida por Modelos o MDE por sus siglas en inglés (Model Driven Engineering) es una metodología para el desarrollo de software, centrada en la creación de modelos de dominio, es decir, representaciones abstractas del modelo a construir. Se habla de dominios en lugar de algoritmos. Todas las formas de ingeniería existentes están basadas en la abstracción de un modelo del mundo real, en otras palabras, en el modelado de diseño de sistemas del mundo real. La importancia de los modelos en el desarrollo y diseño de software va desde su utilidad para el entendimiento de los aspectos físicos del sistema, de las características del sistema, impactos y riesgos, hasta la comunicación e integración de las características del sistema con las partes interesadas [19]. MDE nace de la necesidad de separar la lógica del negocio y la tecnología usada. Con las herramientas MDE se imponen restricciones de dominio para detectar y
20
prevenir errores al inicio del ciclo de vida del software. Con MDE el sistema de modelos posee suficiente detalle como para permitir la generación de todo un sistema de aplicación de los modelos propios. Entonces, todo nace a partir de los modelos, por lo que la atención se centra en el modelamiento y el código se genera mecánicamente a partir del modelo. Así como en la orientación a objetos “todo es un objeto”, en MDE “todo es un modelo” [20].
La Ingeniería Dirigida por Modelos promete grandes hazañas en el campo de complejidad de plataformas, en donde los lenguajes de tercera generación sufren inconvenientes para aliviar esta complejidad y a su vez para expresar conceptos de dominio de manera sencilla para el público. MDE cubre grandes cantidades de espacios tecnológicos de trabajo de manera uniforme. Los dos espacios tecnológicos de trabajo más populares son los Lenguajes de Sistemas de Gestión de Bases de Datos o DBMS (Database Management System) y la Arquitectura Dirigida por Modelos o MDA (Model Driven Arquitecture) [21]. a. Arquitectura dirigida por modelos
La Arquitectura Dirigida por Modelos es una familia de estándares propuesta por la OMG (Object Management Group) con el fin de establecer una guía para el desarrollo de software separándolo en diferentes niveles de abstracción, conectados entre sí por medio de modelos o artefactos. Así, existe un modelo para cada nivel de abstracción el cual es tomado como guía para el siguiente nivel [22]. A OMG propone cuatro niveles de abstracción, la arquitectura en cuatro capas, representada en la Figura 2 [23].
Figura 2. Arquitectura en Cuatro Capas MDA [23].
- M3 Meta-meta modelo: también llamado MOF por sus siglas en inglés
(Meta Object Facility) es un lenguaje abstracto y autodefinido el cual
21
unifica cada paso del desarrollo e integración del modelo del negocio, a través de modelado de aplicaciones y arquitectural para el desarrollar, mantener y evolucionar. MOF incluye una familia de especificaciones para manejar el ciclo de vida e intercambio de los modelos. MOF ofrece estándares que proveen especificaciones de cómo importar o exportar modelos desde varios formatos textuales [24].
- M2 Meta modelo: contiene los estándares definidos por el usuario en el Meta-meta modelo [25].
- M1 Modelo: abstracción del mundo real, es lo que se busca diseñar. Contiene los conceptos que son representados por un meta modelo.
- M0 Realidad: Hace referencia a lo que se planea modelar, es decir, al mundo real.
b. Protocolos de Red Un protocolo de red es un conjunto de reglas necesarias para permitir a dos o más procesos computacionales comunicarse entre sí. Estos procesos pueden ser ejecutados en el mismo equipo o en diferentes dispositivos conectados por diferentes tipos de redes. Estos procesos separan los procesos del sistema operativo, ejecutando diferentes programas, o pueden ser procesos virtuales, o partes modulares de un solo programa. Siempre van a existir dos o más procesos y deben ser comunicados entre sí [26]. Las reglas describen el cálculo que cada uno de los procesos debe hacer con el fin de enviar el mensaje que contenga los valores correctos en el tiempo adecuado. Estas reglas pueden ser ejecutadas tanto por software como por hardware, o por una combinación de los dos. Así como los lenguajes de programación describen cálculos, los protocolos describen las comunicaciones, “los protocolos son a las comunicaciones como los lenguajes de comunicación son a los cómputos.” [27].
22
6. METODOLOGÍA
Figura 3. Diagrama de flujo de metodología aplicada.
Las actividades realizadas para este proyecto son las descritas a continuación:
5.1 Selección de tecnologías router a usar.
Se realizó el estudio de diferentes router con sus respectivos detalles operativos de conectividad entre los cuales se escogen los dispositivos pertenecientes a las plataformas Cisco y Mikrotik.
5.2 Conexión entre dispositivos y selección de protocolos de conexión.
Se establece conexión al PC por dos diferentes medios, vía wifi o vía cable cruzado, en cuanto al protocolo de conexión se establece que de manera más práctica se debe realizar conexión vía telnet (Telecommunication Network).
5.3 Creación de diagramas de análisis.
Se realiza la serie de diagramas de clases, casos de uso y diagramas de secuencia para generar el modelo UML guiado por MDA a modo de análisis, paso fundamental previo al inicio del desarrollo y la implementación.
23
5.4 Creación de modelo UML.
Basados en el análisis llevado a cabo y representado mediante diagramas se procede a la creación integral de todo el modelo UML a fin de generar una base teórica que permita mejorar los tiempos de desarrollo y mejorar el soporte a la planeación y control del proyecto.
5.5 Selección de detalles técnicos para la correcta programación del router.
Realizando el análisis de tecnologías que se encuentran a la vanguardia en el campo del software se decide desarrollar el proyecto basado en tecnología java, con conexión a base de datos Mysql y llevar a cabo las conexiones a dispositivos router por medio de protocolo telnet, dejando abierta la posibilidad de realizar conexión vía WiFi o LAN.
5.6 Envío de comandos para configuración DNS y pruebas del modelo.
Una vez se ha culminado la etapa de análisis y posterior desarrollo, se procede a
la realización de pruebas de calidad del modelo, en el cual se establecen ciertos
escenarios que permitan determinar si la configuración de DNS es correcta
mediante los comandos enviados por Telnet hacia el router y verificación del
aplicativo para los escenarios no exitosos.
Por último se harán las pruebas finales por usuarios, estudiantes de la Universidad
Distrital Facultad Tecnológica, verificando el funcionamiento del aplicativo y a su
vez del algoritmo, esto permite consolidar que el modelo es portable a diferentes
entornos de programación sin necesidad de utilizar un entorno específico para
programar un router y brindar al usuario una plataforma que soporte dos
tecnologías de routers escalables a un futuro.
7. EVALUACIÓN DE PROVEEDORES
Para iniciar el análisis del proyecto se necesita tener claridad sobre los router o
dispositivos en los cuales se va a implementar el desarrollo, inicialmente se realiza
el estudio de proveedores, en donde se identifican routers de fácil acceso, que
cumplan con las características requeridas por el proyecto, y cuya adquisición sea
económica y se encuentre dentro de nuestro alcance.
Comparando varias tecnologías, características, tipos de conectividad y costos se
obtiene la siguiente tabla:
24
Tabla 3. Comparativa de dispositivos por proveedor.
PROVEEDOR MODELO CARACTERISTICAS PROTOCOLOS DE CONEXION
TIPO DE ENVIO DE PAQUETES
CAPA COMPLEJIDAD DE CONFIGURACION
PRECIO APROXIMADO
GASTO DE ENVIO
GARANTIA DEL
VENDEDOR
CISCO
1841
*Módulo de memoria sincrónica dual in-line (DIMM) SDRAM 256MB por defecto *WLAN Hardware basado en IEEE 802.11a/b/g *Soporte VLAN: 802.1Q VLAN soportada en todos los puertos 10/100BASE-T [28].
TELNET / puerto 23
SSH/ puerto 22 vía web
HTTP/HTTPS PUERTO SERIAL
RS232 [28].
Puertos 10/100 Ethernet [28].
3
MEDIO. cuenta con interfaz de administrador, sin embargo esta interfaz requiere
de alto conocimiento
sobre el dispositivo para poder realizar
configuraciones
$1'699.400 COP [33].
GRATUITO 1 año
1941
*licencia LAN-BASE V15.1 *Protocolos de enrutamiento dinámico y estático *Memoria (DDR2 Código de corrección de errores [ECC] ECC DRAM) 512MB *Característica de seguridad WLAN: 802.11i estándar *Embedded Crypto aceleración basada en hardware (IPSec) [29].
TELNET / puerto 23
SSH/ puerto 22 via web
HTTP/HTTPS PUERTO SERIAL
RS232 DIAL UP [29].
Puertos Gigabit Ethernet
10/100/1000 Mbit/s WAN
[29].
3
FACIL. Cuenta con interfaz
de administrador que permite que el
proceso de configuración sea
más sencillo, debido a su
interfaz amigable. Se requieren
conocimientos básicos.
$2'000.000 COP [33]. Opción de
obtener el router a manera de
préstamo para practicas
GRATUITO 1 año
LYNKSYS E900
*IOS Original de Cisco. *Conexión Ethernet (RJ-45) *Estándares de red: IEEE 802.11n, IEEE 802.3, IEEE 802.3u *Protocolos de red compatibles: IPv4/IPv6 [30].
Vía web HTTP/HTTPS PUERTO 80
Vía web HTTP/HTTPS PUERTO 443
[30].
4 puertos 10, 100 Mbit/s
Ethernet LAN 1 Puerto 10, 100 Mbit/s
[30].
3
FACIL. Consola de
administración básica, no ofrece
grandes características configurables debido a su
enfoque de router de oficina.
$115.300 COP [33].
$10.000 COP
2 años
MIKROTIK RB750GL
*Memoria SDRAM de 64Mb *Sistema operativo basado en software libre RouterOS *Excelente relación costo beneficio. *Velocidad de procesamiento nominal: 400 MHz *Basado en arquitectura MIPS-BE [31].
TELNET / puerto 23
SSH/ puerto 22 vía web
HTTP/HTTPS [31].
Gigabit Ethernet LAN
5 puertos 10/100 Mbit/s
[31].
3
MEDIO. Cuenta con interfaz de usuario que no
cuenta con entorno grafico
amigable al usuario, está
desarrollado sobre software libre, su
configuración requiere
conocimientos básicos
$180.000 COP [33].
$10.000 COP
1 año
TP-LINK TL-
WR841HP
*WLAN Hardware basado en IEEE
802.11n/b/g *Tipo de WAN:
Dinámico/IP estático/ PPPoE/PPTP/L2TP/BigP
ond *Alta potencia de
transmisión inalámbrica [32].
TELNET / puerto 23
SSH/ puerto 22 [32].
4 Puertos LAN y 1puerto WAN 10/100Mbps
[32].
3
FACIL. Cuenta con interfaz
de administrador diseñada para que se pueda realizar
una fácil configuración,
adicionalmente cuenta con
múltiples tutoriales del fabricante y
usuarios.
$209.900 COP [33].
GRATUITO 4 años
25
Basados en la información recolectada se opta por usar dos tipos de tecnologías las cuales fueron MikroTik y Cisco, para la implementación el proyecto, estas tienen sistemas operativos propios del fabricante y cuentan con las conexiones necesarias para el desarrollo del proyecto. Se buscaron dos proveedores de tecnologías que facilitaran su configuración a través de consola. También que ofrecieran características comerciales costo/beneficio. Como se sabe Cisco Systems es un proveedor bastante reconocido a nivel mundial ofreciendo una amplia gama de dispositivos para diferentes aplicaciones de red, este fabricante llamó bastante la atención de este proyecto para ser incluido en las tecnologías a utilizar. Otro factor que influye en la decisión de enfocar el desarrollo del proyecto sobre estos dispositivos tipo router, es que el grupo de investigación ROMA de la Universidad Distrital Francisco Jose de Caldas cuenta con varios modelos disponibles para llevar a cabo prácticas de laboratorio, gracias a esto el proyecto tiene acceso de manera rápida y económica a los dispositivos y de esta manera se pueden realizar las pruebas necesarias para concretar el óptimo funcionamiento del modelo. Teniendo en cuenta esto, se revisaron dos referencias de routers marca Cisco y una referencia de router Mikrotik con las que cuenta el grupo de investigación ROMA, de las cuales se evaluaron parámetros esenciales para la ejecución del proyecto.
Cisco 1941: Con el IOS Original de Cisco y licencia LAN-BASE V15.1 permite acceso remoto por Telnet puerto 23, SSH puerto 22 además también tiene acceso por vía web protocolos HTTP/HTTPS, permite un enlace serial por medio del puerto de consola y un puerto AUX para comunicación por vía Telefónica o Dial-UP, el router cuenta con protocolos de enrutamiento dinámico y estático. Aunque el costo comercial del router es demasiado elevado, teniendo en cuenta que se desea adquirir únicamente para prácticas estudiantiles, se tiene la opción de adquirir este router a manera de préstamo en la empresa donde los ponentes realizan desempeño laboral, debido a estas razones se opta por este modelo de la serie 1900 de Cisco para la implementación.
26
Figura 4. Imagen de Routers Cisco series 1900/1941
Cisco Lynksys E900: Se evaluó también el router SOHO Cisco E900 Linksys con el IOS original de cisco y este solo tiene acceso por medio de HTTP/HTTPS puerto 80 o 443 a su configuración por lo que se requiere tener de una conexión a Internet Disponible.
Figura 5. Imagen de Router Linksys e900
El costo comercial del router es bajo, teniendo en cuenta que se ha diseñado para uso en hogares y oficina, pero debido a las pocas prestaciones que tiene el Router Cisco E900 con su Sistema operativo original, se debería cambiar a un sistema operativo como OpenWrt. Así que se opta por utilizar el router Cisco 1941. Respecto a lo anterior se eligió el Router Cisco 1941, dejando el sistema operativo provisto por el fabricante Mikrotik RB750GL: Para llevar a cabo la elección de la segunda tecnología se realizó una búsqueda en los routers tipo SOHO (Small office/home office) ya que la primera tecnología a tratar (el router Cisco 1941) es una tecnología orientada a entornos empresariales más exigentes y robustos. En los routers tipo SOHO un proveedor de tecnología como Mikrotik se prefirió por su sistema operativo que está basado en software libre, por ser un router de bajo costo y alto beneficio, con una amplia documentación y porque su sistema operativo puede ser instalado en un computador de escritorio emulando un Router. Por ello la referencia adquirida es la Mikrotik RB750GL [31].
Figura 6. RouterBoard 750GL
27
Los costos de los dispositivos se obtienen de cotización comercial realizada por Solutek Informática, Outsourcing tecnológico empresarial [33].
6.1 Características de dispositivos.
Los dispositivos seleccionados cuentan con una serie de características, las cuales hacen que sean ideales para su implementación en el proyecto, así mismo cuentan con una serie de características que no son relevantes al momento de evaluar el impacto que generan en la propuesta, a continuación se dará de manera breve un enfoque en las características relevantes y de omisión de los dispositivos. Los router Cisco cuentan con gran respaldo debido a su gran dominio sobre el mercado, durante los últimos tiempos se han convertido en dispositivos muy robustos con enfoque hacia el uso industrial y empresarial, esto hace que los dispositivos de tecnologías cisco brinden la confianza que requiere cualquier tipo de aplicación, red o proyecto que se base en ellos. El router cisco 1941 cuenta con soporte de protocolo de conexión telnet, ideal para la implementación que se le da en el proyecto y encaja perfectamente en el enfoque de la conexión a realizar, también cuenta con soporte a protocolos de conexión SSH, HTTP/HTTPS y puerto serial RS232, todos estos protocolos de comunicación son irrelevantes durante el proyecto, y se consideran características de omisión del dispositivo debido a que no se tendrán en cuenta en ninguna etapa del desarrollo ni de la implementación, y se consideran igualmente características de redundancia debido a que el dispositivo cuenta con gran variedad de protocolos soportados para comunicación a fin de cumplir el mismo objetivo. La gran cantidad de puertos con los que cuenta el dispositivo y las tecnologías de hardware para WLAN y LAN que soporta no serán tenidas en cuenta y no presentaran gran relevancia durante la ejecución del proyecto. En la implementación del proyecto se han tenido en cuenta los comandos de configuración DNS proporcionados por el fabricante para los router, y se ha establecido configuración en base de datos para poder hacer reutilización de estas en los procesos de configuración, teniendo en cuenta esto, se puede definir como característica de reutilización el proceso de configuración, para los diversos dispositivos que cubre el alcance del desarrollo. El router seleccionado como segunda tecnología para la implementación en el proyecto, tiene una de las características más importantes que se detectaron durante la investigación de proveedores y comparación de tecnologías y dispositivos ofrecidos, se trata de la relación costo – beneficio que tiene, pues realizando el estudio en detalle, se puede concluir que cuenta con las
28
características básicas que se requieren para el proyecto, como lo son accesibilidad a configuraciones DNS y soporte de protocolo telnet para la comunicación, esto a un precio realmente bajo, comparado con otros dispositivos de tipo SOHO que se evaluaron durante todo el proceso de investigación. La velocidad de transmisión de este dispositivo de red es muy alta en comparación con la velocidad ofrecida por algunos otros router de este rango de precios, sin embargo esta característica del router se omite y no presenta ninguna relevancia para la implementación. El RB750GL cuenta con soporte de protocolos de conexión SSH, HTTP y HTTPS, características que se determinan como redundantes debido a que para la implementación en este proyecto solo se requiere realizar conexión por socket abierto a través de protocolo telnet.
8. ESTANDARIZACIÓN DE MODELO DE CONFIGURACIÓN DE BUSQUEDA DNS EN DISPOSITIVOS ROUTERS
La estandarización se refiere a un proceso de unificación de características en un producto, servicio, procedimiento, etc; esto con el fin de establecer un modelo a seguir aplicable a las características comunes de todos los componentes que se quieran estandarizar.
Hay que tener en cuenta que en un modelo estandarizado se debe incluir la mayor parte de características posibles de los elementos a estandarizar, debido a que si no son suficientes no se puede llegar al objetivo principal que consiste en unificar procesos.
El modelo puede ser parametrizable o configurable, es decir, el modelo se aplica a varios elementos pero una configuración distinta para cada elemento puede hacer que el modelo acapare más procesos del elemento en uno solo,
La estandarización del modelo de configuración DNS para router debe cumplir con lo mencionado anteriormente.
7.1 Análisis de Componentes del modelo de configuración DNS para Routers
Los componentes del modelo son todos aquellos elementos que de una u otra manera inciden en el proceso que se quiere estandarizar. Para el caso de los componentes del modelo de configuración DNS para Routers se deben tener en cuenta todos los elementos técnicos, físicos, de conexión, además de los elementos dependientes de otros, y la intervención en el proceso por parte de elementos externos al sistema. De acuerdo a esto, se encuentran los siguientes elementos que afectan este proceso:
29
ELEMENTO DESCRIPCIÓN INCIDENCIA EN
PROCESO
JUSTIFICACIÓN DEPENDENCIAS
Usuario Persona que requiere
configurar DNS en un Router
MEDIA Solo el usuario puede definir como desea realizar el proceso, aunque hay elementos que no
dependen de el
No
Dispositivo Router que se quiere configurar
ALTA Es el elemento principal del proceso
Conexión
Terminal Equipo por medio del cual se realiza la configuración
BAJA El equipo no debe tener tanta afectación debido a que no se
necesitan mayores especificaciones técnicas del mismo para poder realizar el
proceso
Dispositivo, Conexión,
Usuario
Interfaz Software o sistema operativo en el
cual se realiza la conexión al
dispositivo y se realiza la
configuración
MEDIA La interfaz depende en gran parte de lo que el usuario
requiera además de las condiciones de conexión al
dispositivo
Usuario, Proceso,
Comandos
Conexión Unión entre la interfaz y el
dispositivo por medio de
protocolo Telnet
MEDIA La conexión permite que cualquier proceso de
configuración que se requiera se haga de manera
satisfactoria
Dispositivo, Interfaz
Algoritmo Conjunto ordenado de
comandos hechos sistemáticamente aplicados en una interfaz para la
configuración del Router
ALTA Los algoritmos son aplicados en una interfaz para uso del usuario, estos pueden ser parametrizables o no de
acuerdo a lo que requiera el usuario
Todos
Comandos Instrucción u orden dada desde la interfaz hacia el
dispositivo
BAJA Los comandos no son los mismos para todos los
dispositivos y estos se pueden configurar en la interfaz
Proceso, Usuario,
Dispositivo
Conocimiento Técnico
Facultad del usuario para
realizar el proceso de configuración DNS en Router
MEDIA Se debe tener el conocimiento para el levantamiento del
modelo a partir del dispositivo, ya con el resultado del modelo
no se necesita tanto conocimiento del mismo
Usuario, Proceso
30
Proceso Operaciones que se deben hacer al
dispositivo por medio de los
comandos
ALTA Es el resultado esperado al incluir a todos los elementos
en un estándar
No Aplica
Tabla 4. Elementos que inciden en proceso para estandarización
De acuerdo a lo anterior, se puede evidenciar que el elemento Algoritmo es quien más depende del resto de componentes para su funcionamiento, es decir, que este elemento es el que se puede estandarizar en un modelo.
Se indaga entonces, la razón por la cual es la que más incide en el proceso encontrando un flujo en común, que se presenta en la mayoría de los procesos de configuración DNS de los dispositivos procedentes del estudio realizado anteriormente. Esto se puede ver a continuación en la figura 7.
Figura 7. Diagrama de contexto de configuración DNS en Router.
7.2 Algoritmos de configuración de Router CISCO y Router
Aplicando lo encontrado anteriormente, se obtienen los algoritmos de
configuración de los dos routers seleccionados luego del estudio. Los algoritmos
para cada Router se muestran a continuación.
31
Figura 8.Algoritmo de Configuración DNS Router Cisco.
32
Figura 9.Algoritmo de Configuración DNS Router MikroTik.
7.3 Estandarización de los componentes
Con el estudio de proveedores así como el estudio de los componentes del proceso de configuración DNS en Routers se determina hacer un modelo con las siguientes características de acuerdo a los elementos que lo componen:
ELEMENTO TIPO DE ESTANDARIZACION PARAMETRIZABLE JUSTIFICACIÓN
Usuario No Aplica No Aplica
El usuario interactúa mas no realiza cambios de configuración
Dispositivo Precargado No
El dispositivo ya cuenta con comandos y configuraciones propias
33
Terminal
No No
El terminal en donde se encuentre la interfaz no debe afectar el funcionamiento de la misma
Interfaz Instalación Dinámica Si
La interfaz se debe poder instalar en cualquier terminal que se pueda conectar al dispositivo
Conexión Precargado No
La conexión se va a poder realizar de manera automática
Algoritmo Dinámico Si
El algoritmo es dinámico de acuerdo al dispositivo que se quiere configurar
Comandos Precargados o configurables Si
Los comandos son variables que definen el proceso
Conocimiento Técnico
Aplicación al Proceso No
EL conocimiento técnico va a permitir desarrollar un modelo
Proceso No Aplica No
El proceso va a ser parte de la estandarización realizada
Tabla 5. Elementos de estandarización del modelo
7.4 Desarrollo de un modelo UML basado en algoritmos para la configuración de dos diferentes routers.
El desarrollo de software depende generalmente de tres etapas: desarrollo del algoritmo, programación y pruebas. Anteriormente se dedicaba un 40% del tiempo dedicado a desarrollar el algoritmo y aplicar las pruebas de funcionamiento, y el tiempo restante a la programación en un lenguaje determinado. Ahora con el análisis basado en UML se busca implementar un 60% del tiempo en el desarrollo del algoritmo, y el otro 40% del tiempo se destina a la programación y a las pruebas, esto da un gran peso a las acciones previas a la programación, por lo tanto es de gran importancia contar con buenas especificaciones del proyecto a realizar. En primera medida se consideran las especificaciones técnicas de los dispositivos a implementar, y el tipo de conexión que soportan, teniendo en cuenta que se establece Telnet como protocolo de comunicación para este proyecto. Se tienen en cuenta parámetros de configuración como IP de dispositivos y contraseñas de acceso a routers para que se establezca la conexión adecuada que permita la correcta configuración de router, todos estos parámetros de conexión se consideran por parte del algoritmo, identificando automáticamente los valores y parámetros propios de cada router, de esta manera el aplicativo llevara a cabo tareas de reconocimiento y configuraciones iniciales de manera autónoma, sin dejar de lado el tema de control de accesos solicitando contraseña de acceso al router, de manera previa a la conexión para configuración.
34
El proyecto se desarrolló implementando conexión a base de datos Mysql a manera de que sean parametrizables los comandos de configuración y dispositivos con los cuales puede interactuar el aplicativo. Teniendo estas especificaciones claras, se procede a realizar el modelo basado en algoritmos diseñados en base a 3 principales funcionalidades.
7.4.1 Desarrollo de algoritmo para la configuración de DNS en dispositivos de diferentes proveedores.
Realizado el análisis técnico y funcional de la aplicación y teniendo en cuenta los actores implicados en el proceso de configuración de DNS, se procede a crear el algoritmo que se describe en las siguientes etapas:
1. Cargar elementos de la interfaz de usuario del aplicativo 2. Identificación de las variables de la red (dirección IP, puerto). 3. Establecer comunicación con el router. (Solicitud de contraseña) 4. Reconocer que router se conectó al aplicativo 5. Envío de comandos al router, configuración de red requerida por el usuario 6. Recepción información proveniente del router, verificación de la
configuración 7. Cierre de la aplicación.
Estas etapas se visualizan mejor en el diagrama de flujo de la figura 10. El algoritmo fue sometido a diferentes modificaciones para poder ser plasmado en la figura 10. Como se mencionó anteriormente el trabajo dedicado antes de la programación debe ser extenso, someter el algoritmo a revisiones más rigurosas, para evitar el gasto de recursos al momento de realizar la programación. Para comprobar la validez de este algoritmo se implementó por medio lenguaje específico para la aplicación desarrollado en Java, el resultado será descrito más adelante en el documento.
35
36
Figura 10. Diagrama de actividades configuración DNS
7.4.2 Desarrollo de algoritmo para la configuración de registros en base de datos de acuerdo a los parámetros propios de cada dispositivo router a implementar.
Basando el desarrollo del algoritmo en el análisis realizado sobre las
especificaciones técnicas y funcionales de la aplicación, se establece que el
algoritmo se debe basar en las siguientes etapas:
1. Cargar elementos de la interfaz de usuario del aplicativo
2. Solicitud de parámetros a cargar en base de datos.
37
3. Realiza conexión a base de datos.
4. Cargue de registros en base de datos.
5. Cierre de la aplicación.
Estas etapas se visualizan mejor en el diagrama de flujo de la figura 11.
Figura 11. Diagrama de actividades registró en base de datos.
7.4.3 Desarrollo de algoritmo para la actualización de registros en base de datos de acuerdo a los parámetros propios de cada dispositivo router a implementar.
Basando el desarrollo en un aplicativo configurable y abierto para que se puedan
realizar diferentes parametrizaciones sobre dispositivos y protocolos a configurar,
se desarrolla un algoritmo para permitir la actualización de los parámetros
38
previamente configurados en base de datos, este algoritmo se puede describir con
las siguientes etapas:
1. Cargar elementos de la interfaz de usuario del aplicativo
2. Realiza conexión a base de datos.
3. Solicitud de parámetros a actualizar en base de datos.
4. Actualización de registros en base de datos.
5. Cierre de la aplicación.
Estas etapas se visualizan mejor en el diagrama de flujo de la figura 12.
Figura 12. Diagrama de actividades Actualización en base de datos
39
7.4.4 Casos de uso
De acuerdo a los modelos recomendados se procede a desarrollar la lógica del
negocio mediante un documento que define el caso de uso que interpreta la
relación del usuario con el aplicativo para cada servicio que este exponga.
Dichos casos de uso se encuentran anexos al documento y se encuentra la
relación del usuario o actor con el sistema integralmente en el siguiente diagrama:
Figura 13. Diagrama de casos de uso general.
Anexos:
Anexo A: Caso de uso del servicio de configuración DNS.
CU01_CONFIGURAR_DNS_V1.0
Anexo B: Caso de uso del servicio de configuración de base de datos.
CU02_CONFIGURAR_BD_V1.0
Anexo C: Caso de uso del servicio de actualización de base de datos.
CU03_ACTUALIZAR_BD_V1.0
7.4.5 Interfaz grafica
Luego de desarrollar la lógica contenida en los casos de uso se obtiene una interfaz gráfica que funciona como se define en el documento anexo.
Anexos:
Anexo D: Manual de usuario para la aplicación Configurador DNS.
MUS01_CONFIGURADOR_DNS_V1.0
40
7.4.6 Diagrama de clases
Teniendo en cuenta todas las capas que plantean las metodologías de buenas
prácticas en el desarrollo de software, se ha realizado un análisis de clases para el
proyecto en base a los siguientes diagramas de clases:
Para el modelo desarrollado encontramos diez clases las cuales se describen a continuación:
Clase Init
Figura 14. Clase Init
Esta clase expone los métodos y atributos que se implementan para la
inicialización del servicio, ejecuta métodos estáticos que permiten desplegar la
interfaz gráfica y cuenta con métodos públicos, que permiten que se realice la
ejecución tanto dentro como fuera de la clase es decir, es accesible desde
cualquier capa de la aplicación.
Clase conector
Figura 15. Clase Conector
41
Esta clase se enfoca en permitir la conexión vía socket entre el aplicativo y el
router, para esto, implementa métodos y atributos públicos que pueden ser
ejecutados desde cualquier capa de la aplicación.
Clase ConfDNS
Figura 16. Clase ConfDNS
Esta clase expone la interfaz gráfica que permite interactuar con la capa DAO del
aplicativo para llevar a cabo tareas de registro en base de datos, implementa
métodos y atributos públicos.
Clase ConfRouter
Figura 17. Clase ConfRouter
Esta clase expone la interfaz gráfica que permite al aplicativo llevar a cabo tareas
de configuración de router, ejecuta protocolos de conexión vía telnet y ejecuta la
42
capa DAO que se encarga de realizar consultas en base de datos, implementa
métodos y atributos públicos, así como métodos y atributos de tipo privado que
solo pueden ser implementados desde la misma clase.
Clase ModDNS
Figura 18. Clase ModDNS
Esta clase expone la interfaz gráfica que permite al aplicativo interactuar con la
capa DAO que ejecuta métodos de actualización de registros en base de datos,
implementa métodos y atributos públicos.
Clase AtributosIP
Figura 19. Clase AtributosIP
43
Esta clase implementa métodos públicos y atributos privados que se encargan de
generar el objeto DTO diseñado para almacenar parámetros de configuración de
la red, y exponer estos parámetros para poder realizar interacciones con estos.
Clase IpConfig
Figura 20. Clase IpConfig
Esta clase se encarga de realizar las verificaciones de parámetros de
configuración de la red, implementa métodos públicos y atributos estáticos.
Clase Constantes
Figura 21. Clase Constantes
La clase constantes expone atributos públicos que permiten mantener valores que
no son configurables y se pueden aplicar desde todas las clases del servicio.
44
Clase ConexionDAO
Figura 22. Clase ConexionDAO
Esta clase implementa métodos y atributos públicos que componen la capa DAO
que se encarga de realizar conexión a base de datos para la implementación de
objetos tipo tabla que expone MySql.
Clase ServiciosBD
Figura 23. Clase ServiciosBD
Esta clase implementa métodos y atributos públicos que componen la capa DAO
que se encarga de exponer los servicios de actualización, consulta e inserción en
base de datos.
Integralmente las clases componen todo el aplicativo que interactúa entre sí,
teniendo en cuenta las capas necesarias para la óptima implementación del
servicio, basado en modelos de buenas prácticas de programación.
45
Se puede ver en el siguiente diagrama de clases integral, la relación que existe
entre clases, y la herencia que se genera a partir de ciertas clases que se
diseñaron para ser implementadas en el aplicativo globalmente.
Figura 24. Diagrama de clases
46
7.5 Selección de lenguajes de programación
Dentro de la propuesta del proyecto se planteó la necesidad de ofrecer al usuario una interfaz gráfica sencilla, de fácil acceso y de uso práctico, desarrollada mediante un lenguaje de programación que permitiera plasmar en el software los parámetros descritos anteriormente en el algoritmo. Realizando el estudio de las tecnologías de vanguardia, se llega a la selección de Java 1.7 como lenguaje de programación orientado a objetos, que permite que se cree software con las últimas tecnologías de desarrollo y esto conllevara que la aplicación se encuentre basada en un lenguaje de programación global, para su fácil integración con otros sistemas o aplicaciones [34]. Dentro de las API implementadas por java para el desarrollo del proyecto, se decidió implementar Swing que es una librería gráfica, desarrollada inicialmente por Netscape y la cual fue publicada inicialmente en el año de 1996 [35]. Esta librería cuenta con las herramientas requeridas para poder desarrollar una interfaz bastante amigable y funcional, con miras a la realización del proyecto. El entorno de programación implementado ha sido Netbeans, debido a que es un entorno de desarrollo de uso libre y creado principalmente para lenguaje de programación Java, lo que brinda el respaldo necesario para poder tener finalmente un software que cumpla con todos los estándares de calidad. El desarrollo requiere de conexión a base de datos, para lo cual se decide hacer uso de MySql, que es una de las bases de datos open source más grandes del mundo, que adicionalmente cuenta velocidades de lectura y velocidades operacionales muy altas [36]. Como protocolo de conexión al router se implementa TELNET que permite generar una conexión de comunicación entre el terminal (PC) y el router que cuenta con un sistema ejecutor de comandos, esta conexión se realiza por el puerto 23, diseñado para este fin.
9. PRUEBAS UNITARIAS
Se realizaron distintas pruebas a los dos routers seleccionados en el estudio ejecutando comandos de configuración DNS, así como ejecutando la misma configuración por medio de la aplicación desarrollada.
Anexos: Anexo E: Pruebas Unitarias del servicio de configuración DNS.
PU01_CONFIGURADOR_DNS_V1.0
47
10. RESULTADOS OBTENIDOS
Con las métricas tomadas en las pruebas unitarias se evidencia lo siguiente:
METRICA DISPOSITIVO CONFIGURACION RESULTADO
Ingresos de comandos al
sistema
Router Cisco Comandos 132 ingresos
Tiempo de configuración
Router Cisco Comandos 2 Minutos 41 Segundos
Velocidad de Respuesta
Router Cisco Comandos Instantánea
Ingresos de comandos al
sistema
Router Mikrotik Comandos 156 ingresos
Tiempo de configuración
Router Mikrotik Comandos 3 Minutos 11 Segundos
Velocidad de Respuesta
Router Mikrotik Comandos Instantánea
Ingresos de comandos al
sistema
Router Cisco Aplicación 6 ingresos
Tiempo de configuración
Router Cisco Aplicación 48 Segundos
Velocidad de Respuesta
Router Cisco Aplicación Instantánea
Ingresos de comandos al
sistema
Router Mikrotik Aplicación 6 ingresos
Tiempo de configuración
Router Mikrotik Aplicación 54 Segundos
Velocidad de Respuesta
Router Mikrotik Aplicación Instantánea
Tabla 6. Resultados obtenidos en las pruebas unitarias
Esto evidencia que el desarrollo del modelo optimiza tanto los ingresos de comandos al sistema así como el tiempo de configuración del mismo.
La velocidad de respuesta del dispositivo no se ve afectada.
Cabe anotar, que estos resultados no tuvieron en cuenta el hecho de que para configuración por comandos de consola se necesita un conocimiento técnico previo.
48
11. CONCLUSIONES
Llevando a cabo estudios realizados sobre tecnologías, costos comerciales, características y aplicabilidad de configuración de búsqueda DNS de proveedores de dispositivos router, se obtiene toda la información necesaria para tener la claridad sobre los mismos, que se adaptan a las necesidades del requerimiento y son ideales para realizar la implementación en el proyecto.
La implementación del modelo, basado en algoritmos de configuración aplicados por los proveedores seleccionados, reduce el tiempo de desarrollo considerablemente y facilita el control del proceso y la ejecución de las tareas programadas para la configuración de búsqueda DNS.
La estandarización basada en algoritmos de configuración implementada por los proveedores seleccionados, facilita los procesos a fin de popularizar las prácticas de configuración de búsqueda DNS para personal que cuente o no con conocimientos previos sobre dichas labores.
Este proyecto insta a que se lleven a cabo futuros desarrollos sobre la herramienta de administración, a fin de lograr una funcionalidad integral de todos los procesos de configuración de Búsqueda DNS en dispositivos Router de diferentes proveedores, así como de otros procesos relacionados con la configuración de estos dispositivos.
49
12. AGRADECIMIENTOS
Queremos agradecer primeramente a Dios por permitirnos realizar el proyecto, también al Ing. Gustavo Higuera por su asesoría y colaboración constante durante el desarrollo del proyecto, agradecemos a nuestra familia por el constante apoyo y a todas las personas que con cada uno de sus aportes contribuyo a la finalización exitosa de este proyecto.
50
13. REFERENCIAS
[1] Luna Valero Francisco. "Meta heurísticas avanzadas para problemas reales en redes de telecomunicaciones". [En línea] Marzo de 2016, disponible en http://neo.lcc.uma.es/tesis/F.Luna.Phd.Dissertation.pdf
[2] Araque Álvarez Juan Camilo, Espinosa Torres Sindy Lorena. "Desarrollo de un modelo para la configuración vlan de switch de las plataformas cisco y huawei"
[3] Solano Arenas John Camilo, Jaimes Fajardo Leonardo Andrés "Implementación en Java del modelo de propagación Andino UIS® para planificación y análisis de redes celulares sobre CellGis" [En línea] Febrero de 2016, disponible en http://repositorio.uis.edu.co/jspui/bitstream/123456789/3308/2/125826.pdf
[4] Juan Bernardo Quintero, Raquel Anaya. (Diciembre 2007). 2MDA Y EL PAPEL DE LOS MODELOS EN EL PROCESO DE DESARROLLO DE SOFTWARE2. EIA, ISSN 1794-1237 Número 8, 131-146. [En línea] Consultado en marzo de 2016, disponible en http://repository.eia.edu.co/revistas/index.php/reveia/article/view/190/187
[5] “A Modification of Jacobson et al.’s (1997) Individual Branch-Antlered Male Method for Censusing White-Tailed Deer” PDF [En línea] Consultado marzo de 2016, disponible en
http://research.amnh.org/~rfr/hbp/weckeletal11b.pdf
[6] Brian Henderson-Sellers Director of the Centre for Object Technology Applications and Research, and Professor of Information Systems at the University of Technology, Sydney. “On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages”.
[7] Carlos Johany Sierra Guzman. (2016). Desarrollo de un algoritmo para la configuración de dos tecnologías de routers utilizando MDA. Universidad Distrital Francisco José de caldas. Bogotá, Colombia [En línea] Consultado en marzo de 2016, disponible en Universidad Distrital Francisco José de caldas. Bogotá, Colombia [6] CUERVO, F., GREENE, N., HUITEMA, C., RAYHAN, A., ROSEN, B. y SEGERS, J. (2000). Megaco Protocol versión 0.8. RFC 2885, Agosto 2000.
[8] “Que es un router” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en: http://es.ccm.net/faq/2757-que-es-un-router
[9] “El principio de funcionamiento del router” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en: http://resumenes.eu/index.php?newsid=172128
[10] “Arquitectura de los routers” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en: http://www.textoscientificos.com/redes/arquitectura-routers
[11] “Configuración de Switch - Router” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en https://www.mhe.es/cf/ciclos_informatica/844819974X/archivos/unidad9_recurso1.pdf
[12] “Blog de Javier Smaldone, Como funciona el DNS” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en: https://blog.smaldone.com.ar/2006/12/05/como-funciona-el-dns/
[13] “Arquitectura DNS” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en: https://technet.microsoft.com/es-es/library/dd197427%28v=ws.10%29.aspx
51
[14] “Definición de DNS” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en https://msdn.microsoft.com/es-es/library/cc787920%28v=ws.10%29.aspx
[15] Iris Reinhartz-Berger, Arnon Sturm , Tony Clark, Sholom Cohen, Jorn Bettin. (2013). Domain-Specific Languages and Standardization: Friends or Foes?. In Domain Engineering. Part II, pp. 159-186. Berlin: Springer.
[16] Carl Bamford, Paul Curran. (1991). SQL. In Data Structures, Files and Databases, pp 209-228. UK: Macmillan Education.
[17] Haim Kilov, Bernhard Rumpe, Ian Simmonds. (1999). UML, The Future Standard Software Architecture Description Language?. In Behavioral Specifications of Businesses and Systems, pp. 195-207. New York: Springer US.
[18] “Extensible Markup Language (XML)”. [En línea] consultado marzo 13 de 2016 10:00 am, disponible en: W3C. www.w3.org/XML/
[19] Joachim Fischer, Markus Scheidgen, Ina Schieferdecker, Rick Reed. (2015). SDL: Model-Driven Engineering for Smart Cities. Switzerland: Springer International Publishing.
[20] Marco Bernardo, Vittorio Cortellessa, Alfonso Pierantonio. (2012). MDE Basics with a DSL Focus. In Formal Methods for Model-Driven Engineering, pp. 21-57. Berlin: Springer.
[21] Oscar Pastor, Juan Carlos Molina. (2007). The Need for New Development Environments. In Model-Driven Architecture in Practice, pp. 13-18. Berlin: Springer.
[22] Liming Zhu. (2011). Model-Driven Architecture. En Essential Software Architecture, pp. 201-217. Berlin: Springer.
[23] García Díaz, Vicente (2012). Ingeniería Dirigida por Modelos [Imagen]. Recuperado de Universidad de Oviedo, databases.
[24] “Ontology Definition Metamodel Request For Proposal” [En línea] consultado marzo 13 de 2016 10:00 am, disponible en http://www.omg.org/cgi-bin/doc?ad/2003-3-40
[25] “The Architecture Of Choice For A Changing World” [En línea] consultado marzo 13 de
[26] John Cowley. (2013). Network Protocols. En Communications and Networking, pp.81-109. London: Springer.
[27] Comer (2000). Sect. 11.2 - The Need For Multiple Protocols, p. 177, "They (protocols) are to communication what programming languages are to computation"
[28] “Cisco 1800 Series Integrated Services Routers (Modular) Hardware Guide” PDF consultado Agosto 11 de 2016, disponible en http://www.cisco.com/c/en/us/td/docs/routers/access/1800/1841/hardware/installation/guide/hw.pdf
[29] “Cisco 1941 Series Integrated Services Routers Data sheet” [En línea] consultado Agosto 11 de 2016, disponible en http://www.cisco.com/c/en/us/products/collateral/routers/1900-series-integrated-services-routers-isr/data_sheet_c78_556319.html
[30] “ROUTER INALÁMBRICO N300 LINKSYS E900” [En línea] consultado Agosto 11 de 2016, disponible en http://www.linksys.com/co/p/P-E900/
52
[31] “RouterBOARD con 5 puertos Ethernet MIKROTIK RB750” [En línea] consultado junio 18 de
2016 9:00 am, disponible en http://www.ds3comunicaciones.com/mikrotik/RB750.html
[32] “Router Inalámbrico Alta Potencia N 300Mbps” [En línea] consultado Agosto 11 de 2016, disponible en http://www.tp-link.com/co/products/details/TL-WR841HP.html
[33] Solutek informática Outsourcing tecnológico, Cotización comercial de dispositivos de red, solicitada Agosto 11 de 2016, sitio web http://www.solutekcolombia.com/venta_tecnologia
[34] “¿Qué es java?” [En línea] consultado junio 20 de 2016 2:00 pm, disponible en https://www.java.com/es/download/faq/whatis_java.xml
[35] “Swing biblioteca grafica Java” [En línea] consultado junio 20 de 2016 2:30 pm, disponible en https://es.wikipedia.org/wiki/Swing_(biblioteca_gr%C3%A1fica)
[36] “¿Why MySql?” [En línea] consultado junio 20 de 2016 2:30 pm, disponible en https://www.mysql.com/why-mysql/
