Plan de Trabajo
Contexto
Para la realización del proyecto Teldatsi durante el periodo octubre 2009 - octubre 2010 hemos propuesto el siguiente plan de trabajo:
Implementación de protocolos de routing
Esta parte será llevada a cabo por Alexandru Ionut Grama y consta de las siguientes partes
| Tareas | Estado | Comentarios adicionales | |
|---|---|---|---|
| Octubre 2009 | Hacer un sistema de ficheros y kernel | Completado | No funciona el kernel con NFS |
| Instalar las utilidades lo más reducidas posibles | Completado | Sistema Ficheros + Quagga stripped = 6,5 Mb | |
| Implementar IPSEC | En Proceso | ||
| Noviembre 2009 | Rip v2 | No empezado | |
| BGP | No empezado | ||
| OSPF | No empezado | ||
| Reparar el bootloader del router con linux | No empezado | ||
| Pruebas IPSEC | No empezado | ||
| Diciembre 2009 | Pruebas IPSEC | No empezado | |
| Pruebas Rip v2, BGP y OSPF | No empezado | ||
| Enero 2010 | L2TD/IPSEC | No empezado | |
| Febrero 2010 | Pruebas L2TD/IPSEC | No empezado | Las pruebas las hago en esta época ya que hay exámenes |
| Marzo 2010 | NAT, iptables y netfilter(estático,dinámico y puertos | No empezado | |
| Abril 2010 | Pruebas NAT | No empezado | |
| SNMP (administración) | No empezado | ||
| Mayo 2010 | BRS | No empezado | |
| Multicast (PIM) | No empezado | ||
| NTP (sincronización de tiempos | No empezado | ||
| Junio 2010 | Pruebas BRS y NTP | No empezado | |
| Pruebas Multicast | No empezado | ||
| Julio 2010 | PPPoE | No empezado | |
| ATM, NHRP y PPPoA | No empezado | Tarjetas ATM necesarias | |
| Agosto 2010 | Vacaciones | ||
| Septiembre 2010 | Pruebas ATM | No empezado | |
| Redactar informe calidad y TFC | No empezado | ||
| Octubre 2010 | Redactar informe calidad y TFC | No empezado |
Porting de lenguajes de Scripting
Esta parte será llevada a cabo por Christian Van de Walle Coello y consta de las siguientes partes
| Tareas | Estado | Comentarios adicionales | |
|---|---|---|---|
| Octubre 2009 | Hacer un sistema de ficheros y kernel | Completado | No funciona el kernel con NFS |
| Estudiar la viabilidad de los lenguajes de Scripting | Completado | ||
| →TCL | Completado | Ocupa 800KB, funciona bastante bien, tiene sockets | |
| →Python | Completado | Estudiado PyMite, descartado por ahora | |
| →Perl | Completado | Funciona correctamente, pero no he conseguido que tenga sockets | |
| →Ruby | Completado | Ocupa 2,6MB, funciona bien y tiene sockets | |
| →Lua | Completado | Ocupa 800+150KB, funciona bien, tiene sockets | |
| Noviembre 2009 | →PHP | Completado | Ocupa 1,8MB, funciona bien y tiene sockets |
| →JSP | Completado | Descartado, necesita máquina virtual de 32MB | |
| →JavaScript | Completado | 600KB, funciona bien, sin sockets | |
| →ASP | Completado | Descartado, no es posible | |
| →AngelScript | Completado | Descartado, es una biblioteca para compilar scripts | |
| →Squirrel | Completado | 267KB, es como el LUA pero sin sockets | |
| Diciembre 2009 | Evaluar los lenguajes viables (pruebas de CPU, memoria…) | No Empezado | |
| →Elegir el lenguaje con mayor rendimiento | No Empezado | ||
| Enero 2010 | Estudiar a fondo el sistema de menú actual | No Empezado | |
| Diseñar la nueva estructura de menús en el nuevo lenguaje | No Empezado | ||
| Febrero 2010 | Desarrollar el nuevo sistema de menús | No Empezado | |
| Marzo 2010 | Desarrollar el nuevo sistema de menús | No Empezado | |
| Abril 2010 | Evaluar el nuevo sistema y comparar con el actual | No Empezado | |
| Mayo 2010 | Incorporar un servidor http al router | No Empezado | |
| Diseñar web compatible y basada en el nuevo menú | No Empezado | ||
| Junio 2010 | Desarrollar la web | No Empezado | |
| Julio 2010 | Desarrollar la web | No Empezado | |
| Agosto 2010 | Vacaciones | ||
| Septiembre 2010 | Redactar informe calidad y TFC | No Empezado | |
| Octubre 2010 | Redactar informe calidad y TFC | No Empezado |
El objetivo último de este proyecto es conseguir portar un Lenguaje de Scripting que sea lo suficientemente potente como para poder implementar todos los scripts de configuración del router con él, de forma cómoda y fiable, y sin tener que hacer uso de herramientas externas (exceptuando Quagga y otras herramientas que se consideren imprescindibles).
Para poder realizar esta tarea, será necesario primero familiarizarse con el router X60 de Teldat y leer toda la documentación sobre el mismo, tanto la suministrada por Teldat como la recabada por los compañeros del año anterior. Se repetirán los pasos documentados del año anterior para aprender el manejo de las herramientas de desarrollo utilizadas, tales como Busybox y Buildroot. El primer objetivo será conseguir toda la funcionalidad alcanzada el año pasado y tener las herramientas necesarias para poder desarrollar aplicaciones para el router.
Tras esto, se procederá a hacer el estudio de los diferentes Lenguajes de Scripting. Lo primero será hacer una selección amplia de los lenguajes sobre los que se va a trabajar para así ir descartando aquellos que no cumplan los criterios marcados. La idea es ir aplicando una serie de filtros o criterios para ir reduciendo el número de lenguajes hasta obtener uno o varios sobre los cuales desarrollar los scripts de configuración.
Los criteros que se aplicarán son los siguientes (en este orden):
- Viabilidad: Se estudiará si el porting del lenguaje es viable, es decir, si cumple con los requisitos de memoria y espacio en disco del router y se puede implementar el intérprete en el S.O. del router.
- Sockets: Como se ha dicho anteriormente, se espera que el lenguaje elegido no necesite ninguna herramienta extena como sucede con el sistema actual, que hace uso de Netcat para comunicarse con Quagga. Es necesario que el lenguaje permita implementar sockets.
- Facilidad para implementar un servidor HTTP: Este criterio no será determinante para descartar o no un lenguaje, pero es un punto muy interesante, tal y como se explicará más adelante.
- (por definir)
Una vez se disponga de un conjunto de lenguajes que se consideren portables, se realizará un estudio comparativo de todos ellos, con pruebas de rendimiento en el uso de la CPU, memoria, entrada/salida, etc, y se elegirá el que mejor se adapte a las necesidades del proyecto.
A continuación se rediseñará la aplicación de menús para adaptarla al lenguaje elegido, para ello, se estudiará a fondo el sistema actual y se diseñará otro equivalente, desarrollado por completo en el nuevo lenguaje. Sin embargo, no se ha planteado un nuevo sistema de menús por consola, sino que esté orientado a un interfaz web, por ser ésto más interesante de cara a su desarrollo. Esto plantea otras dificultades adicionales como poder incorporar un servidor HTTP al router, por esta razón sería muy interesante poder desarrollar el servidor en el mismo lenguaje de scripting.
