INSTITUTO POLITCNICO NACIONAL CENTRO DE INVESTIGACIN EN COMPUTACIN

No. 43 Serie: AZUL Fecha: Noviembre 99

Comunicaciones en Tiempo Real en Internet

Juan Gabriel Gonzlez Serna1 Felipe Rolando Menchaca Garca2

RESUMEN
Actualmente la demanda de servicios de comunicacin para aplicaciones de tiempo real, en Internet, se ha venido intensificando, y los requerimientos de intercambio de informacin altamente sensible al retardo (voz, audio y vdeo) en ambientes distribuidos como es el de Internet son cada vez ms importantes. El proporcionar los mecanismos y servicios necesarios para garantizar el desempeo requerido por este tipo de aplicaciones es el propsito de los nuevos desarrollos en el rea de comunicaciones en tiempo real. El objetivo de este trabajo es mostrar una perspectiva de los servicios de comunicacin en tiempo real y las arquitecturas propuestas para Internet. Se analizarn las caractersticas de los nuevos protocolos para Internet RTP, IPv6, y RSVP, para lograr comunicacin en tiempo real en ambientes dinmicos como Internet. Palabras Clave: Comunicaciones en tiempo real, comunicaciones multimedia, Internet, IPv6, RSVP, RTP/RTCP, tiempo real, QoS.
1

Alumno de Doctorado del Centro de Investigacin en Computacin del I.P.N. y ProfesorInvestigador del CENIDT 2 Profesor Investigador del Centro de Investigacin en Computacin del I.P.N.

LAS COMUNICACIONES EN TIEMPO REAL EN INTERNET.

1. INTRODUCCIN. Con los ltimos avances en la tecnologa de redes, las aplicaciones multimedia y de control de procesos se han visto beneficiadas. Estas aplicaciones tienen caractersticas especiales que demandan Servicios de Comunicacin en Tiempo Real (SCTRs) que garanticen un desempeo confiable de la red, en trminos de retardos, variaciones de los retardos, caudal y tasas de prdida de informacin [1]. Las arquitecturas actuales de redes y protocolos se basan en diseos que proporcionan el servicio denominado del Mejor Esfuerzo (ME), el cual es ineficiente para aplicaciones de Tiempo Real (TR). El esquema de trabajo del ME tiene como propsito obtener el mayor progreso, procesar tan rpido como sea posible [2]. Las aplicaciones que no son sensibles a retardos, prdida de informacin y condiciones difciles de recuperacin de datos, trabajan bien con este servicio. En contraste, las aplicaciones de TR imponen restricciones en aspectos tales como retardos, tiempos de recuperacin y tasas de prdida de informacin, los cuales no pueden ser solventados por medio del servicio del ME. Los recientes avances en la tecnologa de redes han permitido el desarrollo de conmutadores de alto desempeo y amplios anchos de banda, lo que ha resultado en Redes de Alta Velocidad (RAVs). Sin embargo velocidad, no significa tiempo real , tener una RAVs no significa que se cuenta con todos los requerimientos de una aplicacin de TR que permitan asegurar un desempeo adecuado en todas las condiciones de carga de la red. Los requerimientos de tiempo de una aplicacin se satisfacen fcilmente sin necesidad de tomar previsiones, siempre y cuando las condiciones de carga de la RAV sean ligeras. Obviamente estas condiciones de carga cambian dinmicamente, por lo que es difcil mantener estos requerimientos temporales de manera constante. Los estndares de las RAVs todava muestran variantes en su desempeo, por lo que no se garantizan los SCTRs. Los requerimientos de una aplicacin de TR se pueden caracterizar en funcin de la cantidad de informacin que es posible perder, sin que esto afecte sensiblemente la calidad del servicio, por lo que podemos decir que los SCTRs no slo se plantean en trminos de retardos, sino tambin, en trminos de tasas aceptables de prdida de informacin. El asegurar que estos requerimientos son aceptables y permiten el correcto desempeo de la aplicacin, significa asegurar la Calidad de Servicio (QoS). Los parmetros de inters de la QoS son: retardos, variaciones de los retardos ("delay jitter"), ancho de banda, y rangos de prdida de informacin.

1.1. Qu Significa Tiempo Real?. Un Sistema de Tiempo Real (STR) es un sistema de cmputo que debe reaccionar a eventos de su medio ambiente en tiempos muy precisos. El correcto comportamiento de estos sistemas no depende nicamente de la validez de sus resultados, sino tambin del tiempo que se tarda en obtenerlos [10]. Aunque el trmino TR se utiliza muy comnmente en varias reas de aplicacin, no siempre se utiliza correctamente, generalmente decimos que un sistema de control opera en TR si ste es capaz de reaccionar rpidamente a eventos externos. El trmino rpido es relativo ya que no contempla las principales propiedades de los STRs; rapidez en hardware, no implica tiempo real. Las tareas que realiza un STR se pueden clasificar en dos clases: Rgidas. Se dice que una tarea TR es rgida, si cuando se completa su ejecucin despus de un tiempo lmite establecido por la aplicacin, se provocan daos catastrficos al ambiente o al sistema.

