El Protocolo FLUTE

Capítulo 3
El Protocolo FLUTE
3.1.
Introducción
El protocolo FLUTE[46] (File Delivery over Unidirectional Transport, distribución de ficheros
sobre transporte unidireccional) permite la difusión de ficheros de forma masiva y escalable en
internet, especialmente en redes multicast. En FLUTE, un único transmisor envía ficheros a múltiples receptores admitiendo varias modalidades de emisión que se detallarán más adelante. FLUTE
contempla el uso de mecanismos de control de congestión, que se basan en la transmisión de datos
a distintas tasas binarias, para adecuarse en la medida de lo posible a la capacidad de recepción de
cada receptor. El protocolo FLUTE, como todos aquellos que ofrecen la posibilidad de transmisión
de datos de forma fiable en redes multicast, son catalogados como experimentales[43]. La razón de
esta clasificación se fundamenta en que la IETF todavía no ha adoptado un esquema de control
de congestión para protocolos multicast fiables. Aunque está principalmente pensado para redes
unidireccionales, en FLUTE es posible utilizar métodos de recuperación de archivos, en los que es
necesaria la comunicación entre los receptores y el emisor.
3.2.
ALC y LCT
FLUTE utiliza las funcionalidades ofrecidas por el protocolo ALC [45](Asynchronus Layered Coding, codificación asíncrona por capas) que a su vez es una implementación de LCT[44] (Layered
Coding Transport, transporte de codificación por capas). Estos protocolos proporcionan a FLUTE
el transporte de objetos binarios a través de IP y UDP. ALC implementa LCT mediante el uso de
FEC como mecanismo de recuperación de errores y un control de congestión basado en la transmisión de datos a múltiples tasas binarias. En el contexto del uso de FLUTE en IPDC sobre DVB-H
no es necesaria la utilización de mecanismos de control de congestión, ya que la transmisión de
los datos se produce sobre una red de difusión controlada. Con la utilización de FEC se consigue
que la recuperación de errores se realice sin necesidad de comunicación entre los receptores y el
emisor.
La transmisión de objetos binarios en ALC/LCT se realiza mediante canales y sesiones. Un canal
está definido por la dirección IP fuente, la dirección IP destino y puerto. Una sesión está compuesta
por uno o varios canales. La utilización de varios canales dentro de una misma sesión está justificada
en el ámbito del uso de protocolos de control de congestión en redes multicast. De esta forma cada
canal de una sesión puede enviar los mismos datos pero a distintas tasas binarias. El primer canal,
al que se le denomina canal base tendrá la tasa más pequeña, aumentando en los siguientes canales.
De este modo, si el ancho de banda es el suficiente el receptor puede recibir la información por el
canal de más alta capacidad, mientras que si existe congestión, se conecta al canal base. También
es posible distribuir distintos ficheros en cada canal, por lo que los receptores dependiendo de la
capacidad disponible, pueden descargar un menor o mayor número de ficheros.
15
16
3.2. ALC y LCT
Cada sesión se identifica con un TSI (Transport Session Identifier, identificador de sesión de
transporte) presente en las cabeceras de los paquetes ALC. En caso de que se transmitan varios
objetos en una misma sesión cada objeto se identifica mediante el campo TOI (Transport Object
Identifier, identificador de objeto de transporte) de la cabecera ALC. El TOI se compone de un
máximo de 3 bloques de 32 bits más un bloque de 16 bits. Por tanto, la longitud de un TOI
puede ser 0, 16, 48, 80 o 112 bits. La cabecera ALC es básicamente la misma que la de LCT pero
con un último campo que describe los datos del paquete codificados con FEC (FEC Payload ID,
identificador de carga FEC). La estructura de la cabecera ALC se muestra en la figura 3.1.
Figura 3.1: Estructura de un paquete ALC
La función de los distintos campos son los siguientes:
V (versión): número de versión de LCT.
C (bandera de control de congestión): determina la longitud del campo CCI.
S (bandera del identificador de sesión de transporte): indica el número de palabras de 32
bytes que tiene el campo TSI. La longitud en bits del TSI viene determinada por la fórmula
32∗S + 16∗H, siendo H el campo de bandera de media palabra.
O (bandera del identificador de objeto de transporte): es análogo al campo S pero aplicado
al TOI, siendo la longitud en bits del TOI 32∗O + 16∗H.
T (bandera de presencia del SCT): si está a 1 es que el campo SCT (Sender Current Time,
hora actual del emisor) se está utilizando.
R (bandera de presencia del ERT): su funcionalidad es análoga a la del campo T pero en
este caso hace referencia a la existencia del campo ERT (Expected Residual Time, tiempo
restante estimado) en vez de al SCT.
A (bandera de cierre de sesión) y B (bandera de cierre de objeto): si su valor es 1 indica que
no se recibirán más paquetes de la sesión actual y del objeto actual respectivamente.
HDR_LEN (longitud de la cabecera LCT): anuncia la longitud total de la cabecera LCT en
palabras de 32 bits.
CP (código de puntos): se utiliza para informar al receptor de parámetros que cambian
durante la sesión. En ALC un parámetro variable en el transcurso de una sesión puede ser la
codificación FEC. Por lo tanto en el código de puntos se podría transportar el identificador
de la codificación FEC. Cabe destacar que la correspondencia entre el contenido del campo
código de puntos y el identificador de codificación FEC o cualquier otro parámetro se realiza
externamente al protocolo ALC.
3. El Protocolo FLUTE
17
CCI (información de control de congestión): contiene información relevante del protocolo de
control de congestión como número de canales o de capas.
TSI (identificador de sesión de transporte): permite la identificación de una sesión entre
todas las pertenecientes a un determinado receptor.
TOI (identificador de objeto de transporte): identifica los paquetes que transportan datos
de un determinado objeto dentro de una sesión.
SCT (hora actual del emisor): indica la hora en la que el emisor ha enviado el paquete.
ERT (tiempo residual esperado): anuncia el tiempo estimado hasta el final de la sesión o de
la transmisión del objeto.
Extensiones de la cabecera LCT: se pueden ampliar el número de campos de los paquetes
LCT mediante la extensión de la cabecera. La presencia de campos que extiendan a los
estándares se infiere del campo HDR_LEN, que como se ha dicho anteriormente informa de
la longitud de la cabecara LCT en palabras de 32 bits.
Identificador de Carga FEC: este campo es propio de ALC. Identifica a los símbolos codificados que se transportan en la carga útil de los paquetes.
FLUTE a partir de las funcionalidades que le proporcionan ALC y LCT añade elementos que
permiten anunciar los archivos presentes en cada sesión con el proposito de que los receptores
elijan cuáles descargar. Para tal fin se transmite junto con los ficheros un documento XML llamado
FDT (File Delivery Table, tabla de distribución de ficheros).
3.3.
Instancias FDT
En el FDT se describen, además de las propiedades de los ficheros transmitidos, las características
de la transmisión FLUTE. El documento FDT se distribuye como un conjunto de instancias FDT,
que se transmiten con un TOI de valor 0 . Cada instancia FDT describe uno, varios o la totalidad de
los ficheros de los descritos en la FDT. Así pues, los receptores no necesitan conocer completamente
el contenido de una determinada sesión en un principio, ya que a medida que vayan interpretando
las instancias FDT que lleguen, obtendrán la información completa de la sesión. Las instancias
FDT se distinguen unas de otras a través de un identificador de instancia FDT, que se incorpora
al paquete LCT por medio de una extensión llamada EXT_FDT, tal y como se muestra en la
figura 3.2.
Figura 3.2: Paquete de datos de una instancia FDT
La estructura de la instancia FDT es la siguiente:
18
3.3. Instancias FDT
Elemento FDT-Instance: es el elemento raíz. Contiene el atributo Expire que indica el tiempo
en formato NTP en el que la instancia FDT ya deja de tener validez. También cuenta con
el atributo booleano Complete que indica si su valor es “true” que en siguientes instancias
FDT no se aportarán datos nuevos.
Elemento File representa las propiedades de un fichero difundo en una sesión FLUTE. Debe
contener obligatoriamente los atributos TOI y Content-Location. El atributo TOI contiene el
TOI de los paquetes que transportan el fichero y Content-Location contiene una URI (Unifom
Resource Identifier, identificador uniforme de recurso) válida que identifica al fichero. Además
de estos atributos obligatorios, pueden incluirse otros opcionales como:
• Content-Type: describe el contenido de los ficheros segun el formato MIME (Multipurpose Internet Mail Extensions, Extensiones de Correo de Internet Multiproposito).
• Content-Length: describe la longitud en bytes del fichero.
• Content-Encoding: contiene la codificación que se ha usado para comprimir el archivo,
en el caso de que se haya utilizado alguno.
• Content -MD5: se utiliza para que el receptor pueda comprobar la integridad del fichero.
• FEC Object Transmision Information: engloba un conjunto de atributos que describe
la codificación FEC de los archivos distribuidos. Mediante estos atributos es posible
difundir la información de la codificación FEC de los datos en las instancias FDT en
vez de en las cabeceras ALC. Estos atributos comienzan por FEC-OTI ( FEC Object
Transmision Information, información de transmisión de objectos FEC) e informan
del identificador de la codificación (FEC-OTI-FEC-Encoding-ID), del identificador de
instancia (FEC-OTI-FEC-Instance-ID), del tamaño máximo de los bloques originales (FEC-OTI-Maximum-Source-Block-Length), de la longitud de los símbolos codificados (FEC-OTI-Encoding-Symbol-Length) así como del número máximo de bloques
codificados(FEC-OTI-Max-Number-of-Encoding-Symbols).
El esquema XML de las instancias FDT puede extenderse con nuevos atributos ya sea en el
elemento FDT-Instance o en File. En IPDC se añaden los siguientes elementos:
Group: se utiliza para identificar objetos que deben descargarse de manera conjunta. Si
por ejemplo se transmite una página web en una sesión FLUTE, dentro de esta sesión se
enviará el archivo html y las imágenes que se pudieran referenciar. Todos estos elementos se
describirían en las instancias FDT como pertenecientes a un mismo grupo, de modo que en
el caso de descargar el código html, el receptor FLUTE sabrá qué objetos complementarios
tendrá que descargar. Este elemento está definido en el esquema de FDT definido para IPDC
[34].
FullFDT : es un atributo booleano que indica si todos los archivos transmitidos en la sesión
FLUTE están descritos en la instancia FDT. Este atributo (con valor true) asegura al lado
receptor que la instancia FDT que se recibe es una relación completa de los ficheros difundidos en la sesión. FullFDT es de gran utilidad para el descubrimiento de los servicios en
IPDC. Como se comentó en el capítulo referente a IPDC, los servicios disponibles en una
plataforma se describen en la ESG. La ESG se trocea y se encapsula en archivos llamados
contenedores que se distribuyen a los receptores mediante el protocolo FLUTE. Dado que cada contenedor puede contener referencias a otros contenedores generados de la misma ESG,
es fundamental para el receptor procesar la totalidad de los contenedores que componen la
ESG. Con FullFDT se consigue informar al receptor de que todos los archivos presentes en
la sesión en un determinado instante de tiempo están descritos en la instancia FDT, y por
ende, garantizar que no existen otros ficheros (y por tanto contenedores) difundidos en la
sesión y así poder formar una ESG coherente, es decir, sin referencias erróneas.
3. El Protocolo FLUTE
19
Version-ID-Length: informa al receptor de la longitud en bits que se utiliza del campo TOI
para especificar la versión de cada fichero ya que el TOI de LCT se puede utilizar para
identificar al objeto transportado a la vez que notificar nuevas versiones del mismo, utilizando
los bits más significativos para identificar al objeto y los menos significativos para informar
de la versión. Así pues si en el elemento File de una instancia FDT se encuentra un atributo
Version-ID de valor 16, 16 bits en el TOI se dedican a identificar el objeto y otros 16, los
menos significativos, a notificar la versión. Version-ID-Length se utiliza en el mecanismo
de actualización de la ESG conocido como “Split-TOI”. Este mecanismo utiliza los bits de
versión del fichero para informar de cambios en los contenedores (con el cambio del número
de versión). Tanto este atributo como FullFDT están definidos en una extensión específica
para el transporte de la ESG[36] dentro del esquema FDT en IPDC.
3.4.
Descarga de ficheros en FLUTE
Como ya se ha visto, FLUTE está diseñado para la difusión de ficheros a un gran número de
receptores. Las diferentes maneras en las que se puede realizar dicha difusión acarrea un comportamiento distinto en los receptores. Conviene recordar que en FLUTE los receptores en un
principio disponen sólo de la información necesaria para sintonizar la sesión (fundamentalmente
IP destino, IP origen y TSI) pero no tienen información de los archivos transportados. Es decir, el
receptor puede enfrentarse a una sesión que transporta siempre los mismos archivos, o que varían
con el tiempo, archivos de gran longitud o de unos pocos kilobytes. Así pues, los siguientes apartados se describirán los distintos tipos de sesiones FLUTE existentes y el proceso de estimación
de los ficheros transportados en cada sesión.
3.4.1.
Tipos de Sesiones en FLUTE
En FLUTE es posible llevar a cabo los siguientes tipos de sesiones:
Sesión estática: se distribuyen unos ficheros prefijados de antemano aunque de cada fichero
pueden distribuirse distintas versiones, nunca se distribuiran de forma simultánea.
Sesión de contenidos fijos: similar a la sesión estática, pero en el que las versiones de los
archivos enviados no pueden cambiar durante toda la sesión. Un ejemplo de este tipo de
sesiones puede verse en la figura 3.3.
Figura 3.3: Ejemplo de una sesión de contenidos fijos.
Sesión dinámica: en esta clase de sesiones los archivos transportados pueden variar en el
transcurso del tiempo.
Carrusel estático: se envían un conjunto fijo de ficheros en una sesión que puede llegar a ser
ilimitada en el tiempo. La figura 3.4 ilustra una este tipo de emisión en carrusel.
20
3.4. Descarga de ficheros en FLUTE
Figura 3.4: Ejemplo de un carrusel estático
Carrusel dinámico: es un carrusel en el que los archivos se eliminan, modifican o añaden en
el trascurso de la emisión.
A continuación se detallan las características específicas de FLUTE correspondientes a cada tipo
de sesión:
Sesión estática:
• De la totalidad de las instancias FDT emitidas durante la sesión al menos una debe
describir todos y cada uno de los ficheros distribuidos. La instancia FDT en cuestión
debe tener el atributo Complete a TRUE.
• Algunas instancias FDT pueden trasportar datos que no se incluían en las instancias
anteriores o que hayan cambiado (como el tamaño de los ficheros).
• Cualquier instancia FDT puede retransmitirse durante la sesión.
Sesión de contenidos fijos:
• Cada instancia FDT debe informar de todos los archivos que se transmiten en la sesión.
Por lo tanto el atributo Complete de cada una de ellas tiene el valor TRUE.
• Como en el caso anterior las intancias FDT pueden repetirse en el transcurso de la
sesión.
Sesión dinámica:
• En lo que respecta a FLUTE, las características de emisión son las mismas que en la
sesión estática.
Carrusel estático:
• Sus características son similares a las vistas en la sesión estática de contenidos fijos,
salvo en la duración de la sesión, mucho más larga en este caso.
Carrusel dinámico:
• Las instancias FDT se distribuyen de la misma forma que en las sesiones dinámicas.
3.4.2.
Estimación del Fin de la Sesión
Una vez descritos los tipos de sesiones FLUTE desde el punto de vista de la construcción y
emisión de las instancias FDT, es conveniente aclarar cómo se produce la recepción de ficheros en
estas distintas clases de sesiones. Para la recepción de cualquier fichero en FLUTE es necesaria la
creación de la relación de ficheros distribuidos en la sesión. Esta tarea que en un principio puede
3. El Protocolo FLUTE
21
resultar sencilla, dependiendo de las características de la sesión que se sintonice puede hacerse más
compleja, ya que no se tiene la plena seguridad de extraer una relación exacta de los ficheros que
se transportan.
En las sesiones de contenidos fijos es fácil determinar cuándo se tiene la información completa
acerca de los ficheros transportados en la sesión, dado que cada instancia FDT contiene la relación
definitiva de los ficheros enviados. En cambio en las sesiones estáticas los archivos pueden actualizarse y en las sesiones dinámicas además añadirse o eliminarse en cualquier momento durante la
sesión. Así pues, queda a criterio del receptor la consideración de una sesión como suficientemente
completa, exceptuando el caso en el que se reciban paquetes FLUTE con el campo A activado,
lo que anuncia el fin de la sesión. Se verán a continuación unos criterios definidos en el “DVB
Document A101”[30] para la suposición de una sesión como completa:
Una sesión de contenidos fijos se considera completa cuando se recibe una instancia FDT con
el atributo Complete a “true” y el terminal recibe correctamente todos los ficheros descritos
en la FDT. En caso de que no se reciban todos los ficheros, es necesario que se reciban
paquetes FLUTE con el campo B activado para considerar que no se recibirán más paquetes
de algún fichero.
Una sesión estática o un carrusel estático se consideran suficientemente completos cuando
se reciben una o varias instancias FDT con el atributo Complete activado y además se han
producido las descargas de las últimas versiones de los ficheros. Como en las sesiones de
contenidos fijos, si se reciben paquetes con la bandera B activada también se considera a la
sesión suficientemente completa.
En una sesión o un carrusel dinámico se utilizan algoritmos basados en temporizadores para
no permanecer indefinidamente escrutando los paquetes de la sesión. Estos temporizadores
marcan el tiempo máximo que se espera a la llegada de actualizaciones de la FDT así como
de paquetes con TOI no definidos en las instancias FDT recibidas.
22
3.4. Descarga de ficheros en FLUTE