QoS para Aplicaciones de Tiempo Real en NOWs mediante

Transcripción

QoS para Aplicaciones de Tiempo Real en
NOWs mediante Reconguracion Dinamica?
Francisco J. Alfaro1 , Aurelio Bermudez2 , Rafael Casado2 ,
Jose Duato3 , Pedro J. Garca2, Francisco J. Quiles2 , Jose L. Sanchez2
1
Departamento de Ingeniera y Tecnologa de Computadores
Facultad de Informatica
Universidad de Murcia
30071{Murcia
[email protected]
2
Departamento de Informatica
Escuela Politecnica Superior
Universidad de Castilla-La Mancha
02071{Albacete
fabermu, rcasado, pgarcia, paco, [email protected]
3
Departamento de Informatica de Sistemas y Computadores
Facultad de Informatica
Universidad Politecnica de Valencia
46071{Valencia
[email protected]
Resumen
(Networks
Las actuales tecnicas de reconguracion empleadas en NOWs
of Workstations) no garantizan la calidad de servicio (QoS,
Quality of Service) requerida por ciertas aplicaciones, como aquellas que
soportan traco en tiempo real. El presente documento describe nuestros estudios dirigidos a desarrollar protocolos de reconguracion que no
degraden en exceso las prestaciones de la red. Nuestros protocolos se
adaptan a redes que empleen encaminamiento fuente o distribuido.
1 Introduccion
Hace tres a~nos, el grupo de investigacion en Redes y Arquitecturas de Altas
Prestaciones (RAAP) de la Universidad de Castilla-La Mancha inicio una nueva
lnea de investigacion destinada a desarrollar protocolos de reconguracion de
NOWs. Nuestro objetivo era (y sigue siendo) proponer alternativas a las tecnicas
de reconguracion tradicionales para solventar la degradacion de prestaciones
que sufre la red cuando se emplean dichas tecnicas. Esta degradacion de prestaciones afecta especialmente a las aplicaciones que emplean traco con requerimientos de QoS, como es el caso de aquellas que se ejecutan en tiempo real.
Buena parte de nuestro trabajo ya ha sido presentado en varios foros internacionales [5,4] y en la actualidad nos encontramos desarrollando nuevas ideas
dentro de la misma lnea.
? Este trabajo est
a parcialmente soportado por el proyecto CICYT TIC97-0897-C04
y Caja Castilla-La Mancha
VIII Jornadas de Concurrencia
224
Este documento tiene dos propositos. El primero de ellos es plantear la problematica asociada al dise~no de mecanismos de reconguracion y describir los
inconvenientes que, para el traco en tiempo real, presentan las propuestas
tradicionales. El segundo objetivo es presentar la losofa basica de nuestras
propuestas y las ventajas que aportara su uso.
El resto del documento esta organizado de la siguiente forma: la seccion
2 presenta, de una forma general, la necesidad del empleo de mecanismos de
reconguracion en NOWs y los riesgos inherentes a su uso. En la seccion 3 se
describen las distintas estrategias adoptadas por los mecanismos implementados
por las redes comerciales para evitar estos riegos. La seccion 4 se centra en los
requisitos de QoS de las aplicaciones en tiempo real. La seccion 5 plantea los
inconvenientes que presentan los metodos de reconguracion tradicionales para
garantizar dicha QoS. En la seccion 6 ofrecemos una vision global de nuestro
trabajo y de las mejoras que supone frente a las tecnicas de reconguracion
tradicionales.
2 Reconguracion en NOWs
Las NOWs actuales, tales como Autonet [25], Myrinet [20] y Servernet [13] incorporan tecnicas propias de las redes de interconexion de computadores paralelos.
Algunos ejemplos son la utilizacion de enlaces punto a punto entre conmutadores o tecnicas de conmutacion segmentadas (wormhole switching [15], virtual
cut-through switching [7]). Este tipo de redes tambien ha heredado caractersticas
de las redes locales convencionales, como la irregularidad y la variabilidad en la
topologa de la red. En la gura 1 se muestra un ejemplo de NOW, donde podemos apreciar dicha irregularidad.
2
1
0
12
8
4
14
10
7
Figura 1.
Ejemplo de red conmutada
225
Estas propiedades provocan la aparicion de ciertos problemas relacionados
con la conguracion de la topologa y el encaminamiento de mensajes. En concreto, el empleo de tecnicas de conmutacion hace necesaria la existencia de una
funcion de encaminamiento de mensajes, a diferencia de lo que ocurre en entornos
donde la red de interconexion es un medio compartido. La topologa irregular
de la red implica que para obtener esta funcion de encaminamiento es necesario
contar con informacion explta sobre la topologa completa de la red, lo cual no
es necesario en redes regulares. La implementacion de esta funcion de encaminamiento no puede realizarse de forma sencilla mediante hardware, como en las
redes de interconexion de multicomputadores o multiprocesadores. En lugar de
esto, cada componente de la red con capacidad de encaminar mensajes necesita emplear una tabla de encaminamiento donde encontrara una ruta para cada
posible destino de un mensaje. Para elaborar estas tablas de encaminamiento es
necesario contar con informacion explcita sobre la topologa completa de la red.
En la mayora de las redes comerciales, el encaminamiento se realiza de modo
que no se producen situaciones de bloqueo [11] (deadlock) entre mensajes. Para
garantizar esta ausencia de bloqueos, se emplean tecnicas que permiten obtener,
dada una topologa arbitraria, funciones de encaminamiento libres de bloqueo
plasmadas en tablas de encaminamiento. Estas funciones imponen ciertas restricciones sobre el encaminamiento [11].
Ahora bien, la topologa de la red puede cambiar debido a la activacion y
desactivacion de conmutadores y terminales, el reajuste de conexiones o fallos en
los componentes. En estos casos, para que la comunicacion siga siendo posible
entre los diferentes componentes de la red, es necesario un mecanismo que se
encargue de sustituir las tablas de encaminamiento (que han quedado obsoletas)
por otras tablas actualizadas. A dicho proceso se le denomina reconguracion de
la red de interconexion. El mecanismo de reconguracion necesita que los cambios
en la topologa de la red se detecten de alguna manera. Una vez detectado
cualquier cambio, debe comenzar el proceso que culminara con la actualizacion
de las tablas.
Suponiendo que la red emplea siempre funciones de encaminamiento libres de
bloqueo, tanto las tablas obsoletas como las nuevas tablas garantizaran la ausencia de bloqueos durante el funcionamiento normal de la red. Durante el proceso
de reconguracion, la actualizacion de las tablas de encaminamiento no puede
realizarse de forma sincronizada. Por tanto, es posible la existencia simultanea
de traco encaminado segun las tablas obsoletas y traco encaminado segun las
tablas actualizadas. La coexistencia de dos funciones de encaminamiento puede
provocar bloqueos incluso aunque ambas funciones sean libres de bloqueo por
separado. Esto es debido a que las restricciones al encaminamiento impuestas
por una de ellas para garantizar la ausencia de bloqueos pueden ser ignoradas
por la otra, y viceversa. La solucion al problema de los posibles bloqueos durante
el proceso de actualizacion de tablas de encaminamiento es uno de los aspectos
clave en cualquier mecanismo de reconguracion.
226
3 Mecanismos de Reconguracion en NOWs Comerciales
Los ejemplos mas signicativos de NOWs comerciales implementan mecanismos de reconguracion que les permiten adaptarse a cualquier cambio en su
topologa. Aunque las diferentes arquitecturas de estas redes dan lugar a que
la implementacion del mecanismo de reconguracion sea distinta en cada caso,
podemos encontrar similitudes en ciertas facetas del planteamiento basico de
estos mecanismos.
3.1 Reconguracion en Autonet
Uno de los mas tempranos ejemplos de NOW comercial es la red Autonet [25].
Esta red emplea encaminamiento distribuido, es decir, las decisiones de encaminamiento se toman en los conmutadores de la red, que por tanto deben tener
capacidad para almacenar las tablas de encaminamiento.
Los conmutadores de Autonet incorporan un procesador interno que monitoriza completamente su funcionamiento. Estos conmutadores implementan un
complejo y robusto mecanismo de deteccion de cambios en sus enlaces. Cuando
se produce un cambio en uno de ellos, el conmutador dispara un proceso de reconguracion distribuido que se extiende a toda la red y acaba produciendo la
actualizacion de la tabla de encaminamiento en cada conmutador.
A grandes rasgos, podemos identicar tres fases en el proceso de reconguracion [24]: propagacion, recogida y distribucion. La fase de propagacion comunica a toda la red que el proceso ha comenzado. Durante esta propagacion se
construye un arbol de expansion (spanning-tree ) de la red [22]. En la segunda
fase, la raz del arbol de expansion recopila toda la informacion sobre la nueva
topologa. La tercera y ultima fase consiste en la distribucion de la topologa
al resto de la red y la construccion de las tablas de encaminamiento, labor que
realiza cada conmutador una vez que dispone de la nueva topologa y del arbol
de expansion de la red. A partir de esta informacion, el conmutador debe obtener
un grafo dirigido acclico. Las tablas se crean aplicando a este grafo el algoritmo
up*/down* [25].
Con el n de evitar la aparicion de bloqueos durante la ejecucion del proceso de reconguracion, Autonet detiene el traco generado por las aplicaciones.
Cuando el proceso termina, se reactiva su circulacion. En estas situaciones decimos que se ha producido una reconguracion estatica de la red de interconexion.
3.2 Reconguracion en Myrinet
Myrinet [3] es una NOW de mas reciente creacion que, a diferencia de Autonet,
emplea encaminamiento fuente. En estas redes las decisiones para el encaminamiento de un mensaje se toman unicamente en el terminal emisor. Las rutas hacia
otros terminales se determinan completamente en el origen y cada mensaje contiene informacion suciente para llegar a su destino siguiendo la ruta denida. El
papel de los conmutadores en este tipo de redes es pasivo por cuanto no pueden
producir ni \reencaminar" mensajes, limitandose a darles salida por el puerto
227
indicado en el propio mensaje. Dicho de otro modo: los conmutadores carecen
de tablas de encaminamiento, que solo estan presentes en los terminales.
En redes que empleen este tipo de encaminamiento, las limitaciones de los
conmutadores pasivos obligan a plantear el problema de la reconguracion de
la red bajo premisas distintas a las expuestas hasta ahora. As, un conmutador
pasivo es incapaz de detectar un cambio en el estado de sus enlaces y disparar
un proceso de reconguracion. Esta responsabilidad recae en los terminales.
Myrinet es una red controlada por software. El funcionamiento global de la
red, incluyendo el mecanismo de reconguracion, se controla por programas que
se ejecutan en un procesador situado en la tarjeta de interfaz de cada terminal
de la red. Existen distintos programas de control que pueden ser modicados
por los usuarios para adaptarlos a sus necesidades. Los dos sistemas software
ofrecidos por el fabricante [20] son Myrinet-MCP [18] y Myrinet-GM [8].
Ambos sistemas implementan un mecanismo de reconguracion centralizado.
Un unico terminal de la red (denominado mapper) se encarga de explorar la
topologa para detectar cualquier cambio, confeccionar un nuevo mapa de la
red y comunicarlo al resto de los terminales para que actualicen sus tablas de
encaminamiento (segun el algoritmo up*/down*). Los conmutadores Myrinet,
ajustandose al modelo de conmutadores pasivos, carecen de dichas tablas, e
incluso de direccion (UID, unique identier) propia. La arquitectura de Myrinet
complica la tarea del mapper notablemente. Por ejemplo, la carencia de UID
propio para los conmutadores obliga a complejas estrategias para evitar que un
mismo conmutador sea duplicado en el mapa [17].
El mecanismo de reconguracion que implementa Myrinet-MCP no detiene
el traco de usuario durante el proceso de reconguracion. La solucion prevista
para los posibles bloqueos originados durante la actualizacion de las tablas se
basa en eliminar los mensajes cuyo tiempo de transmision supere un determinado
timeout. De esta forma ningun mensaje puede estar bloqueado indenidamente.
En otras palabras, Myrinet-MCP emplea una estrategia de recuperacion de bloqueos durante el proceso de reconguracion, en lugar de evitarlos.
Myrinet-GM, por su parte, implementa un mecanismo de reconguracion que
no permite la circulacion de mensajes de usuario durante el proceso de reconguracion. En denitiva, implementa una tecnica de reconguracion estatica similar
a la de Autonet.
4 QoS en Aplicaciones de Tiempo Real
Las aplicaciones distribuidas de tiempo real requieren condiciones muy estrictas
en su traco [1] con rigurosas limitaciones en parametros como el maximo retraso
extremo a extremo (deadline), la varianza del retraso de las celulas ATM (CDV,
Cell Delay Variance), el maximo retraso entre celulas (CTD, Cell Transfer Delay), el porcentaje de celulas perdidas (CLR, Cell Lost Ratio), etc. Las aplicaciones multimedia distribuidas (videoconferencia, reuniones virtuales, vdeo
bajo demanda, etc), tienen tambien requerimientos, aunque menos estrictos, en
cuanto a QoS.
228
Las aplicaciones en tiempo real podemos clasicarlas en [1]:
{ Blandas (soft): presentan una cierta tolerancia en cuanto a que los mensajes
lleguen despues de su deadline. Estos mensajes que ya no son validos para
las aplicaciones deben descartarse. Muchas de las aplicaciones multimedia,
estaran en esta categora.
{ Duras (hard): a estas aplicaciones se les permite imponer cualquier restriccion
para establecer la comunicacion, pero una vez establecida no se permite que
ningun mensaje llegue despues de su deadline y mucho menos que se pierdan
mensajes. En esta categora estaran las aplicaciones industriales que por
ejemplo controlan robots o sistemas de seguridad.
Todas estas aplicaciones suelen estar orientadas a la conexion, es decir,
primero se establece la conexion entre las entidades, luego se produce el trasiego
de informacion, y nalmente se libera la conexion [12]. De hecho, es bastante
comun que las conexiones esten establecidas durante bastante tiempo, con un
trasiego constante o variable de informacion. En estos casos es necesario que
la red pueda proporcionar esos requerimientos mnimos de QoS sin los cuales
dichas aplicaciones no llegaran a utilizarse.
Para que se llegue a establecer la conexion es necesario estudiar si es posible
satisfacer los requerimientos. Para ello hay dos posibles esquemas:
{ Centralizado: todas las peticiones se envan a un controlador que se encarga
de repartir los recursos disponibles.
{ Distribuido: en este caso la solicitud de conexion recorre la ruta desde el so-
licitante hasta el destino de forma que todos los nodos intermedios estudian
la peticion para decidir si les es posible satisfacer los requerimientos solicitados. En cada nodo de la ruta se reservan recursos de espacio (buers) o, en
un esquema sncrono, de tiempo (slots de transmision) para su uso posterior
por los mensajes de informacion que circulen por la conexion una vez que
este establecida.
En ambos casos, la conexion se establece solo si hay recursos disponibles
para poder garantizar un retraso maximo y el ancho de banda solicitado. Para
el esquema distribuido, si en algun punto se deniega la conexion se emite un
mensaje hacia atras liberando los recursos asignados e intentando establecer la
conexion por otra ruta.
En el caso de las aplicaciones mas exigentes de tiempo real (hard), ademas
de tener establecida una conexion, se suele tener otra conexion secundaria en
reserva por si fallara la primera [19]. Ambas conexiones no pueden compartir
ningun enlace o nodo intermedio, teniendo unicamente en comun los terminales
origen y destino as como los enlaces de salida y llegada a ellos respectivamente.
En redes de area local, el traco generado por aplicaciones multimedia (y,
en general, de tiempo real) con necesidades de QoS, debe coexistir con traco al
mejor intento, que no requiere garantas de ningun tipo. En estas redes la QoS
suele soportarse en capas superiores (la capa de transporte), que introducen
una considerable sobrecarga software. En redes de altas prestaciones el retraso
229
introducido por dichas capas podra resultar inaceptable, y deben considerarse
nuevos metodos para proporcionar esta QoS.
Trabajos recientes han abordado esta cuestion, aunque casi siempre orientada
a traco multimedia, y tres son las alternativas que se presentan:
{ Crear dos subredes separadas [14] a~nadiendo enlaces a la topologa: una para
soportar exclusivamente el traco con necesidades de QoS y la otra dedicada
al traco al mejor intento.
{ Crear un marco \sncrono" dentro de la red \asncrona" [14,6]. Una multiplexacion en el tiempo permite que varias conexiones usen, en instantes
distintos, los mismos canales sin interferencias. Para ello es imprescindible
una correcta asignacion de slots de tiempo a cada conexion.
{ Usar gran cantidad de canales virtuales que permitan atender simultaneamente
muchas conexiones y traco al mejor intento [10,14].
5 Inconvenientes de los Mecanismos de Reconguracion
Tradicionales
Hemos visto que tanto Autonet como Myrinet-GM evitan los bloqueos durante el
proceso de reconguracion empleando reconguracion estatica. La detencion de
traco producida por una reconguracion estatica conlleva una degradacion de
las prestaciones de la red. La gura 2 muestra el efecto que produce la reconguracion estatica sobre la latencia1 instantanea de los mensajes del sistema. Para
obtener estos resultados, hemos simulado la ejecucion distribuida del proceso de
reconguracion completo. En el caso de la gura 2, hemos forzado el disparo del
mecanismo de reconguracion en dos instantes de la simulacion, concretamente
en t=220000 y en t=260000. Puede apreciarse como la latencia desaparece , despues sufre un incremento de varios ordenes de magnitud, para nalmente volver
a los valores esperados, tras cada proceso de reconguracion.
Como hemos visto en la seccion anterior, el traco en tiempo real requiere
cierta QoS que no podra garantizarse en estas condiciones. Por una parte, la
detencion del traco y el aumento de la latencia, y por otra el descarte de mensajes hacen que, en general, el empleo de reconguracion estatica sea inaceptable
en redes sobre las que se ejecutan aplicaciones distribuidas en tiempo real. La
transmision de vdeo bajo demanda podra ser un buen ejemplo, pues el ujo de
informacion generado podra verse afectado por el incremento de latencia hasta
el punto de no poder satisfacer las condiciones temporales impuestas por la
transmision. Muchos organismos (como el ministerio de defensa de los EEUU)
rehusan sustituir sus multicomputadores por este tipo de redes en tanto este
problema no haya sido solucionado.
Ademas, con reconguracion estatica, la cada de un nodo intermedio hara
que la red dejara de servir mensajes incluso para los sistemas de tiempo real hard
con un canal secundario establecido, pues al detener el traco no se podra avisar
1
Tiempo transcurrido desde que un mensaje es generado en el origen hasta que llega
a su destino. Se trata de una medida habitual de las prestaciones del sistema.
230
Latencia instantánea (ciclos)
16000
14000
12000
10000
8000
6000
4000
2000
0
210 220 230 240 250 260 270 280 290 300
Tiempo de simulación (ciclos x 1000)
Efecto de la reconguracion estatica sobre la latencia instantanea de los
mensajes de usuario
Figura 2.
al nodo origen para que conmutara al canal secundario hasta que se recongure
la red.
Por otra parte, el mecanismo de reconguracion implementado por MyrinetMCP no detiene el traco durante la actualizacion de las tablas, pero emplea
recuperacion de bloqueos durante este proceso. Este mecanismo de recuperacion
implica la necesidad de retransmitir la informacion que se pierde al eliminar
la situacion de bloqueo. Myrinet-MCP no dene el modo en que esta retransmision debe efectuarse, dejando esta responsabilidad a protocolos superiores,
como TCP.
En general, vemos que los metodos tradicionales de reconguracion descartan mensajes de usuario durante el proceso. Esto implica la existencia en todos
los casos de un protocolo que se encarge de reinyectar los mensajes descartados.
La presencia de este protocolo produce una sobrecarga software que degrada las
prestaciones de la red [21] hasta extremos que pueden considerarse inaceptables para aplicaciones con necesidades de QoS. Ademas, como hemos dicho, el
mero hecho de descartar mensajes puede ser intolerable para las aplicaciones que
emplean traco en tiempo real.
Ninguno de los estudios sobre QoS citados aborda el problema de mantener
la QoS ofrecida durante el proceso de reconguracion. As, trabajos como FM
[16] o BIP [23] no consideran siquiera la posibilidad de cambios en la red.
6 Nuestras Propuestas: Reconguracion Dinamica con
Evitacion de Bloqueos
Los inconvenientes planteados por la reconguracion estatica aconsejan abordar
la reconguracion de la red desde una nueva perspectiva: realizar la recongu-
231
racion sin que ello implique una paralizacion del traco de usuario, aplicando
lo que hemos denominado tecnicas de reconguracion dinamica. El principal objetivo es reducir los efectos negativos que la reconguracion estatica produce
directamente sobre la latencia de la red, e indirectamente sobre el grado de
satisfaccion del usuario.
En [5,9] se describe detalladamente un protocolo de reconguracion dinamica
para NOWs: la Reconguracion Parcial Progresiva (Partial Progressive Reconguration). Este protocolo esta dise~nado para redes que emplean encaminamiento
distribuido y basado en la funcion de encaminamiento up*/down* (como es el
caso de Autonet). El mecanismo de reconguracion propuesto realiza la reconguracion de la red de interconexion sin detener el traco de aplicacion durante
el proceso y, por supuesto, sin producir bloqueos. El protocolo incorpora una
tecnica de evitacion de bloqueos basada en prevenir la formacion de ciclos en el
grafo de dependencia de canales [7]. Para conseguirlo se recurre a una serie de
modicaciones parciales y progresivas de las tablas de encaminamiento.
La Reconguracion Parcial Progresiva reduce sensiblemente el impacto que
los mecanismos de reconguracion tradicionales pueden llegar a producir sobre
las prestaciones de la red de interconexion [4]. La gura 3 presenta el comportamiento de la latencia instantanea cuando se aplica nuestro protocolo de
reconguracion dinamica sobre la misma red de la gura 2 y con los mismos
cambios en su topologa (observese ademas que las escalas en ambas gracas son
identicas). Como puede apreciarse, las sucesivas reconguraciones de la red no
tienen efecto alguno sobre la latencia de los mensajes de aplicacion.
Latencia instantánea (ciclos)
16000
14000
12000
10000
8000
6000
4000
2000
0
210 220 230 240 250 260 270 280 290 300
Tiempo de simulación (ciclos x 1000)
Efecto de la reconguracion dinamica sobre la latencia instantanea de los
mensajes de usuario para las mismas condiciones de simulacion que en la gura 2
Figura 3.
232
Este protocolo de reconguracion presenta ademas otras ventajas como son
la disminucion drastica del numero de mensajes descartados y la reduccion del
tiempo necesario para desarrollar el proceso de reconguracion [4].
En [2] se pone de maniesto que la Reconguracion Parcial Progresiva puede
aplicarse con resultados similares en entornos en los que se emplea encaminamiento adaptativo [26]. Este esquema de encaminamiento mejora las prestaciones ofrecidas por el encaminamiento up*/down* tradicionalmente empleado
en NOWs.
A la vista de los resultados obtenidos por este protocolo de reconguracion
dinamica nos planteamos la posibilidad de adaptarlo a redes con encaminamiento
fuente, y en concreto a Myrinet. Puesto que Myricom permite a sus clientes el
acceso al codigo de los programas de control, basta con modicar convenientemente estos para cambiar la tecnica de reconguracion de la red. As pues,
Myrinet se presenta como una plataforma de prueba ideal donde implementar
un protocolo de reconguracion acorde con nuestros planteamientos.
A pesar de las diferencias existentes entre redes que emplean encaminamiento
distribuido y encaminamiento fuente, las lneas principales del protocolo de reconguracion dinamica con evitacion de bloqueos desarrollado para las primeras
siguen siendo validas para las segundas. As, puede intuirse que la evitacion de
bloqueos durante el proceso de reconguracion tambien debe basarse en que la
actualizacion de las tablas de encaminamiento se realice de forma parcial y progresiva. En este caso debe tenerse muy en cuenta que los mensajes no pueden
ser reencaminados en los conmutadores, y que el mapper, como responsable del
proceso de reconguracion, debe ser consciente en cada momento del estado del
traco en determinados enlaces. Tambien emplearemos grafos de dependencia
de canales como herramienta para vericar la ausencia de bloqueos durante el
proceso.
6.1 Reconguracion Dinamica y Garanta de QoS
La aplicacion de un protocolo de reconguracion dinamica puede ser el primer
paso para proporcionar garanta de QoS en NOWs. Al tratarse de redes con
pocos recursos no podemos plantearnos usar multitud de canales virtuales o
reales, sino que debemos optimizar el uso que se hace de los que se disponen
mediante una adecuada planicacion.
En redes con reconguracion dinamica s podremos intentar proporcionar
garanta de QoS. Incluso para sistemas de tiempo real hard, al no detener el
traco sera posible avisar al nodo origen para que pase a enviar por el canal
secundario al mismo tiempo que comienza el proceso de reconguracion actualizando las tablas de encaminamiento de los nodos. En este caso, la red debe estar
preparada para que simultaneamente se encuentre otra conexion para mantenerla como canal secundario. Si el canal secundario es el unico afectado por la
cada de un nodo intermedio, no se vera afectado el canal primario, pero sera
igualmente necesario buscar otra ruta para establecerla como canal secundario.
As pues, con la reconguracion dinamica conseguiramos restaurar de la forma
mas rapida posible la situacion inicial.
233
7 Conclusiones
Las NOWs emplean mecanismos de reconguracion para adaptarse a los cambios
que pueden darse debido a la variabilidad de su topologa. Los mecanismos de
reconguracion tradicionales son incapaces de garantizar QoS a las aplicaciones
en tiempo real. La reconguracion estatica, empleada por Autonet y Myrinet, no
permite ningun tipo de QoS al detener el traco de usuario durante el proceso
de reconguracion. Tambien es usual que cuando ocurre una reconguracion en
la red los nodos tengan que descartar muchos mensajes. Esto puede solucionarse
con la presencia de una capa software superior que reenve los mensajes descartados, a cambio de introducir una sobrecarga considerable, a veces inaceptable,
sobre todo en redes de altas prestaciones. En aplicaciones de tiempo real, este
descarte masivo de mensajes no es tolerable.
Nuestra propuesta de reconguracion se basa en no detener el traco durante
el proceso (reconguracion dinamica) y emplea tecnicas de evitacion de bloqueos,
que permiten realizar la actualizacion de las tablas de encaminamiento sin que
aparezcan bloqueos y sin un descarte signicativo de mensajes. Los resultados obtenidos para redes con encaminamiento distribuido, que seran extendidos
proximamente a encaminamiento fuente, muestran que las tecnicas de reconguracion dinamica con evitacion de bloqueos pueden constituir la base para
proporcionar la QoS requerida por las aplicaciones en tiempo real.
Referencias
1. C.M. Aras, J.F. Kurose, D.S. Reeves, and H. Schulzrinne. Real-time communication in packet-switched networks. In IEEE, volume 82, pages 122{139, January
1994.
2. A. Bermudez, F.J. Alfaro, R. Casado, J. Duato, Quiles F.J., and J.L. Sanchez.
Extending dynamic reconguration to NOWs with adaptive routing. In Proceedings
of the Workshop on Communication, Architecture and Applications for Networkbased Parallel Computing, January 2000.
3. N.J. Boden, D. Cohen, and R.E. Felderman. Myrinet { a gigabit per second local
area network. IEEE Micro, pages 29{36, February 1995.
4. R. Casado, A. Bermudez, F.J. Quiles, J.L. Sanchez, and J. Duato. Performance
evaluation of dynamic reconguration in high-speed local area networks. In
Proceedings of the 6th Symposium on High Performance Computer Architecture
(HPCA-6), January 2000.
5. R. Casado, F.J. Quiles, J.L. Sanchez, and J. Duato. Deadlock-free routing in irregular networks with dynamic reconguration. In Proceedings of the Workshop on
6.
Communication, Architecture and Applications for Network-based Parallel Computing, January 1999.
K.H. Connelly. FM-QOS a Quality of Service messaging substrate for asynchronous
local-area networks with hardware-level network feedback. Ph. D. Thesis. University
of Illinois at Urbana-Champaign, 1999.
7. W.J. Dally and C.L. Seitz. Deadlock-free message routing in multiprocessor interconnection networks. IEEE Transactions on Computers, C-36(5):547{553, May
1987.
234
8. Myricom GM documentation. http://www.myri.com:80/GM/doc.
9. J. Duato, R. Casado, F.J. Quiles, and J.L. Sanchez. Dependable Network Computing, chapter Dynamic reconguration in high speed local area networks. Kluwer
Academic Publishers, 1999.
10. J. Duato, S. Yalamanchili, M.B. Caminero, D. Love, and F.J. Quiles. MMR: A highperformance multimedia router. architecture and design trade-os. In Proceedings
of the 5th Symposium on High Performance Computer Architecture (HPCA-5),
January 1999.
11. J. Duato, S. Yalamanchili, and L. Ni. Interconnection networks. An engineering
approach. IEEE Computer Society, 1997.
12. D. Ferrari and D.C. Verma. Scheme for real-time channel establishment in widearea networks. IEEE Journal on Selected Areas in Communications, 8(3):368{379,
April 1990.
13. D. Garcia and W. Watson. Servernet II. In Lecture Notes in Computer Science,
pages 119{136. Springer, June 1997. Proceedings of the Workshop on Parallel
Computer Routing and Communication.
14. M. Gerla, B. Kannan, B. Kwan, P. Palnati, S. Walton, E. Leonardi, and F. Neri.
Quality of service support in high-speed, wormhole routing networks. In International Conference on Network Protocols, October 1996.
15. P. Kermani and L. Kleinrock. Virtual cut-through: A new computer communication switching technique. Computer Networks, 3:267{286, 1979.
16. M. Lauria, S. Pakin, and A.A. Chien. EÆcient layering for high speed communication: Fast messages 2.x. In Proceedings of the 7th High Performance Distributed
Computing (HPDC7) conference (Chicago, Illinois), pages 28{31, July 1998.
17. Mainwaring A. M., Chun B. N., Schleimer S., and Wilkerson D. S. System area
network mapping. In Proceedings of the 9th Annual Symposium on Parallel Algorithms and Architectures (SPAA), 1997.
18. Myrinet User's Guide: The MCP.
http://www.myri.com:80/scs/documentation/mug/development/mcp.html.
19. A. Mehra, A. Indiresan, and K.G. Shin. Resource management for real-time communication: making theory meet practice. In IEEE RTAS, pages 130{138, 1996.
20. Inc. Myricom. http://www.myri.com.
21. F. Naquin. Evaluation d'architecture reseaux locaux haut debit: Myrinet, master's
thesis. Technical report, LHPC, Laboratoire d"informatique de Besancon, 1997.
22. R. Perlman. An algorithm for distributed computation on a spanning tree in
a extended lan. In Proceedings of the 9th Data Common Symposium, Whistler
Mountain, British Columbia, pages 44{53, September 1985.
23. L. Prylli and B. Tourancheau. Bip: A new protocol designed for high performance
networking on myrinet. Lecture Notes in Computer Science, 1388:472{488, 1998.
24. T.L. Rodeheer and M.D. Schroeder. Automatic reconguration in Autonet.
Technical Report 77, Systems Research Center of Digital Equipment Corporation,
September 1991.
25. M.D. Schroeder, A.D. Birrell, M. Burrows, H. Murray, R.M. Needham, T.L.
Rodeheer, E.H. Satterthwate, and C.P. Thacker. Autonet: a high-speed, selfconguring local area network using point-to-point links. IEEE Journal on Selected
Areas in Communications, 9(8):1318{1334, October 1991.
26. F. Silla and J. Duato. Improving the eÆciency of adaptive routing in networks with
irregular topology. In Proceedings of the 1997 Int. Conference on High Performance
Computing, December 1997.

QoS para Aplicaciones de Tiempo Real en NOWs mediante

Transcripción

Documentos relacionados

ProPlan CMF Solicitud de servicio: reconstrucción