Suaves. Se dice que una tarea TR es suave, si cuando se completa su ejecucin despus de un tiempo lmite establecido por la aplicacin, no se provocan daos al ambiente ni se afecta el comportamiento del sistema.

2. FUNDAMENTOS DE LA COMUNICACIN EN TIEMPO REAL. Consideremos un paquete que va del nodo S al nodo D pasando por los nodos A, B y C, y los enlaces 1, 2, 3 y 4 como se muestra en la Figura 1. Si las condiciones de trfico en la red son mnimas, la transferencia de paquetes se realiza sin ningn retraso. Para lograr estas condiciones los nodos y los enlaces deben estar disponibles para procesar inmediatamente los paquetes. Sin embargo, generalmente una red no maneja solo una transmisin sino varias a la vez, lo que implica que los nodos o enlaces no procesen los paquetes inmediatamente, y esta carga en la red genera retrasos que pueden afectar a cierto tipo de aplicaciones. Por esto las aplicaciones de TR deben gestionar de manera eficiente el manejo y reservacin de recursos, para asegurar la QoS requerida por las aplicaciones de TR [9].

S 1 A 2 B 3 C 4 D
t0 tk
Tiempo de Procesamiento

Figura 1. Procesamiento de Paquetes Distribuidos.

En la figura 1, llega un paquete en el instante t 0 al nodo S, el cual tarda un cierto tiempo en procesar el paquete para luego enviarlo a travs del enlace 1 al nodo A. El paquete tarda otro tiempo en el enlace 1 y llega al nodo 2, en donde a su vez es procesado en un determinado tiempo. De la misma manera viaja por el enlace 2, al nodo B, luego por el enlace 3 al nodo C y finalmente por el enlace 4 al nodo D. El retardo total del paquete al atravesar por todos los nodos es de t k - t 0. 2.1. Componentes de un Sistema de Comunicacin en Tiempo Real. Un SCTR adecuado, debe ser capaz de soportar comunicaciones en TR y del ME. Las aplicaciones en tiempo real requieren que se garantice el desempeo de la comunicacin, en el peor de los casos. Dependiendo del volumen de trfico, la red consume recursos que garantizan la comunicacin. Para garantizar los recursos necesarios para la aplicacin, sta debe describir su demanda de trfico, por medio de una caracterizacin de mismo, la cual describe el volumen de datos a transmitir en un perodo de tiempo especfico [9]. Cualquier aplicacin que requiera SCTR, necesita especificar este volumen y los requerimientos de comunicacin. La comunicacin en TR es orientada a conexin, esto implica que la fase de establecimiento de la conexin se utiliza como un Control de Admisin (CA). En esta fase, la red busca una ruta que rena los recursos suficientes que garanticen los requerimientos de la conexin, sin que esto afecte las garantas de otras conexiones de tiempo real ya establecidas. Si tal ruta se encuentra, los recursos requeridos se reservan y la conexin se acepta, si no es as, la conexin se rechaza.

Cada conexin es un contrato entre la aplicacin y la red. Un control de flujo basado en rangos, utiliza patrones de trfico en la fuente y polticas de trfico en la red para garantizar que la aplicacin fuente no acte inadecuadamente. En cada conmutador, el trfico entrante proveniente de varias conexiones puede multiplexarse. El multiplexaje ocasiona fluctuaciones de carga en la red, tales que, el trfico de una conexin podra no satisfacer los requerimientos establecidos en su caracterizacin, aunque se satisfagan los requerimientos en la fuente. Esta disciplina de servicio tiene que proteger las garantas de servicio dadas a una de conexin, del trfico sobrepuesto de otra conexin. Esto se logra por medio de las disciplinas de servicio basadas en rangos, en las que a cada conexin se le garantiza una velocidad de servicio mnima (suficiente para satisfacer su caracterizacin de trfico) sin considerar el trfico entrante de otras conexiones. La comunicacin con servicio del Mejor Esfuerzo puede ser orientada a conexin o sin conexin, y puede escoger independientemente su propio control de flujo y disciplina de servicio. Generalmente se usa el control de flujo basado en una ventana deslizante, y la disciplina de servicio secuencial ("round- obin"). Por cual, el servidor en de un r conmutador puede tener dos disciplinas de servicio con diferentes niveles de prioridad. La disciplina de servicio de mayor prioridad se usa para servicios de trfico en tiempo real. La disciplina de servicio de menor prioridad se usa para servicios de trfico del mejor esfuerzo. Por lo tanto, el trfico del mejor esfuerzo se atender nicamente cuando no haya paquetes de trfico de tiempo real. El trfico del mejor esfuerzo no afecta las garantas de desempeo de las conexiones de tiempo real. En resumen, el modelo de servicio incluye los siguientes elementos[9]: 1. La Especificacin de Conexin: Que es una estructura de datos que se usa como interfaz entre una aplicacin y la red. Describe la caracterizacin del trfico y los requerimientos de desempeo (parmetros de QoS) de la conexin. El Control de la Conexin: (a) Ruteado: Encuentra trayectorias unidifusin o multidifusin que puedan satisfacer los requerimientos de desempeo. (b) Control de Admisin y Reservacin de Recursos: Decide si cualquiera de las trayectorias sugeridas por el ruteador rene los recursos suficientes que den el desempeo que garantiza la caracterizacin del trfico. Si se encuentra tal trayectoria, se acepta la conexin y se reservan los recursos. De otra forma, la conexin se rechaza. 3. El Control de Paquetes:

