Una Propuesta para Simplificar el Dise˜no de Encaminadores IP

Una Propuesta para Simplificar el Dise˜no de Encaminadores IP

Una Propuesta para Simplificar el Diseño de
Encaminadores IP con QoS
Alejandro Martı́nez, Francisco J. Alfaro, José L. Sánchez y José Duato
Resumen— En la actualidad los encaminadores IP
capaces de proporcionar QoS lo hacen mediante complejos mecanismos de gestión de colas. Para ello,
el procesamiento de los paquetes debe hacerse de
forma distribuida.
La gran cantidad de tráfico
que deben manejar estos encaminadores requiere un
procesamiento en varias etapas.
En este trabajo se presentan nuevos mecanismos,
no para proporcionar mejor calidad de servicio, sino
para hacerlo simplificando el diseño y, por tanto, utilizando menos recursos. Para ello se tratarán de explotar las redundancias que se han detectado en el
diseño de los encaminadores IP actuales.
Palabras clave— Internet, QoS, Encaminador.
I. Introducción
E
L tráfico en Internet crece de un modo exponencial y nadie puede prever cuando terminará esta
tendencia. Además de crecer en intensidad, también
aparecen nuevos tipos de tráfico: donde antes sólo
habı́a HTTP, FTP y e-mail, ahora surgen necesidades multimedia, tales como audio en tiempo real
(VoIP, voz sobre IP), vı́deo bajo demanda o videoconferencia. Estos nuevos tipos de aplicaciones necesitan algo más de la red que el tı́pico servicio BestEffort que se ha proporcionado hasta ahora.
Las aplicaciones multimedia suelen presentar requisitos en cuanto a ancho de banda y/o latencia.
Esto se conoce como requisitos de calidad de servicio (QoS). Además, pueden necesitar algún tipo de
garantı́a de que los recursos que demandan estarán
disponibles. Para satisfacer estos requisitos necesitamos enlaces de alta velocidad y encaminadores más
rápidos. Los notables avances en el área de la fibra
óptica han mejorado significativamente la velocidad
y capacidad de los enlaces. Sin embargo, la velocidad
de los encaminadores, limitada por la ley de Moore,
crece a un ritmo mucho menor.
En este trabajo se aborda la tarea de simplificar el
diseño de los encaminadores, manteniendo las prestaciones. Para ello se buscarán y aprovecharán las redundancias que puedan existir en dicho diseño. Una
versión completa del trabajo realizado puede encontrarse en [1].
Este artı́culo se estructura de la siguiente forma:
en la Sección II se presenta la arquitectura genérica
de un encaminador IP, la Sección III se centra en
cómo consiguen los encaminadores IP actuales proporcionar QoS. En la Sección IV se presentan las
Departamento de Informática, Escuela Politécnica Superior, Universidad de Castilla-La Mancha, 02071 - Albacete
(España). {alexmv,falfaro,jsanchez}@info-ab.uclm.es
Departamento de Informática de Sistemas y Computadores, Universidad Politécnica de Valencia, 46071 - Valencia
(España). [email protected]
Este trabajo ha sido parcialmente financiado por la CICYT
con el proyecto TIC2000-1151-C07 y por la Junta de Comunidades de Castilla-La Mancha con el proyecto PBC-02-008.
propuestas de este trabajo para la planificación en el
encaminador. Finalmente, la evaluación de las propuestas se realiza en la Sección V y la Sección VI
contiene las conclusiones y el trabajo futuro.
II. Arquitectura de los encaminadores IP
Los encaminadores son los encargados de unir las
redes que componen Internet, haciendo posible que
exista como un todo. Su principal función es llevar
paquetes desde unos enlaces de entrada a otros de salida. Sin embargo, también deben ser capaces de gestionar distintas tecnologı́as de enlace, proporcionar
QoS y participar en algoritmos de encaminamiento
distribuidos.
Las redes que forman Internet pueden clasificarse
en tres categorı́as: las redes de acceso permiten a
los hogares y pequeños negocios conectarse a sus
ISPs (Proveedores de Servicios de Internet), las redes
corporativas conectan decenas de miles de computadores en un campus o corporación, y finalmente el
backbone, la columna vertebral de Internet, conecta
las redes corporativas y los ISPs. En estas tres categorı́as los encaminadores juegan un papel fundamental, con distintos retos en cada una de ellas.
Los encaminadores corporativos, también conocidos como “de campus”, conectan sistemas finales.
Al contrario que los encaminadores backbone donde
es prioritaria la velocidad y el coste es secundario,
en este tipo de encaminadores se pretende conectar
el máximo número de terminales de la forma más
barata posible. Además, en estos casos es deseable
que haya un soporte para diferentes niveles de servicio, de cara a poder priorizar ciertos tipos de tráfico
sobre el resto. Por estos motivos, éste es el tipo de
encaminador idóneo para este estudio.
Switch
F a b r ic
Puertos de
E n tra da
Procesador de
E n ru t am i en t o
Puertos de
S a l i da
Fig. 1. Estructura de un encaminador IP genérico.
Tal y como puede apreciarse en la Figura 1, un
encaminador IP genérico tiene básicamente cuatro
partes [2]:
Puertos de entrada (Input adapters, IA). Los
puertos de entrada proporcionan diversas funcionalidades. En primer lugar, llevan a cabo el
encapsulado y desencapsulado de la capa de enlace de datos. En segundo lugar, pueden consultar la dirección destino en una tabla de reenvı́o
para determinar su puerto destino. En tercer lugar, el puerto puede determinar la clase de servicio de los paquetes para proporcionarles QoS.
En cuarto lugar, el puerto puede que tenga que
ejecutar protocolos de nivel de enlace de datos
como SLIP o PPP, o incluso de la capa de red
como PPTP. Cuando se conoce su destino, se
envı́a el paquete al puerto de salida a través del
elemento de conmutación.
Elemento de conmutación: El elemento de
conmutación conecta los puertos de entrada
con los de salida, permitiendo que los paquetes
atraviesen el encaminador. Se puede implementar de diferentes formas, siendo las más
habituales buses, crossbars, redes multietapa y
memorias compartidas. Los buses son simples
y conectan todas las entradas con las salidas.
Sin embargo, son un recurso compartido que
necesita arbitraje y escalan muy mal. Los
crossbars permiten varios caminos de datos
simultáneos, sin embargo su complejidad crece
cuadráticamente con el número de entradas
que conectan y su velocidad se ve limitada por
el planificador. Las redes multietapa surgen
para resolver los problemas de escalabilidad
de los crossbar. Son más lentas pero permiten
un mayor número de conexiones. El SF de
memoria compartida puede ser accedida por
los puertos de entrada y salida, y sirve para
almacenar los paquetes entrantes hasta que son
encaminados. Sin embargo, su punto débil es
su velocidad.
Puertos de salida: Los puertos de salida almacenan los paquetes hasta que son transmitidos
por el enlace de salida. Pueden implementar algoritmos de planificación del enlace para soportar prioridades y garantı́a de servicio. Al igual
que los puertos de entrada, los puertos de salida
también realizan el encapsulado y desencapsulado de la capa de enlace de datos. Además,
también pueden soportar diversos protocolos de
enlace de datos y red.
Procesador de enrutamiento: El procesador
de enrutamiento calcula la tabla de reenvı́o, implementa los protocolos de encaminamiento y
ejecuta el software para configurar y gestionar
el encaminador. Además, también gestiona
cualquier paquete cuya dirección no se haya determinado en los puertos de entrada.
III. QoS en encaminadores IP
Un encaminador acepta tráfico de muy distintos
tipos. Algunos tienen requisitos en cuanto a latencia
máxima, otros no son tan sensibles al retardo, pero
necesitan un ancho de banda constante. A otros simplemente les basta con llegar. A los encaminadores
que son conscientes de estas diferencias e intentan
proporcionar un trato distinto a cada tipo de tráfico
según sus necesidades se les denomina encaminadores con soporte QoS.
Pelissier [3] propone una clasificación de los flujos de tráfico en función de sus requisitos. Se distinguen cuatro categorı́as: DBTS (Dedicated Bandwidth Time Sensitive), DB (Dedicated Bandwidth),
BE (Best Effort) y CH (Challenged). El tráfico
DBTS y DB presentan requisitos en cuanto a ancho
de banda, pero además, el tráfico DBTS es sensible al
retraso, mientras que el tráfico DB no lo es. La diferencia entre el tráfico BE y CH es que BE debe competir con los tráficos más prioritarios para circular
por la red, mientras que sólo se transmitirı́a tráfico
CH cuando no hubiera otro tipo de tráfico presente.
Por ejemplo, podrı́a ser tráfico CH el tráfico generado
por una copia de seguridad que necesita almacenarse
en un dispositivo remoto y que puede transmitirse en
los momentos en que no se esté transmitiendo otro
tipo de tráfico por la red.
Los dos principales enfoques propuestos para que
Internet afronte el reto de la QoS son: los Servicios
Diferenciados [4] y los Servicios Integrados [5].
A. Servicios Diferenciados
El modelo de Servicios Diferenciados se basa en
un esquema de prioridades. Los encaminadores hacen un tratamiento paquete a paquete en el que sólo
tienen en cuenta el nivel de servicio que éstos llevan incorporado en sus cabeceras. En IPv4 era en el
campo ToS, pero nunca se llegó a usar. En IPv6 es
el campo Traffic Class.
Para marcar cada paquete con el nivel de servicio
adecuado hace falta un acuerdo de los usuarios con
sus ISPs y un tratamiento adecuado en los encaminadores fronterizos.
B. Servicios Integrados
En el modelo de Servicios Integrados se persigue
un marco global para proporcionar QoS en Internet.
En este marco se hace un tratamiento a nivel de flujos
de paquetes, donde todos los paquetes de un mismo
flujo deben tener los mismos requisitos de QoS.
El modelo de Servicios Integrados requiere las siguientes funciones:
•
•
•
•
Control de admisión: Antes de comenzar a
transmitir, las aplicaciones deben hacer una
reserva previa de recursos. Si no es posible satisfacer las demandas realizadas por las aplicaciones puede haber un proceso de negociación,
pudiendo suceder que la conexión no llegue a
establecerse.
Algoritmo de enrutamiento: Debe tener en
cuenta las necesidades de QoS, buscando no sólo
la ruta más corta, sino la que mejores prestaciones puede dar.
Arbitraje: Para resolver adecuadamente los conflictos que se puedan presentar en el interior de
los encaminadores.
Descarte de paquetes: Si se permite el descarte
de paquetes para tratar la congestión, habrá que
tener en cuenta las necesidades de QoS. Esto
también es aplicable a Servicios Diferenciados.
IV. Planificación en el encaminador
Como se ha puesto de manifiesto en las secciones
anteriores, las exigencias demandadas a los encaminadores son cada vez mayores. Para conseguir
cumplir con ellas se han planteado diversas lı́neas de
actuación. Ası́, por ejemplo, se ha propuesto incrementar el número de canales virtuales (CVs), con lo
que es más sencillo evitar el HOL Blocking. También
se han planteado complejas polı́ticas de calidad de
servicio, como asignar un canal virtual a cada flujo
[6]. Sin embargo, incrementar el número de canales
virtuales implica o bien reducir el espacio de buffer
asignado a cada canal virtual con colas a la entrada
o a la salida, o bien usar un buffer central, que optimice el espacio pero que debe funcionar a frecuencias
de reloj muy altas.
El objetivo principal de este trabajo es analizar
si una reducción en la complejidad del diseño permite seguir alcanzando niveles de prestaciones similares. Evidentemente reducir complejidad no debe
suponer eliminar funcionalidades, y por tanto esta
reducción debe estar basada en la eliminación de redundancias. Un análisis detenido del modelo de encaminador que se presentó en la Sección II permite
ver que hay muchas posibles redundancias. En los
buffers del IA se absorbe el tráfico entrante en el
orden en que llega. Sin embargo, en el IA tiene lugar cierto procesamiento que permite que a la salida
los paquetes más prioritarios hayan adelantado a los
menos urgentes. Este flujo ordenado de paquetes entra a continuación en la primera etapa del SF, en
forma de varios canales virtuales. En el primer conmutador entran los flujos provenientes de varios IAs.
En su interior se realiza un nuevo procesamiento de
modo que a la salida se vuelve a tener un flujo ordenado, compuesto otra vez de varios canales virtuales.
En el conmutador ya se puede apreciar que quizá
se esté haciendo trabajo de más. Como se ha visto,
a la salida de los IAs ya se tienen los paquetes ordenados. Ası́ pues, es posible plantear la cuestión
de si es realmente necesario volver a separar el flujo
en canales virtuales, o si no serı́a más fácil tratar
de conservar, en la medida de lo posible, el trabajo
realizado en el IA.
A. Redundancia en la clasificación del tráfico
El problema que se plantea en el primer conmutador es muy similar a la ordenación de un vector
de números mediante el método divide y vencerás.
El conocido algoritmo consiste en dividir el vector
en varias partes, ordenarlas por separado y combinar las soluciones. Para hacer esto último se crea el
nuevo vector solución tomando en cada paso el elemento de cabeza menor de los vectores componentes,
es decir, sólo se comparan las cabezas de los vectores,
respetando la ordenación que se ha hecho en las etapas anteriores.
En el caso del conmutador el problema es simi-
lar. En lugar de deshacer el flujo que le llega de
los canales virtuales, desbaratando el orden en que
venı́an los paquetes, podrı́a tratar de conservar ese
orden, ahorrando trabajo y simplificando la lógica.
Esta mayor simplicidad se traducirá en elementos
más baratos y con ciclos de reloj más cortos.
Por supuesto, estos razonamientos también son
aplicables a los conmutadores de las siguientes etapas, de hecho a todos los conmutadores, los cuales
respetarı́an la ordenación de sus predecesores.
B. Proporcionar calidad de servicio
Si sólo hubiera un único criterio para ordenar los
paquetes, como el deadline o el nivel de servicio, el
esquema planteado en la sección anterior tendrı́a un
rendimiento perfecto. A la salida de la última etapa
los paquetes estarı́an ordenados del mejor modo posible. Sin embargo, lo habitual es que haya que tener
en cuenta otros criterios a la hora de seleccionar un
paquete u otro. En concreto, son comunes criterios
del tipo de ancho de banda, latencia máxima, etc..
Para proporcionar un cierto ancho de banda, el
algoritmo de planificación suele dividir el tiempo en
slots y repartirlos proporcionalmente a la demanda
de cada flujo o nivel de servicio. Un algoritmo común
para esta tarea es el WRR [7]. A la salida del IA, por
ejemplo, tendremos una mezcla de paquetes tal que
la cantidad de cada tipo será proporcional al ancho
de banda otorgado.
Cuando el flujo proporcionado llega al conmutador
de la primera etapa, éste no necesita demultiplexar el
flujo en canales virtuales porque las proporciones de
paquetes de cada tipo son las correctas. Le basta con
repartir el ancho de banda de forma adecuada entre
los enlaces de entrada, de modo que se preserve la
proporción entre paquetes. Ası́ pues, cuando sólo hay
un criterio para ordenar los paquetes, todo va muy
bien, pero ¿qué pasa si tenemos que aplicar varios
criterios a la vez?
En la clasificación del tráfico de la Sección III,
se vio que hay tráfico sensible al retraso, sensible al ancho de banda y sensible a ambos. Para
resolver este problema podemos plantearnos varias
soluciones: podrı́amos demultiplexar el tráfico en dos
categorı́as, sensible a retraso y sensible a ancho de
banda, y aplicar el arbitraje sobre ellas. También
podrı́amos confiar en que la ordenación del IA sea lo
bastante buena como para respetarla tal como llega.
O quizás, este problema haga que la idea de respetar
la ordenación anterior no sea práctica. Estas son las
cuestiones que se tratarán de resolver en este trabajo.
Por otro lado se tiene el tráfico Best-Effort. En
general, el IA se limitará a rellenar los huecos que
queden tras enviar el tráfico más prioritario, quizá
garantizándole un mı́nimo de ancho de banda. En
esta situación podrı́an alterarse las prioridades de
los paquetes debido al HOL Blocking. Si el conmutador de la siguiente etapa se limita a observar el
paquete de la cabeza del flujo, como se ha defendido
antes, podrı́a darse el caso de que un paquete más
prioritario quedase bloqueado detrás de un paquete
Best-Effort. Sin embargo la solución es tan sencilla
como demultiplexar el tráfico Best-Effort en su propio canal virtual.
En resumen, la propuesta consiste en tratar de reducir el número de canales virtuales que se necesitan
en las etapas posteriores al IA. En lugar de tener un
CV por flujo o nivel de servicio, podrı́amos tener tres
canales virtuales: el de paquetes sensibles al retardo,
el de paquetes sensibles al ancho de banda y el de
paquetes Best-Effort.
V. Evaluación
En esta sección se van a concretar una serie de propuestas y se evaluarán mediante simulación. Se ha
desarrollado un simulador de un encaminador corporativo, con arquitectura basada en conmutador con
procesadores totalmente distribuidos, inspirado en el
Avici TSR [8]. Para empezar, se verá en detalle el
modelo simulado.
A. Modelo de encaminador
El encaminador en el que se centra este trabajo
es de tipo corporativo. Este tipo de encaminador
necesita conectar una gran número de sistemas, por
lo que implementa muchos puertos. También debe
ofrecer un gran ancho de banda, pero teniendo en
cuenta las necesidades de QoS. Por último, el coste
de este tipo de encaminadores no debe ser excesivo.
Estos requisitos hacen que los encaminadores corporativos sean un reto para sus diseñadores y el marco
ideal para probar los objetivos de este trabajo.
A.1 Input Adapter
La misión del IA consiste en almacenar y clasificar
el tráfico entrante. Para ello dispone de un buffer
dividido en canales virtuales para los distintos niveles
de servicio. Los buffers son lo bastante grandes para
absorber posibles ráfagas que puedan llegar.
Por otra parte, el IA implementa algún mecanismo
de control de flujo, como el de créditos. En este
trabajo no es de interés entrar en estas cuestiones,
por lo que supondremos que el tamaño del buffer no
es un problema, dentro de unos lı́mites razonables.
Se considera también Virtual Output Queuing
(VOQ) pues es la solución al HOL Blocking habitualmente incorporada en este tipo de encaminadores. Dado que estos dispositivos reciben tráfico de
muy diferentes caracterı́sticas, se considera que se
disponen de facilidades para su clasificación.
A.2 Switch Fabric
El encaminador utilizará una red multietapa como
Switch Fabric. El Avici TSR, modelo de referencia,
tiene el procesamiento distribuido entre los IAs y utiliza una red de interconexión toro 3d [8]. Aunque
la red multietapa que se modela proporciona peores prestaciones [9], para este estudio se ha preferido
porque no se pretende medir el rendimiento del
Switch Fabric, y es ideal para poner en práctica las
ideas antes presentadas, al contener redundancias entre sus etapas. Esto no quiere decir que las mejoras
que aquı́ se discuten solo sirvan en redes multietapa.
Llevarlas a los nodos del toro 3d del Avici TSR, por
ejemplo, serı́a algo directo.
A.3 Conmutadores
Los conmutadores son cada uno de los nodos que
interconecta la red multietapa. Los conmutadores
modelados en el simulador se componen de los siguientes elementos:
Crossbar: Sirve de Switch Fabric a nivel de conmutador, conectando los enlaces de entrada con
los de salida.
Buffer: Espacio del almacenamiento para los
mensajes que esperan que quede libre el enlace
que deben usar. Sobre los buffers se implementa, mediante CVs, VOQ y el tratamiento
de los niveles de servicio. Estos CVs son en realidad colas lógicas, que se reparten el espacio del
buffer según es necesario, de un modo parecido
a los buffers centrales.
Unidad de encaminamiento: Ejecuta la
función de encaminamiento, que para el modelo
considerado es determinista.
Link Controller: Resuelve los conflictos sobre
un enlace, decidiendo qué paquete debe continuar. El arbitraje del conmutador se hace de
forma distribuida.
Los paquetes que forman un mensaje nunca se
adelantan unos a otros, pues al utilizar los mismos
buffers en los conmutadores y seguir la misma ruta
en la red multietapa, preservan el orden. Además,
no se intercalan paquetes de dos mensajes distintos. El primer paquete del mensaje va reservando
recursos según avanza, mientras que el último los va
liberando.
Entre los conmutadores de la multietapa se implementa como técnica de conmutación cut-through [10],
de modo que la cabecera de un paquete no necesita
esperar a que llegue el resto para salir por el enlace.
Sin embargo, a diferencia de wormhole [11], siempre
debe haber espacio suficiente para todo el paquete
en el buffer del siguiente salto.
El control de flujo entre conmutadores se basa
en créditos, de modo que cada conmutador conoce
cuanto espacio le quedan a los buffers de la siguiente etapa. Este tipo de control de flujo elimina la
necesidad de descartar paquetes. En el simulador un
crédito permite almacenar un paquete completo.
B. Modelo de tráfico
Los tipos de tráfico se simularon mediante el uso
de 5 niveles de servicio, tal y como se refleja en la
Tabla I.
TABLA I
Niveles de servicio
Nivel
1
2
3
4
5
Tráfico
Best Effort
Requisito de Ancho de banda
Requisito de Deadline
TABLA II
Configuraciones sobre planificación en el encaminador
El tráfico sensible al retraso se modeló mediante
los niveles 3, 4 y 5, donde se supone que los flujos
de nivel de servicio 4 tienen un deadline más restrictivo que los de nivel de servicio 3 y los de nivel de
servicio 5 tienen un deadline más restrictivo que los
de nivel de servicio 4. Los paquetes no llevan un
deadline como tal, ası́ que no es posible hacer una
ordenación efectiva de los paquetes. Sin embargo,
esto se abstrae mediante los tres niveles de servicio.
En los resultados de la simulación habrá que comprobar que la latencia de cada nivel es igual o mejor
que la del nivel inmediatamente inferior.
El tráfico sensible a ancho de banda se modela con
el nivel de servicio 2. En este caso el parámetro más
relevante es la productividad. Los mensajes tampoco
llevan el requisito de ancho de banda especı́fico, ni
hay una reserva previa de recursos. De este modo
el encaminador no puede darle a cada flujo el ancho
de banda exacto que necesita, con lo que se limita a
proporcionar la mejor productividad posible.
Por último, el tráfico Best Effort se simula con
el nivel de servicio 1. Aunque para este tipo de
tráfico no hay que optimizar nada, generalmente se
considera que debe tener una productividad mı́nima.
Este tipo de tráfico hace necesaria y posible la calidad de servicio. Necesaria porque si no estuviera, la
red irı́a muy descargada y todos los mensajes irı́an a
las máximas prestaciones. Posible porque todas las
mejoras de los otros niveles de servicio se hacen a
costa del tráfico Best Effort.
En la Tabla II se presentan las cuatro configuraciones que se han considerado. La primera, configuración A, modela un encaminador de altas prestaciones que aplica WRR en los IAs y en los conmutadores del Switch Fabric, esperando obtener los
mejores resultados. La configuración B cambia el
WRR de los conmutadores del Switch Fabric por un
esquema de prioridades estricto. En la configuración
C se reduce a 3 el número de canales virtuales de los
conmutadores del Switch Fabric, multiplexando en
un CV todo el tráfico sensible a retraso. La última
configuración, la D, es la más sencilla. En lugar de
VOQ en los IAs, pone tan sólo 2 canales virtuales
para ello. Además, esta configuración D aplica en
los conmutadores un esquema de prioridades estricto,
pero haciendo primero round-robin de enlaces.
En todas las configuraciones se aplica VOQ en el
SF y se asigna el CV en el IA según el nivel de
servicio. Se han probado dos tamaños de buffer.
Las configuraciones A y B utilizan buffers de 20
créditos, mientras que las configuraciones C y D utilizan buffers de 12 créditos. En [1] pueden encontrarse más configuraciones con otras variantes.
Switch Fabric
Asignación CV Selección CV
NS
WRR
NS
NS-G
NS-M
NS-G
NS-M
NS-R
CVs
5
5
3
3
Buffer
20
20
12
12
C. Índices de prestaciones
Para evaluar las prestaciones de las distintas configuraciones se examinarán tres parámetros:
Latencia de cruce: El tiempo que tarda un
paquete en cruzar el Switch Fabric. Aquı́ no se
considera el tiempo que se esperó en el IA.
Espera en el IA: Tiempo que cada paquete estuvo esperando en los buffers del IA. Sumado a
la latencia de cruce nos proporciona el tiempo
total que estuvo un paquete en el encaminador,
es decir, la latencia desde la generación, que es
la que realmente importa.
Productividad: Viene expresada en tanto por
uno y se obtiene al dividir las palabras salientes
entre las palabras entrantes.
D. Resultados de la simulación
En la Figura 2 se muestran los tiempos de cruce
de cada nivel de servicio en cada configuración. Las
cuatro gráficas son muy parecidas. En la configuración A se aprecia que el tráfico sensible a ancho
de banda tiene un tiempo de cruce mayor que en las
otras configuraciones. Esto es debido a que el uso
de WRR en los conmutadores no penaliza tanto al
tráfico Best-Effort. Por lo demás, las configuraciones
se comportan de un modo muy parecido, sobre todo
en lo que respecta al tráfico sensible a retraso (niveles
1 a 3).
500
500
450
SL 1
SL 2
SL 3
SL 4
SL 5
400
350
450
SL 1
SL 2
SL 3
SL 4
SL 5
400
Latencia (Ciclos)
VOQ
Sı́
Sı́
Sı́
2
300
250
200
150
100
350
300
250
200
150
100
50
50
0
0
0
0.01
(a)
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
0.08
0
0.01
(b)
500
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
0.08
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
0.08
500
450
SL 1
SL 2
SL 3
SL 4
SL 5
400
350
450
SL 1
SL 2
SL 3
SL 4
SL 5
400
Latencia (Ciclos)
IA
Selección CV
WRR
WRR
WRR
WRR
Latencia (Ciclos)
CVs
5
5
5
5
Latencia (Ciclos)
Configuración
A
B
C
D
300
250
200
150
100
350
300
250
200
150
100
50
50
0
0
0
(c)
0.01
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
0.08
0
(d)
0.01
Fig. 2. Latencia de cruce para las configuraciones A, B, C y
D, respectivamente.
Una cuestión notable es que a pesar de haber entrado en saturación, el tráfico sensible a retraso apenas varı́a sus tiempos de cruce. Esto indica que es
el IA quien absorbe el impacto de sobrecargar el encaminador.
10000
10000
1000
1000
Espera (Ciclos)
Espera (Ciclos)
La Figura 3 representa la espera en el IA de los paquetes para cada una de las cuatro configuraciones.
Tampoco hay grandes diferencias para las configuraciones estudiadas. Se puede apreciar como después
de saturarse el encaminador, el tráfico sensible a retraso siempre se comporta mejor, aunque en esta
situación de sobreutilización los tiempos se mueven
de una forma un tanto errática.
100
SL 1
SL 2
SL 3
SL 4
SL 5
10
100
1
1
0
0.01
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
(a)
0.08
0
10000
10000
1000
1000
100
SL 1
SL 2
SL 3
SL 4
SL 5
10
0.01
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
(b)
Espera (Ciclos)
Espera (Ciclos)
SL 1
SL 2
SL 3
SL 4
SL 5
10
0.08
100
SL 1
SL 2
SL 3
SL 4
SL 5
10
1
1
0
0.01
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
(c)
0.08
0
0.01
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
(d)
0.08
Fig. 3. Espera en el IA para las configuraciones A, B, C y D,
respectivamente.
1
1
0.8
0.8
Productividad
Productividad
Por último, en la Figura 4 se muestra la productividad obtenida para las cuatro configuraciones utilizadas. Al igual que en los casos anteriores, no hay
apenas diferencias entre las cuatro configuraciones
estudiadas. En todas ellas, cuando hay saturación
el primer tipo de tráfico en sentirlo es el Best-Effort,
seguido del sensible a ancho de banda. El tráfico sensible a retraso es el que menos sufre, aunque llega a
un punto en el que también empieza a caer su productividad.
0.6
0.4
SL 1
SL 2
SL 3
SL 4
SL 5
0.2
0
0
0.01
(a)
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
0.08
0
1
1
0.8
0.8
0.6
0.4
SL 1
SL 2
SL 3
SL 4
SL 5
0.2
0.01
(b)
Productividad
Productividad
SL 1
SL 2
SL 3
SL 4
SL 5
0.2
0
[1]
0.6
0.4
0.08
0.6
0.4
SL 1
SL 2
SL 3
SL 4
SL 5
0.2
0
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
0
0
(c)
0.01
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
0.08
0
(d)
0.01
0.02 0.03 0.04 0.05 0.06 0.07
Tasa de inyeccion (flits/ciclo/nodo)
Fig. 4. Productividad para las configuraciones A, B, C y D,
respectivamente.
VI. Conclusiones y trabajo futuro
El estudio del diseño de los encaminadores con soporte para QoS ha mostrado que existen redundancias en el procesamiento de los paquetes. En este
trabajo se ha visto que estas redundancias pueden
explotarse para obtener las mismas prestaciones, o
similares, reduciendo la complejidad del diseño.
En este estudio se ha comprobado que en un encaminador como el Avici TSR, los conmutadores del
Switch Fabric no tienen por qué repetir una y otra
vez el mismo trabajo. Con que se haga una vez bien
en los IAs, las etapas de procesamiento posteriores
pueden reducir su complejidad.
A lo largo de este estudio se ha usado un esquema
de QoS orientado a los Servicios Diferenciados. Esto
quiere decir que no hay una reserva previa de recursos. Este tipo de esquema no permite hacer un
correcto dimensionado de los recursos, con lo que
nada impedirá que se haga un uso excesivo del encaminador, con las consecuencias negativas que eso
puede tener.
Este trabajo sólo es una primera aproximación.
Por ejemplo, una reserva previa de recursos podrı́a
ofrecer nuevas e interesantes posibilidades a estudiar,
como algoritmos más complejos que el WRR o un uso
más ajustado de los recursos del encaminador.
Como conclusión, se puede decir que vale la pena
realizar un estudio detallado del diseño de los encaminadores, porque quizá se estén poniendo más
medios de los que realmente son necesarios. Un estudio como éste podrı́a llevar a encaminadores que sean
a la vez más sencillos, más rápidos y con la misma
funcionalidad, simplemente aprovechando mejor los
recursos de los que disponen.
Agradecimientos
Los autores quieren agradecer a Pepe Flich del
GAP de la Universidad Politécnica de Valencia la
atención y ayuda que nos ha prestado.
Referencias
0.08
A. Martı́nez, “Una Propuesta para Simplificar el Diseño
de Encaminadores IP con QoS,” Proyecto fin de carrera.
Dpto. Informatica, Universidad de Castilla-La Mancha,
2003, http://www.info-ab.uclm.es/personal/falfaro/
pfc/AMartinez.zip.
[2] J. Aweya, “On the Design of IP Routers, Part 1: Router
Architectures,” Journal of Systems Architecture, vol. 46,
pp. 483–511, July 2000.
[3] Joe Pelissier, “Providing Quality of Service over Infiniband Architecture Fabrics,” in Proceedings of the 8th
Symposium on Hot Interconnects, Aug. 2000.
[4] S. Blake, D. Back, M. Carlson, E. Davies, Z. Wang, and
W. Weiss, “An Architecture for Differentiated Services,”
Internet Request for Comment RFC 2475, Internet Engineering Task Force, Dec. 1998.
[5] R. Braden, D. Clark, and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” Internet Request for Comment RFC 1633, Internet Engineering Task Force, June 1994.
[6] D. Love, S. Yalamanchili, J. Duato, M.B. Caminero,
and F.J. Quiles, ““Switch scheduling in the Multimedia
Router (MMR)”,” in Proceedings de International Parallel and Distributed Processing Symposium (IPDPS).
Mayo 2000, IEEE Computer Society.
[7] M. Katevenis, S. Sidiropoulos, and C. Corcoubetis,
“Weighted round-robin cell multiplexing in a generalpurpose ATM switch,” IEEE Journal on Selected Areas
in Communications, Oct. 1991.
[8] Avici Systems,
“Avici Terabit Switch Router.
http://www.avici.com” .
[9] William J. Dally, “Scalable switching fabrics for internet routers,” Tech. Rep., Computer Systems Laboratory,
Stanford University and Avici Systems, Inc., 2003.
[10] P. Kermani and L. Kleinrock, “Virtual cut-through:
A new computer communication switching technique,”
Computer Networks, vol. 3, pp. 267–286, 1979.
[11] W.J. Dally and C.L. Seitz, “Deadlock-free message routing in multiprocessor interconnection networks,” IEEE
Transactions on Computers, vol. C-36, no. 5, pp. 547–
553, May 1987.