Transmisión de datos 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

Enrique Hernández Orallo Página 2 07/08/00

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



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



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 ( FDDI-II, 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.



• 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.



• 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. Retraso en la compresión y descomposición en paquetes en la fuente, 2. Retraso de transmisión en la red, 3. Almacenamiento en el destino y retraso de sincronización, 4. 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.



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):

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.

Sensible alretraso

No sensible al retraso

No sensiblea la perdida

Sensiblea la perdida

Tiempo real

Elásticas

Tiempo real adaptativo

Control deprocesos

Transferenciaficheros, email

Video y audio



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):



Valores típicos para distintos tipos del tráfico se describen en la siguiente tabla: Retraso máximo(s) Máxima variación en

el retraso Ancho de banda(Mbps)

Tasa de perdida de paquetes

Voz 0.25 10 0.064 10e-1 Vídeo 0.25 10 100 10e-3 Imagen 1 2-10 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.

Gran ancho de banda

Bajo anchode banda

Bajo retraso Alto retraso

Transferencia de ficheros

email

Video y audio

Control de procesos



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



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 RDSI-B 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.



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.



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.



• 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 155-

Mbps, 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:



Clase A Clase B Clase C Clase D Relación temporal entre

fuente y destino. Requerida No requerida

Tasa de transferencia Constante Variable Modo de conexión Con conexión Sin conexión

Tipo de AAL AAL 1 AAL 2 AAL 3 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:



Red Ancho banda (Mbps)

Retraso transmisión Variación del

Retraso

Broadcast Soporte CBO

Disponible

Ethernet 10 Aleatorio ∞ Si No Si Iso-Ethernet* 10+6 Fijo < 1ms. 0 No Si No Token Ring 4/16 Configuración < 20ms. ∆ Si No Si 100Base-T 100 Aleatorio ∞ Si No Si

802.12 100 Configuración < 10ms. ∆ Si No No FDDI 2 x 100 Configuración ∆ Si No Si

FDDI-II* N x 6 Fijo < 1ms. 0 Si Si No X-25 <2 Aleatorio ∞ No No Si

Frame Relay < 50 Aleatorio ∞ No No Si RDSI N x 0.064 Fijo < 10ms 0 No Si Si ATM 25 – 155 Fijo < 10ms ∆ (SI) Si(AAL1) 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



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:

• Direccionamiento : IPv6 utiliza direcciones de 128-bit. Este es un valor que parece lo suficientemente amplio incluso para incluir direcciones Ethernet internamente.

3 Tienen en los primero 4 bits de la cabecera del datagrama el número 4.



• 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 4 8 16 24 Versión Prioridad Etiqueta de flujo

Longitud de pago Próxima cabecera Limite de saltos Dirección origen Dirección destino

donde los campos son los siguientes:

Campo Descripción Tamaño Versión Contiene el valor 6 4 Prioridad 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.

4

Etiqueta de flujo 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.

16

Longitud de pago Longitud del paquete menos la cabecera 16 Próxima cabecera Tipo de cabecera después de la cabecera IPv6. 8 Límite de saltos Se decrementa en uno por cada nodo por el que pasa el

paquete. Cuando el valor llega a cero se elimina el paquete.

8

Dirección origen Dirección desde donde se envía el mensaje 128 Dirección destino Dirección de destino. Esta pueda que no se la dirección

final si existe una cabecera de enrutamiento. 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



Cabecera Descripción Opciones de salto 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 Tipo de tráfico 0 No se especifica prioridad 1 Tráfico de relleno (noticias) 2 Transferencia de datos desatendida (e-mail) 3 Reservado 4 Transferencia de datos atendida (FTP, HTTP, etc. ) 5 Reservado 6 Tráfico interactivo (conexión on-line de terminales) 7 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.



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.



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

• 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.

5 Existe un grupo de trabajo en el IETF sobre el tema; el Integrated Services Working Group.



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.