2.

(a) Control de Flujo: Protege las garantas dadas a las conexiones. Forza a cada conexin a establecer su caracterizacin de trfico para definir la fuente y poltica de transmisin para la red. (b) Disciplina de Servicio: Planifica la retransmisin de los paquetes que llegan al nodo. Para conexiones de TR, se usa la disciplina de servicio basada en tasas, para proteger las garantas dadas a las conexiones, contra fluctuaciones de carga de la red y trfico del ME. Se garantiza una velocidad de servicio mnima a conexiones individuales sin considerar el trfico de otras conexiones.

2.2. Tipos de Trfico en Red. Para analizar y entender la problemtica de las comunicaciones en tiempo real en entornos distribuidos como Internet, se deben identificar los diferentes tipos de datos que se transmiten en estos entornos, en donde millones de usuarios solicitan una gran variedad de servicios que van desde la transmisin de un simple texto hasta la de datos continuos de audio y video. En este trabajo se definen tres clases de trfico en red, cada una de las cuales estn basada en la variacin del tamao de los paquetes generados y en la variacin del tiempo requerido para su procesamiento [8], los tres tipos de trfico son los siguientes: trfico de medios digitales continuos (audio y video), trfico de datos peridicos de sensores y actuadores en aplicaciones de control y trfico de datos tradicionales.

Estas tres clases de trfico se pueden caracterizar en funcin de la cantidad de informacin generada. Algunas fuentes de datos generan paquetes de tamao constante a intervalos de tiempo constantes, a este tipo de trfico se le denomina fuente con velocidad de bits constante ("Constant Bit Rate source, CBR"); la voz y el vdeo normal sin compresin y los datos generados por sensores o enviados a actuadores entran en esta categora. Algunas aplicaciones de medios continuos utilizan tcnicas de compresin o adaptacin para reducir el tamao de los datos que se van a transmitir. Esto genera paquetes de tamao variable y se les denomina fuente con velocidad de bits variable ("Variable Bit Rate source, VBR"). Por ejemplo, el trfico de vdeo se reduce aplicando compresin a los cuadros individuales, resultando una fuente de datos que genera paquetes de tamao variable en intervalos de tiempo regulares.

Las fuentes de datos tradicionales son: transferencia de mensajes, transferencia de archivos, comunicacin interprocesos y datos interactivos ("login remoto"). Estas fuentes producen mensajes grandes o n mensajes cortos en intervalos considerables

(como en la comunicacin interprocesos, o en el uso de los servicios rlogin o telnet de unix). Las fuentes de datos tradicionales utilizan el servicio del ME, el cual no asegura buenos requerimientos de QoS. El trfico de una fuente de datos se puede clasificar como uniforme o irregular. Una fuente de trfico uniforme no tiene mucha variacin en su velocidad de trfico, por otro lado, una fuente de trfico irregular, tiene ocasionalmente grandes explosiones de trfico provocando grandes variaciones en su velocidad de trfico. La mayora de las fuentes VBR son de tipo irregular.

3. SERVICIOS DE COMUNICACIN EN TIEMPO REAL. El incremento del nmero de conmutadores y ruteadores conectados a Internet y de la demanda de aplicaciones multimedia, han provocado que surjan nuevos protocolos tales como IPv6, RTP/RTCP, RSVP y RTSP. Estos protocolos conforman la nueva generacin de servicios de aplicacin para el WWW.

