Transmisión en tiempo real

Síntesis Protocolos de TR 23/07/98 20:12
Transmisión de datos en Tiempo Real
Síntesis de protocolos y redes para transmisión en
tiempo real
La necesidad de transmisión de voz y imagen compartiendo las
mismas redes de transmisión de datos normales ha provocado la
aparición de nuevas redes y protocolos.
El siguiente documento describe los protocolos y redes para la
transmisión de datos en tiempo real. Se hace un repaso a la bibliografía
existente y al estado tecnológico del tema.
Trabajo doctorado 2 créditos.
Presentado por _______________________________________ Enrique Hernández Orallo
Dirigido por _________________________________________________ Joan Vila i Carbó
Transmisión de datos en Tiempo Real
1.- Introducción ______________________________________________________________ 4
2.- Transmisión en tiempo real __________________________________________________ 4
2.1.- Estado tecnológico actual _______________________________________________________ 4
2.2.- Requerimientos para la transmisión multimedia ____________________________________ 5
2.2.1.- Ancho de banda ____________________________________________________________________ 5
2.2.2.- Retraso de transmisión ______________________________________________________________ 5
2.2.3.- Fiabilidad_________________________________________________________________________ 6
2.2.4.- Sincronización de canales ____________________________________________________________ 6
2.3.- Modelo de servicios integrados __________________________________________________ 7
2.3.1.- Calidad de Servicio. Tipos de tráfico ___________________________________________________ 7
2.3.2.- Requerimientos de compartición de recursos _____________________________________________ 9
2.3.3.- Eliminación de paquetes ____________________________________________________________ 10
2.3.4.- Modelo de reserva _________________________________________________________________ 10
2.4.- Líneas actuales de investigación_________________________________________________ 10
3.- Redes de transmisión de datos. _______________________________________________ 11
3.1.- Ethernet ____________________________________________________________________ 11
3.2.- Iso-Ethernet. ________________________________________________________________ 11
3.3.- Token Ring__________________________________________________________________ 12
3.4.- 100Base-T___________________________________________________________________ 12
3.5.- IEEE 802.12 (100-Mbps Demand Priority LAN) ___________________________________ 12
3.6.- FDDI (Fiber Distributed Data Interface) _________________________________________ 13
3.7.- FDDI-II (Fiber Distributed Data Interface) _______________________________________ 13
3.8.- X-25________________________________________________________________________ 13
3.9.- Frame Relay_________________________________________________________________ 13
3.10.- RDSI (Red digital de servicios integrados) _______________________________________ 14
3.11.- ATM (Asynchronous Transfer Mode)___________________________________________ 14
3.12.- Resumen de las características de las redes ______________________________________ 15
4.- Protocolos de red__________________________________________________________ 16
4.1.- Introducción_________________________________________________________________ 16
4.2.- IPv4________________________________________________________________________ 16
4.3.- IPv6 (Internet Protocol version 6) _______________________________________________ 17
4.3.1.- Introducción _____________________________________________________________________ 17
4.3.2.- Formato de los paquetes ____________________________________________________________ 18
4.3.3.- Gestión de las prioridades ___________________________________________________________ 19
4.3.4.- Gestión de la fragmentación _________________________________________________________ 19
4.3.5.- Control de flujos __________________________________________________________________ 20
4.3.6.- Direcciones IPv6 __________________________________________________________________ 20
4.3.7.- Seguridad________________________________________________________________________ 20
5.- Protocolos RPSI __________________________________________________________ 21
5.1.- Introducción_________________________________________________________________ 21
5.2.- RSVP (Resource ReSerVation Protocol)__________________________________________ 23
5.2.1.- Introducción _____________________________________________________________________ 23
5.2.2.- Objetivos de diseño ________________________________________________________________ 23
Enrique Hernández Orallo
Página 2
07/08/00
Transmisión de datos en Tiempo Real
5.2.3.- Principios de diseño________________________________________________________________ 24
5.2.4.- Clases de calidad de servicio _________________________________________________________ 24
5.2.5.- Funcionamiento de RSVP ___________________________________________________________ 26
5.2.6.- Modelos de reserva de recursos_______________________________________________________ 29
5.2.7.- Tipos de encaminamiento para RSVP __________________________________________________ 30
5.2.8.- Conclusiones _____________________________________________________________________ 31
5.3.- Tenet suite __________________________________________________________________ 31
5.3.1.- Introducción _____________________________________________________________________ 31
5.3.2.- El diseño de los protocolos Tenet _____________________________________________________ 31
5.3.3.- Establecimiento y control de canales___________________________________________________ 32
5.3.4.- Transmisión y planificación de paquetes________________________________________________ 33
5.3.5.-Nivel de transporte _________________________________________________________________ 34
5.4.- ST-II (Stream Protocol-II) _____________________________________________________ 34
5.4.1.- Introducción _____________________________________________________________________ 34
5.4.2.- Establecimiento de canales __________________________________________________________ 34
5.4.3.- Control de miembros _______________________________________________________________ 35
5.4.4.- Fiabilidad________________________________________________________________________ 35
5.4.5.- Modelos de servicio________________________________________________________________ 35
5.4.6.- Conclusiones _____________________________________________________________________ 35
5.5.- RTP (Real-time transport protocol) _____________________________________________ 35
5.5.1.- Introducción _____________________________________________________________________ 35
5.5.2.- Protocolo RTP ____________________________________________________________________ 36
5.5.3.- El protocolo de control RTP (RTCP) __________________________________________________ 37
5.6.- Comparación de los protocolos _________________________________________________ 39
6.- Protocolos a nivel de aplicación ______________________________________________ 39
6.1.- RTSP (Real Time Streaming Protocol) ___________________________________________ 39
Apéndice 1 : Bibliografía ______________________________________________________ 40
Apéndice 2 : Acrónimos _______________________________________________________ 42
Enrique Hernández Orallo
Página 3
07/08/00
Transmisión de datos en Tiempo Real
1.- Introducción
La necesidad de transmisión de información multimedia (audio y vídeo) tendrá un gran
impacto en los sistemas de comunicación. Esta transmisión requerirá no sólo el soporte de las
redes , sino también de los protocolos de comunicación de niveles superiores. En este sentido se
trabaja tanto en redes locales (LAN) como en internetworks.
Podemos hablar de transmisión de información en tiempo real1 cuando se puede asegurar
que la información llegue a su destino con unos parámetros determinados (retraso , rendimiento,
fiabilidad, etc.). En este sentido se puede asumir que la transmisión multimedia tiene unos
requerimientos temporales que necesitan del uso de esta transmisión en tiempo real.
En general las aplicaciones multimedia requieren una calidad de servicio (QoS) por parte
de los servicios de red. De las nuevas redes se exige poder especificar esta calidad de servicio y
asegurar su cumplimiento. Otro problema es quién proporciona esta calidad de servicio : la red (
los routers, nodos, conmutadores, etc.) o el sistema operativo.
2.- Transmisión en tiempo real
2.1.- Estado tecnológico actual
El estado tecnológico actual es desolador. Las LAN actualmente más usadas como
pueden ser Ethernet o Token Ring no están preparadas para la transmisión de datos en tiempo
real [1]. En internetworks la situación es peor. El gran problema de TCP/IP es el retraso no
determinista de los paquetes [2]. El hecho es que aunque existen una serie de productos
comercializados para videoconferencia, telefonía y vídeo por internet, etc.; sus resultados dejan
mucho que desear.
Otro tema es el elevado ancho de banda requerido para transmisión de vídeo y/o audio de
alta calidad. Esto supone un problema debido a la actuales limitaciones de las redes de
transmisión de datos y su alto coste económico.
Ante esta necesidad se han desarrollado un conjunto de redes y protocolos para
transmisión en tiempo real. Se pueden distinguir dos grupos:
•
Las redes de transmisión de datos: En este grupo se incluyen las nuevas LAN ( FDDIII, Isochronous Ethernet [4], IEEE 802.12 [6] y WAN (ATM [5], RDSI-BA). Todas
estas redes contemplan en mayor o menor medida la transmisión de datos en tiempo
real. Además tienen unos ancho de banda muy elevados para soportar la transmisión
de vídeo de alta calidad.
1
Se ha extendido el uso del término de transmisión en tiempo real como transmisión multimedia, aunque realmente
la transmisión multimedia requiere otros parámetros aparte de los meramente temporales. En general el uso de este
término se ha extendido a parámetros como rendimiento o fiabilidad.
Enrique Hernández Orallo
Página 4
07/08/00
Transmisión de datos en Tiempo Real
•
Protocolos de transporte y red : Se están desarrollando un conjunto de nuevos
protocolos para la transmisión de datos en tiempo real en internetworks. Se basan en
la modificación de protocolos de red o bien la utilización de algún otro protocolo de
red como IPv4. Entre estos se pueden distinguir : ReSerVation Protocol (RSVP)
[18][7][8], Internet Protocol v6 (IPv6) [17][18] , Stream Protocol-II (ST-II) [22][23] ,
Real Time Transport Protocol (RTP) [24] y los protocolos de la Tenet
Suite[3][9][10][16].
Mientras en las redes de transmisión de datos se habla de tecnología ya desarrollada y
comercializada2, los protocolos para internetworks es un tema actualmente de investigación y
con soluciones parciales o reducidas.
Aunque el objetivo de esta tesis son los protocolos para internetworks es necesario tener
un conocimiento de las redes de transmisión de datos para su modelización.
2.2.- Requerimientos para la transmisión multimedia
En general los requerimientos para la transmisión de audio y vídeo han sido tratados
extensamente [25] y se describen en los siguientes puntos.
2.2.1.- Ancho de banda
La información de vídeo actualmente se trata casi exclusivamente de forma comprimida.
El ancho de banda dependerá por tanto del tipo de compresión y de la calidad con que se quiera
transmitir.
De los tres estándares más difundidos para compresión de vídeo: ISO Moving Pictures
Expert Group (MPEG), Intel’s Digital Video Interactive (DVI) y International
Telecommunications Union (ITU) H.261; requieren un ancho de banda de 1.2 a 40 Mbps para el
MPEG y MPEG-2, 1.2 a 1.8 Mbps para DVI, y de 0.064 a 2 Mbps para el H.261.
La actuales sistemas de videoconferencia que usan RDSI muestran que canales de 64kbps
sólo es aceptable con imagen con pocas variaciones (como suelen ser las imágenes de los “bustos
parlantes”).
En la práctica [1] la transmisión multimedia demanda un ancho de banda de 0.4 Mbps a
1.4 Mbps y esto únicamente en comunicación unidireccional.
2.2.2.- Retraso de transmisión
Estos requerimientos son más estrictos que los de ancho de banda. La experiencia con los
sistemas de conferencia multimedia y los estándares ITU sugieren un retraso máximo de 150 ms
en las aplicaciones de vídeo interactivas.
En función del retraso se pueden distinguir los siguientes tipos de tráfico:
2
Aunque todavía no de uso general por el inmenso coste económico que supone la migración de las actuales redes.
Enrique Hernández Orallo
Página 5
07/08/00
Transmisión de datos en Tiempo Real
•
•
•
Asíncrono : Retraso de transmisión sin restricciones,
Síncrono : El retraso de transmisión está acotado para cada mensaje,
Isócrono : El retraso de transmisión es constante para cada mensaje.
La isocronía no tiene porqué ser mantenida durante todo el camino de un mensaje, ya que
puede ser recuperada en el destino mediante un almacenamiento para visualización.
Otro tema son los tiempos de compresión y descompresión de las imágenes de vídeo.
Siguiendo los requerimientos del CCITT de un máximo de 150 ms de fuente a destino, se pueden
identificar las siguientes componentes en el retraso:
1.
2.
3.
4.
Retraso en la compresión y descomposición en paquetes en la fuente,
Retraso de transmisión en la red,
Almacenamiento en el destino y retraso de sincronización,
Retraso de la composición de los paquetes y la descompresión en el destino.
La imagen debe tener de 25 a 30 tramas por segundo. Esto deja un tiempo máximo de
compresión/descompresión de 30 a 40 ms (aunque puede ser menor). Restando a 150 ms deja un
retraso máximo de 70 a 90 ms para la transmisión en la red. Asumiendo que una ruta de tres
saltos LAN-WAN-LAN es una topología frecuente, y teniendo en cuenta que los elementos de
enlace (gateways, routers, etc. ) también contribuyen al retraso, nos queda un retraso máximo
aceptable de 10 a 15 ms por salto. Aunque estos cálculos son aproximativos y dependerían de
muchos otros factores, nos sirve como una aproximación a los problemas de la transmisión.
2.2.3.- Fiabilidad
Las redes tradicionales proporcionan comunicación fiable entre emisor y receptor. Los
protocolos de transmisión tienen sistemas de control de errores y de reenvío de paquetes que
aseguran que esta fiabilidad es transparente a los niveles superiores.
Para la transmisión en tiempo real esta gestión de errores puede ser negativa, debido al
retraso que produciría la retransmisión de un paquete de nuevo. Para evitar este problema se
plantea que el tratamiento y gestión de los errores sea a niveles superiores.
Las prestaciones de una transmisión multimedia puede ser medida en dos dimensiones :
latencia y fidelidad. La latencia puede ser vital para aplicaciones interactivas como conferencias
mientras que la transmisión de una película no lo es. La fidelidad de la transmisión es variable.
Hay aplicaciones que no toleran ninguna variación en la fidelidad de la imagen como podrían ser
la transmisión de imágenes médicas y otras en que esta variación solo produce una cierta
distorsión tolerable como la transmisión de películas o música.
2.2.4.- Sincronización de canales
Cuando audio, vídeo y otros datos vienen por distintos canales, se necesitan mecanismos
para la sincronización de los distintos flujos en el destino. Esto se puede conseguir usando una
combinación de asignación de tiempos y almacenamiento antes de visualización. Esto en general
no afecta a la red y es un problema del destino.
Enrique Hernández Orallo
Página 6
07/08/00
Transmisión de datos en Tiempo Real
2.3.- Modelo de servicios integrados
Un modelo de servicio define las propiedades que debe tener un servicio y que este ofrece
a las aplicaciones que lo usan [30]. En este caso hablamos de servicios integrados en la que se
ofrece servicios en tiempo real, tráfico de datos y la compartición de enlaces controlado.
El primer requerimiento para cualquier transmisión en tiempo real es que todos los
niveles que compongan la arquitectura de la red deben de garantizar unas prestaciones mínimas y
deterministas. En este sentido no se puede utilizar Ethernet como protocolo de red aunque
usáramos protocolos deterministas a niveles superiores [3].
El modelo de servicios integrados intenta integrar todos los tipos de tráficos posibles en
una misma red de uso general. A continuación se enumeran los requerimientos de este modelo de
servicio:
2.3.1.- Calidad de Servicio. Tipos de tráfico
La calidad del servicio vendrá determinado por el punto de vista que se tome. Desde el
punto de vista del emisor/receptor los requerimientos están relacionados casi exclusivamente con
el tiempo de entrega de los paquetes de información (retraso), la tasa perdida de información y el
ancho de banda [30]. Otros puntos de vista pueden ser la eficiencia en el uso de la red, la tasa de
errores o retransmisiones.
El tráfico se puede dividir en distintas categorías bien en función de la tolerancia a las
parámetros indicados o bien por los requerimientos de los parámetros.
En la siguiente gráfico el tráfico es clasificado en el producto cartesiano (sensibilidad al
retraso) X (sensibilidad a la perdida):
Tiempo real
adaptativo
Sensible al
retraso
Video y audio
No sensible
a la perdida
Control de
procesos
Tiempo real
Sensible
a la perdida
Transferencia
ficheros, email
No sensible
al retraso
Elásticas
Como se ve el grado en que las prestaciones de una aplicación depende de este retraso
varia ampliamente y las podemos catalogar en aplicaciones de tiempo real y aplicaciones
elásticas.
Enrique Hernández Orallo
Página 7
07/08/00
Transmisión de datos en Tiempo Real
2.3.1.1.- Aplicaciones de tiempo real
Una clase importante de estas aplicaciones son las de reproducción. En este tipo de
aplicaciones la fuente coge una señal, la convierte en paquetes y los transmite por la red. La red
introduce un retraso que debe ser tratado en el receptor. Para poder tratar correctamente los
paquetes la aplicación necesita saber a priori el máximo retraso que los paquetes pueden
experimentar.
El retraso puede afectar las prestaciones de las aplicaciones en dos maneras. Primero, el
tiempo del retraso determina la latencia de la aplicación. Segundo, el retraso individual de los
paquetes puede hacer que la fidelidad decaiga si se excede el tiempo de retraso determinado; en
este caso la aplicación puede retrasar la ejecución para reproducir estos paquetes retrasados (lo
que introduce distorsión) o bien simplemente descartarlos (lo que crea una señal incompleta).
En este sentido se pueden distinguir dos tipos de aplicaciones:
•
•
Aplicaciones intolerantes : Estas aplicaciones no se pueden adaptar a que un paquete
se retrase más que el límite predeterminado. Necesitan por lo tanto un límite superior
del retraso fiable. Este aplicaciones requieren un modelo de servicio denominado
servicio garantizado.
Aplicaciones adaptativas : Estas aplicaciones pueden tolerar que lleguen paquetes
con un mayor retraso. Estas aplicaciones requieren un modelo de servicio
denominado servicio predictivo, que proporciona un servicio bastante fiable pero no
seguro. Este tipo de aplicaciones pueden aceptar un merma en la calidad
presumiblemente por el menor coste de este modelo, ya que se incrementa el uso de
los recursos de red.
Para proporcionar un límite en el retraso el tráfico se tiene que caracterizar y debe haber
algún algoritmo de control de admisión que asegure que una petición de flujo puede ser
aceptada.
2.3.1.2.- Aplicaciones elásticas
Estas aplicaciones siempre esperan a que los datos lleguen. Este tipo de aplicaciones no
requieren ninguna caracterización del servicio para funcionar. Ejemplos de estas aplicaciones
son transferencias (FTP), terminales (Telnet, X, NFS), etc.
Un modelo de servicio para estas aplicaciones es proporcionar un servicio “tan rápido
como se pueda” (ASAP as-soon-as-possible) . En contraste a los modelos en tiempo real, estas
aplicaciones no están sujetas a control de admisión.
2.3.1.3.- Ancho de banda y retraso
Otro aspecto a considerar en el tráfico es el ancho de banda y retraso necesario para la
transmisión. En la siguiente gráfico el tráfico es clasificado en el producto cartesiano (ancho de
banda) X (retraso):
Enrique Hernández Orallo
Página 8
07/08/00
Transmisión de datos en Tiempo Real
Gran ancho
de banda
Video y audio
Transferencia
de ficheros
Bajo retraso
Alto retraso
Control de
procesos
email
Bajo ancho
de banda
Valores típicos para distintos tipos del tráfico se describen en la siguiente tabla:
Voz
Vídeo
Imagen
Retraso máximo(s) Máxima variación en Ancho
el retraso
banda(Mbps)
0.25
10
0.064
0.25
10
100
1
2-10
de Tasa de perdida
de paquetes
10e-1
10e-3
10e-9
2.3.2.- Requerimientos de compartición de recursos
Mientras el aspecto más importante en la calidad de servicio es el retraso, aquí el interés
primario es el ancho de banda de los enlaces. Este componente del modelo de servicio, llamado
compartición de enlaces, contempla como compartir el ancho de banda de un enlace entre varios
flujos de acuerdo con ciertas características. Se pueden distinguir los siguientes tipos de
comparticiones:
•
•
•
Compartición multi-entidad : Un enlace puede ser usado por varias organizaciones.
Se debe asegurar que los enlaces son compartidos de forma controlada, quizás de
forma proporcionar a lo que paguen.
Compartición multi-protocolo : Se debe prevenir que un familia de protocolos
(DECnet, IP, IPX, OSI, SNA, etc. ) sobrecargue un enlace y excluya al resto. Esto es
importante porque las distintas familias de protocolos responden de forma diferente a
la congestión.
Compartición multi-servicio : Un administrador de red puede limitar la fracción de
ancho de banda para cada clase de servicio.
El control de admisión será necesario de nuevo para asegurar que la compartición de
recursos se va a cumplir.
Enrique Hernández Orallo
Página 9
07/08/00
Transmisión de datos en Tiempo Real
2.3.3.- Eliminación de paquetes
Cuando la red prevé que no va a cumplir alguna de sus compromisos de servicio, puede
eliminar algún paquete para asegurar el resto. Esto implica imponer en los paquetes algún tipo de
prioridad.
En principio esta eliminación solo afectaría a las aplicaciones que no tengan el servicio
garantizado ya que en la asignación de recursos se habría asegurado que esto no pasaría.
2.3.4.- Modelo de reserva
El modelo de reserva describe como una aplicación negocia el nivel de calidad de
servicio. El modelo más simple es que una aplicación pregunte por una calidad de servicio
particular y que la red se lo proporcione o lo deniegue.
Sin embargo, más que rechazar la petición, la red podría conceder un nivel de recursos
menor que el pedido. Un esquema más complejo es el modelo de reserva de “doble pasada”. En
este esquema se propaga flowspec inicial desde el origen a los posibles destinos. Cada router
en las rutas guarda estos valores y quizá los ajusta para reflejar su capacidad disponible. Los
receptores obtienen estos flowspec pudiéndolo modificar y generar otro flowspec de vuelta
al origen. Por cada nodo de vuelta se reservan de forma definitiva los recursos indicados en este
flowspec hasta que llegue al origen.
2.4.- Líneas actuales de investigación
Hay varios grupos de investigación trabajando en protocolos de transporte y red para
tiempo real como el Tenet Group de la University of California at Berkeley, IBM European
Networking Center en Heidelberg, Information Sciencies Institute de la University of Southern
California.
La investigación de estos grupos se centra en:
•
•
•
•
•
Desarrollo y evaluación de distintas disciplinas de servicio en los nodos. Algoritmos
de planificación. Gestión de las prioridades.
Reserva de recursos en la red. Mecanismos de control de admisión en la red y política
de gestión de los recursos. Multicasting ( Distribución de audio y vídeo compartiendo
recursos). Integración de los protocolos en MBONE.
Modelos formales de los protocolos. Formalización de los parámetros de servicio de
las redes. Demostración y aseguramiento de la calidad para cargas determinadas.
Simulación. Elaboración de herramientas de simulación adecuadas para evaluar estos
sistemas.
Calidad de servicio (QoS) : Formas de expresar y asegurar la calidad de servicio.
Introducir seguridad, tolerancia a fallos y contabilidad en el diseño de estas redes.
Límites absolutos o probabilísticos.
Los distintos protocolos desarrollados y comentados en el punto 2.1 han intentado
investigar y resolver algunos de los problemas comentados, pero en general no existe todavía un
protocolo que sea de propósito general. De hecho la mayoría de estos grupos de investigación
Enrique Hernández Orallo
Página 10
07/08/00
Transmisión de datos en Tiempo Real
están actualmente desarrollando segundas versiones de sus protocolos (RSVP-2, Suite Tenet
Group)
3.- Redes de transmisión de datos.
Existen un conjunto de redes que permiten la transmisión de datos en tiempo real.
Algunas de ellas son un desarrollo totalmente nuevo, otras son la adaptación de redes en uso para
admitir canales para transmisión de audio y vídeo. Incluso se transmite información multimedia
en redes no especialmente preparadas como puede ser Ethernet.
Aunque el concepto de red para LAN se refiere claramente a los niveles físicos y de
acceso al medio, en el contexto de las WAN está menos claro ya que proporcionan un conjunto
de servicios y funciones. Estos suelen incluir niveles de red y de enlace.
Se va a hacer un estudio de las distintas tecnologías de red en función de los siguientes
parámetros:
•
•
•
•
Ancho de banda. Al menos 1.4 Mbps para vídeo.
Retraso de transmisión. Un máximo de 10 a 15 ms (aunque puede ser mayor si no hay
ningún salto).
Comunicación multipunto : Ver si la red incorpora funciones de multicasting. Es
obvio que en redes de tipo broadcast esto no es ningún problema
Fiabilidad : Control de errores y mecanismos de recuperación en la red.
3.1.- Ethernet
Ethernet es la red de área local más utilizada actualmente. Su ancho de banda de 10 Mbps
permite varios canales de vídeo. El inconveniente es el método no determinista de acceso a la red
(CSMA-CD). Con altas cargas en la red no hay control sobre el tiempo de acceso a la red o el
ancho de banda disponible.
Sin embargo, muchas aplicaciones multimedia usan Ethernet como su mecanismo de
transporte, generalmente en un entorno controlado y protegido.
Evaluación : Ethernet no es adecuada debido a su retraso no determinista, sin embargo se
puede utilizar teniendo poco canales debido a su gran ancho de banda.
3.2.- Iso-Ethernet.
Es una red híbrida que integra una Ethernet estándar de 10 Mbps con 6.144 Mbps de
ancho de banda isócrono (RDSI), ofreciendo un total de 16 Mbps. Proporciona 96 canales RDSIB de 64-Kbps utilizando el mismo cable que la Ethernet a 10 Mbps, con lo cual tiene poco coste
de integrarlo con los cableados actuales. [4][2]
Evaluación : Esta red es una solución destinada a aprovechar los recursos existentes.
Proporciona tráfico isócrono. La estructura de los canales parecida a RDSI permite la
transmisión de audio o vídeo H.261, pero no permite la transmisión de vídeo de alta calidad.
Enrique Hernández Orallo
Página 11
07/08/00
Transmisión de datos en Tiempo Real
3.3.- Token Ring
Token Ring está mejor preparada para la transmisión multimedia. Una razón es su ancho
de banda de 16 Mbps. Más importante es la disponibilidad de prioridades y su acceso
determinista. Se pueden usar la alta prioridad para datos es tiempo real y la baja para datos
normales.
Los retrasos dependen del número de estaciones conectadas, la carga y el tamaño del
paquete. En general si se trabaja en un entorno en el que no hay muchas estaciones y el paquete
se escoge de un tamaño bajo ( 64 a 128 bytes) se pueden asegurar retraso de cómo máximo 10
ms. De hecho existen algoritmos que pueden determinar en estas redes el peor retraso.
Evaluación : Proporciona el suficiente ancho de banda para un número limitado de
canales multimedia. Se puede garantizar el retraso si se utiliza un esquema de acceso y
prioridades definidos. También permite multicasting.
3.4.- 100Base-T
Esta red es una simple evolución de Ethernet ampliando su velocidad a 100 Mbps,
utilizando el mismo protocolo de acceso a red. La evaluación es la misma que para Ethernet.
3.5.- IEEE 802.12 (100-Mbps Demand Priority LAN)
Este nuevo protocolo de red está pensado para satisfacer las necesidades de los nuevos
entornos de red. Se busca la posibilidad de enviar vídeo y audio en tiempo real utilizando la red.
Es una LAN de 100 Mbps de ancho de banda con prioridades.
El objetivo de este protocolo es poder sustituir los protocolos 802.3 y 802.5. De hecho
mantiene el LLC de estos protocolos y el MAC es compatible con estos dos. Se definen dos
niveles de prioridad en las tramas, el más alto con el objetivo de la transmisión multimedia. El
protocolo es determinista ya quien gestiona la red es el repetidor y lo hace por medio de un
mecanismo round-robin con dos prioridades. [6]
Con este protocolo se puede calcular y garantizar los tiempos de retraso para un tamaño
máximo de paquete y un número de estaciones conectadas. Por ejemplo, la transmisión de un
paquete de 4-Kbytes es de 0.3 ms. Así, incluso cuando hubiese 30 estaciones conectadas y todas
ellas hicieran peticiones para enviar, el retraso de acceso es menor de 10 ms.
Evaluación : Esta red es adecuada para transmisión multimedia. Si se configura la red de
forma adecuada y se limita el tamaño del paquete se pueden asegurar que los retrasos de
transmisión estarán asegurados. Su alto ancho de banda también lo hacen adecuado para la
transmisión multimedia de calidad.
Enrique Hernández Orallo
Página 12
07/08/00
Transmisión de datos en Tiempo Real
3.6.- FDDI (Fiber Distributed Data Interface)
En principio la red FDDI es una Token-Ring rápida. Este ancho de banda alto permite una
comunicación multimedia. Además FDDI soporta una clase de tráfico síncrono, que permite
tráfico con un retraso limitado, configurable en tiempo de inicialización del anillo.[1]
Desafortunadamente, al configurar un retraso demasiado bajo reduce la utilización del
ancho de banda. Prácticamente, el límite de retraso está entre 5 y 50 ms.
Evaluación : FDDI soporta la transmisión multimedia aceptablemente bien, gracias a su
elevado ancho de banda, su clase de tráfico síncrono y el multicasting disponible.
3.7.- FDDI-II (Fiber Distributed Data Interface)
Para evitar los problemas del FDDI aparece FDDI-II que está basado en un protocolo
slotted-ring. Permite capacidades isócronas usando slots de tiempo pre-asignados a una tasa de
8-khz.
Evaluación : Esta red proporciona canales con retraso del orden de milisegundos. El
ancho de banda es suficiente y el multicasting está disponible.
3.8.- X-25
En Europa la mayoría de servicios que utilizan conmutación de paquetes utilizan como
red X-25, que permite la transferencia fiable de datos sobre enlaces de baja velocidad y
fiabilidad. Su control de flujo y mecanismo de recuperación de errores provoca retrasos
incontrolables.
Evaluación : X-25 no sirve para la transmisión multimedia.
3.9.- Frame Relay
Frame Relay fue desarrollado para superar las limitaciones de X-25 para un entorno de
transmisión de alta velocidad. Usa la trama LAP-D (Link Access Procedure Direct) con un
identificador de 19 bit para encaminamiento. Los paquetes están limitados a un máximo de 4 Kb.
El protocolo frame relay no proporciona control de errores y mecanismo de control de
flujo. Esto significa que por parte del protocolo no hay ningún mecanismo que afecte
negativamente la transferencia. Por otro lado, los conmutadores si que introducen un retraso que
depende de la carga, la velocidad de la línea y el tamaño de trama.
Frame Relay se puede utilizar de dos formas:
•
La mas frecuente como un protocolo simple sobre línea dedicadas. En este caso no se
introduce ningún tipo de retraso.
Enrique Hernández Orallo
Página 13
07/08/00
Transmisión de datos en Tiempo Real
•
Sobre redes conmutadas, en este caso el retraso vendrá dado por los conmutadores.
Además el direccionamiento está limitado a 10 bit. Por lo tanto no se espera que se
convierta en la red universal multimedia.
Evaluación : Frame Relay es un protocolo de nivel 2 que no añade retrasos. El protocolo
en si es adecuado para la transmisión en tiempo real, pero solo si se usa en líneas dedicadas ya
que en redes conmutadas el retraso no es determinista.
3.10.- RDSI (Red digital de servicios integrados)
La Red Digital de Servicios Integrados (RDSI) fue diseñada para soportar una gran
variedad de servicios, como datos, voz, fax o vídeo. Esta construido sobre canales síncronos de
64-kbps, que se pueden usar con tráfico CBO (continuous bit-stream oriented) o CBR (constant
bit-rate).
La única desventaja de esta red es su ancho de banda limitado. Para construir un ancho de
banda alto hay que utilizar varios canales, y estos canales pueden seguir distintas rutas por lo que
requieren una sincronización en el receptor.
Utilizando tráfico CBO el retraso es constante y pequeño. Pero en el caso de transmisión
de paquetes existe un retraso debido al limitado ancho de banda. Este dependerá del tamaño del
paquete.
Evaluación : En general RDSI es la única WAN ampliamente disponible en Europa que
soporta bien las transmisión multimedia. Se hecha en falta la posibilidad de multicast.
3.11.- ATM (Asynchronous Transfer Mode)
ATM aparece como la tecnología ganadora en un futuro distante.[2] ATM es una
arquitectura de red basada en células, que permite la multiplexación y conmutación de paquetes.
La ITU ha declarado ATM como la tecnología base para la futura red pública B-ISDN.
La red define tres niveles:
Nivel físico. Se han definido distintos medios de transmisión como fibra óptica a 155Mbps, o 100-Mbps FDDI para ATM de área local, además de otras opciones. En el futuro los
interfaces a ATM evolucionarán hasta 622 Mbps o incluso 2.4 Gbps.
Nivel ATM. El nivel ATM es un capa independiente para la conmutación y el
multiplexado de los paquetes. Se define la estructura de las células como contenedores de
información de 53 octetos ( 5 octetos para cabecera más 48 de datos). El encaminado se basa en
los identificadores de circuito virtual VCI (virtual circuit identifiers) y los identificadores de
camino virtual VPI (virtual path identifiers). Además ATM es una red orientada a la conexión.
Debido al pequeño tamaño de las células ATM, la alta velocidad de los enlaces, y la
velocidad de conmutación de los nodos, ATM proporciona una latencias mínimas.
Nivel de adaptación ATM (AAL). Este nivel esta diseñado como puente entre el nivel
ATM y de aplicación. La ITU define cuatro clases diferentes de servicio:
Enrique Hernández Orallo
Página 14
07/08/00
Transmisión de datos en Tiempo Real
Relación temporal entre
fuente y destino.
Tasa de transferencia
Modo de conexión
Tipo de AAL
Clase A
Clase B
Requerida
Constante
AAL 1
Clase C
Clase D
No requerida
Variable
Con conexión
AAL 2
AAL 3
Sin conexión
AAL 4
Para soportar estas cuatro clases de servicio se proponen cuatro tipos de niveles de
adaptación. Además se proponen otros dos tipos.
•
•
•
•
•
AAL 1 para la clase A emplea funciones de partición y composición para convertir el
tráfico CBO en células y viceversa.
AAL 2 para la clase B es difícil de implementar ya que tasa de transferencia variable
hace difícil la reserva de los recursos. O bien se reserva el ancho de banda pico o no
se podrá garantizar la máxima tasa.
AAL 3 y 4 implementan la clase C y D. Debido a que ATM está orientado a la
conexión, los servicios sin conexión necesitan ser proporcionados por servidores que
emulan esta servicio sobre ATM. La principal función de AAL 3 y 4 es la
segmentación y composición de grandes mensajes.
AAL 5 también proporciona servicios de clase C y D. Este tipo proporciona una
utilización más eficaz de los recursos de ATM. El problema es que como utiliza una
corrección de error más simple una célula corrupta se descarta directamente.
AAL 6. Su objetivo es la transmisión de paquetes multimedia especialmente vídeo
MPEG y MPEG-II
Calidad de servicio : En la petición de establecimiento de conexión se especifica la
calidad de servicio requerida, que contiene parámetros como ancho de banda, retraso y
fiabilidad.
Evaluación : El protocolo permite la transmisión de datos de forma determinista y tiene
un ancho de banda impresionante necesario para la transmisión de vídeo de alta calidad.[5] ATM
también proporciona comunicación multicast.
3.12.- Resumen de las características de las redes
La siguiente tabla es un resumen de las características de las distintas redes evaluadas:
Enrique Hernández Orallo
Página 15
07/08/00
Transmisión de datos en Tiempo Real
Red
Ethernet
Iso-Ethernet*
Token Ring
100Base-T
802.12
FDDI
FDDI-II*
X-25
Frame Relay
RDSI
ATM
Ancho
banda
(Mbps)
10
10+6
4/16
100
100
2 x 100
Nx6
<2
< 50
N x 0.064
25 – 155
Retraso transmisión
Aleatorio
Fijo < 1ms.
Configuración < 20ms.
Aleatorio
Configuración < 10ms.
Configuración
Fijo < 1ms.
Aleatorio
Aleatorio
Fijo < 10ms
Fijo < 10ms
Variación
del
Retraso
∞
0
∆
∞
∆
∆
0
∞
∞
0
∆
Broadcast
Soporte
CBO
Disponible
Si
No
Si
Si
Si
Si
Si
No
No
No
(SI)
No
Si
No
No
No
No
Si
No
No
Si
Si(AAL1)
Si
No
Si
Si
No
Si
No
Si
Si
Si
Si
* : Se refiere a los canales isócronos.
Fijo : El retraso es fijo para un canal.
Configuración : El retraso depende de la configuración de la red (tamaño de los paquetes,
número de estaciones, etc. ). Se da un valor para una red configurada para que pueda asegurar una
transmisión aceptable de información multimedia.
∞ = Red asíncrona sin control del retraso
∆ = Red síncrona con una variación del retraso entre 0 y un valor máximo ∆.
0 = Red isócrona.
De la comparativa realizada se saca la conclusión de que existen algunas redes que
prometen un buen soporte al tráfico multimedia, pero solo unos pocas están disponible en
realidad. ATM se configura como la red multimedia por excelencia tanto para WAN como LAN.
La diferenciación entre LAN y WAN es cada vez menor y de hecho el usuario requiere
servicios de red independientes de la organización física y lógica. De hecho las nuevas redes
como ATM asumen este concepto.
4.- Protocolos de red
4.1.- Introducción
En el punto anterior se han comparado la redes de transmisión, pero realmente las
comunicaciones entre emisor y receptor suelen involucrar varios tipos de redes.
Los protocolos de red proporcionan la funcionalidad de conectar distintos sistemas a
través de múltiples redes. Se examinan dos únicos protocolos que son IPv4 y IPv6. Su
conocimiento es útil debido a que son utilizados por el resto de protocolos de transporte. Se
estudia en más detalle el protocolo IPv6 por contemplar varios aspectos de la transmisión en
tiempo real.
4.2.- IPv4
Internet Protocol (IP) es un protocolo de red que fue introducido a principios de los 80.
Este protocolo está basado en la idea de transmisión de datagramas desde un origen a un destino,
posiblemente atravesando varias redes. IP está implementado en cada sistema final y en los
Enrique Hernández Orallo
Página 16
07/08/00
Transmisión de datos en Tiempo Real
routers que son dispositivos que proporcionan conexión entre redes. Se denomina IPv43 al
protocolo IP utilizado actualmente con TCP/IP.
El protocolo IP funciona de la siguiente forma. El nivel de transporte coge los mensajes y
los parte en datagramas de cómo máximo 64K bytes. Cada datagrama es transmitido a través de
la red, posiblemente siendo fragmentado en unidades más pequeñas mientras viaja. Cuando todas
las piezas finalmente llegan al destino, son ensambladas por el nivel de transporte para formar el
mensaje original.
IP fue diseñado como un sistema de transporte con la filosofía best-effort delivery
(“envíese como pueda”), en el que no se asegura ni la ruta ni el tiempo de transmisión ni incluso
que lleguen los datagramas. En general se depende totalmente de la configuración de la red, los
routers y de la carga de la red.
Por esto, IP no es adecuado para la transmisión en tiempo real. En general existen los
siguiente graves limitaciones:
•
•
•
•
No existe forma de especificar prioridades ni control de congestión.
Cada datagrama puede ir por una ruta
Los datagramas pueden llegar en desorden
Los datagramas pueden llegar fragmentados
El protocolo TCP no proporciona un mejor servicio ya que enmascara estos problemas
por medio de una corrección de errores y un control de la congestión que produce unos tiempos
de transmisión indeterminados.
Existe otra limitación de este protocolo es que el direccionamiento está limitado a 4 bytes
y actualmente se está llegando al límite. El tamaño máximo del datagrama es de 64kb.
4.3.- IPv6 (Internet Protocol version 6)
4.3.1.- Introducción
Mientras la red internet fue aumentando se vio hace tiempo que el protocolo IP era
inadecuado para cumplir los requerimientos funcionales y de prestaciones actualmente
demandados. Pero quizá la mayor motivación de cambio fue la actual limitación de direcciones
IP de 32 bits que se están prácticamente terminando.[17]
En respuesta a estas necesidades el IETF hizo una llamada para propuestas para un nuevo
protocolo en Julio de 1992. Después de una serie de propuestas en diciembre de 1995 se
presentaron los primeros RFC sobre IPv6.
El diseño de este nuevo protocolo ha tenido en cuenta las siguientes consideraciones:
•
3
Direccionamiento : IPv6 utiliza direcciones de 128-bit. Este es un valor que parece
lo suficientemente amplio incluso para incluir direcciones Ethernet internamente.
Tienen en los primero 4 bits de la cabecera del datagrama el número 4.
Enrique Hernández Orallo
Página 17
07/08/00
Transmisión de datos en Tiempo Real
•
•
•
•
Prestaciones : IPv6 se ha diseñado para que los routers puedan hacer su trabajo lo
más rápido posible. En este sentido el tamaño de la cabecera es fijo y con un número
de campo menor que IPv4 con lo que simplifica su tratamiento y la fragmentación de
paquetes no está permitida en los routers.
Servicio de red : Es importante soportar servicios en tiempo real y especificar niveles
de prioridad para determinar estrategias de eliminación en el caso de congestión. IPv6
permite el etiquetado de paquetes que pertenezcan a un flujo particular.
Flexibilidad en el direccionamiento : IPv6 incluye el concepto de dirección anycast,
en el que el paquete se entrega a solo uno de los conjuntos de nodos. Además se
incluyen esquemas de direccionamiento multicast.
Seguridad : IPv6 incluye el soporte para la autentificación y la privacidad.
4.3.2.- Formato de los paquetes
Se denomina paquete al PDU (protocol data unit) del IPv64. Este paquete está formado
por una cabecera fija de 40 bytes y opcionalmente por unas cabeceras de extensión. La cabecera
fija es la siguiente:
0
Versión
4
8
Prioridad
Longitud de pago
16
Etiqueta de flujo
Próxima cabecera
24
Limite de saltos
Dirección origen
Dirección destino
donde los campos son los siguientes:
Campo
Versión
Prioridad
Etiqueta de flujo
Longitud de pago
Próxima cabecera
Límite de saltos
Dirección origen
Dirección destino
Descripción
Contiene el valor 6
Indica a los routers el nivel de servicio requerido por el
paquete. Se distingue dos tipos de tráfico: con control de
congestión y sin control de congestión.
Se asigna un número de identificación para cada
comunicación entre ordenadores. Los routers usan esta
identificación para almacenar información relevante
asociada a la conexión.
Longitud del paquete menos la cabecera
Tipo de cabecera después de la cabecera IPv6.
Se decrementa en uno por cada nodo por el que pasa el
paquete. Cuando el valor llega a cero se elimina el
paquete.
Dirección desde donde se envía el mensaje
Dirección de destino. Esta pueda que no se la dirección
final si existe una cabecera de enrutamiento.
Tamaño
4
4
16
16
8
8
128
128
Se han definido además las siguientes cabeceras de extensión:
4
En IPv6 se ha optado por denominar paquete al PDU a diferencia del término datagrama usado en IPv4
Enrique Hernández Orallo
Página 18
07/08/00
Transmisión de datos en Tiempo Real
Cabecera
Opciones de salto
Descripción
Define opciones especiales que requiera un
procesamiento por salto.
Opciones de destino
Contiene información opcional a examinar por el nodo
de destino.
Encaminamiento
Proporciona encaminamiento extendido, similar al
encaminamiento IPv4.
Fragmentación
Contiene información sobre la fragmentación y
recomposición
Autentificación
Proporciona integridad a los paquetes y autentificación.
Seguridad encapsulada Proporciona privacidad.
4.3.3.- Gestión de las prioridades
Como parte de la cabecera existe un campo con la prioridades de los paquetes para
indicar el tipo de servicio. Existen dos grupos uno con control de la congestión y otro sin él que
se tratan de forma independiente.
El tráfico con control de congestión se refiere al tráfico en el que la fuente puede
soportar o gestionar una congestión del tráfico. Un ejemplo de esto es el protocolo TCP que
regula el flujo en función de la congestión de la red. Se definen las siguientes categorías de
menor a mayor prioridad.
Nivel
0
1
2
3
4
5
6
7
Tipo de tráfico
No se especifica prioridad
Tráfico de relleno (noticias)
Transferencia de datos desatendida (e-mail)
Reservado
Transferencia de datos atendida (FTP, HTTP, etc. )
Reservado
Tráfico interactivo (conexión on-line de terminales)
Tráfico de control (routing, control de red, SNMP)
El trafico sin control de congestión es un tráfico con tasa de transmisión y retraso
constante, o por lo menos es deseable. Ejemplo de este tráfico es vídeo en tiempo real y audio.
Se define ocho niveles de prioridad en el que 8 es la menor prioridad y 15 la de mayor prioridad.
4.3.4.- Gestión de la fragmentación
Los routers IPv6 no fragmentan los paquetes a diferencia que en IPv4. Cuando IPv6
envía su mensaje de conexión a un sistema remoto, se graba el máximo tamaño de paquete de
cada subred en la ruta. Cuando la respuesta a la conexión llega, estableciendo la conexión, el
origen sabe cual es el tamaño mayor de paquete que puede enviar. Es en el origen donde se
fragmenta en paquetes para evitar la posible partición.
Dado que los paquetes no se fragmentan existe menos probabilidad de perdida de
paquetes y de reenvío de paquetes.
Enrique Hernández Orallo
Página 19
07/08/00
Transmisión de datos en Tiempo Real
4.3.5.- Control de flujos
IPv6 define un flujo como una secuencia de paquetes enviados desde una fuente
particular a un destino particular y que el origen desea un tratamiento especial por los routers.
Desde el punto de vista de la fuente un flujo es una secuencia de paquetes que tienen los
mismo requerimientos de transferencia. Una aplicación puede generar un único flujo o varios.
Desde el punto de vista del router un flujo es una secuencia de paquetes que comparten una serie
de atributos que afectan como son tratados por él.
En IPv6 estos atributos son definidos antes del comienzo del flujo y asociados a la
etiqueta de flujo de la cabecera. En este caso el router debe asociar a cada flujo sus
características por medio de la etiqueta.
Se aplican las siguientes reglas a la etiqueta de flujo:
•
•
•
Los nodos o routers que no soporten este campo deben poner a cero este campo o
ignorarlo según el caso.
Todos los paquetes de un mismo origen con una misma etiqueta deben tener la misma
dirección de destino y origen, prioridad, opciones de salto y de encaminamiento (si
las tienen).
El origen asigna una etiqueta de flujo al flujo.
4.3.6.- Direcciones IPv6
Las direcciones de IPv6 son de 128 bits. La forma más aceptada de representar las
direcciones IPv6 es x:x:x:x:x:x:x:x, donde cada x es un valor hexadecimal de una porción de 16
bit de la dirección. Se permiten tres tipos de direcciones:
•
•
•
Unicast : Identifica un único destino. Actualmente se han partido las direcciones en
distintos campos pero sin una longitud fija. La direcciones IPv4 se encapsulan en
IPv6 poniendo los 96 bits primeros a cero.
Anycast : Una dirección anycast permite al origen especificar que quiere contactar
con cualquier nodo de un grupo de nodos por medio de una única dirección. Una
utilidad puede ser para llegar a un solo router de varios conectados a una misma red
local.
Multicast : La dirección multicast permite definir grupos de 112 bits. El resto
identifica el tipo de multicast, si va a se local, de organización o global.
Por medio de la cabecera de encaminamiento se puede indicar una ruta parcial o completa
por donde irá el paquete. En ese sentido cuando se llegue a la dirección de destino indicada en la
cabecera se leerá esta cabecera y se enviará a la próxima dirección de la lista.
4.3.7.- Seguridad
IPv6 establece seguridad en el propio protocolo, con lo que una organización puede
asegurar que tendrá seguridad no solo en las aplicaciones que tienen mecanismos de seguridad
sino para todas las aplicaciones.
Enrique Hernández Orallo
Página 20
07/08/00
Transmisión de datos en Tiempo Real
La seguridad en IPv6 incluye tanto autentificación como privacidad.
•
•
El mecanismo de autentificación asegura que el paquete recibido es el mismo que el
enviado por el emisor. Se asegura que el paquete no ha sido alterado durante la
transmisión
La privacidad imposibilita que el contenido del paquete se pueda examinar. Para ello
se emplean distintas técnicas de cifrado y claves publicas.
El paquete puede a su vez ser autentificado y encriptado.
5.- Protocolos RPSI
5.1.- Introducción
En el punto anterior se han visto las redes de transmisión existentes, pero realmente se
requiere un software de comunicaciones que proporcione a las aplicaciones los servicios
necesarios para la transmisión multimedia o en tiempo real.
Los servicios de comunicaciones para multimedia en general tienen dos requerimientos :
la especificación y aseguramiento de la calidad de servicio y el soporte para la comunicación
para grupos. En general se habla de Servicios Integrados sobre Internetworks (intserv)5.
La comunicación de audio o vídeo requiere la provisión de cierto nivel de calidad (QoS),
garantizándolo durante el tiempo de la transmisión. Este nivel de calidad lo tienen que establecer
las aplicaciones a la hora de comunicarse. Por lo tanto se tiene que proveer mecanismos para el :
•
•
•
establecimiento y corte de los canales,
negociación de los niveles de calidad entre emisor – receptor, sistemas intermedios y
control de red, y
control del nivel de calidad acordado.
En general el medio (físico o virtual) por el que se realizan estas comunicaciones se suele
denominar canal. Estos canales son definidos con unos parámetros típicos como pueden ser el
ancho de banda, retraso, variación del retraso (delay jitter) y fiabilidad.
La comunicación multimedia se suele realizar para grupos de más de dos usuarios. Los
grupos pueden
•
•
•
5
tener miembros estáticos o dinámicos durante su vida,
tener control de acceso de los miembros centralizado (por el emisor) o distribuido
(por el receptor), y
consistir en miembros con características y requerimientos homogéneos o
heterogéneos.
Existe un grupo de trabajo en el IETF sobre el tema; el Integrated Services Working Group.
Enrique Hernández Orallo
Página 21
07/08/00
Transmisión de datos en Tiempo Real
En general proporcionar este tipo de servicios es más complejo que implementar una pila
de protocolos TCP o OSI. En cambio cuando se ha establecido la comunicación los
requerimientos son menores, en conceptos como tratamiento de errores y control de flujo.
La implementación de estos sistemas incluye el desarrollo de nuevos routers que
soporten este tipo de transmisión. Cada router solo debe admitir nuevas comunicaciones si
permiten obtener la calidad requerida.
Las redes basadas en paquetes como IP tienen como objetivo maximizar la utilización de
la red por medio de la multiplexación de los canales. Además pueden proporcionar
comunicación multipunto, y proporcionar robustez adaptándose a la dinámica de la red. Sin
embargo este funcionamiento hace que el comportamiento sea difícilmente predecible. En
cambio las redes basadas en conexión proporcionan un servicio garantizado, pero sin embargo,
hacen un uso no eficiente de los recursos de la red, no se adaptan a los fallos de la red y no
soportan comunicaciones multipunto.
Se puede hablar de una Red de paquetes de servicios integrados (RPSI) en la que se
mezclan estos dos paradigmas de comunicación; combinando la comunicación multipunto y
multiplexada y robustez de la red de paquetes conmutadas y la garantía de servicio del modelo
de conexión.
El desarrollo de este tipo de redes requiere distintos componentes, que incluyen :
1. Especificación del flujo : Una especificación del flujo definiendo el tipo del tráfico
,los requerimientos del receptor y la calidad de servicio que se va a proporcionar al
flujo
2. Encaminamiento : La red debe decidir como transportar los paquetes desde la fuente
al destino. Por ello se requiere un protocolo de encaminamiento que soporte calidad
de servicio y rutas unicast y multicast,
3. Reserva de recursos : Para mantener un flujo con una calidad de servicio se requiere
un protocolo de reserva para crear y mantener las reservas de recursos, como el
ancho de banda o número de buffers.
4. Control de admisión : Un algoritmo de control de admisión para mantener la carga
de la red a un determinado nivel,
5. Planificador de paquetes : Un algoritmo de servicio de paquetes para planificar la
transmisión de los paquetes con el objetivo de mantener el servicio garantizado para
cada flujo.
Se ha denominado protocolo de RPSI a los diseñados con el objetivo de servir como
soporte a una red de servicios integrados. Los protocolos que se van a ver implementan
solamente algunos de los componentes vistos, dando la posibilidad de integrarlos con otros
componentes.
Enrique Hernández Orallo
Página 22
07/08/00
Transmisión de datos en Tiempo Real
5.2.- RSVP (Resource ReSerVation Protocol)
5.2.1.- Introducción
RSVP se ha diseñado [19][29] para permitir a los emisores, receptores y routers de las
sesiones de comunicación (tanto multicast como unicast) comunicarse con el resto para
establecer una ruta que pueda soportar la calidad de servicio requerida. La calidad de servicio
viene especificado en un flowspec.
RSVP identifica una sesión por medio de una dirección de destino, un tipo de protocolo
de transporte y un número de puerto de destino. RSVP no es un protocolo de encaminamiento, se
usa meramente para reservar recursos a través de la ruta que se establezca por cualquiera de los
protocolos de niveles inferiores.
Existe un draft del protocolo del IETF[7]. Además existe un proyecto para una nueva
versión del protocolo RSVP2 de la University of Southern California/Information Sciences
Institute.[8] También existe varias implementaciones[44] de libre distribución para Linux,
FreeBSD, etc
Aunque RSVP en principio sólo era un protocolo de reserva de recursos se describe las
especificaciones de flujos utilizada en una implementación[19] de este protocolo así como su
control de admisión.
5.2.2.- Objetivos de diseño
RSVP se ha diseñado con los siguientes objetivos:
1. Proporcionar la posibilidad de que receptores heterogéneos puedan hacer reservas
de acuerdo a sus necesidades. No se debe asumir que todos los receptores tienen las
mismas capacidades ni que requieran la misma calidades de servicio.
2. Debe adaptarse a las variaciones de miembros en grupo multicast. La conexión o
desconexión de los miembros de un grupo multicast debe ser dinámica.
3. Permitir a los usuarios especificar sus necesidades a nivel de aplicación para que los
recursos reservados para un grupo multicast puedan reflejar con precisión los recursos
necesitados por el grupo.
4. Permitir a los receptores seleccionar entre varios canales. Un receptor debería ser
capaz de controlar que paquetes son llevado en sus recursos reservados, no solo los
que se visualicen en su pantalla.
5. Debe adaptarse a los cambios en los rutas unicast y multicast. RSVP no es un
algoritmo de encaminamiento, utiliza el nivel de red para estos propósitos pero si
debe mantener un estado de las rutas.
6. Controlar la sobrecarga que produce el protocolo en la red para que no crezca
linearmente o peor con el número de participantes.
7. Hacer el diseño modular para acomodar distintas tecnologías.
Enrique Hernández Orallo
Página 23
07/08/00
Transmisión de datos en Tiempo Real
5.2.3.- Principios de diseño
Para obtener los objetivos vistos en el punto anterior el diseño de RSVP se basa en seis
principios básicos:
1. Reserva iniciada por el receptor. Los receptores escogen el nivel de servicio
requerido y son responsables de iniciar y mantener la reserva activa mientras quieran
recibir datos. Esto es así porque el receptor es quien conoce sus limitaciones y la
calidad de servicio que recibe. Además esto permite la gestión de peticiones
heterogéneas.
2. Filtro de paquetes. La reserva de recursos en un router asigna ciertas recursos a la
entidad que hace la reserva, pero no determina que paquetes pueden usar estos
recursos. Hay una función separada, llamado filtro de paquetes, que selecciona los
paquetes que pueden usar estos recursos. Este filtro puede ser estático o dinámico y
permite establecer varios modelos de reserva.
3. Proporcionar varios estilos de reserva. Por medio del filtro de paquetes se pueden
definir diferentes modelos de reserva. Actualmente existen tres estilos : libre, filtro
fijo y filtro dinámico.
4. Mantener un “soft-state” de la red. Durante una comunicación larga es posible que
nuevos miembros se unan al grupo mientras otros lo dejen, y la rutas pueden cambiar
debido a cambios en la red. Por esto RSVP debe mantener un estado de la red. Esta
información se mantiene por medio de mensajes que periódicamente se envían para
refrescar el estado. RSVP distingue dos clases de información en cada router, el
estado de la ruta y el estado de la reserva. Cada fuente envía periódicamente un
mensaje Path y cada receptor envía periódicamente un mensaje Resv.
5. Control de sobrecarga del protocolo. La sobrecarga de RSVP se determina por tres
factores: el número de mensajes RSVP enviados, el tamaño de estos mensajes y las
frecuencias de refresco de los mensajes de ruta y reserva. Para reducir la sobrecarga
RSVP funde los dos mensajes mientras atraviesan la red.
6. Modularidad. RSVP tiene interfaz con otros tres componentes en la arquitectura : (1)
el flowspec que se maneja a nivel de aplicación o sesión; (2) el protocolo de
encaminamiento de red, que lleva los mensajes hasta los receptores; (3) el control de
admisión en red, que realiza las decisiones basado en el flowspec que está el los
mensajes de reserva.
5.2.4.- Clases de calidad de servicio
IETF ha considerado varias clases de QoS aunque sólo dos han sido formalmente
especificados para RSVP: Servicio Garantizado (Guaranteed Service) [26] y Servicio de carga
controlada (Controlled-Load Service )[27]
5.2.4.1.- Servicio garantizado
Esta calidad de servicio está destinada para aplicaciones con requerimientos exigentes de
tiempo real. Esta calidad asegura un ancho de banda, un límite en el retraso y ninguna perdida en
las colas.
Enrique Hernández Orallo
Página 24
07/08/00
Transmisión de datos en Tiempo Real
Como introducción, un flujo es descrito usando un esquema “token bucket6” y dada esta
descripción, cualquier elemento de la red (un router, una subred, etc.) calcula varios parámetros
describiendo como va a manejar los datos del flujo. Combinando los parámetros de los distintos
elementos que recorre el flujo es posible calcular el retraso máximo que se producirá en el flujo.
Cada router caracteriza el servicio garantizado para un flujo determinado, asignando un
ancho de banda, R, y un espacio de memoria (buffer space), B, que representa los recursos que el
flujo puede consumir. Esto representa que existe un ancho de banda R entre emisor y receptor.
Así para un flujo que siga las características de ”token bucket”[39] con un cubo de capacidad b y
tasa r se puede calcular el límite del retraso como b/R siempre que R sea mayor r. Para permitir
desviaciones para este modelo perfecto se añaden dos términos de error C y D; con lo que el
límite del retraso se convierte en b/R +C/R + D. El termino C es el error dependiente de la tasa.
Representa el retraso que un datagrama en el flujo puede experimentar debido a la tasa de los
parámetros en el flujo. El termino de error D es el error independiente de la tasa y representa el
peor caso de variación de tiempo de tránsito a través del router.
Sin embargo se impone una tasa pico del flujo p, que reduce los límites del retraso.
Además se tienen que tener en cuenta los efectos de la partición en paquetes en el flujo
considerando el tamaño máximo del paquete, M. Esto nos permite disponer de un limite más
preciso para el retraso:
(b − M )( p − R ) ( M + Ctot )
+
+ Dtot
( caso p > R ≥ r )
(1)
R( p − r )
R
( M + Ctot )
Qdelay =
+ Dtot
(caso R ≥ p ≥ r )
(2)
R
donde Ctot y Dtot representan el sumatorio de los términos de error C y D de cada router de la
ruta.
Cada router necesita ser informado de las características del tráfico, Tspec, y del flujo
con las características de las reservas realizadas, Rspec. Además necesita los términos Csum y
Dsum que representan la suma de los términos de error C y D, de cada router desde el origen del
mensaje. Los parámetros Tspec y Rspec son los siguientes:
Qdelay =
Parámetro Tspec
p
b
r
m
M
Parámetros Rspec
R
S
Descripción
Tasa pico del flujo
(bucket depth) Tamaño del cubo
(token bucket rate)Tasa de transmisión del cubo
Tamaño mínimo de un paquete
Tamaño máximo de paquete
Unidad
Bytes/s
Bytes
Bytes/s
Bytes
Bytes
Ancho de banda
Bytes/s
Slack term. Diferencia entre el retraso deseado y el µs
obtenido usando una reserva de ancho de banda R.
6
“Token Bucket es una forma particular de especificación del flujo que consiste en una tasa de tokens r y un tamaño
de cubo b. Esencialmente, el parámetro r especifica la tasa de datos sostenible continuamente, mientras que b
especifica en cuanto se puede exceder esta tasa para cortos periodos de tiempo. Más específicamente, el tráfico debe
obedecer la regla de que para cualquier periodo de tiempo, la cantidad de datos enviados no puede ser superior a
rT+b, donde T es la longitud del periodo de tiempo ”. Ver descripción en el Tanenbaum Pags380-386.
Enrique Hernández Orallo
Página 25
07/08/00
Transmisión de datos en Tiempo Real
Para utilizar este esquema los routers tienen que aproximarse al modelo de flujo. Existen
varios algoritmos de planificación como el WFQ (Weighted Fair Queueing) [34], JitterEDD[36] y Virtual Clock [35].
5.2.4.2.- Servicio de carga controlada
Este clase de servicio no proporciona garantía firme de que se cumplan unos parámetros.
Se puede indicar un Tspec para la calidad servicio requerida, aunque no es necesario incluir el
parámetro de tasa pico p. Si el flujo es aceptado el router intenta ofrecer un servicio equivalente
como en un flujo “best-effort” en una red ligeramente cargada. La diferencia es que este flujo no
se deteriora aunque aumente la carga de la red.
5.2.5.- Funcionamiento de RSVP
5.2.5.1.- Mensajes de establecimiento de ruta
La siguiente figura muestra un ejemplo de una sesión multicast que involucra un emisor,
S1, y tres receptores; RCV1-RCV3;
Upstream
Downstream
Resv
ResvTear
PathErr
S1
R1
RCV1
R1
R1
Path
PathTear
ResvErr
ResvConf
R1
RCV2
RCV3
Figura 1 : Dirección de los mensaje RSVP
Los mensajes primarios usados por RSVP son el mensaje Path, que tiene su origen en el
emisor, y el mensaje Resv que tiene su origen en el receptor:
•
•
Mensaje Path : Su objetivo es primero instalar un estado del encaminamiento
inverso a través de la ruta, y segundo proporcionar a los receptores información sobre
las características del tráfico a enviar y de la ruta para que se puedan hacer las
peticiones de reserva adecuadas.
Mensaje Resv : Realizan las peticiones de reserva a los routers a lo largo del árbol
de distribución entre receptores y emisores.
Los mensajes se pueden transportar dentro de datagramas IP usando el protocolo número
46 (en otros sistema se tendrá que utilizar UDP)
Enrique Hernández Orallo
Página 26
07/08/00
Transmisión de datos en Tiempo Real
Cada mensaje Path incluye la siguiente información:
Path message
Phop
Sender Template
Sender Tspec
Adspec
Descripción
Dirección del último nodo RSVP capaz de enviar este mensaje
Path
Contiene la dirección IP del emisor y opcionalmente el puerto.
Define las características del tráfico
Opcional. Contiene información que es actualizada por cada
router de la ruta. Contiene la información OPWA (One Pass
With Advertising)
Cada receptor debe primero unirse a grupo multicast para empezar a recibir los mensajes
Path. Esta gestión de los grupos multicast está fuera del ámbito del protocolo RSVP.
5.2.5.2.- Proceso y propagación de los mensajes Path
Cada router del árbol de distribución intercepta los mensajes Path y chequea su validez.
Si se detecta un error el router enviará un mensaje PathErr para informar al emisor que no
puede realizar ninguna acción apropiada. Asumiendo que el mensaje es válido el router hace lo
siguiente:
•
•
Actualiza el estado de la entrada de la ruta para el emisor identificado en el Sender
Template. Si no existe la ruta la crea. El estado de la ruta incluye Sender
Tspec, dirección, Phop del anterior router y opcionalmente el Adspec. La
dirección Phop es necesaria para encaminar los mensajes Resv en el sentido
contrario.
Actualiza los contadores de limpieza de rutas a su valor inicial.
RSVP incorpora un protocolo de mensajes con refresco periódico para mantener una
estado de los routeres intermedios para proporcionar fiabilidad y seguridad. Para ello, cada
entrada en el router tiene un contador asociado que cuando llega a cero se elimina la conexión.
Para que esto no ocurra las rutas activas tienen que recibir un refresco por medio del mensaje
Path a intervalos regulares. Este periodo debe ser bastante menor que el tiempo de los
contadores de limpieza para que no produzcan desconexiones innecesarias.
Aparte de la eliminación de la rutas de forma automática, RSVP incluye el mensaje
PathTear para eliminar la ruta de forma activa.
5.2.5.3.- Objeto ADSPEC
El objeto Adspec se puede incluir en los mensajes Path para enviar a los receptores las
características de la ruta de comunicación establecida. Este objeto consiste en una cabecera de
mensaje, un fragmento con los parámetros generales por defecto (Default General Parameters),
y al menos uno de los dos fragmentos del Servicio Garantizado o Servicio de carga controlado:
Enrique Hernández Orallo
Página 27
07/08/00
Transmisión de datos en Tiempo Real
Parámetros generales por defecto
Latencia mínima de la ruta
Ancho de banda de la ruta
Global bit break
Contador de salto IS
PathMTU
Parámetros de servicio garantizado
Ctot
Dtot
CSum
DSum
Break bit
Parámetros generales
Parámetros de servicio controlado
Break bit
Parámetros generales
Descripción
Suma individual de las latencias de los enlaces.
El mínimo de los ancho de banda de los enlaces.
Este bit lo pone a uno el emisor. Se pone a cero en el
caso de que el paquete pase por un router que no
soporte RSVP para indicar que la información
contenida puede no ser válida.
Se incrementa en uno por cada router RSVP.
Path maximum transmission unit. ( es el mínimo de
las MTU’s de los enlace individuales de la ruta).
Valor total del parámetro C de emisor a receptor
Valor total del parámetro D de emisor a receptor
Suma compuesta del valor C hasta el anterior router.
Suma compuesta del valor D hasta el anterior router
Mismo funcionamiento que Global bit break.
Estos parámetros son opcionales pero si se incluyen
sustituyen los valores de los por defecto. Puede ser
utilizado por los routers que tengan unos
requerimientos específicos.
Equivalente al anterior
Equivalente al anterior
Este paquete no puede ser nunca fragmentado, por lo tanto el valor de M de una petición
de reserva no puede ser mayor que PathMTU. Toda esta información será actualizada por cada
router RSVP a lo largo de la ruta.
5.2.5.4.- Haciendo reservas usando OPWA
OPWA se refiere al modelo de reserva en el caso en que el emisor incluya en el mensaje
Path información Adspec. Si el emisor omite esta información el modelo de reserva se llama
de “Una pasada” (One pass) y en este caso no hay forma sencilla por parte del receptor de
determinar el tipo de servicio obtenido.
Cuando el receptor recibe un mensaje Path extrae los siguientes parámetros del
Sender Tspec: r, b, p, m. Además también extrae del objeto Adspec los siguientes
parámetros : latencia mínima de la ruta, Ctot, Dtot, PathMTU y ancho de banda de la ruta.
El límite requerido para el retraso de cola, Qdelreq se calcula restando la latencia mínima
de la ruta, del valor del retraso de emisor a receptor requerido por la aplicación receptora. El
receptor realizará un chequeo inicial evaluando la ecuación 2 para R igual a la tasa pico p. Si el
resultado es mayor o igual que Qdelreq se utilizará esta formula para calcular el mínimo valor de R
necesario para satisfacer Qdelreq; sino se utilizará la ecuación 1 para este propósito. Este mínimo
valor de R se obtiene insertando Qdelreq en la ecuación 1 o 2 con los valores determinados de Ctot,
Dtot ,r, b, p, M. Si el valor R excede el ancho de banda obtenido del Adspec recibido se
reducirá. El receptor entonces puede crear una especificación de la reserva, Rspec, que contiene
el valor R de ancho de banda que se reservará en cada router y un término slack que será
inicialmente cero. Rspec forma parte del mensaje Resv cuyos parámetros son los siguientes:
Enrique Hernández Orallo
Página 28
07/08/00
Transmisión de datos en Tiempo Real
Resv message
Estilo de reserva
FilterSpec
Flowspec
ResvConf
Descripción
Indica el estilo de reserva a utilizar. Puede ser FF, SE o WF.
Especificación de filtro para identificar a los emisores.
Se compone del Rspec y la especificación de tráfico, Tspec.
Opcionalmente se envía un objeto de confirmación conteniendo
la dirección IP del receptor.
Este mensaje se envía de vuelta por la ruta que ha recorrido. Por cada router que pasa de
vuelta, los mensajes se pueden fusionar con otros mensajes Resv con el mismo interfaz, de
acuerdo a una serie de reglas que dependen del estilo de reserva, obteniendo un nuevo
Flowspec y FilterSpec. Cada router realiza además las siguientes acciones :
•
•
•
El Flowspec se pasa al módulo de control del tráfico que aplica el control de
admisión para determinar si la reserva se acepta.
Si la reserva es denegada, se envía un mensaje ResvErr.
Si la reserva es aceptada, el estado de las reservas se actualiza de acuerdo con los
parámetros FilterSpec y FlowSpec. La reserva puede ser mezclada con otras
reservas de acuerdo con el estilo de reserva, y con esto se creará un nuevo mensaje
Resv.
5.2.5.5.- Término slack
Cuando el receptor genera un Rspec en el mensaje Rserv se incluye un termino slack,
S(ms) que inicialmente es cero. S representa la cantidad por la que el límite del retraso estará por
debajo del retraso requerido por la aplicación, asumiendo que cada router de la ruta reserva un
ancho de banda R. Este término permite una mayor flexibilidad a los router al hacer sus reservas
locales.
Cualquier router que use el termino S para reducir su nivel de reserva debe seguir las
reglas en la ecuación 3 para asegurar que el límite del retraso de emisor a receptor se satisface.
Sout +
Ctot i
b
b C tot i
+
≤ S in +
+
Rout Rout
Rin Rin
r ≤ Rout ≤ Rin
(3)
donde Ctot i es la suma acumulativa de los términos de error, C para todos los routers hasta el
emisor e incluyendo el actual elemento i . (Rin, Sin) es la petición de reserva recibida por el
router, i. (Rout, Sout) es la petición de reserva modificada unicast del anterior router en dirección
al emisor.
En otras palabras este elemento consume Sin- Sout del término slack y puede usarla para
reducir su nivel de reserva asegurando que se cumple la ecuación 3.
5.2.6.- Modelos de reserva de recursos
Como se vio en los objetivo de diseño, RSVP modela una reserva por medio de dos
componentes, una asignación de recursos y un filtro de paquetes. La asignación de recursos
especifica que cantidad de recursos son reservados mientras el filtro de paquete selecciona que
paquetes pueden usar los recursos. Esta distinción y la posibilidad de cambiar el filtro de
Enrique Hernández Orallo
Página 29
07/08/00
Transmisión de datos en Tiempo Real
paquetes dinámicamente permite a RSVP ofrecer varios estilos de reserva. Un estilo de reserva
captura los requerimientos de comunicaciones del nivel de aplicación. Por ahora se han definido
tres modelos de reserva:
•
•
•
Libre (Wildcard): Este modo indica que cualquier paquete con destino al grupo
multicast asociado puede utilizar los recursos reservados. Esto permite hacer una
única asignación de recursos a través de todas las rutas de distribución del grupo.
Filtro Fijo (Fixed Filter): Este modo indica que mientras dure la conexión el receptor
solo recibirá paquetes de las fuentes indicadas en la petición de reserva original.
Filtro dinámico (Dynamic Filter): Se permite durante la conexión modificar la
función de filtro. Esto permite la posibilidad de dinámicamente seleccionar un canal
entre las distintas fuentes. Esto requiere que se asignen los recursos suficientes para
manejar el peor caso que es cuando todos los receptores pidan de diferentes fuentes.
5.2.7.- Tipos de encaminamiento para RSVP
Aunque se ha visto que RSVP no es un protocolo de encaminamiento si que hay cuatro
problemas que se deben tratar con el protocolo de encaminamiento :
1. Encontrar una ruta que soporte la reserva de recursos.
2. Encontrar una ruta que tenga la suficiente capacidad disponible para un nuevo flujo.
Se puede optar por dos formas diferentes de encontrar esta ruta. Una podría ser la de
modificar los protocolos de encaminamiento y gestionarlos de acuerdo a un
mecanismo de control del tráfico. Alternativamente, el protocolo de encaminamiento
podría se rediseñado para proporcionar múltiples rutas alternativas, y en la reserva
podría intentarlo en cada una de las rutas.
3. Adaptarse a una fallo de ruta. Cuando un nodo falla, el encaminamiento adaptativo
encontrará un ruta alternativa. El refresco periódico de RSVP automáticamente hará
una reserva en la nueva ruta. Pero, la nueva reserva puede fallar porque no haya
suficiente capacidad disponible en la nueva ruta. Esto es un problema de
dimensionamiento y calidad de la red, que nop puede ser solucionado por los
protocolos de encaminamiento o reserva.
4. Adaptarse a un cambio de ruta (sin fallo) . Los cambios de ruta pueden ocurrir sin que
se produzcan fallos. Aunque RSVP podría usar las misma técnicas de reparación que
las descritas en el punto 3, esta solución podría producir una merma en la calidad de
servicio. Podría ocurrir que si el control de admisión fallo en la nueva ruta, el usuario
verá una degradación del servicio innecesaria y caprichosa, ya que la ruta original
está todavía funcional. Para evitar este problema, se sugiere un mecanismo de fijado
de rutas (route pinning) en el que las rutas se mantienen fijas mientras sean viables.
RSVP está actualmente diseñado para trabajar con cualquier protocolo de
encaminamiento disponible sin modificación. Esto puede provocar que se produzcan ciertas
degradaciones en la calidad de servicio al no cumplirse los anteriores requerimiento. Se espera
que las futuras generaciones de protocolos de encaminamiento incluirán mecanismo que en
conjunción con RSVP resolverán los problemas enumerados.
Enrique Hernández Orallo
Página 30
07/08/00
Transmisión de datos en Tiempo Real
5.2.8.- Conclusiones
RSVP es un protocolo de reserva de recursos. Soluciona de forma eficiente la mayoría de
la problemática presentada. Con la introducción de los flowspec descritos y el control de
admisión en los routers se puede convertir en una solución completa para transmisión
multimedia si se utiliza como nivel de red IPv6.
5.3.- Tenet suite
5.3.1.- Introducción
El Tenet Group de la University of California at Berkeley a diseñado, simulado e
implementado un conjunto de protocolos para soportar canales en tiempo real.[3][9] Intenta ser
una solución completa y está más orientado a la investigación y solución de los problemas
existentes en este tipo de redes. Los protocolos Tenet están diseñados para coexistir con los
protocolos Internet.
Los canales en tiempo real son establecidos en la fase de conexión que precede a la
transferencia de datos. Un mensaje es enviado desde el origen del canal y viaja al destino,
provocando que en cada nodo se ejecuten unos test de admisión para comprobar si se puede
obtener la calidad de servicio requerida. Cuando llega el mensaje al destino este envía un
mensaje de aceptación de canal que llegará al origen estableciéndose el canal.
El grupo tenet tiene también modelos matemáticos y simulaciones de los protocolos
utilizados [10][11][12][15].
5.3.2.- El diseño de los protocolos Tenet
La suite tenet está formado por la siguiente pila de protocolos:
TCP
UDP
RMTP
IP
CMTP
RTIP
Red de transmisión
(FDDI, ATM, etc.)
Módulo
RMTP
CMTP
RTIP
RCAP
RTCMP
Real time Message Transport
Protocol
Continuos Media Transport
Protocol
Real time internet protocol
Real time Channel
Administration Protocol
Real time Control Message
Protocol
Enrique Hernández Orallo
R
C
A
P
R
T
C
M
P
Descripción
Protocolo de transporte orientado a mensaje
Protocolo de transporte orientado a flujo.
Protocolo de red en tiempo real
Protocolo de establecimiento
canales
No implementado
Página 31
y
control
de
07/08/00
Transmisión de datos en Tiempo Real
5.3.3.- Establecimiento y control de canales
El módulo RCAP (Real-time Channel Administration Protocol) proporciona los servicios
de control. Su función principal son el establecimiento y liberación de los canales en tiempo real.
El establecimiento de un canal se realiza en una sola pasada. Un mensaje
establish_request se envía desde el origen al destino del canal. Cada entidad RCAP
mantiene una tabla de rutas para calcular el próximo salto para el establecimiento del canal. Si el
canal puede ser soportado por este nodo (mediante la realización de un test de control de
admisión) se reservan de forma provisional los recursos necesarios y el mensaje se envía al
siguiente nodo. Si el nodo determina que no puede soportar este canal se envía un mensaje
establish_denied de vuelta al origen. Este mensaje libera los recursos reservados por cada
nodo por el que pasa de vuelta. Cuando el mensaje establish_request alcanza el destino,
este toma la última decisión de aceptar o rechazar el canal. Si se acepta el canal se envía de
vuelta al origen el mensaje establish_accept. Cuando este mensaje llega a cada nodo
intermedio el RCAP local puede reducir la asignación de recursos realizada en la ida del
mensaje establish_request. Cuando la asignación definitiva de recursos se realiza se
informa al agente RTIP de que se ha establecido un nuevo canal y se envía el mensaje al nodo
siguiente de vuelta. Cuando este mensaje llega al origen la transmisión sobre el canal puede
comenzar.
Además existen mensajes para consultar el estado de un canal en un nodo y para cerrar un
canal tanto desde el emisor como el receptor.
Los mensajes del RCAP son los siguientes:
Path message
Establish_request
Establish_accept
Establish_denied
Status_request
Status_report
Sentido
Ida
Vuelta
Vuelta
Ida
Vuelta
Close_request_forward
Close_request_reverse
Ida
Vuelta
Descripción
Petición de establecer un nuevo canal.
Aceptación de un canal.
Se ha rechazado el establecimiento de un canal.
Petición del estado de un canal en un nodo.
Retorna los datos recolectados por un mensaje
status_request.
Cierra un canal a petición del origen.
Cierra un canal a petición del destino
El cliente debe establecer los requerimientos de calidad de servicio y una descripción del
tráfico que va a transmitir en la red. Los parámetros son los siguientes:
Parámetros de QoS
Dmáx
Zmin
Jmáx
W min
Parámetros del tráfico
Xmin
Xave
I
Smax
Enrique Hernández Orallo
Descripción
Limite superior de retraso del mensaje de emisor a receptor
Límite inferior de retraso del mensaje de emisor a receptor
Límite superior de la variación del retraso (delay jitter)
Límite inferior en la probabilidad de no perdida debido a una
sobrecarga de los buffers.
Tiempo mínimo entre mensajes
Tiempo medio entre mensajes
Intervalo medio
Tamaño máximo del mensaje
Página 32
07/08/00
Transmisión de datos en Tiempo Real
La implementación de este agente es a través de un daemon. Para la transmisión de
mensajes el RCAP utiliza TCP/IP para asegurar que los mensajes llegan a su destino
correctamente. Esto implica que los tiempos de conexión no son determinados.
5.3.4.- Transmisión y planificación de paquetes
RTIP (Real- Time Internet Protocol) es el nivel de red de la Tenet Suite. Su principal
función es la de transportar los paquetes para cumplir los requerimientos del correspondiente
canal. En contraste con IP este protocolo está orientado a la conexión. RTIP no es fiable debido a
que los paquetes se pueden corromper o perder debido a sobrecarga de buffers ( sólo si Wmim< 1
). RTIP también realiza la planificación de los paquetes basándose en los parámetros de calidad
de conexión de cada canal. Ya que todos los paquetes de una conexión RTIP siguen el mismo
camino, los paquetes llegan siempre en el mismo orden.
La cabecera RTIP es de tamaño fijo para permitir un rápido proceso. Para poder trabajar
con IP los cuatro primeros bits de la cabecera identifican el paquete como RTIP.
0
RTIP
4
8
16
Sin uso
Longitud del paquete
24
Local ID
Número de secuencia
Timestamp
Reservado
Campo
Versión
Local ID
Longitud del paquete
Número de secuencia
Timestamp
Header checksum
Header checksum
Descripción
Tamaño
Contiene identificador de paquete RTIP
4
Identificador del canal
16
Número de octetos del paquete
16
Número de secuencia del paquete
16
Tiempo en el que el paquete se recibió por el 32
modulo RTIP del emisor.
Sólo hay checksum de la cabecera ya que no se 16
asegura la integridad de los datos.
La entidad RTIP en cada nodo tiene el objetivo de asegurar que todos los paquetes son
transportados para que cumplan sus requerimientos de calidad. Cuando se establece una
conexión RTIP es informado del máximo retraso d que puede tener un paquete en ese nodo.
RTIP asegura que un paquete llegado al nodo en un tiempo T es transmitido al siguiente nodo
antes de T + d. RCAP informa además de la cantidad de espacio de buffer asignado a la nueva
conexión y del tiempo mínimo y medio entre mensajes. (Xmin, Xave y I).
Cada entidad RTIP contiene dos módulos :
•
•
Módulo de control de tasa : Este módulo controla el tráfico de cada conexión y lo
ajusta de acuerdo con la especificación del tráfico. Así si un paquete no se esperaba
antes del tiempo Te, y llega antes, entonces el paquete no se convierte en elegible
hasta el tiempo Te. Cuando es elegible se transfiere al modulo planificador.
Módulo planificador: Se encarga de planificar los paquetes elegibles, asegurando
que se cumplan los deadlines.
Este módulo también se encarga de llevar estadísticas.
Enrique Hernández Orallo
Página 33
07/08/00
Transmisión de datos en Tiempo Real
La implementación de este agente se realiza en el kernel del sistema y coexiste con TCP,
UDP y IP. Su acceso es a través de un nuevo tipo de socket IPPROTO_RMTP. Se han
implementado las siguientes de disciplinas de servicio : Delay-Earliest-Due Rate, Jitter-EarliestDue-Rate y Rate-Controlled Static Priority, aunque se puede implementar cualquier otra
disciplina debido a su diseño modular
5.3.5.-Nivel de transporte
RMTP proporciona una abstracción basadas en mensajes sobre RTIP. RMTP esta
diseñado como protocolo de transporte no fiable. Tampoco proporciona ningún control de
congestión o flujo. El principal objetivo de RMTP es proporcionar fragmentación.
5.3.6.- Conclusiones
Los inconvenientes actuales de la implementación de este protocolo es que no permite
multicast, y no tiene control de errores. El nivel de transporte proporcionado RMTP no corrige
errores. Tampoco permite distintos paradigmas de conexión.
Los trabajos actuales de este grupo tienen el objetivo de compartición de recursos en
distribuciones multicast [16]
5.4.- ST-II (Stream Protocol-II)
5.4.1.- Introducción
ST-II es la segunda versión de un protocolo orientado a la transmisión de flujos de
información asegurando una calidad de servicio.
ST-II [22][23] modela una reserva de recursos como un flujo de datos simplex con origen
desde una fuente que se extiende a todos los receptores por medio de una árbol de distribución
multicast.
5.4.2.- Establecimiento de canales
El establecimiento de un canal se inicia cuando el emisor genera un mensaje Connect
con la especificación del flujo y el conjunto inicial de participantes. El proceso del mensaje
Connect en cada agente intermedio implica determinar el conjunto de las siguientes subredes
requeridas para alcanzar los receptores de la lista, instalando estado de forwarding multicast y
reservando el nivel de recursos de red a lo largo de cada subred. Si los recursos reservados
obtenidos a través de las subredes es menor que la cantidad pedida entonces se apunta en el
mensaje Connect actualizando la información del flujo. Cuando el receptor reciba el mensaje
Connect debe determinar si desea unirse al grupo, y retornar bien un mensaje Accept o
Refuse. En el caso de una aceptación el receptor puede reducir más la petición de recursos
actualizando la especificación del flujo
Enrique Hernández Orallo
Página 34
07/08/00
Transmisión de datos en Tiempo Real
Durante la conexión el origen debe esperar por una respuesta Accept o Refuse de
cada receptor de la lista antes de empezar la transmisión. ST-II trata el flujo como una ruta de
distribución homogénea. Cuando el emisor recibe un Accept con una reducción en las
especificaciones del flujo se puede adaptar a esta reducción o bien rechazar la participación de
este receptor en el grupo enviándole un mensaje Disconnect.
5.4.3.- Control de miembros
Se permite añadir o eliminar miembros dinámicamente a los grupos. Cada adición de un
receptor requiere la interacción con la fuente del flujo para que envíe un mensaje Connect.
Esta interacción no está definida en el protocolo pero se realiza fuera de banda utilizando IP.
Como en la conexión inicial la fuente del flujo debe examinar la especificación del flujo en el
mensaje Accept del nuevo receptor y debe decidir si tiene que reducir la calidad del servicio
para el grupo o rechazar al receptor en el caso de que haya un reducción de recursos.
La eliminación de miembros se hace asíncronamente por el receptor enviando un mensaje
Refuse al origen o bien la fuente puede enviar un mensaje Disconnect. El mensaje
Disconnect puede desconectar a receptor individuales o bien a todo el grupo en global.
5.4.4.- Fiabilidad
La fiabilidad esta incorporada en ST-II por medio de dos mecanismos:
•
•
Todos los mensajes de control usados para crear y controlar el flujo son transmitidos
con fiabilidad usando reconocimiento y retransmisión.
Usa un protocolo de eco para consulta el estado de los agente ST vecinos que
comparten flujos activos. Cuando no se puede alcanzar algún vecino se puede intentar
una recuperación del flujos
5.4.5.- Modelos de servicio
El único modelo de servicio soportado es la reserva homogénea sobre un árbol de
distribución uno a muchos. Se denomina a este estilo de flujos independientes.
5.4.6.- Conclusiones
Este protocolo de reserva de recursos es la segunda versión de un protocolo antiguo
denominado Stream Protocol. Es un protocolo que adolece de algunas carencias como no
permitir grupos heterogéneos o distintos modelos de servicio. Además no parece escalar bien
cuando aumentan el número de usuarios [28].
5.5.- RTP (Real-time transport protocol)
5.5.1.- Introducción
RTP [24] proporciona funciones de transporte adaptadas a aplicaciones que transmitan
datos en tiempo real, como audio, vídeo o dato de simulación, sobre servicios de red multicast o
unicast. RTP no implementa reserva de recursos ni servicio de garantía de control de calidad. A
Enrique Hernández Orallo
Página 35
07/08/00
Transmisión de datos en Tiempo Real
este protocolo se añade el RTCP que permite supervisar la entrega de los datos de una manera
escalable. RTP y RTCP están diseñados para ser independientes de los niveles de transporte y
red inferiores.
Las aplicaciones normalmente ejecutan RTP encima de UDP para hacer uso de su
servicio de multiplexación y gestión de errores. RTP soporta la transferencia de datos a múltiples
destinos usando la distribución multicast sólo si lo proporciona los niveles inferiores.
RTP por si mismo no proporciona ningún mecanismo para asegurar el tiempo de entrega
o proporcionar garantía de calidad de servicio. RTP como se ha indicado antes está formado por
dos partes estrechamente relacionadas:
•
•
El protocolo RTP que se encarga de transporta los datos con características en tiempo
real.
El protocolo de control RTP (RTCP) que supervisa la calidad del servicio y gestiona
la información acerca de los participantes en una sesión.
El objetivo de RTP es que sea maleable y proporcionar la información requerida por una
aplicación particular y normalmente será integrada dentro de la aplicación en vez de constituir un
nivel separado. La intención de RTP es que sea adaptado a través de las modificaciones y/o
adiciones de la cabeceras necesarias.
5.5.2.- Protocolo RTP
5.5.2.1.- Ejemplo de uso de RTP
Para ver el funcionamiento el protocolo de RTP se utiliza un ejemplo de uso que es una
conferencia de audio multicast. A través de algún mecanismo se obtiene un dirección de grupo
multicast y un par de puertos. Un puerto se usa para los datos de audio y el otro es usado para
control. La información sobre la dirección y puertos es distribuida a los participantes.
La aplicación de conferencia de audio usada por cada participante envía los datos de
audio en pequeños trozos cada 20 ms por ejemplo. Cada trozo de audio es precedido por una
cabecera RTP.
La red, ocasionalmente puede perder y desordenar los paquetes y provocar retardo de
transmisión variables. Para paliar estas deficiencias, la cabecera RTP contiene información
temporal y un número de secuencia que permite a los receptores reconstruir la información de
audio.
Ya que nuevos miembros se pueden agregar a un grupo durante la conferencia, es útil
saber quien está participando en cada momento y conocer bien si están recibiendo los datos del
audio. Para este propósito cada instancia de la aplicación de audio en la conferencia
periódicamente difunde un informe de su recepción con el nombre de su usuario en el puerto
RTCP.
Para soportar la heterogeneidad de los receptores y línea se añade el concepto de
mezclador (mixer) que es un sistema intermedio que recibe paquetes RTP de una o varias fuentes
Enrique Hernández Orallo
Página 36
07/08/00
Transmisión de datos en Tiempo Real
y cambia el formato de los datos para adaptarse al nuevo enlace generando un nuevo paquete
RTP.
5.5.2.2.- Cabecera RTP
La cabecera RTP tiene el siguiente formato, donde los primeros doce octetos están
presentes en todos los paquetes, mientras que la lista de identificadores CSRC solo son
insertados por el mezclador.
0
4
V=2 P X CC
8
M
16
PT
24
Número de secuencia
Timestamp
SSRC
CSRC
.....
donde los campos son los siguientes:
Campo
Versión (V)
Padding (P)
Extension(X)
CSRC count (CC)
Marker (M)
Payload type(PT)
Número secuencia
Timestamp
SSRC
CSRC list
Descripción
Versión de RTP. Actualmente es la 2
Indica si existe información adicional al final del paquete.
Esta información puede ser útil para los algoritmos de
encriptación
Indica si a continuación viene una cabecera de extensión.
Número de identificadores CSRC que siguen a la
cabecera fija.
Esta indicada para señalar eventos especiales como
salirse de los límites.
Formato de la información que se transporta para que lo
interprete la aplicación
Se incrementa en uno por cada paquete envia, y sirve
para que el receptor detecte perdidas de paquetes.
Tiempo en el que se muestra el primer octeto de los datos
transmitidos en el paquete
Synchronization source identifier. Identifica la fuente del
paquete.
Contributing source
identifiers.. Esta información es
introducida por los mezcladores para indicar que han
contribuido ha modificar la información
Tamaño
2
1
1
4
1
7
16
32
32
32
5.5.3.- El protocolo de control RTP (RTCP)
5.5.3.1.- Funciones del RTCP
El protocolo de control RTP está basado en la transmisión periódica de paquetes de
control a todos los participantes en la sesión, usando el mismo mecanismo de distribución que
los paquetes de datos. RTCP realiza cuatro funciones:
Enrique Hernández Orallo
Página 37
07/08/00
Transmisión de datos en Tiempo Real
1. La función principal es proporcionar información sobre la calidad de la distribución
de los datos. Esta función está relacionada con la funciones de control de congestión y
flujo de otros protocolos de transporte. El enviar informes del estado de la recepción a
todos los participantes permite a alguien que esta observando problemas evaluar si
estos son locales o globales.
2. RTCP transporta un identificador persistente para cada fuente RTP que se denomina
nombre canónico o CNAME. Los receptores requieren el CNAME para mantener
información de todos los participantes y para asociar distintos flujos por ejemplo para
sincronizar audio y vídeo.
3. La dos primeras funciones requieren que todos los participantes envíen paquetes
RTCP, por lo que la tasa de envío debe ser controlada para que RTP se pueda escalar
bien con un número grande de participantes.
4. Otra función opcional es la de convenir la mínima información de control de sesión,
por ejemplo la identificación del participante que se presentará en la pantalla del
usuario.
5.5.3.2.- Paquetes RTCP
RTCP tiene los siguientes tipos de paquetes:
Paquete
SR
RR
SDES
BYE
APP
Descripción
Sender Report. Sirve para la transmisión y recepción de las estadísiticas de
los participantes que son emisores activos.
Receiver report : Sirve para la recepción de estadísticas de los participantes
que no son emisores activos
Source description. Describe la fuente, incluye el CNAME.
Indica un fin de la participación en el grupo
Funciones especificas de aplicación
Cada paquete RTCP empieza con una parte fija que es similar a los paquetes de datos
RTP, seguido por elementos estructurados que pueden ser de longitud variable de acuerdo con el
tipo de paquete.
Para cumplir las funciones de este protocolo se imponen las siguientes condiciones:
•
•
•
Las estadísticas de recepción (en SR o RR) deben ser enviadas tan a menudo como lo
permita el ancho de banda para maximizar la resolución de las estadísticas.
Los nuevos receptores deben recibir el CNAME de una fuente tan pronto como sea
posible para identificar la fuente.
El número de tipos de paquetes deben aparecer en el primer paquete para determinar
su tratamiento.
El intervalo de transmisión de paquetes RTCP debe ser calculado de forma que se
permita tener sesiones que vayan desde pocos participantes a miles. Para ello, en cada sesión se
asume que el tráfico de datos está sujeto a un límite denominado “ancho de banda de sesión” que
se divide entre los participantes. Este ancho de banda debe ser reservado y limitado por la red. El
parámetro de ancho de banda de sesión debe ser proporcionado por la aplicación de control de
sesión. A partir de este valor y en función del número de participantes se calcula el intervalo con
una formula empírica.
Enrique Hernández Orallo
Página 38
07/08/00
Transmisión de datos en Tiempo Real
5.5.4.- Conclusión
El objetivo de este protocolo es la de transportar información de tiempo real. No se
plantea como un nuevo nivel sino como una parte de otros niveles como el de aplicación o
sesión. Su única utilidad es su utilización con otros protocolos de red que si que proporcione lo
que le falte.
5.6.- Comparación de los protocolos
La siguiente tabla resume las características principales de los protocolos estudiados:
Protocolo
Tipo de protocolo
Inicio de comunicación:
Soporta multicast
Grupos heterogéneos
Estado
Asegura QoS
Tiempo de
establecimiento de QoS
Cambios en QoS
Asignación de recursos
Selección de canal
dinámica
Gestión de errores
Protocolos de red
soportados
*
RSVP
Reserva
Receptor
SI
SI
Soft state
(refresco, Time-out)
SI
Separado del
establecimiento de la
ruta
Dinámico
Unidireccional
SI
ST-II
Reserva
Emisor
SI
NO
Hard state
(desconexión explicita)
SI
Concurrente con el
establecimiento de la
ruta
Dinámico
Unidireccional
NO
NO
IPv4, IPv6
NO
Tenet Suite
Global
Emisor
NO
NO
SI
RTP
Transporte
SI
No
determinado
NO
*
SI*
Soft state
*
*
NO
NO
Propio
NO
UDP
Sólo si lo proporciona los niveles de red.
De la comparativa realizada se destaca que como protocolo de reserva de recursos el más
avanzado es el RSVP. ST-II adolece de varios inconvenientes que quizá sean subsanados en el
futuro. La Tenet Suite es una solución global aunque presenta muchas limitaciones. RTP sólo
plantea un protocolo para transmisión en tiempo real pero sin proporcionar control de calidad.
6.- Protocolos a nivel de aplicación
A nivel de aplicación un protocolo para la transmisión multimedia debe encargarse de
localizar el servidor, acordar entre el emisor y receptor que protocolo de red utilizar, el formato
del fichero a transmitir, la conexión y desconexión de usuarios, etc. Aunque estos protocolos se
basan en los niveles de transporte para proporcionar servicio en tiempo real se analiza
brevemente el más utilizado actualmente.
6.1.- RTSP (Real Time Streaming Protocol)
Es un protocolo a nivel de aplicación para el control sobre la transmisión de datos en
tiempo real. RTSP proporciona un marco extensible para permitir la transmisión de datos en
tiempo real bajo demanda como audio y vídeo. Este protocolo permite controlar múltiples
Enrique Hernández Orallo
Página 39
07/08/00
Transmisión de datos en Tiempo Real
sesiones, y se puede escoger los protocolos de transporte a utilizar como UDP, multicast UPD y
TCP y RTP.[21]
El protocolo es intencionadamente similar en sintaxis y notación a HTTP/1.1. Esto
facilita su implementación basándose en los desarrollos de HTTP/1.1. El protocolo soporta las
siguientes operaciones:
•
•
•
Petición de medios7 a servidor. El cliente puede pedir una descripción de presentación
vía HTTP u otro método. Si la presentación es multicast, la descripción contienen las
direcciones multicast y puertos que pueden ser usados. Si la presentación sólo se va a
enviar al cliente , el cliente proporcionará la dirección por motivos de seguridad.
Invitación a un servidor de medios para una conferencia. Un servidor puede ser
invitado a unirse a una conferencia existente, bien como participante o simplemente
para grabar parte de la conferencia. Este modo es útil para las aplicaciones de
enseñanza distribuida.
Adición de medios a una presentación existente. Particularmente en presentaciones en
directo es interesante que el servidor pueda avisar al cliente de que nuevos medios
están disponibles.
Actualmente existen varias compañías que utilizan este protocolo. Entre ellas esta el
producto RealMedia de Progressive Networks. Este producto implementa tanta la parte cliente
como servidor para la distribución y visualización de ficheros multimedia. Está implementado
para la mayoría de plataformas disponibles.
Tanto Netscape como Microsoft han introducido este protocolo para la transmisión de
audio y vídeo en su exploradores / navegadores.
Apéndice 1 : Bibliografía
[1]
[2]
[3]
[4]
[5]
[6]
[7]
H.J.Stuttgen, “Network Evolution and Multimedia Communication” IEEE Multimedia .
Fall 1995 Pág. 42- 59
N.J.Muller,
“Multimedia
Over
The
Network”,
BYTE
http://www.byte.com/art/9603/art3.html Mar. 1996.
A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma, and H. Zhang, ``The Tenet RealTime Protocol Suite: Design, Implementation, and Experiences'', Technical Report TR94-059, International Computer Science Institute, Berkeley, CA, November 1994; also
IEEE/ACM Transactions on Networking, vol. 4, n. 1, pp. 1-10, February 1996.
F.E.Ross, D.R. Vaman, “IsoEthernet : An integrated Services LAN”, IEEE
Communications Magazine , August 1996 Pág. 74-84.
H.Armbruster, “The Flexibility of ATM : Supporting Future Multimedia and Mobile
Communications”, IEEE Communications Magazine, Feb 1995, Págs. 76-84
E.H.Orallo ,”Descripción de la red IEEE P802.12”, Trabajo de doctorado Julio- 1997.
IETF : “Internet Draft: Resource Reservation Protocol (RSVP). Versión 1 Functional
Specification. ( expires 14 dec 1997 ) .
7
Se ha traducido el concepto media como medios para acortar su traducción como medios de comunicación o
difusión.
Enrique Hernández Orallo
Página 40
07/08/00
Transmisión de datos en Tiempo Real
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
ReSerVation Protocol 2 (RSVP2) University of Southern California/Information Sciences
Institute. http://www.ito.darpa.mil/Summaries95/D016--USC_ISI_ReSerVation2.html size 6K - 12-Sep-96 - English
D. Ferrari. "Real-Time Communication in Packet-Switching Wide-Area Networks". TR89-022. International Computer Science Institute, Berkeley, May 1989.
D. Ferrari. "Real-Time Communication in an Internetwork", Technical Report TR-92001, International Computer Science Institute, Berkeley, CA, January 1992; also Journal
of High Speed Networks, vol. 1, n. 1, 1992, pp. 79-103, 1992.
D. Ferrari. "Design and Applications of a Delay Jitter Control Scheme for PacketSwitching Internetworks", Proceedings of the Second International Workshop on
Network and Operating System Support for Digital Audio and Video, Springer-Verlag,
Heidelberg, Germany, pp. 72-83, November 1991; also Computer Communications, vol.
15, n. 6, pp. 367-373, July-August 1992.
D. Ferrari. "Distributed Delay Jitter Control in Packet-Switching Internetworks",
Technical Report TR-91-056, International Computer Science Institute, Berkeley, CA,
October 1991; also Journal of Internetworking: Research and and Experience, vol. 4, n. 1,
pp. 1-20, 1993
L.Sha, S.S.Shathaye, “A systematic Approach to Designing Distributed Real-Time
Systems”, IEEE Computer September 1993, Pág. 68-78
H. Zhang and D. Ferrari, ``Rate-Controlled Service Disciplines'', to appear in Journal of
High Speed Networks, accepted in February, 1994.
R. Widyono, ``The Design and Evaluation of Routing Algorithms for Real-Time
Channels'', M.S. Report, University of California, Berkeley, CA, May 1994.
A. Gupta, W. Howe, M. Moran, and Q. Nguyen, ``Resource sharing for multi-party realtime communication'', Proc. IEEE INFOCOM`95, Boston, MA, April 1995.
K.J.Rae. “Digital Audio and IPv6”. Senior Thesis. Claremont McKenna College.
W.Stallings. “IPv6: The New Internet Protocol”. IEEE Communications Magazine. July
1996. Pág 96-108.
P.P.White. “RSVP and Integrated Services in the Internet : A tutorial”. IEEE
Communications Magazine . May 1997 Pág. 100-106
Progressive Networks “RealMedia Overview”. 1997
“Real Time Streaming Protocol (RTSP)” IETF Draft July 30,1997.
C.Tolpovic, “Experimental Internet Stream Protocol. Version 2 (ST-II)” Internet RFC
1190, October 1990
L.Delgrossi, R.G.Herrtwich, F.O.Hoffman, “An Implementation of ST-II for the
Heidelberg Transport System,” IBM ENC TR-43.9303. To appear in Internetworking :
Research and Experience.
Jacobsen V., Fredrick R., Casner S., and Schulzrinne H., “RTP: A transport Protocol for
Real-Time Applications”. RFC 1889. Lawrence Berkeley National Laboratory, Xerox
PARC, Precept Software Inc., GMD Fokus, January 1996. Online. Internet.
http://www.connect.org.uk./teckwatch/cgi-bin/rfcshow?1889 Accessed 16 Oct., 1996
D.Hehmann, M.Salmony, H.J. Stüttgen, “Transport Services for Multimedia Applications
on Broadband Networks”, Computer Comm. Rev., Vol 13, Nº 4, May 1990, pp. 197-203.
S. Schenker, C.Partridge, R.Guerin “Specification of Guaranteed Quality of Service”,
RFC 2212.
J.Wroclawski, “Specification of the controlled-Load network Element Service”. RFC
2211.
D.Mitzel et al, “An architectural Comparison of ST-II and RSVP”, Proc Infocom’94,
http://www.isi.edu/div7/rsvp/pub.html
Enrique Hernández Orallo
Página 41
07/08/00
Transmisión de datos en Tiempo Real
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
L. Zhang, S.Deering, D. Estrin, S. Shenker, D. Zappala. “RSVP : A New Resource
Rservation Protocol”. IEEE Network Magazine September 1993.
R.Braden, D.Clark, S.Shenker, “Integrated services in the Internet Architecture : An
Overview”. Internet RFC 1633. July 1994.
Shenker,S., Clark, D,, and L. Zhang, “A Scheduling Service Model and a Scheduling
Architecture for an Integrated Services Packet Network”, submitted to ACM/IEEE Trans.
On Networking.
Shenker,S., Clark, D,, and L. Zhang, “A Scheduling Service Model for the Integrated
Services Internet”.
Wroclawski, J., “Use of RSVP with IETF Integrated Services”, RFC 2210, September
1997.
A. Demers, S. Keshav and S. Shenker, “Analysis and Simulation of a Fair Queueing
Algorithm”, in Internetworking : Research and Experience, Vol 1, No. 1., pp. 3-26.
L. Zhang, “Virtual Clock : A new traffic Control Algorith for Packet Switching
Networks”, in Proc. ACM SIGCOMM ’90, pp. 19-29.
D. Verma, H. Zhang, and D.Ferrari, “Guaranteeing Delay Jitter Bounds in Packet
Switching Networks”, in Proc. Tricomm ’91.
L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivarajan, “Efficient Network QoS
Provisioning Based on per Node Traffic Shaping”, IBM Research Report No. RC-20064.
P. Goyal, S.S. Lam and H.M.Vin, “Determining End-To-End Delay Bounds in
Heterogeneous Networks”, in Porc. 5th Intl. Workshop on Network and Operating System
Support for Digital Audio and Video, Abril 1995.
Andrew S.Tanenbaum, “Computer Networks - Third Edition”, Prentice Hall 1996.
J.A. Cobb, M.G. Gouda, “Flow Theory” IEEE/ACM Transactions on Networking, Vol. 5,
Nº 5, October 1997.
S. Shenker, J.Wroclawski, “General Characterization Parameters for Integrated Service
Network Elements”. RFC 2211. September 1997
S. Shenker, J.Wroclawski, “Network Element Service Specification Template”. RFC
2216. September 1997.
E.W.Knightly, H. Zhang, “Traffic Characterization and switch Utilization using a
Deterministic Bounding Interval Dependent Traffic Model”, In Proceding of IEEE
INFOCOM’95
A. Kuznetsov, sitio FTP para los fuentes RSVP y del paquete iproute2+tc, URL
ftp://ftp.inr.ac.ru/ip-routing.
Leído
Leído por encima
Por conseguir
Apéndice 2 : Acrónimos
AAL : ATM Adaptation Layer.
ABR : available bit-rate traffic
CBO : continuous bit-stream oriented traffic
CBR : constant bit-rate traffic
CCITT : Comité Consultatif International de Télégraphigue et Télephonique.
DVI : Digital Video Interactive
Enrique Hernández Orallo
Página 42
07/08/00
Transmisión de datos en Tiempo Real
IETF : Internet Engineering Task Force.
ISO : International Standard Organization
ITU : International Telecommunications Union.
LLC : Logical Link Control
MAC : Medium Access Control
MPEG : Moving Pictures Expert Group
QoS : Quality of Service.
RDSI : (ISDN) Red Digital de Servicios Integrados
VBR : variable bit-rate traffic
Enrique Hernández Orallo
Página 43
07/08/00