Modelado y Simulación de un Nodo Activo

IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 5, DECEMBER 2005
383
Modelado y Simulación de un Nodo Activo
Pablo Magé, Amalio F. Nieto, Mercedes Garijo, Departamento de Ingeniería de Sistemas Telemáticos,
Universidad Politécnica de Madrid
Resumen-- Las Redes Activas (ANs) buscan insertar
programabilidad en la parte intermedia de las redes IP,
buscando mejorar la flexibilidad y el desempeño de la red
mediante la inserción dinámica de servicios y protocolos. En este
artículo se describe la actividad de simulación realizada en el
proyecto ANDROID (Active Network Distributed Open
Infrastructure Development). En ANDROID se implementó una
infraestructura de red programable, escalable y gestionada,
basando sus esfuerzos en la alternativa de las Redes Activas. En
la infraestructura de Red Activa de este proyecto se distinguen
dos tipos de nodo: Los Encaminadores Activos (ARs) y los
Servidores Activos (ASs). En este documento se describe el diseño
e implementación del modelo de simulación del nodo AS, usando
como herramienta de modelado el OPNET Modeler.
Palabras Clave—arquitecturas, redes activas, seguridad,
servicios activos, simulación.
I. INTRODUCCIÓN
E
L presente crecimiento de desarrollo e implantación de
nuevos servicios en las redes de comunicación y la
dificultad que esto involucra, a motivado la búsqueda de
diversas propuestas de redes programables. Inicialmente los
desarrollos de más trascendencia se realizan en el programa de
Redes Activas, patrocinado por DARPA desde 1996. Las
Redes Activas emergen como una de las propuestas más
prolíficas, pues hoy en día existen grupos de investigación en
América de Norte, Europa y Asia, buscando encontrar una
solución adecuada a las especificaciones de este novedoso tipo
de red. Para dar soporte a las Redes Activas existen trabajos
de investigación que recurren al uso de las nuevas tecnologías
existentes hoy en día tales como aplicaciones intermedias
(middleware), agentes móviles, agentes inteligentes, lenguajes
de alto nivel, etc. En el proyecto ANDROID (Active Network
DistRibuted Open Infrastructure Development) [1]
patrocinado por el programa IST de la Comisión Europea, se
demostró que es posible obtener una infraestructura
programable, escalable y gestionada, basando sus esfuerzos en
la arquitectura de las Redes Activas. El grupo de
investigadores de la Universidad Politécnica de Madrid
Este trabajo fue apoyado por el 5th programa marco IST de la Comisión
Europea, proyecto IST-1999-10299-ANDROID.
P. A. Magé es candidate a PhD en el Departamento de Ingeniería de
Sistemas Telemáticos, Universidad Politécnica de Madrid, CP 28040 (e-mail:
[email protected], [email protected]).
A.F. Nieto esta con el Departamento de Ingeniería de Sistemas
Telemáticos, Universidad Politécnica de Madrid, España (e-mail:
[email protected]).
M. Garijo esta con el Departamento de Ingeniería de Sistemas
Telemáticos, CP 28040 SPAIN (e-mail: [email protected]).
participó en el diseño e implementación de modelos de
simulación, modelos diseñados para predecir comportamientos
de los elementos activos de la infraestructura de red.
En este artículo inicialmente se describirán los conceptos
básicos, características y trabajos de investigación en Redes
Activas. Posteriormente se realiza una descripción de la
implementación del modelo de simulación del nodo AS, pues
esta corresponde a la tarea realizada por los autores de este
artículo, actividad enmarcada dentro del proyecto ANDROID.
Las Redes activas son una novedosa propuesta en la cual
programas “personalizados” son ejecutados dentro de las
redes convencionales IP [2]. Estos programas pueden ser
ejecutados en nodos intermedios denominados nodos activos.
Como resultado de la ejecución de los programas
“personalizados” se puede modificar el comportamiento o el
estado de los nodos visitados [3]. Una arquitectura común de
nodo activo [4] ha sido definida dentro del programa de Redes
Activas de DARPA. En esta arquitectura cada nodo activo
contiene su propio sistema operativo (NodeOS) y varios
entornos de ejecución (EEs). El NodeOS es responsable del
control y manejo de los recursos y de la seguridad del nodo
activo. Además, el EE es el responsable de facilitar las
condiciones necesarias para la ejecución de programas activos
sobre el nodo activo. Los usuarios debidamente habilitados
pueden interactuar con el nodo activo para solicitar la
ejecución de un programa activo (servicio activo). Las Redes
Activas poseen un conjunto de características esenciales que
las diferencian de las redes convencionales, comenzaremos
esta corta descripción tratando las características esenciales.
A. Características de las Redes Activas
En [5] se describen las características esenciales a tener en
cuenta al implementar una Red Activa. Estas son:
1) Programabilidad:
Define la capacidad de la red para proveer a los nodos
intermedios de un modelo computacional. El éxito de esta
característica depende del API de red, la potencia del lenguaje
de programación, la capacidad de almacenamiento temporal
del nodo y la capacidad para componer servicios
dinámicamente.
2) Distribución de código:
Define los mecanismos usados en la red para la
recuperación e inserción de código activo en los nodos
intermedios. Existen tres propuestas de implementación de
Redes Activas, las cuales se diferencian principalmente en
esta característica. Son: Propuesta Discreta [6]: En esta
propuesta de implementación los programas son inyectados de
384
manera independiente al procesamiento de los paquetes de los
usuarios. Los paquetes mantienen el formato convencional.
Como ejemplos de proyectos que siguen esta propuesta se
tienen, ASP EE [7], SARA [8], etc. Propuesta Integrada [2]:
A diferencia de la anterior propuesta, en este caso cada
paquete lleva pequeños programas “personalizados”, los
cuales son descargados y ejecutados en los nodos activos. Los
formatos de los paquetes son modificados con el propósito de
facilitar su identificación. Entre los proyectos que siguen esta
propuesta tenemos a ANTS [9], SwitchWare [10],
SmartPackets [11], etc. Propuesta Híbrida [12]: En este caso
se combinan las funcionalidades de las dos propuestas
anteriores. Los programas activos pueden ser cargados por
demanda y de manera dinámica dentro de un nodo activo y el
paquete convencional con instrucciones prefijadas puede
indicar la ejecución de uno de estos programas. Ejemplos de
proyectos que siguen esta propuesta son DAN [13], APE [12],
etc. Las propuestas anteriores se caracterizan por insertar la
actividad a nivel de red en el modelo de referencia de Internet.
Existe otra propuesta que pretende mantener la esencia del
nivel de red insertando la actividad desde el nivel de
aplicación, ejemplo de esta propuesta es ALAN (Application
Level Active Networking) [14].
3) Control de granularidad
La ejecución de un código activo puede modificar el
comportamiento de un nodo activo. Esta característica define
el período durante el cual el comportamiento del nodo
permanece afectado. Los cambios en el comportamiento
pueden afectar a todos los paquetes que visitan al nodo activo
(granularidad por flujo), o puede afectar a un paquete
específico (granularidad por paquete).
4) Seguridad y confiabilidad de código:
La introducción de códigos ejecutables en la parte
intermedia de la red, generados desde fuentes no confiables, es
uno de los asuntos preocupantes en las Redes Activas ante los
potenciales problemas de seguridad que se puedan provocar a
la red. Los trabajos de investigación que buscan la solución a
los asuntos de seguridad están enfocados de dos maneras
diferentes [15]: la solución basada en restricciones del
lenguaje de programación sobre los paquetes activos, como en
el caso del proyecto SafetyNet [15], SANE [16] y la solución
basada en las políticas de autorización, se puede mencionar
como ejemplo de estos esfuerzos a SANTS [17], Seraphim
[18]. Otro problema detectado es la revocación, es decir el
control de los códigos ejecutables que presenten errores. En
[19] Murphy, et al, es propuesta una arquitectura para dar
solución al problema de revocación.
En la siguiente sección mencionaremos algunos trabajos
que proponen implementaciones a los componentes de la
arquitectura de Redes Activas.
B. Trabajos de investigación en Redes Activas
La comunidad de investigadores en Redes Activas han
desarrollado proyectos con el fin de implementar cada uno de
los componentes de la arquitectura general, también surgen
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 5, DECEMBER 2005
trabajos que usan la arquitectura de las Redes Activas para
mejorar el rendimiento de algunos servicios convencionales
existentes hoy en día.
Al interior de estos proyectos de investigación se diseñan
lenguajes de programación para la implementación de
programas activos, como es el caso de PLAN (Program
Lenguaje Active Network) y Calm en [10], Sprocked y
Spanner [11], etc.
El NodeOS es uno de los componentes más importantes
sobre los cuales recae el desempeño de una Red Activa.
Dentro de los proyectos que han implementado sistemas
operativos para los nodos intermedios están Bowman [20], fue
el primer sistema operativo de nodo, Joust [21] es una
plataforma que soporta EE basado en Java. Janos [1] soporta
solo EE basados en Java, no soporta múltiples espacios
concurrentes.
Otros trabajos de investigación soportándose en la
arquitectura de las Redes Activas con el fin mejorar el
desempeño de aplicaciones en la red convencionales. Entre las
líneas donde se vienen realizando numerosos esfuerzos
tenemos Multicast [23], QoS [24], [25], Cacheo [26], Gestión
de red [5], [27],[28], tras codificación, seguridad [29], control
de encaminamiento [24], [30], control de congestión [31], [32]
y composición de protocolos.
II. INFRAESTRUCTURA DE LA RED ACTIVA EN EL
PROYECTO ANDROID.
A. El Proyecto ANDROID.
En el proyecto IST ANDROID (IST 1999-10299), se
implementó una infraestructura de red programable, escalable
y gestionada, basando sus esfuerzos en la alternativa de las
Redes Activas.
La responsabilidad del grupo de trabajo de la Universidad
Politécnica de Madrid estuvo enmarcada en el campo del
modelado y simulación del sistema real que se implementó por
parte de los otros socios del proyecto ANDROID. Dentro del
entorno de trabajo de este proyecto se desarrolló una simple
Red Activa, con el fin de probar de forma real una
infraestructura de gestión para este novedoso tipo de red. Con
el propósito de obtener resultados sobre Redes Activas más
grandes y complejas, se recurrió a la simulación fuera de línea
como un mecanismo para predecir resultados. En esta
actividad de simulación, se obtuvieron 3 modelos de red:
Modelo de la Red Activa en ANDROID, modelado del
prototipo real de Red Activa que utilizó en este proyecto.
Modelo del Servidor activo, es el nodo que tiene la mayor
responsabilidad en el desempeño de la Red activa.
Modelo de una granja de servidores activos, por medio de
este modelo nos permite predecir el comportamiento de un
grupo de servidores activos, determinándose de esta manera la
capacidad de servicio de dicha granja.
MAGE et al.: MODELING AND SIMULATION OF ACTIVE
B. Arquitectura de Red Activa en el Proyecto ANDROID.
La arquitectura de Red Activa [33] en el proyecto
ANDROID posee dos clases de nodos activos: Los Servidores
Activos (ASs) y Encaminadores Activos (ARs). Los ARs
además de poseer las funcionalidades básicas de un
encaminador convencional, adicionan un entorno de ejecución
(EE) que le permite ejecutar programas activos, que podrán
operar sobre el contenido de los paquetes que fluyen por el
encaminador. Dichas operaciones determinan el trato que se le
debe dar a dichos contenidos. La arquitectura de los ASs, se
basa en arquitectura ALAN (Application Layer Active
Networking) [34]. En él se ejecuta el programa activo. Este
programa activo es implementado con el objeto de prestar
algún tipo de servicio al cliente.
La arquitectura ALAN consta de clientes (browsers) y
servidores (Servidores Web) desplegados en Internet. La
conexión entre los servidores y clientes se hace a través de
DPS (Dynamic Proxy Servers), y las entidades
programables/descargables son denominadas proxylets (Fig.
1). Los proxylets son almacenados (como archivos JAR) en
servidores Web y son obtenidos vía una URL. Existe una
implementación
denominada
‘FunnelWeb’
y
una
infraestructura ha sido desarrollada a través del proyecto
ALPINE [34].
385
los ISVs para intercambiar información y descargar los
proxylets y los metadatos de proxylets. Un PB está ubicado en
cada sitio de la red donde existe al menos un AS. En este
proyecto se tienen “sitios” conectados a través de una VPN
(Virtual Private Network). De esta manera los ASs
proporcionan un soporte a nivel de aplicación para servicios
activos a usuarios participantes en la VPN.
D. El Sistema de Gestión en ANDROID.
La plataforma de Gestión que se implementó se basa en un
sistema de gestión distribuida soportado por políticas, eventos,
y programación activa. De esta manera se permite una
monitorización y control de los nodos y servicios activos de
manera automática. Las decisiones de configuración se basan
en la información local disponible y en un conjunto de reglas,
que determinan el comportamiento que se desea imprimir al
elemento o al sistema gestionado. El conjunto de estas reglas
constituye las políticas de gestión. Las políticas son escritas en
XML (eXtensible Markup Languaje). Las políticas que se
implementan se orientan sobre tres frentes principales:
políticas para la gestión de los ARs, políticas para la gestión
de los ASs, y políticas para la gestión de la infraestructura de
soporte.
Fig. 1. Arquitectura ALAN
C. Desarrollo de una CDN en ANDROID.
Para mejorar la búsqueda y ubicación de los proxylets en la
red se recurre a aplicar la filosofía de las redes CDN (Content
Distribution Network).
En el proyecto ANDROID se implementó una arquitectura
similar a la CDN [35] (Fig. 2.). La CDN en este contexto
proporciona búsqueda y rápida localización de los proxylets.
Por medio de la CDN se distribuyen los proxylets requeridos
en el sistema, junto a los datos de información de ese proxylet
(metadatos del proxylet). Esta CDN consta principalmente de
tres elementos:
- ISVs (Independent Software Vendors), los cuales son los
proveedores de las implementaciones de servicios.
- Los Clientes, los cuales buscan y solicitan un proxylet
determinado.
- PBN (Proxylet Broker Network), la cual es una red
conformada por servidores dedicados, que en el contexto de
este proyecto son llamados PBs (Proxylet Brokers), los cuales
proporcionan las funcionalidades de almacenamiento,
búsqueda y recuperación de proxylets. Los PB interactúan con
Fig. 2. Infraestructura CDN en el proyecto ANDROID
E. Escenario de Prueba en ANDROID.
El objetivo del escenario de prueba en el que se trabajó en
el proyecto ANDROID fue implementar (como una aplicación
particular en Redes Activas) una sesión de video conferencia
usando la infraestructura descrita anteriormente (Fig. 2.).
En este escenario de prueba (Fig. 3) se observan 2 sitios,
que toman parte de la VPN. Para controlar el funcionamiento
de la VPN se cuenta con un sistema de gestión de VPN. Este
sistema es el encargado de configurar de manera dinámica a
los ARs [36] y a los encaminadores convencionales con el fin
de establecer la VPN. Esto significa que los túneles IPSEC se
configurarán o borrarán de acuerdo a los requerimientos de los
clientes. Cada “sitio” de esta VPN consta básicamente de un
AR, un servidor que contiene la herramienta que genera el
386
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 5, DECEMBER 2005
tráfico de video (VIC), un AS donde se ejecuta el proxylet
usado en esta aplicación (Trascoding Active Gateway - TAG),
y dependiendo de su posición en la red, se requerirá el uso de
un encaminador convencional.
-Transport
-Transceivers
Fig. 3. Escenario de prueba en ANDROID
El tráfico de video originado por la herramienta VIC es
enviado hacia la red. En el trayecto este tráfico es detectado
por un encaminador activo (AR), el AR enruta este tráfico
hacia el AS (Fig. 3) donde es procesado por el proxylet (TAG)
en un sitio local. Este tráfico multicast es encapsulado en
paquetes unicast. Dinámicamente se inicia el proceso de
establecimiento de una VPN. Con la VPN establecida, el
tráfico unicast es reenviado hacia el AR el cual refleja este
tráfico hacia los diferentes sitios de la VPN. En los sitios de
destino los paquetes unicast son tomados para desencapsular
los paquetes multicast por parte del proxylet (TAG) donde
posteriormente es distribuido localmente en forma de tráfico
multicast.
III. MODELADO DEL SERVIDOR ACTIVO (AS).
El Servidor Activo (AS) (Fig. 4.) es el elemento de esta red
que proporciona un entorno de ejecución seguro para los
proxylets que el usuario requiere. El AS dentro del sistema
interactúa de manera directa con el AR, y de forma indirecta
con los usuarios y el PB. Para realizar su propia gestión y
proporcionar seguridad, se proveen los servicios del MID
(Management Information Distribution), DS (Directory
Service) y el RM (Resource Manager). Estos servicios
corresponden, cada uno, a un módulo en el modelo de nodo
del AS (Fig. 4.).
Se describen los módulos que componen el modelo del AS.
A. Infraestructura del Servidor Activo.
Con base en los servicios de gestión relacionados con el
AS, se han implementado una serie de módulos, que
proveerán la funcionalidad de estos servicios en el modelo
desarrollado.
El Servidor Activo en el modelo de nodo estará compuesto
por los siguientes módulos (Fig. 4.):
-Management Information Distribution (MID)
-Broker
-Directory Service (DS)
-Security Manager (SM)
-Resource Manager (RM)
-Environment Execution (EE)
Fig. 4. Modelo de componentes del AS
B. Management Information Distribution (MID).
Su función básica es el manejo del flujo de eventos
entrantes y salientes circulantes, para establecer la correcta
intercomunicación entre los diferentes módulos que componen
el Servidor Activo.
Cuando un evento llega a este módulo, se busca la política
relacionada con este evento, y dependiendo de dicha política
el evento es redireccionado al módulo respectivo.
C. Broker.
Este módulo es responsable de:
- El almacenamiento de los metadatos del proxylet, y del
proxylet, usando para el primer caso al DS.
- Atención de las consultas realizadas por usuarios
autorizados, acerca de información relacionada con un
determinado proxylet.
- Distribución de los metadatos del proxylet a todos los
elementos que pertenecen a la CDN.
D. Directory Service (DS).
El DS es usado para almacenar los metadatos del proxylet,
también se asume que el almacenamiento del código del
proxylet es también manejado por este módulo.
E. Security Manager (SM).
Su función básica es la validación de los eventos que
fluyen hacia el entorno de ejecución. Al igual que los módulos
anteriores el SM posee un almacén de políticas. Cuando un
evento llega a este módulo se carga la política respectiva con
el fin validar las operaciones a realizar o el proxylet
implicado.
MAGE et al.: MODELING AND SIMULATION OF ACTIVE
F. Resource Manager (RM).
El RM es el encargado de verificar la disponibilidad de
recursos que se requieren para el mantenimiento de la
ejecución de un proxylet. Si existen los recursos suficientes,
este módulo se comunica con el entorno de ejecución (EE)
para iniciar o continuar con la ejecución del proxylet.
387
la memoria del servidor (main memory), el quantum
(Quantum max), la velocidad de transmisión de los enlaces
(ptx data rate). Fijando diferentes valores en estos parámetros
es posible obtener una serie de pruebas, de las cuales se
pueden recoger datos estadísticos detallados en serie de
gráficas estadísticas. Entre las curvas que se podrían obtener
están: estado de la memoria, estado de la CPU, número de
procesos activos, número de procesos en reposo, etc.
G. Environment Execution (EE).
El EE es el responsable del control del ciclo de vida del
proxylet durante su ejecución.
Fig. 5. Modelo de proceso del EE.
Fig. 7. Modelo de proceso del proxylet
IV. CONCLUSIONES
Fig. 6. Modelo de proceso del proxylet
En esta implementación se modela un proceso padre (Fig.
5.). Este proceso padre genera y controla procesos hijos
mediante una petición por demanda. Un proceso hijo
representa el ciclo de vida de un proxylet. El modelo de
proceso de un proceso hijo se observa en la Fig. 6.
En la Fig. 7, se observan algunas de las gráficas recogidas
durante una sesión de prueba. Previamente se fijan parámetros
tales como tamaño de los paquetes de datos que procesará el
proxylet (data size max/min), fijación de la función de
densidad de probabilidad que se seleccionará para generar el
tráfico de solicitudes de servicio hacia el AS (gen interarrival
pdf), fijación de la función de densidad de probabilidad que se
seleccionará para generar el tráfico de datos a procesar (data
interarrival pdf), tamaño del proxylet a descargar en memoria
(proxy size max), el número de solicitudes que se desea
configurar para la prueba (request number), número máximo
de paquetes a procesar en la prueba (num pk data max). En el
AS, es posible fijar los siguientes parámetros: La cantidad de
En este documento se ha presentado una breve descripción
de las fuentes de información en las cuales nos hemos
apoyado para fundamentar el modelado e implementación de
una clase de nodo de la Red activa, desarrollada en el contexto
del proyecto europeo ANDROID. El Modelado del Nodo
Servidor Activo se ha diseñado de manera modular
aprovechando las facilidades que proporciona la herramienta
OPNET Modeler. En el modelo se han logrado insertar
operaciones que permitirán recoger información estadística
acerca del procesamiento de servicios y los recursos
consumidos por dichos servicios. Este modelo posee una
interfaz de atributos, por medio de la cual, el usuario podrá
configurar datos de entrada para configurar diferentes sesiones
de simulación. En el escenario de prueba que se ha definido en
ANDROID, se ha implementado un escenario real donde se
ejecuta una aplicación de videoconferencia soportado sobre un
servicio activo de tras codificación. En este escenario de
prueba se configura una red privada virtual (VPN) para
realizar sesiones de video conferencia. Durante esta sesión se
manejan 5 tipos de eventos para soportar el escenario de
prueba en la VPN. Durante la demostración se genera una
carga de tráfico como consecuencia de la ocurrencia de un
evento. En los Servidores Activos la ejecución del servicio
activo (denominado Reflector Proxylet) consiste en detectar el
388
IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 5, DECEMBER 2005
tráfico durante una sesión de videoconferencia. Para este
propósito se recurre a técnicas de Marcas de agua. Con los
parámetros configurables en el modelo del Nodo Servidor
Activo, es posible medir el retardo de procesamiento que este
tráfico produce, el retardo producido por identificación del
tráfico multicast generado por la videoconferencia, al igual
que la latencia generada. Pero para que los parámetros
medidos en la simulación en línea fuesen más reales a los
obtenidos en las simulaciones es necesario añadir al modelo
del Nodo Servidor Activo la pila de protocolos TCP/IP.
Dentro de las actividades de simulación realizadas por
grupo de trabajo de la Universidad Politécnica de Madrid, se
obtuvieron los siguientes modelos de red Modelo de la Red
Activa en ANDROID, modelado del prototipo real de Red
Activa que utilizó en este proyecto y el Modelo de una granja
de servidores activos, por medio de este modelo nos permite
predecir el comportamiento de un grupo de servidores activos,
determinándose de esta manera la capacidad de servicio de
dicha granja. Como un trabajo futuro a realizar está el integrar
el modelo del Nodo Servidor Activo a los modelos que se
diseñaron dentro del grupo de trabajo.
V. REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
Active Network Distributed Open Infraetructure Development,
ANDROID, [Online] available: www.cs.ucl.ac.uk/research/android
Tenenhouse D. L., Wetherall, D. J., "Towards an Active Network
Architecture", Proceedings of the DARPA Active Networks Conference
and Exposition (DANCE'02), 2002
Psounis K. "Active Networks: Applications, Security, Safety and
Architectures", IEEE Communications Surveys, Vol. 2, No. 1, First
Quarter 1999.
Calvert, K.L., Bhattacharjee, S., Zegura, E.;,Sterbenz, J., "Directions in
active networks", Communications Magazine, IEEE , Volume: 36 Issue:
10 , Page(s): 72-78, Oct. 1998
Calderón, M., Sedano M., García, S, "Principios y Aplicaciones de las
Redes Activas", Jornadas de Ingeniería Telemática-Jitel99, 15-17 Sep
1999
Tennenhouse, D.L., Smith, J.M., Sincoskie, W.D., Wetherall, D.J.,
Minden, G.J., "A survey of active network research", Communications
Magazine, IEEE , Volume: 35 Issue: 1 Page(s): 80 -86, Jan. 1997.
Braden, R.; Lindell, B.; Berson, S.; Faber, T.; The ASP EE: an active
network execution environment, DARPA Active NEtworks Conference
and Exposition, 2002. Proceedings , 29-30 Page(s): 238–254, May 2002
M. Bagnulo, M. Calderón, B. Alarcos, D. Larrabeiti, Mecanismos de
seguridad en redes activas sobre arquitectura SARA, JITEL- II Jornadas
de
Ingeniería
Telemática,
Barcelona,
Septiembre,
2001.[Online].Available:http://www.it.uc3m.es/~maria/papers/papers.ht
ml
Wetherall, D.,Legedza, D., Guttang, J., "Introducing new Internet
services: why and how", Network, IEEE, Volume: 12 Issue: 3, Page(s):
12-19, May-June 1998.
Alexander, D.S., et al, "The SwitchWare active network architecture",
Network, IEEE , Volume: 12 Issue: 3, Page(s): 29-36 , May-June 1998.
Schwartz, B., Jackson, A.W., Strayer, W.T., Wenyi Zhou, "Smart
Packets for active networks", Open Architectures and Network
Programming Proceedings, 1999. OPENARCH '99. 1999 IEEE Second
Conference on, Page(s): 90 -97, 26-27 March 1999.
Takahashi, N., Miyazaki, T., Murooka, T., "APE: Fast and Secure Active
Networking Architecture for Active Packet Editing", Open Architectures
and Network Programming Proceedings, 2002 IEEE , Page(s): 104 -113,
28-29 June 2002.
Decasper, D., Plattner, B., DAN: distributed code caching for active
networks, INFOCOM '98. Seventeenth Annual Joint Conference of the
IEEE Computer and Communications Societies. Proceedings. IEEE ,
Volume: 2 Page(s): 609-616, 29 March-2 April 1998
[14] Ghosh, A., Fry, M., Glen MacLarty, "An infrastructure for application
level active networking", Computer Networks 36, Page(s): 5-20, 2001.
[15] Wakeman, Ian, Alan Jeffrey, Tim Owen, Damian Pepper, "SafetyNet: A
language-based approach to programmable networks", Computer
Networks 36, Elsevier Science B.V., 2001.
[16] Alexander D.S., Arbaugh W.A.., Keromytis A.D., Smith J.M., "A secure
active network environment architecture: realization in SwitchWare
Network", IEEE , Volume: 12 Issue: 3 , Page(s): 37-45, May-June 1998.
[17] Murphy, S., Lewis, E., Puga, R., Watson, R., Yee, R., "Strong security
for active networks", Open Architectures and Network Programming
Proceedings, 2001 IEEE , 27-28 April 2001.
[18] Campbell R.H., Zhaoyu Liu, Mickunas M.D., Naldurg P., Seung Yi,
"Seraphim: dynamic interoperable security architecture for active
networks", Open Architectures and Network Programming, 2000.
Proceeding. OPENARCH 2000. 2000 IEEE Third Conference on ,
Page(s): 55-64, 26-27 March 2000
[19] Murphy, S., Hayatnagarkar A., Krishnaswamy S., Morrison W., Watson
R., "Code revocation for active networks", Open Architectures and
Network Programming, 2003 IEEE Conference on, Page(s): 12-22 ,
April 4-5, 2003.
[20] Merugu, S., Bhattacharjee, S., Zegura, E., Calvert, K., "Bowman: a node
OS for active networks", INFOCOM 2000. Nineteenth Annual Joint
Conference of the IEEE Computer and Communications Societies.
Proceedings. IEEE , Volume: 3, Page(s): 1127-1136 vol.3 , 26-30 March
2000.
[21] Hartman, et al, "Joust: a platform for liquid software", Computer,
Volume: 32 Issue: 4, Page(s): 50-56, April 1999
[22] Tullmann, P., Hibler, M.; Lepreau, J., "Janos: a Java-oriented OS for
active network nodes", DARPA Active NEtworks Conference and
Exposition, 2002. Proceedings , Page(s): 117-129, 29-30 May 2002
[23] Kasera, S.K., et al, " Scalable fair multicast using active services",
DARPA Active NEtworks Conference and Exposition, 2002.
Proceedings , Page(s): 333 -343, 29-30 May 2002
[24] Welzl, M.; Cihal, A.; Muhlhauser, M., "An approach to flexible QoS
routing with active networks ", Active Middleware Services, 2002.
Proceedings. Fourth Annual International Workshop on , Page(s): 75 82, 23 July 2002
[25] Ian W. Marshall, Chris Roadknight, "Provision of quality of service for
active services", Elsevier Science B.V., Computer Networks 36, Page(s):
75-85, 2001
[26] Li-Der Chou, Jeng-Ting Yang, Jui-Ming Chen, Mong-Shin Ou, "Selforganization for cache servers in active networks", Parallel and
Distributed Systems, 2002. Proceedings. Ninth International Conference
on , Page(s): 216-221, 17-20 Dec. 2002
[27] eMeer, H., Tutschku, K., "A performance management architecture for
peer-to-peer services based on application-level active networks",
Network Operations and Management Symposium, 2002. NOMS 2002.
2002 IEEE/IFIP , Page(s): 927 -929, 15-19 April 2002
[28] Barone, A., Chirco, P., Di Fatta, G., Lo Re, G., "A management
architecture for active networks", Active Middleware Services, 2002.
Proceedings. Fourth Annual International Workshop on , Page(s): 4148,23 July 2002
[29] Zhaoyu Liu; Campbell, R.H.; Mickunas, M.D., "Security as services in
active networks", Computers and Communications, 2002. Proceedings.
ISCC 2002. Seventh International Symposium on , 1-4 July 2002
[30] Junbiao Zhang; Ott, M., "ANSWER: information routing based on active
networks", Communications, 1999. APCC/OECC '99. Fifth Asia-Pacific
Conference on ... and Fourth Optoelectronics and Communications
Conference , Volume: 1 , Page(s): 69 -74 vol.1, 18-22 Oct. 1999
[31] Sari, R.F.; Djemame, K., "Performance comparison of active and nonactive network-based multicast multirate congestion control protocols",
Networks, 2002. ICON 2002. 10th IEEE International Conference on ,
Page(s): 249 -254, 27-30 Aug. 2002
[32] Faber, T.; "Experience with active congestion control", DARPA Active
NEtworks Conference and Exposition, 2002. Proceedings , Page(s): 132
-142, 29-30 May 2002
[33] Fisher, M, "Refined Architecture", UCL-ANDROID Consortium,
Document No WP2-BT-001-D01-Int, 8 August 2000
[34] A. Ghosh, M. Fry, and C. Crowcroft, An Architecture for Application
Layer Routing, In Proceed. IWAN 2000, Page(s) 71-86.
[35] N. Dragios, C. Harbilas, G. Karetsos, " CDN deployment in ANDROID
", NTUA-ANDROID Consortium, 5 November 2001
MAGE et al.: MODELING AND SIMULATION OF ACTIVE
[36] Ksinant, Vladimir, Specification for Integration of Core and Edge
Devices , 6WIND Consortium, June 2001
VI. BIOGRAFÍAS
Dr. Mercedes Garijo nació en San Sebastian,
España,, el 20 de Noviembre de 1947. Se graduó
como Ingeniera de Telecomunicaciones en 1972 y
obtuvo su titulo de doctorado en 1982. Los títulos
son obtenidos en la Universidad Politécnica de
Madrid.
Es profesor asociado en el Departamento de
Ingeniería de Sistemas Telemáticos de la
Universidad Politécnica de Madrid (UPM). Enseña
varios niveles de la ciencia de computación y tópicos
de comunicación. Sus áreas de interés son la
ingeniería del software, metodologías orientadas a objetos y técnicas aplicadas
para diseño de agentes sobre internet/Intranet y gestión de redes de
comunicación. Ha participado y gestionado varios proyectos de investigación
y desarrollo patrocinados por programas nacionales y europeos y ha publicado
artículos en revistas técnicas, capítulos de libros y conferencias
internacionales.
Amalio F. Nieto nació en Madrid, el 2 de Julio de
1968. Se graduó de Ingeniero de Telecomunicación
en 1992 por la Universidad Politécnica de Madrid.
Es profesor asociado en el Departamento de
Ingeniería de Sistemas Telemáticos de la
Universidad Politécnica de Madrid, donde imparte
docencia en las áreas de programación, ingeniería
del software y comunicaciones. Sus áreas de
interés son las metodologías orientadas a objetos y
las redes activas.
Pablo Augusto Magé nació en Bolívar (Cauca),
Colombia, el 28 de Agosto de 1966. Se graduó como
Ingeniero en Electrónica y Telecomunicaciones en
1992 y obtuvo un título de especialista en redes y
servicios telemáticos en 1997. Los títulos fueron
obtenidos en la Universidad del Cauca (Colombia).
Es profesor del Departamento de Sistemas,
Facultad de Ingeniería Electrónica de la Universidad
del Cauca. Actualmente adelanta estudios de
doctorado en el departamento de Ingeniería de
Sistemas Telemáticos de la Universidad Politécnica
de Madrid (UPM). Sus áreas de interés son la programación orientada a
objetos, sistemas distribuidos y redes activas.
389