3.1. Evolucin de los Servicios de Comunicacin en Internet. En los primeros aos de Internet las instituciones cientficas y acadmicas lo utilizaban principalmente para aplicaciones de transmisin de datos tales como transferencia de archivos (FTP), correo electrnico (E-MAIL), emuladores de terminal (TELNET), y noticias en red (NET NEWS). En ese entonces el nmero de usuarios era limitado y el espacio de direcciones IP de 32 bits era bastante grande como para vislumbrar problemas futuros. Se contaba con terminales conectadas a equipos que no tenan la capacidad de procesar datos de audio y video. Las aplicaciones de comunicacin trabajaban con el protocolo IPv4 en la capa de red y TCP o UDP en la capa de transporte. Al evolucionar las PCs y las estaciones de trabajo, los usuarios de Internet empezaron a intercambiar grficos, vdeo, audio, y texto. Sin embargo, los primeros protocolos para Internet no proporcionaban servicios adecuados para la transmisin multidifusin, ni para la transmisin de datos en tiempo real, por lo que estos servicios se aadieron al IP a finales de los 80s. Los conmutadores IP y los ruteadores fueron mejorados con los servicios multidifusin de IP y se conectaron a las redes dorsales de multidifusin ("Multicast Backbone", Mbone). Las aplicaciones de TR requieren servicios de deteccin de medios y sincronizacin de flujos. Estas funciones propias de los protocolos de transporte, no se integran como capas aisladas del protocolo sino como parte de la aplicacin. Esto permite especificar tramas o marcos del protocolo que definen la estructura de las unidades de datos. Los algoritmos requeridos para el control de flujo y las estrategias de retransmisin son diseados en funcin de los requerimientos de la aplicacin e integrados en sta. A este diseo se le denomina nivel estructural de la aplicacin ("Application Level

Framing ALF").

3.2. Servicios de Comunicacin Integrados. TCP no es un protocolo adecuado para la transmisin de datos en tiempo real ya que su mecanismo de recuperacin de paquetes provoca que los datos transmitidos a tiempo deban esperar a que todas las peticiones de retransmisin se realicen. Esto genera una gran cantidad de retardos en los muy frecuentes casos de prdida de informacin. Este problema se puede evitar utilizando un protocolo de tipo datagrama (sin conexin) como UDP, que no asegura una comunicacin confiable pero elimina el mecanismo de retransmisin; se puede implementar una aplicacin sobre UDP con slo integrarle algunas funciones. El concepto ALF propone integrar estas funciones dentro de las aplicaciones de comunicacin, permitiendo implementar sistemas ms eficientes. Por otro lado, la integracin de funciones tradicionales de un protocolo de transporte a una aplicacin, trae algunas implicaciones, como el que la aplicacin controle el tamao de los paquetes de la red. ALF maneja este problema proponiendo paquetes de tamao estndar para todas las funciones de la pila de comunicaciones, lo cual incrementa el desempeo del sistema y su implementacin es ms eficiente. Para soportar la interoperabilidad entre aplicaciones, ALF define marcos que describen principalmente el formato de las unidades de datos del protocolo, no definen los algoritmos de control de flujo ni las estrategias de retransmisin, esto se define en base a los requerimientos de la aplicacin.

4. PROTOCOLOS DE COMUNICACIN. Los protocolos de comunicacin son las reglas que los equipos de datos siguen para realizar transferencias de informacin entre ellos. Se programan o construyen como mquinas o procesos intercomunicantes, como se muestra en la Figura 2.

!74.084 

!74.084 

Figura 2. Modelo de sistemas intercomunicantes.

Los mensajes que intercambian los sistemas siguiendo los protocolos, normalmente tienen una estructura que considera toda la informacin que necesita la red para transportar la informacin hacia el sitio donde se requiere, y desde luego el espacio en donde dicha informacin se transportar.

Los servicios y funciones que realizan los protocolos estn contemplados en procedimientos estndar que los definen [6], como son los siguientes: Procedimiento de conexin y desconexin Procedimiento de transferencia de informacin y control de flujo Procedimientos de recuperacin en casos de error Procedimientos de fragmentacin y reensamble Procedimientos de enrutamiento Procedimientos de seguridad Procedimientos de coordinacin de manejo de formatos Procedimientos de manejo de nombres y directorios

Estos procedimientos se implementan en mdulos de hardware y/o software, que son parte de las tarjetas de red, los sistemas operativos o los protocolos de aplicacin. Una contribucin que fue trascendental para las comunicaciones de las computadoras fue la arquitectura de sistemas abiertos adoptada por la ISO y por la UIT a finales de los 70s.
3 U R WR F R OR V 8 V X D U LR  8 VX D U LR
6 RIWZ DUH G H
1 LYH O  $ S OLFD F LyQ 1 LYH O  3 UH VH QW D F LyQ 1 LYH O  6 H VLyQ 1 LYH O  7 UD QV S RUW H 1 LYH O  5HG 1 LYH O  ( QOD F H 1 LYH O  ) tV LF D 1 LYH O  $ S OLFD F LyQ 1 LYH O  3 UH VH QW D F LyQ 1 LYH O  6 H VLyQ

D S OLF D F Ly Q 6 2 

3 U R WR F R OR V 8 V X D U LR  5 H G

5('
1 LYH O  5HG 1 LYH O  ( QOD F H 1 LYH O  ) tV LF D

1 LYH O  7 UD QV S RUW H 1 LYH O  5HG

7 DUMH WD G H

UHG

1 LYH O  ( QOD F H 1 LYH O  ) tV LF D

0 H G LR ) tVLFR

Esta arquitectura se muestra en la Figura 3. La arquitectura de la ISO se ha modificado para adecuarla a los desarrollos que finalmente se impusieron en el mercado mundial,

9 Figura 3. Arquitectura OSI

como es el caso de Internet que tiene la estructura mostrada en la figura 5; sin embargo sus principios y funciones originalmente previstas han sido la pauta para el impresionante desarrollo que han experimentado las redes de comunicaciones.

0 DLO )73 7HOQHW 7&3 ,3

0 DLO 7HOQHW )73

5HG
,3 //& 0 $& 3+ <30 ' 0 HGLR )tVLFR
Figura 4. Arquitectura Internet.

7&3 ,3 //& 0 $& 3+ <30 '

,QWHUID] GH 5HG

//& 0 $& 3+ <30 '