5.2.- RSVP (Resource ReSerVation Protocol)


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.



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.



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:

)()(

)(

))((rRpcasoD

R

CM

rpR

RpMbQ tot

totdelay ≥>+

++

−−−

= (1)

)()(

rpRcasoDR

CMQ tot

totdelay ≥≥+

+= (2)

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:

Parámetro Tspec Descripción Unidad p Tasa pico del flujo Bytes/s b (bucket depth) Tamaño del cubo Bytes r (token bucket rate)Tasa de transmisión del cubo Bytes/s m Tamaño mínimo de un paquete Bytes M Tamaño máximo de paquete Bytes Parámetros Rspec R Ancho de banda Bytes/s S Slack term. Diferencia entre el retraso deseado y el

obtenido usando una reserva de ancho de banda R. µs

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.



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], Jitter-EDD[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;

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)

S1

Upstream Downstream

R1 R1 R1

R1

Resv ResvTear PathErr

Path PathTear ResvErr ResvConf

RCV1

RCV2

RCV3



Cada mensaje Path incluye la siguiente información:

Path message Descripción Phop Dirección del último nodo RSVP capaz de enviar este mensaje

Path Sender Template Contiene la dirección IP del emisor y opcionalmente el puerto. Sender Tspec Define las características del tráfico Adspec 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:



Parámetros generales por defecto Descripción Latencia mínima de la ruta Suma individual de las latencias de los enlaces. Ancho de banda de la ruta El mínimo de los ancho de banda de los enlaces. Global bit break 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.

Contador de salto IS Se incrementa en uno por cada router RSVP. PathMTU Path maximum transmission unit. ( es el mínimo de

las MTU’s de los enlace individuales de la ruta).

Parámetros de servicio garantizado Ctot Valor total del parámetro C de emisor a receptor Dtot Valor total del parámetro D de emisor a receptor CSum Suma compuesta del valor C hasta el anterior router. DSum Suma compuesta del valor D hasta el anterior router Break bit Mismo funcionamiento que Global bit break. Parámetros generales 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.

Parámetros de servicio controlado Break bit Equivalente al anterior Parámetros generales 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:



Resv message Descripción Estilo de reserva Indica el estilo de reserva a utilizar. Puede ser FF, SE o WF. FilterSpec Especificación de filtro para identificar a los emisores. Flowspec Se compone del Rspec y la especificación de tráfico, Tspec. ResvConf 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.

inoutin

itot

inin

out

itot

outout RRr

R

C

R

bS

R

C

R

bS ≤≤++≤++ (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



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.



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


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 CMTP IP RTIP

Red de transmisión (FDDI, ATM, etc.)

R C A P

R T C M P

Módulo Descripción RMTP Real time Message Transport

Protocol Protocolo de transporte orientado a mensaje

CMTP Continuos Media Transport Protocol

Protocolo de transporte orientado a flujo.

RTIP Real time internet protocol Protocolo de red en tiempo real RCAP Real time Channel

Administration Protocol Protocolo de establecimiento y control de canales

RTCMP Real time Control Message Protocol

No implementado



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 Sentido Descripción Establish_request Ida Petición de establecer un nuevo canal. Establish_accept Vuelta Aceptación de un canal. Establish_denied Vuelta Se ha rechazado el establecimiento de un canal. Status_request Ida Petición del estado de un canal en un nodo. Status_report Vuelta Retorna los datos recolectados por un mensaje

status_request. Close_request_forward Ida Cierra un canal a petición del origen. Close_request_reverse Vuelta 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 Descripción Dmáx Limite superior de retraso del mensaje de emisor a receptor Zmin Límite inferior de retraso del mensaje de emisor a receptor Jmáx Límite superior de la variación del retraso (delay jitter) Wmin Límite inferior en la probabilidad de no perdida debido a una

sobrecarga de los buffers. Parámetros del tráfico Xmin Tiempo mínimo entre mensajes Xave Tiempo medio entre mensajes I Intervalo medio Smax Tamaño máximo del mensaje



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 4 8 16 24 RTIP Sin uso Local ID

Longitud del paquete Número de secuencia Timestamp

Reservado Header checksum

Campo Descripción Tamaño Versión Contiene identificador de paquete RTIP 4 Local ID Identificador del canal 16 Longitud del paquete Número de octetos del paquete 16 Número de secuencia Número de secuencia del paquete 16 Timestamp Tiempo en el que el paquete se recibió por el

modulo RTIP del emisor. 32

Header checksum Sólo hay checksum de la cabecera ya que no se asegura la integridad de los datos.

16

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.



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-Earliest-Due-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.


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)


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



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.


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)


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



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



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 8 16 24 V=2 P X CC M PT Número de secuencia

