Internet sobre sistemas DBS
-Internet Híbrido-
1. Introducción.
2. Reducción de la latencia.
2.1 Pre-captación.
2.2 Captación en el NOC.
3. Utilización eficiente del ancho de
banda.
3.1 Cache aéreo - Multicast contínuo.
3.2 Multicast espontáneo.
4. Sistemas integrados de captación
y Multicasting.
5. Multicasting sobre IP.
5.1 Multicast en redes híbridas.
5.2 Técnicas de encaminamiento multicast.
6. Simulación.
Anexo. Diseño del protocolo multicast.
1. Introducción.
En esta parte, vamos a tratar las posibles elecciones para la captación
y el multicasting motivados por las aplicaciones que ya existen en la Internet
terrestre y que pueden ser consideradas para formar parte de un sistema
DBS.Los sistemas DBS (Direct Broadcast Satelite) nos proveen de
una forma de distribuir la información sobre un gran número
de usuarios que se encuentran sobre una extensa área.
Un sistema DBS está caracterizador por un único emplazamiento
del enlace ascendente, el cuál se denomina Centro de Operaciones
de Red (NOC). Un sistema DBS actual, como puede ser DirectPC, nos puede
proveer de velocidades de hasta 400Kbps.
Mientras que muchos aspectos de la captación y del multicasting
ya están dominados en una red terrestre, en un sistema DBS están
mucho menos estudiados. Es por esto por lo que partiremos de los esquemas
originados por la red terrestre para ver su adaptabilidad nuestro sistema.
Nos centraremos en reducir la latencia y la utilización
eficiente del ancho de
banda tanto como se pueda.
2. Reducción de la latencia;captación.
En un sistema DBS podemos dividir el latencia en tres componentes: El
retardo para que la petición del usuario llegue al centro NOC; El
retardo para capturar los datos pedidos desde el servidor web hasta el
NOC; el retardo necesario para enviar los datos desde el NOC hasta el usuario
final, a través de un enlace por satélite. El primer y el
tercer retardo son fijos, mientras que la solución para reducir
la segunda componente reside en la introducción de un cache en el
NOC. De esta forma, idealmente, cuando un usuario genera una petición,
nos gustaría que esa petición fuera resuelta localmente por
medio de la pre-captación por parte del usuario; si esto fallase,
nos gustaría que la petición se solucionase en el NOC, sin
tener que buscar la información en Internet; Si esto vuelve a fallar,
lo que significa que estamos en el peor de los casos, entonces buscaremos
la información a través de Internet. Esta idea se observa
en la figura 1.
Figura 1. Contribuciones a la latencia en un sistema DBS
La figura 1 nos muestra que la contribución más importante
a la latencia es debida al enlace por satélite. Esto es suficiente
para justificar la importancia de la pre-captación (por parte del
usuario) como un factor muy importante para reducir la latencia.
Tradicionalmente , la pre-captación ha sido considerada como
un operación "pull", donde los objetos son capturados antes de que
sean requeridos. Para este propósito, podemos introducir un canal
separado con el objetivo de difundir datos para su pre-captación.
El usuario final opta por subscribirse a este canal y de esta forma actualiza
constantemente su cache local. Pero un análisis más profundo
nos muestra que hay algunas cuestiones no triviales, como: ¿qué
datos deben ser difundidos?, ¿qué debemos guardar en el cache
local del usuario final?, ¿cómo actualizar la información
que hay de difundir en el NOC?, ¿cómo cambiará la
estructura de precios?, ¿la pre-captación debe de ser global
o sólo por usuario?, ¿qué algoritmo de predicción
deberemos usar?. Una solución para la primera pregunta es mantener
perfiles de usuario en el NOC, aunque mantener esta cantidad de información
en el NOC puede no ser viable. Alternativamente, se puede mantener un perfil
global para todos los usuarios; si bien lo más eficiente es
usar ambos perfiles. En este sistema dual, el cache local seleccionando
está formado por una selección de datos que se difunden por
el canal de difusión común sobre el canal de pre-captación.
Actualizar el filtro de pre-captación en el usuario final está
gobernado por el algoritmo de predicción de pre-captación.
Para evitar la búsqueda de información en Internet se
debe de hacer una captación por parte del NOC. En los sistemas DBS,
el NOC es es colector natural de todas las peticiones e, introduciendo
caches en el NOC conseguimos una mejora en la reducción de la latencia,
ya que el NOC tiene mucha información de los patrones de tráfico
y estadísticas que pueden ser utilizadas. Si no se tuviese esta
captación por parte del NOC, la latencia tendría siempre
la componente de la búsqueda por Internet.
3. Utilización eficiente del ancho de banda.
La naturaleza broadcast de los sistemas DBS les permite utilizar multicasting
para el ahorro de ancho de banda. La utilización del multicast está
motivada también por el factor que un gran número de las
webs requeridas estén contenidas en una porción de los documentos
más visitados. Normalmente, en un sistema DBS, una cierta cantidad
de ancho de banda está continuamente difundiendo ciertos contenidos,
como, noticias, deportes, etc.. Los usuarios que se subscriben a estos
servicios pueden sintonizar el canal que deseen y conseguir la información
directamente. De todas formas, el volumen de datos que podemos colocar
en este canal es limitado , ya que el ciclo de difusión determina
el tiempo de espera medio (la mitad de un ciclo) para un usuario. Además,
sólo unos pocos contenidos, cuyos patrones de petición son
bien conocidos, no cambian frecuentemente. De este razonamiento se concluye
que es necesario hacer una planificación para el cambio dinámico
de los datos difundidos.
3.1 Cache aéreo - Multicast contínuo.
La idea básica es utilizar el ancho de banda del satélite
como un "cache" - cache aéreo - para "almacenar" datos por medio
de difundirlos continuamente. Este esquema incluye también un algoritmo
que adapta el contenido del cache aéreo basado en las peticiones
de datos. El funcionamiento en el NOC es el siguiente: si el NOC recibe
una petición de datos que están siendo difundidos, simplemente
la ignora; pero si recibe una petición de datos que no están
siendo difundidos , entonces se los envía al usuario de forma unicast.
Cuanto más grande sea el periodo de difusión, mayor cantidad
de datos habrá en el cache aéreo.
Este concepto tiene una buena aplicación para difusión
de bases de datos, pero un uso muy limitado en la navegación por
Internet.
Una alternativa a la difusión continua, es agregar (en el NOC)
la posibilidad peticiones múltiples para el mismo contenido, de
esta forma contestar esas peticiones con una transmisión multicast,
suponiendo que ciertas peticiones llegan en ráfagas o en grupo.
Esto aumentaría potencialmente la utilización del ancho de
banda. Los grupos multicast se forman espontáneamente en el NOC
y para una única transmisión, de esta forma, muchos usuarios
finales reciben la información pedida. Nótese que la cantidad
de peticiones para el mismo contenido no está limitada. Solicitudes
estrechamente relacionadas también se pueden agrupar juntas. Claramente
el ahorro de ancho de banda en el multicast espontáneo es a costa
de un mayor retardo que deben experimentar los usuarios de la red, ya que
el NOC se espera (y retiene) cierto tiempo la información antes
de transmitirla. Esto se hace para ver si llegan más peticiones
que requieren la misma información.
4. Sistemas integrados de captación y multicasting.
El objetivo seria integrar las opciones de los puntos anteriores en
un sistema de altas prestaciones, teniendo en cuenta su coste. Para que
quede más claro veámoslo con un ejemplo:
Un usuario genera una petición. Al principio, se revisa
el cache local para ver si el documento allí existe. Este cache
local se mantiene por medio de la pre-captación desde el NOC. Si
el documento no se encuentra en el cache local, la petición se envía
al NOC. Al mismo tiempo, mientras se espera la contestación por
parte del NOC, el canal de cache aéreo se escanea para ver si contiene
la información pedida. Cuando la petición llega al NOC, éste
comprueba si el documento pedido se encuentra en el canal de cache aéreo
y si es así, ignora la petición. En el otro caso (la petición
no se encuentra en el canal de cache aéreo) el NOC comprueba si
los datos pedidos se encuentran en alguno de los paquetes que va a difundir
posteriormente (multicast espontáneo) y si es así, el NOC
le envía al usuario la dirección multicast que se va a utilizar
para enviar esa información. Si no hay ningún paquete multicast
en curso que satisfaga la información pedida, el NOC crea un nuevo
paquete multicast y le asocia un contador (multicast espontáneo).
Cuando el contador expira, el NOC difunde el paquete a los posibles usuarios
finales. Mientras se espera a que el temporizador termine, el NOC consigue
la información pedida bien en su propio cache, o bien buscándola
en Internet.
Entendemos por multicasting el envío de un mismo paquete de datos
a varios destinos al mismo tiempo. El kit de la cuestión reside
en la habilidad de enviar un mensaje a uno o más destinos en una
sola operación. El interés del multicasting reside en que
aplicaciones nuevas e interesantes, como videoconferencia o audio en tiempo
real, hacen uso de los servicios de esta técnica
.
IP proporciona una transmisión no fiable de paquetes de datos
desde un único host hasta un único destino i.e. servicio
de transmisión unicast. De todas formas, con una pequeña
modificación le podemos añadir el servicio de encaminamiento
multicast. El resultado es una eficiente entrega de paquetes desde una
única fuente hasta un número arbitrario de destinos a través
de una red tan heterogénea como es Internet. Se ha añadido
una red virtual sobre Internet, Multicast Backbone (MBONE); se trata de
una red que se encarga de explorar las aplicaciones multicast de Internet.
MBONE permite que paquetes multicast atraviesen routers que están
configurados para soportar paquetes unicast. Los datagramas viajan a través
de las redes (nubes) no-multicast a través del encapsulado (tunneling)
de paquetes multicast sobre paquetes corrientes unicast., como se observa
en la figura 2
Figura 2. Arquitectura del MBONE
5.1 Multicasting en redes híbridas.
Las propiedades del multicasting tradicional sobre la red MBONE se ha
usado para el intercambio de información entre grupos de usuarios
en aplicaciones como vídeo y audio conferencias. El mayor problema
que presenta el multicasting sobre Internet es el potencial para usar gran
ancho de banda, lo cuál llevaría a la congestión de
la red. Puede que algunas compañías estuvieran dispuestas
a utilizar alguna aplicación de conferencia multicast, pero debido
a su limitación de ancho de banda en su acceso a Internet no le
sea posible. Para esos usuarios, introducir terminales híbridos
en su LAN corporativa para encaminar el trafico entrante a través
de un enlace por satélite, podría ser una solución
para conservar el ancho de banda de la pasarela para otro tráfico
saliente. Otro motivo para usar multicast sobre redes híbridas son
las aplicaciones militares y médicas, donde los usuarios equipados
con terminales híbridos son capaces de recibir paquetes de datos
a muy alta velocidad. Evidentemente esto sólo es posible en el extremo
receptor, ya que en las redes híbridas el ancho de banda en el enlace
ascendente es limitado.
Un concepto importante dentro de las redes híbridas es
el terminal híbrido (HH), el cuál consiste en un PC conectado
a una antena de satélite y conectado también a una LAN de
cable. La naturaleza asimétrica del tráfico en la mayoría
de las redes (tan evidente en Internet) está conduciendo hacia
el desarrollo de las redes híbridas. Tecnologías como DirectPC,
que permiten al usuario enviar el tráfico por la red terrestre y
recibir por el satélite han demostrado la eficiencia de la naturaleza
broadcast de las comunicaciones por satélite como un medio de ofrecer
gran ancho de banda (en el enlace descendente) a los usuarios. A continuación
vamos a describir extensiones efectivas de IGMP, un algoritmo multicast
asimétrico que aprovecha la asimetría de la red para incrementar
el numero de usuarios. Esto requiere un mecanismo de encaminamiento multicast
asimétrico.
5.2 Técnicas de encaminamiento multicast.
Éstas técnicas las aplicaremos con el fin de construir
árboles multicast en las LANs remotas, de esta forma todo el tráfico
saliente estará dirigido hacia la pasarela de la empresa mientras
que el tráfico entrante vendrá a través del satélite.
La naturaleza asimétrica del tráfico (entrante a través
del satélite y saliente a través de la LAN) crea la posibilidad
de la formación de bucles, rompiendo el concepto de la construcción
de arboles por completo.
Otro problema lo podemos encontrar en que los protocolos de Internet
fueron pensados para enlaces bidireccionales y simétricos, pudiendo
no funcionar sobre enlaces unidireccionales. Por ejemplo, los routers situados
al final de un enlace unidireccional no tienen la posibilidad de comunicarse
con los routers fuente de la información. Un subcomité, el
Uni-Directional Link Routing (UDLR), ha tratado de encontrar soluciones
para los problemas del encaminamiento dinámico causados por los
problemas de os enlaces unidireccionales. Se han desarrollado dos posibles
soluciones al problema. La primera se basa en la modificación de
los protocolos de encaminamiento comunes para soportar enlaces unidireccionales.
La otra solución propone añadir una capa entre el interfaz
de red y el software de encaminamiento para emular los enlaces bidireccionales
a través de túneles. Ambas están siendo estudiadas
con el propósito de conseguir una solución al encaminamiento
dinámico en presencia de enlaces unidireccionales. En el anexo se
propone el diseño de un protocolo de encaminamiento multicast que
permite a los HHs funcionar sobre una red híbrida (satélite-tierra)
para recibir de forma dinámica paquetes multicast.
Uno de los factores que han motivado la aparición del multicast
a través de redes híbridas es permitir a las compañías
que poseen un limitado ancho de banda en su pasarela, entrar en las aplicaciones
multicast de banda ancha. Por eso se ha hecho una simulación para
evaluar el ahorro en ancho de banda que supone la utilización del
multicast sobre una red híbrida, sobre el tradicional multicast
por cable terrestre. En la figura 4 se puede observar la utilización
del enlace terrestre de la compañía en los casos considerados:
multicasting sobre una red terrestre contra multicasting sobre una red
híbrida, con un enlace descendente desde un satélite. Como
era de esperar, introducir terminales híbridos en una LAN corporativa
conserva el ancho de banda de la pasarela de la compañía
para otro tráfico.debido a que los paquetes entrantes son encaminados
a través del satélite, el ancho de banda disponible para
otro tráfico es más de dos veces más que en el caso
de que el tráfico entrante fuese encaminado por vía terrestre.
Figura 4. Comparación de la utilización del enlace terrestre de la compañía
La figura 5 nos muestra el efecto que tiene el tipo de tráfico
y su tamaño sobre el tiempo de transferencia de los paquetes multicast.
Podemos observar que el retardo es menor en la red terrestre para tráfico
lento o para longitud corta. Entonces, sobre este contexto (tráfico
lento, longitud de los paquetes corta) no resulta conveniente encaminar
los paquetes multicast hacia el satélite. Esto demuestra claramente
la necesidad de un encaminamiento inteligente en el MHGW, que permita que
sólo el tráfico rápido o el de tamaño de paquete
grande sea encaminado hacia el satelite.
Figura 5. Efecto del tipo de tráfico
en el tiempo de permanencia en la red