4.1. Protocolos de Aplicacin. Como se ve en la Figura 4, Internet est cimentado en los protocolos TCP/IP, los cuales constituyen parte del software de comunicaciones estndar que incluyen los sistemas operativos como Unix, Windows y Sistema 7.x. Sobre estos protocolos operan los protocolos de aplicacin bsicos de Internet como son el protocolo de terminal virtual Telnet, el protocolo de transferencia de archivos FTP y el protocolo de correo electrnico SMTP, adems de las primitivas de los servicios de comunicacin para crear sistemas cliente-servidor como son los sockets y los RPCs; y de otros protocolos relativamente nuevos, como el protocolo de transferencia de archivos de hipertexto HTTP. Los protocolos de aplicacin corresponden al nivel siete o nivel superior del modelo OSI. De acuerdo con el estndar, este nivel proporciona los servicios de comunicacin entre los diferentes procesos de aplicacin que constituyen el sistema. Se dividen en cinco grupos que son los siguientes: Grupo 1. Protocolos de administracin del sistema de interconexin. Estos protocolos son los que se emplean en las redes de computadoras para dar de alta, configurar e interconectar lgicamente los distintos equipos que constituyen la red

10

Grupo 2. Protocolos orientados a la administracin de la ejecucin de procesos de aplicacin, tales como los de administracin de acceso a partes determinadas del sistema, resolucin de problemas de interbloqueo, contabilidad y facturacin, etc. Los actuales marcos o paredes de fuego ("firewalls") forman parte de este conjunto de protocolos. Grupo 3. Protocolos de comunicacin entre procesos de aplicacin como comunicacin entre tareas, activacin remota de procesos, activacin remota de los sistemas, manejo de archivos, etc.. ISO define cuatro protocolos de aplicacin bsicos para la operacin de redes: Servicio de terminal virtual. Servicio de manejo de archivos. Servicio de manejo de tareas y transferencia de datos. Sistema de manejo de mensajes.

Este conjunto de protocolos evidentemente representa los servicios bsicos que brindan las redes de computadoras. A estos se pueden agregar otros nuevos protocolos, ms sofisticados y funcionales, como el protocolo HTTP utilizado para la transferencia de archivos de hipertexto y los agentes autnomos inteligentes que estn en proceso de desarrollo. Grupo 4/5. Protocolos especficos para aplicaciones industriales, de clculo, de manejo de informacin bancaria, de telereservaciones, etc. Entre stos se pueden incluir los protocolos de aplicacin que se utilizarn para operar y administrar servicios para edificios inteligentes, tarificacin remota de servicios, comercio electrnico, dinero electrnico, etc.