Timestamp SSRC CSRC .....

donde los campos son los siguientes:

Campo Descripción Tamaño Versión (V) Versión de RTP. Actualmente es la 2 2 Padding (P) Indica si existe información adicional al final del paquete.

Esta información puede ser útil para los algoritmos de encriptación

1

Extension(X) Indica si a continuación viene una cabecera de extensión. 1 CSRC count (CC) Número de identificadores CSRC que siguen a la

cabecera fija. 4

Marker (M) Esta indicada para señalar eventos especiales como salirse de los límites.

1

Payload type(PT) Formato de la información que se transporta para que lo interprete la aplicación

7

Número secuencia Se incrementa en uno por cada paquete envia, y sirve para que el receptor detecte perdidas de paquetes.

16

Timestamp Tiempo en el que se muestra el primer octeto de los datos transmitidos en el paquete

32

SSRC Synchronization source identifier. Identifica la fuente del paquete.

32

CSRC list Contributing source identifiers.. Esta información es introducida por los mezcladores para indicar que han contribuido ha modificar la información

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:



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 Descripción SR Sender Report. Sirve para la transmisión y recepción de las estadísiticas de

los participantes que son emisores activos. RR Receiver report : Sirve para la recepción de estadísticas de los participantes

que no son emisores activos SDES Source description. Describe la fuente, incluye el CNAME. BYE Indica un fin de la participación en el grupo APP 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.



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 RSVP ST-II Tenet Suite RTP Tipo de protocolo Reserva Reserva Global Transporte

Inicio de comunicación: Receptor Emisor Emisor Soporta multicast SI SI NO SI*

Grupos heterogéneos SI NO NO Estado Soft state

(refresco, Time-out) Hard state

(desconexión explicita) SI Soft state

Asegura QoS SI SI SI NO Tiempo de

establecimiento de QoS Separado del

establecimiento de la ruta

Concurrente con el establecimiento de la

ruta

No determinado

*

Cambios en QoS Dinámico Dinámico * Asignación de recursos Unidireccional Unidireccional *

Selección de canal dinámica

SI NO NO

Gestión de errores NO NO NO NO Protocolos de red

soportados IPv4, IPv6 Propio 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



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] H.J.Stuttgen, “Network Evolution and Multimedia Communication” IEEE Multimedia .

Fall 1995 Pág. 42- 59 [2] N.J.Muller, “Multimedia Over The Network”, BYTE

http://www.byte.com/art/9603/art3.html Mar. 1996. [3] A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma, and H. Zhang, ``The Tenet Real-

Time Protocol Suite: Design, Implementation, and Experiences'', Technical Report TR-94-059, International Computer Science Institute, Berkeley, CA, November 1994; also IEEE/ACM Transactions on Networking, vol. 4, n. 1, pp. 1-10, February 1996.

[4] F.E.Ross, D.R. Vaman, “IsoEthernet : An integrated Services LAN”, IEEE Communications Magazine , August 1996 Pág. 74-84.

[5] H.Armbruster, “The Flexibility of ATM : Supporting Future Multimedia and Mobile Communications”, IEEE Communications Magazine, Feb 1995, Págs. 76-84

[6] E.H.Orallo ,”Descripción de la red IEEE P802.12”, Trabajo de doctorado Julio- 1997. [7] 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.



[8] 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

[9] D. Ferrari. "Real-Time Communication in Packet-Switching Wide-Area Networks". TR-89-022. International Computer Science Institute, Berkeley, May 1989.

