Provisión de Calidad de Servicio Basada en Reservas para

Provisión de Calidad de Servicio Basada en Reservas para Entornos
Móviles
Alberto López1, Héctor Velayos3, Tomás Robles2, Nuria Villaseñor3
1
Departamento de Ingeniería de la Información y las Comunicaciones, Universidad de Murcia,
Facultad de Informática, Campus Universitario de Espinardo - 30071 Murcia
Teléfono 968 364607, Fax: 968 364151
E-mail: alberto@dif.um.es
2
Departamento de Ingeniería de Sistemas Telemáticos, Universidad Politécnica de Madrid
ETSI Telecomunicación, Ciudad Universitaria – 28040 Madrid
Teléfono: 91 336 7332, Fax: 91 336 7333
E-mail: robles@dit.upm.es
3
Agora Systems S.A.
c/ Aravaca 12 3ºB - 28040 Madrid
Teléfono: 91 533 5857, Fax: fax: 91 534 8477
E-mail: {hvelayos, nuria_villasenor}@agoratechnologies.com
Abstract. With the fast adoption of IP-based communications for mobile computing, users are expecting a
similar service in wireless and wired networks. This raises the need for setting guarantees to the quality of
the offered service (QoS), despite the technology of the access network or the mobility of the terminal. This
generates a new challenge for QoS provision, as it will have to deal with terminals changing their point of
attachment to the network. In this paper an optimisation for the operation of reservation based QoS is given
for mobile environments: the coupling of the reservation protocol RSVP with different per-host micromobility protocols. The micro-mobility and QoS signalling mechanism are coupled either loosely via a
triggering mechanism, or more tightly so the QoS and mobility information is carried by the same protocol.
Qualitative and quantitative results of this coupling is presented. The procedure includes the comparison of
performance parameters such as delay, loss and throughput when protocols are coupled and de-coupled.
1
Introducción.
El crecimiento de la industria de telefonía móvil en
la última década ha sido exponencial, basado
principalmente en sistemas existentes de 2ª
generación como GSM y tráfico de voz. Con la
llegada de sistemas de 3ª generación como UMTS
se espera que aproximadamente en el año 2005 el
número de subscriptores de servicios móviles en el
mundo supere al número de usuarios de telefonía
fija, si no antes. Por otro lado, la cantidad de tráfico
de datos de las redes fijas ha sufrido un incremento
explosivo, debido principalmente al crecimiento de
Internet y a la proliferación de redes intranet
corporativas. Las aplicaciones usadas en esos
entornos están basadas principalmente en IP, como
el Web y las aplicaciones multimedia de banda
ancha. Las redes IP pronto soportarán un rango de
servicios que van desde los tradicionales IP hasta
las aplicaciones interactivas multimedia y
servidores de voz. Todos esos servicios requerirán
garantías de Calidad de Servicio (QoS) diferentes
por parte de la red, y los mecanismos de calidad de
servicio presentes deberán asegurar a los usuarios el
servicio adecuado para sus datos de aplicación.
Si tenemos en cuenta que los nuevos sistemas de 3ª
generación están moviéndose hacia sistemas de
transporte basados en IP, el siguiente paso lógico es
el de extender ése transporte IP hacia el usuario
final de esos servicios, ofreciendo por tanto la
verdadera Internet móvil. Uno de los principales
problemas a resolver en ese entorno es la provisión
de QoS.
Entre las propuestas para proporcionar un
tratamiento privilegiado a ciertos flujos, el
mecanismo de señalización estándar de-facto para
reserva de recursos es el denominado Servicios
Integrados [1] y el Protocolo de Reserva de
Recursos (RSVP) [2]. Éstos fueron diseñados para
proporcionar reservas de recursos explícitas
basadas en flujos principalmente en redes fijas. Sin
embargo, la provisión y mantenimiento de QoS en
un entorno móvil dinámico no es una tarea sencilla.
Además de las propias dificultades que podemos
encontrar a la hora de proporcionar QoS en redes
fijas nos encontramos con que el nodo móvil puede
cambiar potencialmente su punto de acceso a la red1
numerosas veces durante una sesión, por lo que el
verdadero desafío es poder mantener el nivel de
servicio original (el solicitado) a medida que el
terminal se mueve. Además existen otros problemas
como los cambios de dirección IP (Mobile IP [3]) y
la variabilidad y escasez de recursos en el enlace
inalámbrico, que pueden crear situaciones en las
que no se pueda garantizar ciertos niveles de
servicio a los terminales, y por tanto se produzcan
violaciones de la QoS. Una violación de la QoS
puede resultar en retardos excesivos, pérdidas de
paquetes o incluso en una total denegación del
servicio.
Por norma general los mecanismo de QoS y
movilidad
han
evolucionado
de
manera
independiente. El protocolo RSVP estándar puede
reparar cambios producidos en el camino pero no es
consciente del origen o la causa del cambio. La
propuesta aquí presentada consiste en acoplar el
protocolo de movilidad con RSVP. De esta manera
se podría realizar un restablecimiento más rápido de
la reserva tras el handover y se minimizaría el
impacto causado a los flujos con recursos
reservados. Nuestras simulaciones mostrarán cómo
el acoplado de los protocolos junto con la
priorización de la señalización de establecimiento
de reservas reducen el impacto en el rendimiento de
manera considerable.
A lo largo del texto nos referiremos de manera
implícita tan solo a mecanismos del tipo soft-state
tales como RSVP, aunque estos métodos pueden ser
aplicadados igualmente a mecanismos del tipo
hard-state.
2. Acoplado de protocolos.
La calidad de servicio basada en reservas asume, de
manera implícita, un camino relativamente estable
a lo largo de la red. Los cambios en las rutas sólo se
reflejan en las reservas una vez que el mensaje de
refresco ha recorrido todos los nodos del nuevo
camino, lo cual puede introducir un retardo extremo
a extremo muy elevado desde el nodo emisor hasta
el nodo móvil. Mecanismos de refresco y soft-state
en protocolos basados en reservas como RSVP se
diseñaron originalmente para tratar casos de enlaces
caídos, que por otro lado ocurren con poca
frecuencia. Mecanismos más avanzados como el de
reparación del camino local (Local Path Repair) se
diseñaron para reparar de manera eficiente las
reservas de RSVP tras un cambio en las rutas, pero
su funcionamiento no es óptimo si el cambio en la
ruta no es visible de manera explícita para los
routers. La mayoría de los protocolos de movilidad
más comunes tales como MobileIP o MobileIP
1
Este proceso se conoce con el nombre de
handover.
jerárquico [4] funcionan de esa manera. Además,
dado que un cambio en la ruta suele implicar que el
terminal móvil sea responsable de activar o parar el
mecanismo de reparación de camino, se introduce
una sobrecarga de señalización en el terminal
móvil.
2.1 Cooperación entre protocolos.
La solución aquí propuesta consiste en la
colaboración entre los mecanismos de señalización
de QoS los de movilidad local. Esta colaboración o
acoplado se puede diseñar de formas muy diversas,
aunque
podemos
identificar
tres
niveles
fundamentales:
•
No acoplados: Este es el estado actual, donde
un protocolo no es consciente de la existencia
del otro, aparte de por los efectos externos
como por ejemplo el propio cambio en la ruta.
•
Acoplado ‘débil’: Se utilizan mecanismos de
disparo para informar a un protocolo sobre
cambios o acciones del otro.
•
Acoplado ‘fuerte’: La información de calidad
de servicio y movilidad es transportada
conjuntamente de alguna manera, por ejemplo
añadiendo información de QoS en los mensajes
del protocolo de movilidad. Un ejemplo claro
de este acoplado aplicado a QoS es el protocolo
INSIGNIA [5].
La elección de una de estas opciones es un
compromiso entre aplicabilidad, complejidad y
rendimiento. Si ambos protocolos conviven sin
ningún tipo de información sobre el otro no es
posible aprovecharse de algunas de sus
características avanzadas, y por lo tanto no es
posible obtener un aumento del rendimiento,
aunque la transparencia se conserva. Esta
transparencia hace posible el desarrollo libre e
independiente de los protocolos. Por otro lado el
acoplamiento fuerte tiene la ventaja de poder
obtener un rendimiento óptimo a un mayor coste en
aplicabilidad y desarrollo, ya que las soluciones
existentes deben ser modificadas de manera más
profunda. En general un mayor nivel de
acoplamiento entre elementos de la red no es una
buena práctica de diseño ya que puede violar
algunos de los principios arquitectónicos de
Internet, tales como la división en capas o el
principio extremo a extremo [6].
2.2 Acoplado ‘débil’ de protocolos de
QoS y movilidad.
Entre las alternativas anteriores proponemos el
acoplado débil de los mecanismos de QoS y los
protocolos de movilidad local. Al mejorar le
mecanismo de QoS en el entorno móvil la
reparación del camino local es posible y los
cambios en la reserva son tan solo locales al área
afectada por el cambio en la ruta, sin ninguna
sobrecarga de procesamiento o señalización en los
terminales móviles.
En la aproximación ‘débil’, el cambio de posición
del nodo móvil, y por lo tanto las actualizaciones de
la información de encaminamiento en la propia red,
disparan la generación de mensajes de reparación
RSVP PATH. Éste mecanismo tan sólo repara la
parte de la reserva que se ha perdido, provocando
que la reserva extremo a extremo pueda instalarse
de manera más rápida ya que no se necesita
señalizar nuevamente desde el emisor hasta el
receptor (con el retardo que ello supone). Hay que
tener en cuenta que la señalización de reparación de
la reserva no debe realizarse hasta que exista la
seguridad de que la nueva ruta en la red es estable,
por lo que existe un retardo fijo (el tiempo en que la
nueva ruta se establece) que no puede ser reducido
y depende directamente del mecanismo de
movilidad subyacente. La implementación de este
mecanismo implica cambios en todos los nodos
envueltos en la provisión de QoS excepto en los
nodos móviles.
2.3 Mecanismos complementarios.
En un entorno móvil el acoplamiento débil
proporciona una mejora en el rendimiento pero
puede no ser suficiente. Existen una serie de
mecanismos que complementan éste acoplado:
Priorización de la señalización de QoS: El
acoplado débil proporciona un mecanismo por el
cual una reserva puede reinstalarse tan pronto como
el nuevo camino es estable, permitiendo un uso más
eficiente de los recursos y minimizando el impacto
del handover. Sin embargo, si el nuevo camino
contiene enlaces sobrecargados y los mensajes de
QoS se pierden, el tiempo asignado al soft-state
vencerá y los paquetes de datos pertenecientes al
flujo de la reserva caerán a un prioridad best—
effort, pudiendo producirse una violación de la
QoS. Si proporcionamos prioridad a los paquetes
de señalización de QoS este efecto puede
minimizarse y por lo tanto la nueva reserva puede
instalarse. La priorización puede realizarse de
diversas maneras, con mecanismos como DiffServ
[7] o simplemente reservando una cierta cantidad
de ancho de banda en los routers con colas del tipo
CBQ [8]. Si no hay suficientes recursos en los
nuevos enlaces (p. ej. ya existen otras reservas y no
queda ancho de banda), entonces la reserva no
podrá ser reinstalada. Esto puede resolverse con
mecanismos de reserva anticipada como MRSVP
[9] y otros, que quedan fuera del alcance de este
documento.
Priorizaciuón de paquetes ‘en handover’:
Denominaremos paquetes ‘en handover’ a aquellos
paquetes pertenecientes a un flujo de datos que, a
pesar de tener una reserva instalada en su camino
de datos anterior, están pasando durante un periodo
reducido de tiempo por unos nodos que no poseen
(aún) información de reserva debido al cambio de
ruta producida por un handover, y por lo tanto están
siendo tratados como tráfico best-effort.
Muchas modificaciones del protocolo RSVP han
intentado establecer una reserva antes de que el
handover ocurra. En esta propuesta nosotros
evitamos esta opción – primero porque no todos los
handover son planeados y por lo tanto no hay
tiempo de hacerlo, segundo por la carga de proceso
y de señalización que imponen, así como la posible
ineficiencia en el uso de los recursos de la red que
son inevitables dado que la nueva ruta no puede ser
determinada hasta que se ha producido el cambio en
ella. Por lo tanto se hace necesario un mecanismo
para tratar el tráfico que temporalmente carece de
reserva. La priorización de estos paquetes
proporcionan un mecanismo para el tráfico en
handover basado en reservas acceda a unas bandas
de guarda de ancho de banda, reservado únicamente
para tráfico de alta prioridad proveniente de un
handover. La priorización de los datos ‘en
handover’ que tiene que ser encaminada por un
túnel hacia el nuevo destino proporciona una QoS
mejorada sin necesidad de usar reservas temporales
(que producen sobrecarga tanto en señalización
como en tiempo de proceso) [10].
Esta priorización también puede usarse en
procedimientos de reserva salto a salto (como
RSVP) que son afectados por la movilidad. Permite
a este tráfico tener una prioridad alta mientras la red
espera a que el nuevo camino se estabilice antes de
intentar reparar la reserva.
Protocolos de transferencia de contexto: Un
protocolo de transferencia de contexto transfiere la
información de estado sobre los requisitos de QoS
del nodo móvil desde el antiguo router de acceso
hasta el nuevo. Este intercambio puede ser iniciado
de varias maneras: por indicaciones de handover de
la capa de enlace, o por ejemplo, en el caso de
protocolos de movilidad local basados en túneles,
podría ser iniciados por los nodos extremos de los
túneles.
El protocolo de transferencia de contexto requiere
el soporte de todos los nodos que soportan la
movilidad en la red de acceso. El protocolo
necesario para activar este procedimiento, así como
los parámetros a ser intercambiados, son un objeto
de estudio hoy en día. Por ejemplo, el concepto de
protocolo de transferencia de contexto está
empezando a ser considerado por el grupo de
trabajo Seamoby [11] (Seamless Mobility WG) del
IETF.
En particular, Seamoby propone un
concepto de transferencia de contexto en unos
términos más amplios que los aquí tratados (QoS),
al transferir información sobre seguridad,
compresión de cabeceras y otros conceptos además
del ya comentado de QoS.
Emisor
de optimización expuestas, aplicándose a entornos
reales significativos con protocolos actuales.
VoIP
Internet
Gateway
Las simulaciones se han realizado con el simulador
de nivel de red NS-2 [12]. En particular se
presentan las simulaciones realizadas con el
protocolo de micro-movilidad HAWAII [13] y el
protocolo de señalización de calidad de servicio
RSVP en el escenario mostrado en la figura 1.
Router
Acceso
Figura 1: Escenario de Red.
Un protocolo de este tipo proporciona un soporte
adecuado para los handovers eficientes y sin
pérdidas2, y en particular, también da soporte a
otras posibles mejoras como la reparación local
RSVP. Se asume que las reservas de QoS de la capa
de enlace son restauradas también como resultado
de este proceso de handover. El protocolo de
transferencia de contexto proporciona al nuevo
router de acceso suficiente información como para
que todos los paquetes IP recibidos sean vinculados
a las reservas inalámbricas adecuadas. De esta
manera se puede restaurar de manera rápida en el
enlace inalámbrico, que generalmente es el enlace
más débil de todo el camino de datos.
Por otro lado, si se utiliza un protocolo de
transferencia de contexto junto con la reparación
local de RSVP, se puede reducir la carga de
señalización en el enlace inalámbrico como
veremos a continuación
De todos estos mecanismos, tan solo la priorización
de la señalización de QoS es un requisito
indispensable para la propuesta de acoplamiento
‘débil’. De todas formas, todos estos mecanismos
proporcionan un marco para el seamless handover
en entornos con QoS basada en reservas.
3. Simulaciones
En este apartado se presentan diversas simulaciones
que dan soporte a las propuestas teóricas planteadas
anteriormente. Se pretende así comprobar la validez
tanto cualitativa como cuantitativa de las propuestas
Entre los posibles escenarios de red de acceso
hemos seleccionado uno que corresponde a una
empresa pequeña típica. Es una topología de árbol
básica. Proporciona un modelo inicial para la
prueba de las mejoras así como otros protocolos de
nivel de red, y se utilizó, entre otros, para la
definición de la arquitectura mostrada en el
proyecto BRAIN [14]. La topología se ha diseñado
de tal forma que permita la existencia de diferentes
distancias desde los routers de acceso al router de
divergencia3 (uno, dos y tres saltos).
La red de acceso se compone de routers de acceso
con interfaces inalámbricos y routers intermedios
que conectan los distintos routers de acceso. Uno de
estos routers intermedios actúa como puerta de
enlace a otras redes. Los enlaces de la red de acceso
están caracterizados como enlaces de 512 Kbytes
de ancho de banda y 10 ms de retardo (en cada
sentido). Hay que observar que el retardo depende
en gran manera de la tecnología de red utilizada, de
manera que este valor puede cambiar.
Para los nodos inalámbricos se ha utilizado la
tecnología HIPERLAN/2 [15]. Dado que el
simulador ns-2 carece de soporte para esta capa de
enlace, se ha modelado basándose en las
simulaciones llevadas a cabo por por Nokia usando
simuladores de nivel de enlace en el marco del
proyecto BRAIN. Utilizamos una aproximación
para cada celda usando una sala industrial sin
paredes internas. Nokia ha evaluado el
comportamiento del interfaz de aire HIPERLAN/2
para diferentes niveles de carga. El tamaño de la
sala es de 250 metros cuadrados y tiene un nivel de
carga similar a 5 nuevas transferencias FTP por
segundo.
En el simulador hemos caracterizado los enlaces
HIPERLAN/2 mediante dos enlaces simplex (de
subida y bajada) con dos parámetros: retardo, ancho
de banda. Para el nivel de carga seleccionado en
nuestras simulaciones y según las simulaciones de
Conversación
Conversación
Silencio
Tiempo
Figura 2: Tráfico de Voz sobre IP (VoIP)
2
Comocidos como seamless handover.
Nokia, éstos parámetros corresponden a 3.2 Mbps
de ancho de banda y a 15 ms de retardo.
Situamos el nodo emisor fuera de la red de acceso.
Tan sólo se encuentra a un salto del gateway
aunque podría haberse situado en cualquier lugar de
Internet. El nodo emisor envía tráfico de voz sobre
IP (VoIP) hacia el nodo móvil en el interior del
dominio. Consideraremos el caso en el que el nodo
móvil cambia suposición entre dos celdas
consecutivas mientras se está realizando la
comunicación tal y como lo muestra la figura 1.
La simulación se ha llevado a cabo de la siguiente
manera: durante los 100 primeros segundos el
emisor realiza la reserva con RSVP y comienza a
transmitir paquetes de voz hacia el nodo móvil.
Posteriormente se produce el handover entre dos
celdas consecutivas. Esto implica la modificación
de las tablas de rutas del protocolo HAWAII y la
necesidad de establecer la reserva a través de la
nueva ruta. En nuestro estudio sólo hemos
contemplado el caso de handover planeado (aquel
en el que el nodo móvil es consciente de que se va a
producir el handover, y por tanto, puede
reaccionar). El nodo móvil cambia su punto de
acceso a la red y durante 20ms ambos enlaces
inalámbricos están activos. Bien es cierto que, a
pesar de ser un handover planeado, la cantidad de
tiempo en el que ambos enlaces están activos es
bastante corto, lo cual tiene su impacto sobre el
rendimiento.
Hemos introducido tráfico interferente en los
enlaces que comunican el nodo de divergencia y los
routers de acceso involucrados en el handover (en
la figura 1 aparecen más gruesos). Este tráfico
interferente utiliza el 100% de los citados enlaces y
nos permite observar el efecto de las reservas de
RSVP cuando deben reinstalarse a lo largo del
nuevo camino. Observar que el tráfico interferente
sólo ocupa un enlace del camino de la nueva ruta y
que éste enlace es fijo. Por otro lado nos permite
comparar la mejora de rendimiento obtenida cuando
el protocolo de micro-movilidad se acopla con
RSVP, y podemos observar la ventaja de reservar
cierto ancho de banda para los paquetes de
señalización de QoS. El tráfico interferente se
caracteriza como tráfico con ancho de banda
constante.
manera que los periodos de actividad y silencio son
generados con una variable aleatoria con
distribución exponencial. El valor medio de esta
variable es igual a T_on durante los periodos de
actividad y a T_off en los periodos de silencio. La
figura 2 muestra un ejemplo gráfico de este modelo.
Los parámetros principales principales del modelo
de tráfico de VoIP son los siguientes:
•
•
•
•
•
•
Intervalo de actividad: 50 %
Duración media de llamada: 120 seg.
Duración media de la fase de actividad T_on: 3
sec
Duración media de la fase de silencio T_off:
3sec
Tamaño de los datos del paquete IP: 32 Bytes.
Los paquetes son de tamaño fijo.
Ratio de transmisión: 12.2 Kbps
Realizamos las medidas de retardo de los paquetes
de VoIP tan sólo en un sentido. Esta aproximación
es correcta dado que los enlaces tienen colas
diferentes para ambos sentidos. Los paquetes que
llegan del nodo emisor no interfieren con los
paquetes que salen del nodo móvil, así que el
retardo obtenido al medir tan sólo un sentido es
significativo.
Las simulaciones se han realizado usando la versión
del simulador 2.1b5. Más detalles obre la
implementación de los protocolos y de los
generadores de tráfico pueden encontrarse en [14].
3.1. Resultados de la simulación.
En esta sección mostraremos el rendimiento de
HAWAII y RSVP en el escenario comentado
anteriormente, cuando éstos protocolos están
acoplados de manera ‘débil’ y cuando están
desacoplados. En ambos casos hemos reservado
El modelo de tráfico de VoIP extraído de [14] se
puede describir como un proceso de nacimientomuerte con un modelo de recepción basado en una
distribución de Poisson y una duración de llamada
con distribución exponencial. Durante la
conversación cada participante está o bien hablando
o bien en silencio. Hemos simulado este tráfico de
3
Conocido como crossover router en inglés. Es el
router común más cercano a las rutas antigua y
nueva tras un handover.
Figura 3: Rendimiento del tráfico VoIP en el
caso desacoplado.
una cantidad de ancho de banda fija para los
paquetes de señalización de RSVP, tal y como se
indica en la sección 2.4. Se añadió una cola WFQ
(Weighted-Fair Queuing) para evitar la pérdida de
paquetes de RSVP y por tanto favorecer la
reparación rápida de las reservas tras el handover.
La cantidad de ancho de banda reservada responde
a la formula n*s*8/30 (donde n es el número de
sesiones que van a instalarse en el enlace y s es el
tamaño medio esperado del paquete. La formula
representa 1/30 de todo el ancho de banda necesario
para los paquetes RSVP en caso de que fueran
refrescados cada Segundo: para un tiempo de
refresco de 3 segundos supone el ancho de banda
para acomodar el 10% de todos los paquetes
RSVP). Este valor debería incrementarse si
existiesen numerosos cambios en las reservas.
Considerando un valor promedio del paquete de
100 bytes y 30 sesiones por celda obtenemos un
valor de 750 bps en el enlace inalámbrico. Para la
parte de la troncal que tienen en común ambos
enlaces reservaremos 1500 bps (por agregación).
En las siguientes figuras es necesario tener en
cuenta que el handover ocurre en el segundo
número 100.
Caso desacoplado.
Este caso muestra el rendimiento de los protocolos
HAWAII y RSVP cuando no tienen constancia de
la existencia del otro.
La figura 3 muestra el rendimiento del tráfico VoIP
en el caso desacoplado. Cuando se produce el
handover (segundo 100), la nueva ruta tan sólo
tiene reserva hasta el router de divergencia y el
tráfico interferente, que es mucho mayor en
proporción que el tráfico de VoIP, no permite que
los paquetes de voz lleguen al terminal, de manera
que es necesario esperar hasta que el refresco de
RSVP se produce para que la nueva reserva se
instale a lo largo de todo el camino. A los 105
Figura 4: Paquetes de VoIP perdidos por
segundo en el caso desacoplado.
Figura 5: Retardo de los paquetesde VoIP en el
caso desacoplado
segundos aproximadamente la nueva reserva es
instalada y de nuevo los paquetes de VoIP llegan al
terminal móvil, de manera que el rendimiento
vuelve a la tasa sostenida previa al handover.
Como podemos ver en la figura 4, los paquetes por
segundo perdidos se disparan hasta que la nueva
reserva es instalada. Hay que tener en cuenta que en
ésta figura se miden los paquetes por segundo, y no
los acumulados. Tras el handover llegan a perderse
hasta 60 paquetes por segundo lo que implica que la
llamada se ve seriamente afectada debido al
movimiento del terminal. La ausencia de paquetes
perdidos durante los dos picos es el resultado del
propio patrón de tráfico de VoIP: simplemente no
hay tráfico emitido en ese momento por lo que no
hay pérdida de paquetes.
Como consecuencia del handover, los paquetes de
VoIP que no se pierden sufren un gran retardo
durante un tiempo como muestra la figura 5. La
Figura 6: Rendimiento del tráfico VoIP en el
caso acoplado.
nueva ruta y por lo tanto sufrirán un retardo
dependiendo del rendimiento del protocolo de
movilidad local subyacente. El acoplamiento
solamente optimiza la reinstalación de las reservas
para minimizar el impacto del handover. Esto es
independiente del mecanismo de movilidad usado,
por lo que no afecta al tiempo que tarda la nueva
ruta en ser establecida.
4. Conclusiones
Figura 7:Paquetes perdidos por segundo de
VoIP en el caso acoplado.
topología es simple por lo que podemos inferir que
la causa del retardo es la ya comentada: la ausencia
de reserva una vez que la nueva ruta se ha
establecido. El enlace está saturado la cola de besteffort está llena, y los paquetes sufren un retardo
proporcional a la longitud de la cola y, como hemos
visto, algunos se pierden.
Caso acoplado (‘débil’)
Este caso es idéntico al anterior salvo por el hecho
de que los protocolos HAWAII y RSVP están
acoplados de manera débil como hemos visto en la
sección 2. Hemos diseñado un mecanismo de
acoplamiento de ambos protocolos de tal forma que
intercambian información en el handover. En el
mismo instante que la nueva ruta es estable el
agente RSVP procede a la reparación de RSVP. Así
aseguramos que la reserva se instala lo antes
posible.
La figura 6 confirma nuestra hipótesis. El
rendimiento del tráfico de VoIP tras el handover se
ve afectado pero el impacto es mucho menor que en
el caso desacoplado. La figura 7 muestra que las
pérdidas de paquetes de VoIP durante el handover
se han minimizado. Tan sólo 3-4 paquetes se han
perdido, debido al handover propiamente dicho. El
resto de pérdidas producto de la ausencia de reserva
en la nueva ruta se ha eliminado dado que los
mensajes de refresco de la reserva se envían tan
pronto como la nueva ruta es estable, así que el
impacto del tráfico interferente es mínimo.
Por último, la figura 8 muestra el impacto del
handover en el retardo. A pesar de que el retardo
máximo no se reduce, el intervalo de tiempo en el
que los paquetes se ven afectados sí disminuye
considerablemente (comparar con la figura 5). Los
únicos paquetes que se ven afectados y que tienen
un retardo elevado son aquellos que estaban en
vuelo en el momento en el que ocurre el handover.
Estos paquetes deben esperar a que se actualice la
Presentamos una mejora para el funcionamiento de
las reservas en entornos móviles basada en la
colaboración de los protocolos de QoS y movilidad.
Aunque se pueden concebir distintos tipos de
colaboración hemos optado por el acoplamiento
‘débil’ como el más prometedor, donde los
protocolos de QoS y movilidad intercambian
información mediante algún mecanismo de disparo
cuando ocurre un handover. Hemos observado
mediante las simulaciones que este acoplamiento
proporciona una ventaja clara en algunos
escenarios. A pesar de que el propio handover en sí
no puede ser acelerado sí que se consigue que las
reservas se reinstalen tan pronto como el nuevo
camino es estable. Esto es especialmente
interesante en escenarios como el aquí mostrado,
donde tráfico interferente puede hacer que el tráfico
con reserva pueda ser descartado. Hemos simulado
también otro mecanismo complementario como la
priorización de los paquetes de señalización que
ofrecer un marco para el seamless handover cuando
se utilizan mecanismos basados en reservas.
En conclusión, el acoplado de los protocolos de
micro-movilidad y protocolos de reserva tiene un
coste reducido y las ventajas, al menos en el caso
de protocolos de movilidad salto a salto (como es el
caso de HAWAII, o Cellular IP [16]), combinado
con la pre-reserva para la señalización de QoS son
suficientes como para justificarlo.
Figura 8: Retardo de los paquetes de VoIP
en el caso acoplado
Agradecimientos
This work has been performed in the framework of
the IST project IST-1999-10050 BRAIN, which is
partly funded by the European Union. The authors
would like to acknowledge the contributions of
their colleagues from Siemens AG, British
Telecommunications PLC, Agora Systems S.A.,
Ericsson Radio Systems AB, France Télécom –
R&D, INRIA, King’s College London, Nokia
Corporation, NTT DoCoMo, Sony International
(Europe) GmbH, and T-Nova Deutsche Telekom
Innovationsgesellschaft mbH.
Alberto López agradece en particular a la
Fundación Séneca (Comunidad Autónoma de la
Región de Murcia) su apoyo y la financiación para
llevar acabo este trabajo.
Referencias
[1] Braden, R., Clark, D. Shenker, S., “Integrated
Services in the Internet Architecture: an
Overview “. Internet Engineering Task Force,
Request for Comments (RFC) 1633, Junio
1994.
[2] Braden, R., et. Al. “Resource ReSerVation
Protocol (RSVP) -- Version 1, Functional
Specification”. Internet Engineering Task
Force, Request for Comments (RFC) 2205,
Septiembre 1997.
Networking, Vol. 3, No. 4, 365-386, Agosto
1995.
[9] A. Talukdar, B. Badrinath, A. Acharya,
MRSVP: A Resource Reservation Protocol for
an Integrated Services Packet Network with
Mobile Hosts, In Proceedings of ACTS Mobile
Summit’98, Junio 1998.
[10] MSc Thesis “Towards Full Quality of Service
Support in a Mobile, Wireless Internet”,
Anne-Louise Burness, University of Essex,
Enero 2001.
[11] IETF Seamoby WG. http://www.ietf.org/
html.charters/seamoby-charter.html
[12] L. Breslau, D. Estrin, K. Fall, S. Floyd, J.
Heidemann, A. Helmy, P. Huang, S.
McCanne, K. Varadhan, Y. Xu, and H. Yu.
“Advances in network simulation.”, IEEE
Computer, 33(5):59(67), Mayo 2000.
[13] Ramjee, R., La Porta, T., Thuel, S., Varadhan,
K., Wang, S.Y., “HAWAII: a domain-based
approach for supporting mobility in wide-area
wireless networks”. Proceedings of the
Seventh International Conference on Network
Protocols (ICNP) 1999, pp. 283 – 292.
[3] Perkins, C., "IP Mobility Support". Internet
Engineering Task Force, Request for
Comments (RFC) 2002, Octubre 1996.
[14]IST-1999-100050 BRAIN D2.2 “BRAIN
architecture specifications and models,
BRAIN
functionality
and
protocol
specification”, Marzo 2001.
[4] Gustafsson, E., Jonsson, A., Perkins, C,.
“Mobile IP Regional Registration”, Internet
Draft (work in progress), Marzo 2001.
[15] ETSI TR 101 683 V1.1.1 (2000-02),
“Broadband Radio Access Networks (BRAN);
HIPERLAN Type 2; System Overview”.
[5] Lee, S.B., Gahng-Seop, A., Zhang, X., and A.T.
Campbell, “INSIGNIA: An IP-Based Quality
of service Framework for Mobile Ad Hoc
Networks”, Journal of Parallel and Distributed
Computing (Academic Press), Special issue on
Wireless and Mobile Computing and
Communications, Vol. 60 No.4. p.374-406,
Abril 2000.
[16] Campbell, A., Gomez, J., Kim, S., Valko, A.,
Chieh-Yih Wan, Turanyi, Z., “Design,
implementation, and evaluation of cellular
IP”. IEEE Personal Communications, Vol. 7,
Agosto 2000, pp. 42-49..
[6] B. Carpenter, "Architectural Principles of the
Internet," Internet Engineering Task Force,
Request for Comments (RFC) 1958, Junio
1996.
[7] M. Carlson, W. Weiss, S. Blake, Z. Wang, D.
Black, and E. Davies, “An Architecture for
Differentiated
Services”,
Request
for
Comments (RFC) 2475, Deciembre 1998.
[8] Floyd, S., Jacobson, V., “Link Sharing and
Resource Management Models for Packet
Networks”, IEEE/ACM Transactions on