4.2. Protocolo HTTP El protocolo HTTP y el lenguaje de manipulacin de hipertexto HTML son los elementos clave de la operacin del servicio WWW ( World Wide Web ) que ha puesto en la cspide de la popularidad a la Internet. La Figura 5 muestra esquemticamente la estructura de operacin de la WWW. Las pginas WWW o pginas electrnicas son archivos de hipertexto que los navegadores ( browsers ) se encargan de interpretar y presentar adecuadamente al usuario. Los navegadores solicitan la conexin con un servidor WWW y una determinada pgina HTML, por medio de su localizacin o URL ("Unit Resource Location), y ste la transmite al navegador por medio del protocolo HTTP, a travs de la

11

red de Internet, sobre los protocolos TCP/IP. Los navegadores como Netscape, Microsoft Explorer, Mosaic, etc. se han desarrollado bajo estos principios.

 , 80 / 0

' DWRV +70/

& OLH Q WH 1 D Y H JD G R U

6 H UY LG R U : HE

7&3,3

7&3,3

0 H G LR GH & RP XQLFDFLyQ

Figura 5. Arquitectura del Servicio WWW de Internet.

4.3. Protocolo de Transporte en Tiempo Real (RTP). RTP es un protocolo de nivel de aplicacin que proporciona funciones de comunicacin en TR, para transmisin de datos como audio y vdeo digital o datos de simulacin en transmisiones unidifusin o multidifusin [3]. El conjunto de funciones que proporciona RTP es el siguiente: Identificacin de tipos de datos de usuario. Secuencias numeradas. Marcado del tiempo ("time stamping)". Monitoreo de la QoS de la transmisin de datos.

RTP se compone de dos protocolos: Protocolo de datos RTP. Para transmisin de paquetes de datos en TR. Protocolo de control RTCP. Para realizar monitoreo de la QoS y minimizar la transferencia de informacin de control a los participantes de una sesin de audiovdeo.

RTP y RTCP son independientes de las capas de transporte y de red, generalmente corren sobre UDP/IP. RTP se implementa como parte de la aplicacin y no como parte del ncleo del sistema operativo [1]. RTP es un protocolo de datos que tiene como funcin la transmisin de paquetes de datos en TR. Cada paquete de datos de RTP se compone de una Encabezado seguida de los datos de usuario. Los primeros 12 bytes

12

de la Encabezado son fijos, los datos de usuario pueden ser cuadros de video o archivos de audio. Algunos de los campos importantes de la Encabezado RTP son los siguientes: Tipo de dato: Identifica el formato del paquete RTP, por ejemplo H.261 para sistemas de vdeo o GMS para flujos de audio. Marcador: Identifica eventos significativos inherentes a los datos de usuario; por ejemplo, el inicio de un segmento de audio o el final de un cuadro de vdeo. Nmero de secuencia: Se incrementa en uno por cada paquete enviado. Este puede ser utilizado por el cliente para detectar la prdida de paquetes y de la secuencia de stos. Marca de tiempo: Representa el instante en que el paquete fue generado. Se utiliza para la sincronizacin y para el clculo de variaciones del retardo ("jitter").

4.4. Protocolo de Control de Tiempo Real (RTCP). El protocolo de control RTCP se encarga de transmitir paquetes de control, peridicamente, a los participantes de una sesin de audio o vdeo; estos paquetes de control permiten monitorear las condiciones actuales de la red e identificar a los participantes de la sesin. A este proceso se le conoce como retroalimentacin. Los paquetes que corresponde al monitoreo de la QoS, permiten obtener datos estadsticos de las condiciones de trfico de la red que permiten tomar acciones de control. Esta informacin se transmite como informes a los participantes. Estos informes son de dos tipos: Informe del Transmisor (SR) e Informe de Receptor (RR). Ambos informes SR y RR contienen informacin estadstica del desempeo de la red con relacin al nmero de paquetes perdidos, nmero de la secuencia ms alto, variaciones y otras mtricas que permiten calcular el tiempo total de ida y vuelta de los paquetes; los informes SR contienen informacin resumida de los datos transmitidos por el emisor, como son: marcas de tiempo y contador de paquetes, entre otros. Recordemos que los protocolos RTP/RTCP se implementan en el nivel de aplicacin, los paquetes RTP son encapsulados en los paquetes UDP y transmitidos por medio de IP, podemos ver un esquema de una transmisin de audio/video en tiempo real en la Figura 6.

'DWRV573 7UDQVPLVRU 5HSRUWHV55

13 Figura 6. Transmisin de Informes de Control.

5HFHSWRU

$SOLFDFLyQ 'HFRGLQJ (QFRGLQJ (QFRGLQJ

$SOLFDFLyQ 'HFRGLQJ

573

57&3

57&3

573

8'3 R $70$$/

8'3 R $70$$/

Figura 7. Arquitectura del Sistema con RTP/RTCP.

Esta informacin de retroalimentacin es muy til para los dos componentes (transmisor/receptor), ya que les permite modificar sus condiciones de trabajo en base a la informacin obtenida de sus receptores. Con esta informacin se puede determinar cuando los problemas de recepcin o transmisin son locales, regionales o globales, tambin se puede utilizar para monitorear el desempeo de la red y diagnosticar problemas. Los mensajes RTCP se transmiten a la misma direccin IP de los correspondientes flujos RTP pero por otro puerto. Las aplicaciones adaptivas frecuentemente utilizan los informes del transmisor o del receptor para adaptar sus transmisiones a las condiciones actuales de la red. Cuando se incrementa la tasa de prdida de los paquetes, puede haber un indicador de sobrecarga de la red, por lo que el transmisor puede disminuir su velocidad de transmisin. Por ejemplo; una aplicacin de vdeo puede conmutar a un esquema de codificacin que consume menos ancho de banda. Cuando la carga de la red disminuye, el transmisor puede conmutar a un esquema de codificacin de ms calidad que requiere ms ancho de banda. RTP generalmente corre sobre UDP/IP pero puede correr sobre otros protocolos como TCP/IP o AAL5/ATM. Un esquema de esta arquitectura se muestra en la Figura 7.

14

4.5. Protocolo de Reservacin de Recursos (RSVP). Cierta clase de aplicaciones requiere garantas de QoS, esto es posible mediante la reservacin de recursos tales como: capacidad de procesamiento y memoria en los sistemas finales e intermediarios. Tambin requieren reservar cierto ancho de banda para satisfacer su demanda de transmisin. Antes de reservar los recursos, el administrador de estos debe asegurar que existan recursos suficientes para satisfacer la solicitud (control de admisin), si no los hubiere se rechaza la solicitud; los recursos deben asignarse a las aplicaciones fuente de los paquetes de datos. Los sistemas deben verificar que los datos enviados no excedan la capacidad de los recursos reservados, los datos que excedan la estimacin de trfico negociada pueden ser descartados o negociados con un nivel de prioridad menor al de los datos que conforman la especificacin acordada. Los recursos se reservan de acuerdo a la especificacin de trafico escrita conforme al modelo "recipiente de estafeta".

5. LA SIGUIENTE GENERACIN DE IP. Actualmente Internet es utilizado por instituciones, compaas y usuarios los cuales se incrementan rpidamente (se dice que en la actualidad Internet tiene 150 millones de usuarios), con lo cual han surgido varios problemas. Primero, la demanda de direcciones Internet crece tan rpido que se considera que el espacio proporcionado por IPv4 no ser suficiente dentro de algunos aos, si la demanda sigue creciendo al mismo ritmo (el nmero de usuarios se est duplicando cada dos aos). Segundo la congestin en Internet se est haciendo cada vez ms comn a pesar de los constantes aumentos en los anchos de banda de las redes. Otro de los factores importantes que se debe considerar es la prdida de informacin por congestin, ya que aplicaciones tales como transferencia de archivos y correo electrnico las toleran, en contraste con las aplicaciones de tiempo real que no toleran prdidas de informacin o retardos [5]. Las aplicaciones de tiempo real que trabajan con RTP se desempean bien en redes con trfico ligero sin importar el ancho de banda disponible. Sin embargo, los sistemas de comunicacin que trabajan con RTP y (UDP o TCP)/IP no cuentan con mecanismos que garanticen la QoS en cuanto a retardos y caudal. Para garantizar la QoS se han desarrollado protocolos que permiten a las aplicaciones negociar sus requerimientos de QoS entre el conmutador IP y el sistema final. Entre los primeros protocolos que utilizaron estos mecanismos se encuentra el protocolo de flujo (SP), este protocolo primero estableca la comunicacin entre las

15

partes a conectar, posteriormente los conmutadores y ruteadores involucrados intercambiaban los parmetros de QoS requeridos por la aplicacin y reservaban los recursos necesarios para satisfacer estos requerimientos. Posteriormente s desarrollo el Protocolo de Reservacin de Recursos (RSVP), este protocolo no establece conexin explcitamente ya que se basa en el concepto de flujo. Un flujo es una secuencia de paquetes para el cual la fuente requiere de servicios especiales o de tiempo real. Un concepto directamente relacionado con RSVP es el de multidifusin IP orientado al receptor.

5.1. IPv6. En 1994 se decidi desarrollar una nueva versin del IP. Esta nueva versin de IP incorpora opciones y funciones de IPv4 que no estn incluidas en todas las aplicaciones IP. Tambin se le han incorporado nuevas funciones como QoS y mecanismos de seguridad. Su nuevo formato de direcciones no slo resuelve el problema del espacio de direccionamiento sino que tambin da soporte a los sistemas autoconfigurables.

5.2. Direccionamiento. IPv6 cuenta con un campo de direcciones de 128 bits, aproximadamente 6.25 x 1023 direcciones. Este campo de direcciones permite establecer varios niveles jerrquicos, por ejemplo, el bit ms significativo define el tipo de direccionamiento: unidifusin, difusin de grupo y multidifusin. Un direccionamiento unidifusin identifica una sola interfaz de ruteador o sistema final, en el que el paquete que se enva es recibido por una sola interfaz definida explcitamente. Un direccionamiento de grupo de difusin permite identificar interfaces de sistemas IP diferentes, un ejemplo del uso de este tipo de direccionamiento es para balancear la carga de trabajo. Por ejemplo un conjunto de servidores puede compartir una misma direccin de grupo de difusin, cuando se presenta una solicitud de servicio esta se canaliza al servidor con menos carga. El direccionamiento multidifusin es la base que fundamenta los mecanismos de control de IPv6. Este direccionamiento permite identificar grupos que se encuentran registrados o no, define el alcance de los grupos que pueden estar limitados a nodos, enlaces, sitios u organizaciones o tener validez global. 5.3. Formato del paquete. El encabezado de IPv6, Figura 8b, ha experimentado varios cambios, por ejemplo el encabezado mnimo de IPv6 es ms pequeo que el de IPv4, Figura 8a. Esto aumenta la velocidad de procesamiento de IP. Los campos longitud, verificador, tipo de servicio

16

e identificacin han sido eliminados. Los campos restantes del IPv4 cambiaron de nombre pero no de funcionalidad [4]. El nico campo nuevo en el IPv6 es la etiqueta de flujo que se aplica a las comunicaciones TR. Si la aplicacin o la red requieren de informacin adicional esta se codifica por separado en encabezados de extensin insertados despus del encabezado principal; el orden de estos encabezados es el siguiente: S S S S S S S S Encabezado IPv6. Opciones salto-a-salto a ser procesadas en cada salto. Opciones destino para ser procesadas por el nodo destino identificado por la direccin destino y los nodos especificados en el encabezado de enrutamiento. Encabezado de enrutamiento. Encabezado de fragmento. Encabezado de identificacin. Encabezado de encriptado. Opciones destino para ser procesadas en el nodo destino final.

9HUVLRQ +HDGHU !70.0/03.0 7\SH RI 7RWDO OHQJWK OHQJWK VHUYLFH ,GHQWLILFDWLRQ )ODJV )UDJPHQW RIIVHW 7LPH WR OLYH 3URWRFRO 6RXUFH DGGUHVV 'HVWLQDWLRQ DGGUHVV
(a) Encabezado de IPv4.