[10] D. Ferrari. "Real-Time Communication in an Internetwork", Technical Report TR-92-001, International Computer Science Institute, Berkeley, CA, January 1992; also Journal of High Speed Networks, vol. 1, n. 1, 1992, pp. 79-103, 1992.

[11] D. Ferrari. "Design and Applications of a Delay Jitter Control Scheme for Packet-Switching 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.

[12] 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

[13] L.Sha, S.S.Shathaye, “A systematic Approach to Designing Distributed Real-Time Systems”, IEEE Computer September 1993, Pág. 68-78

[14] H. Zhang and D. Ferrari, ``Rate-Controlled Service Disciplines'', to appear in Journal of High Speed Networks, accepted in February, 1994.

[15] R. Widyono, ``The Design and Evaluation of Routing Algorithms for Real-Time Channels'', M.S. Report, University of California, Berkeley, CA, May 1994.

[16] A. Gupta, W. Howe, M. Moran, and Q. Nguyen, ``Resource sharing for multi-party real-time communication'', Proc. IEEE INFOCOM`95, Boston, MA, April 1995.

[17] K.J.Rae. “Digital Audio and IPv6”. Senior Thesis. Claremont McKenna College. [18] W.Stallings. “IPv6: The New Internet Protocol”. IEEE Communications Magazine. July

1996. Pág 96-108. [19] P.P.White. “RSVP and Integrated Services in the Internet : A tutorial”. IEEE

Communications Magazine . May 1997 Pág. 100-106 [20] Progressive Networks “RealMedia Overview”. 1997 [21] “Real Time Streaming Protocol (RTSP)” IETF Draft July 30,1997. [22] C.Tolpovic, “Experimental Internet Stream Protocol. Version 2 (ST-II)” Internet RFC

1190, October 1990 [23] 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.

[24] 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

[25] 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.

[26] S. Schenker, C.Partridge, R.Guerin “Specification of Guaranteed Quality of Service”, RFC 2212.

[27] J.Wroclawski, “Specification of the controlled-Load network Element Service”. RFC 2211.

[28] D.Mitzel et al, “An architectural Comparison of ST-II and RSVP”, Proc Infocom’94, http://www.isi.edu/div7/rsvp/pub.html



[29] L. Zhang, S.Deering, D. Estrin, S. Shenker, D. Zappala. “RSVP : A New Resource Rservation Protocol”. IEEE Network Magazine September 1993.

[30] R.Braden, D.Clark, S.Shenker, “Integrated services in the Internet Architecture : An Overview”. Internet RFC 1633. July 1994.

[31] 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.

[32] Shenker,S., Clark, D,, and L. Zhang, “A Scheduling Service Model for the Integrated Services Internet”.

[33] Wroclawski, J., “Use of RSVP with IETF Integrated Services”, RFC 2210, September 1997.

[34] 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.

[35] L. Zhang, “Virtual Clock : A new traffic Control Algorith for Packet Switching Networks”, in Proc. ACM SIGCOMM ’90, pp. 19-29.

[36] D. Verma, H. Zhang, and D.Ferrari, “Guaranteeing Delay Jitter Bounds in Packet Switching Networks”, in Proc. Tricomm ’91.

[37] 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.

[38] 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.

[39] Andrew S.Tanenbaum, “Computer Networks - Third Edition”, Prentice Hall 1996. [40] J.A. Cobb, M.G. Gouda, “Flow Theory” IEEE/ACM Transactions on Networking, Vol. 5,

Nº 5, October 1997. [41] S. Shenker, J.Wroclawski, “General Characterization Parameters for Integrated Service

Network Elements”. RFC 2211. September 1997 [42] S. Shenker, J.Wroclawski, “Network Element Service Specification Template”. RFC

2216. September 1997. [43] E.W.Knightly, H. Zhang, “Traffic Characterization and switch Utilization using a

Deterministic Bounding Interval Dependent Traffic Model”, In Proceding of IEEE INFOCOM’95

[44] 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



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

Documents

Transmisión de datos en Tiempo Real