9HUVLRQ

3ULRULW\

)ORZODEHO 1H[W 6RXUFHDGGUHVV +RSOLPLW

3D\ORDGOHQJWK

+HDGHU FKHFNVXP

'HVWLQDWLRQDGGUHVV
(b) Encabezado IPv6

Figura 8. Formatos de Encabezado IPv4/6.

6. EL FUTURO DE LOS SISTEMAS DE COMUNICACIN EN INTERNET. Internet se basa principalmente en el protocolo IP, el cual podemos considerar como ineficiente ya que los paquetes pueden perderse, duplicarse o llegar fuera de secuencia. Para solucionar este problema se desarroll TCP que proporciona los mecanismos necesarios para hacer confiable a IP. TCP se encarga de retransmitir los paquetes perdidos o aqullos que llegaron demorados asegurando la llegada de todos los paquetes al destino. Sin embargo, este mtodo de retransmisin aade retardos adicionales a la transmisin por lo que no podemos garantizar la liberacin de paquetes a tiempo.

17

En la Figura 9 se muestra la arquitectura propuesta para los nuevos sistemas de comunicacin en Internet [4]. Como se observa en la figura, la versin 6 de IP (IPv6) podr coexistir con la versin 4 de IP (IPv4), RSVP ser ms solicitado que el servicio de ME, aumentando el surtido de comunicacin de Internet, adems podr correr como un protocolo de sealizacin paralelo al (UDP o TCP)/IP. En esta arquitectura slo se indica que las aplicaciones de tiempo real y de WWW tienen acceso a las funciones de reservacin de recursos de RSVP. Esto no significa que otras aplicaciones no puedan utilizar estas funciones.

$SOLFDFLRQHV ,QWHUQHW HVWiQGDU 61031)6

$SOLFDFLRQHV PXOWLFDVW FRQILDEOHV 650

$SOLFDFLRQHV 7LHPSR5HDO DXGLRYLGHR 573 5693 ,3Y 5HG

3URWRFRORVGH DSOLFDFLRQHV ::: +7735693 7&3

$SOLFDFLRQHV ,QWHUQHW HVWiQGDU )731)6

8'3

Figura 9. Arquitectura de un sistema de comunicacin Internet.

6.1. Soporte de QoS. Este servicio se define por un valor de prioridad incluido en la Encabezado IP y por una etiqueta de flujo que identifica flujos de datos individuales. El campo prioridad permite a la fuente definir la prioridad del paquete. La prioridad es relativa a cada fuente. Los valores de prioridad se dividen en dos grupos, los valores del 0 al 7 se utilizan para tipos de trfico con control de congestin integrado, los valores del 8 al 15 se utilizan para tipos de trfico sin control de congestin, por ejemplo, transmisiones de tiempo real con velocidad constante. La prioridad 8 puede utilizarse en paquetes en donde el transmisor puede tolerar la prdida de informacin, ya que en condiciones de congestin los paquetes de menor jerarqua son eliminados primero para disminuir el trfico. Los paquetes que requieren manejo especial se identifican con la etiqueta de flujo. El tipo de manejo espacial se puede comunicar a los ruteadores por medio de un protocolo de sealizacin como RSVP o con informacin contenida en el mismo paquete, por ejemplo en las opciones salto-a-salto [7].

18

7. CONCLUSIONES. Aun con los avances que se han presentado en este trabajo y los servicios que se proporcionan para ayudar a reducir la congestin en la red, el dramtico crecimiento de usuarios de Internet y la creciente demanda de aplicaciones de tiempo real y la garanta de servicios podra implicar que Internet requiera de servicios de reservacin de recursos con diferentes clases de servicio tales como mejor esfuerzo, control de carga, garantas y posiblemente otros. Una de las problemticas ms claras en el uso de estos servicios y arquitecturas es que no es posible la aplicacin de estos servicios a nivel de redes de rea amplia ya que no todos los ruteadores y conmutadores soportan la reservacin de recursos, as mismo no existen polticas que determinen cuotas de recursos a cada usuario ya que podra haber aplicaciones que demanden recursos indiscriminadamente, sin ningn control de asignacin. El resultado de este trabajo nos arrojo los siguientes nichos de investigacin: Garantas de QoS para la multidifusin y enrutamiento en la transmisin de paquetes de medios continuos en entornos distribuidos. Monitoreo de QoS en redes de rea amplia. Aplicacin de QoS a nivel de capa de enlace. Control de prioridades a nivel de capa de enlace.

REFERENCIAS. [1] R. El-Marakby, D. Hutchinson, Delibery of Real-Time Contiuous Media over the Internet , Proccedings of the 2nd IEEE Symposium on Computer and Comunications (ISCC97), julio 1997. [2] A. Bestavros, M. Chen, M. Crovella, A. Hedday and S. Sclaroff, Resourse Management for Responsive Web Computing , Boston University, Computer Science Department, March 1996. [3] R. El-Marakby, D. Hutchinson, Towards Managed Real-Time Communications in the Intrenet Environment , Proccedings of the 4nd IEEE Workssalto on the Architecture and Implementation of Higk Performance Communication Systems (HPCS97), june 1997.

[4] T. Braun, Internet Protocols for Multimedia Communications, Part I: Png-The

19

Foundation of Internet Protocols , IEEE Multimedia, Julio-Septiembre 1997, pp. 8590. [5] T. Braun, Internet Protocols for Multimedia Communications, Part II: Resource Reservation, Transport and Application Protocols , IEEE Multimedia, OctoberDecember 1997. pp. 74-82. [6] R. Menchaca, Protocolos de Aplicacin , Laboratorio de Cmputo Paralelo, Centro de Investigacin en Computacin, IPN, mayo 1998. [7] A. Campbell, G. Coulson and D. Hutchinson, A Quality of Service Architectura , Departament of Computing, Lancaster University, 1996. [8] D. Hutchinson, G. Coulson, A. Campbell and G. Blair, A Quality of Service Management in Distributed Systems , Departament of Computing, Lancaster University, report number MPG-94-02, 1994. [9] A. Cilingirogly, S. Lee, A. Agrawala, Real-Time Comunication , Tecnical Report, System Design and Analisis Group, Department of Computer Science, University of Maryland, Jenary 1997. [10] G. Buttazzo, Hard Real-Time Computing Systems, Predictable Scheduling Algorithms and Applications. Kluwer Academic Publishers, 1997.

20