INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS ESTADO DE MÉXICO

DIVISIÓN DE GRADUADOS E INVESTIGACIÓN DIRECCIÓN DE MAESTRÍAS EN INGENIERÍA

11 I 'tl fl,l!:BL,luT!'._t..;A

.:~\, ,,: -

- r, A f ..

CONSIDERACIONES TÉCNICAS PARA LA TRANSMISIÓN DE VIDEO SOBRE REDES PÚBLICAS DE ALTA VELOCIDAD.

Asesor externo:

Comité de Tesis:

Jurado:

FRAME RELAY Y ATM

TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES

PRESENTA:

ING. ALFREDO ZAMORA LÓPEZ

M. en C. José Fernando Tavera Parra

Dr. Luis A. Trejo Dr. Jesús Vázquez

Dr. Jesús Vázquez, Presidente Dr. Luis A. Trejo, Secretario M. en C. J. Fernando Tavera Parra, Vocal

Atizapán de Zaragoza, Estado de México, Diciembre de 1998.

RESUMEN

En años pasados las redes de área amplia, eran consideradas inseguras, lentas, susceptibles de espionaje y aún más, sin una alta confiabilidad de disposición, cuando estás eran requeridas por el usuario, como lo fué la red X.25 TELEPAC de la SCT. En la actualidad, vivimos una tendencia global a la integración de servicios de voz video y datos en las redes de comunicación de empresas, escuelas, instituciones y comercios. El ambiente de las redes locales ha proliferado demasiado en esta integración, lo cual, es debido principalmente gracías a las nuevas tecnologías que ofrecen mayores capacidades de acceso, pérdidas mínimas y una alta confiabilidad y seguridad de la información que transportan. Pero a su vez, la explosión de integrar esas redes locales con otras redes remotas, ya sea alrededor de una ciudad, un país e incluso el mundo entero a través del Internet, han auspiciado un fuerte desarrollo en las redes de área amplia, que a su vez, garanticen a los usuarios integrar de forma segura, confiable, rápida y estandarizada los servicios multimedia. Por todo esto, y evaluando las grandes ventajas económicas y competitivas que representan para cualquier organización el contar con un sistema de videoconferencia interactivo de tiempo real, se ha motivado el desarrollo de este trabajo, que tiene como principal objetivo evaluar la integración de la videoconferencia bajo los estándares H.320 y H.323 con IP, sobre redes de área amplia con tecnologías Frame Relay y ATM.

Hoy por hoy TELMEX a través de Consorcio RedUno, ofrece un servicio de transporte a nivel nacional, a través de su red de fibra óptica conocida como UniNet, la cual, permite el uso de los protocolos X.25, Frame Relay e IP. En esta tesis, más que resolver un problema, se busca desarrollar una nueva área de oportunidad para poder integrar el video sobre el "backbone" de Frame Relay de UniNet y que en un futuro no muy lejano cambiará su núcleo con la tecnología ATM. Las preguntas que se pretenden contestar en este trabajo, atienden a analizar cuál sería la mejor opción de transporte y por que, sus pros y contras, tendencias en los estándares de video, requerimientos mínimos necesarios y una gran cantidad de recomendaciones técnicas que le permitan al usuario poder integrar el video a través de UniNet con Frame Relay y ATM.

El trabajo se soporta en estudios realizados por organismos de normalización, análisis de las tecnologías, fabricantes y pruebas en el laboratorio de Integración y Desarrollo de RedUno.

CONTENIDO

Página

LISTA DE FIGURAS 7

LISTA DE TABLAS 7 , LISTA DE ABREVIACIONES Y TERMINOLOGIAS 8

Capítulo l. INTRODUCCIÓN 9

1.1 Antecedentes 9 1.2 Objetivo 11 1.3 Organización del Estudio 1 1 1.4 Propósito y Limitaciones 11 1.5 Metodología de la Investigación 11

Capítulo 2. TECNOLOGÍA 12

2.1 Los Sistemas de Videoconferencia 12 2.2 La Red Pública UniNet. Descripción y Servicios 15 2.3 Características Generales de Frame Relay 16

2.3.1 El Crecimiento de Frame Relay 18

Capítulo 3. DELIMITACIÓN DEL MARCO TEÓRICO. 19

3.1 El Estándar de Codificación de Video H.261 23 3.2 El Estándar H. 3 20 25 3.3 El Estándar H.323 26

3.3.1 El Protocolo de Transporte de Tiempo Real (R TP) 28 3.4 Requerimientos Técnicos para Transportar Audio y Video Interactivo

de Tiempo Real 31

Capítulo 4. PLANTEAMIENTO DEL PROBLEMA 32

4.1 Video Sobre Frame Relay 32 4.1.1 Causas que Originan los Problemas Técnicos en Frame Relay 33

4.2 Video Sobre ATM 34 4.2.1 Servicios ATM 34

Página

Capítulo 5. DESARROLLO DE LA CONTRIBUCIÓN 41

5.1 Requerimientos de Calidad de Servicio. Propuestas Técnicas Generales para Frame Relay. 41 5 .1.1 Configuración del tamaño de la Trama Frame Relay 41 5. 1.2 Manejo de Esquemas Propietarios de Prioridades por

Circuito Virtual. 44 5.1.3 Adecuación del CIR Atendiendo al Requerimiento Deseado 46 5. 1.4 Ruteo Inteligente de los Circuitos Virtuales 4 7

5.2 Propuestas Técnicas Particulares para Frame Relay 49 5.2.1 Video H.320 Sobre Frame Relay. 49 5.2.2 Video H:323 Sobre Frame Relay. 50

5.3 Propuestas para el Manejo de Video sobre ATM. 53 5.3.1 Video H.320 sobre ATM 53

5.3.1.1 Establecimiento del Circuito 54 5.3.2 Video H.323 sobre ATM 56

5.3.2.1 Capa 5 de Adaptación ATM (AAL5) 57 5.3.2.2 Ventajas del Transporte de Video H.323 sobre VBR 58

5.3.3 Video Paquetizado sobre ABR 59

CONCLUSIONES PARTICULARES Y GENERALES 61

REFERENCIAS Y BIBLIOGRAFÍA 63

ANEXO A. PRUEBAS H.323/FRAME RELA Y 66

ANEXO B. PRUEBAS H.320/ATM 76

LISTA DE FIGURAS

Figura 2.1 Capacidades de Transmisión "Frame Relay" Figura 3 .1 Capacidades Típicas para Diferentes Aplicaciones de Video. Figura 3.2 Capacidades de Transmisión y Retardos para Diferentes Aplicaciones de Video. Figura 3.3 Sistema Visual H.320. Figura 3.4 Componentes de una Terminal H.323. Figura 3.5 Protocolos H.323. Figura 3.6 Arquitectura del Protocolo RTP. Figura 4.1 Función de Densidad de Probabilidad de Retraso de Celda Figura 5.1 Procesamiento de Diferentes Tamaños de Tramas. Figura 5.2 Tolerancia de Retraso de Videoconferencia contra el Retraso de Algunos Equipos. Figura 5.3 Interoperabilidad "Frame Relay"/ATM. Figura 5 .4 Video Servicio en la Nube "Frame Relay" con CFR Figura 5. 5 Resource Reservation Protocol Figura 5.6 Reservación en un Nodo en la Ruta de Flujo de Datos. Figura 5.7 Parámetros de Información para el nivel de adaptación 1 de ATM

LISTA DE TABLAS

Tabla 1.1 Diferentes Aplicaciones de Video. Tabla 2.1 Implementation Agreements From "Frame Relay" Forum. Tabla 3.1 Diferentes Aplicaciones de Video, Fuente Cisco Systems. Tabla 3.2 Capacidades de Transmisión y Retardos para Diferentes Estándares de Video. Tabla 3.3 Parámetros de Resolución de Video para H.261, CIF y QCIF.

7

Tabla 3.4 Diferentes Formatos de Codificación del Video Digital que Utilizan el Estándar H.261. Tabla 4.1 Características de las categorías de Servicio ATM. Tabla 4.2 Areas de Aplicación para las Categorías de Servicio ATM. Tabla 4.3 Atributos de las Categorías de Servicio ATM. Tabla 5.1 Servicio de Parámetros QoS y Aplicaciones. Tabla 5.2 Diferentes Equipos para Incorporar H.320 sobre "Frame Relay". Tabla 5.3 Soporte de Estándares del Algoritmo H.263. Tabla 5.4 Formatos de Imagen para Videoconferencia ITU-T.

8

LISTA DE ABREVIACIONES Y TERMINOLOGÍAS

ATM BISDN bps CIF FDDI fps ftp HDLC Hz ICMP IETF IP LAN MCU PC Ping PSTN RAM TCP UDP www

"Asynchronous Transfer Mode", Modo de Transferencia Asíncrono "Broadband ISDN', ISDN de Banda Ancha "bits per second", bits por segundo "Common Intermediate Format", Formato Intermedio Común "Fiber Distributed Data Interface", Interface de Datos Distribuidos de Fibra "frames per second", tramas por segundo "file transfer protocol", protocolo de transferencia de archivos "High Data Link Control", Control de Enlace de Alto Nivel

Hertz "Internet Control Message Protocol", Protocolo de Control de Mensajes Internet "Internet Engineering Task Force", Fuerza de Ingenieros de Internet "Internet Protocol", Protocolo de Internet "Local Area Network", Red de Area Local "Multi - Conferencing Unit" "Personal Computer", Computadora Personal "ICMP echo request/echo reply", Solicitud/Respuesta de Eco. Generado por ICMP "Public Services Telephone Network", Red de Servicios Telefónicos Públicos" "Random Access Memory", Memoria de Acceso Aleatorio "Transmission Control Protocol", Protocolo de Control de Transmisión "U ser Datagram Protocol", Protocolo de Datagrama de Usuario "World Wide Web", Telaraña Alrededor del Mundo

9

CAPÍTULO l. Introducción

Esta tesis analiza y describe una serie de recomendaciones para incorporar el transporte de videoconferencia bajo los estándares H.320 y H.323 con IP, sobre redes públicas de conmutación de paquetes "Frame Relay" y ATM. Así como también, da (l)un análisis detallado de estos dos estándares que actualmente son muy usados por la mayoría de los usuarios de videoconferencia, (2) una visión de las tendencias hacía el video de escritorio y (3)los pros y contras de cada una de estos estándares sobre las tecnologías de redes en cuestión.

Este proyecto es una necesidad actual de la empresa Consorcio Red Uno, quien es a su vez una filial de TELMEX, y cuya misión está enfocada principalmente a la integración de redes de voz, video y datos. El tema, corresponde a una respuesta a la tendencia global en la integración de estos servicios, sobre redes públicas de conmutación de paquetes, disipando la creencia tradicional de que el tráfico con diferentes características debe ser transportado por redes separadas [ 1, 16], y debido a que en el terreno de la transmisión de video se cuenta actualmente con muy poca información acerca de las técnicas y tecnologías más confiables para implementar este servicio por redes públicas de alta velocidad de conmutación de paquetes, como lo son "Frame Relay" y ATM.

1.1 ANTECEDENTES

Actualmente los servicios de videoconferencia que se ofrecen en nuestro país son relativamente caros y se presentan únicamente contratados como enlaces privados TDM ("Time Division Multiplexing", Multiplexación por División de Tiempo) y fuera del alcance económico de muchas pequeñas y medianas empresas, que bien podrían incorporar este servicio como una herramienta de ahorro y productividad. Vale la pena resaltar que en nuestro país no se encuentra disponible aún la tecnología de las Redes Digitales de Servicios Integrados (RDSI), que en otros países ofrece una excelente alternativa para el transporte de video interactivo.

Dentro de las necesidades de video interactivo y de tiempo real que actualmente son más demandadas por sus implicaciones comerciales y productivas en nuestro país, se encuentran principalmente las siguientes[7,38]:

Educación a Distancia Reuniones de Ejecutivos Diseño Colaborativo Supervisión de Procesos Productivos Estudios Financieros Compras Administración de Juntas Manejo de Crisis Vigilancia Remota Juntas corporativas, etc.

lO

Es claro observar que los servicios anteriores requieren de la transferencia de video en tiempo real e interactivo y que en su mayoría no se necesita de una alta resolución ni definición de la calidad del video, es decir, hablaríamos entonces de que las aplicaciones a evaluar son las clásicas de videoconferencia y/o teleconferencia, en donde lo que importa es recibir una señal clara y entendible de audio y una imagen continua y definida de video que probablemente no sea apropiada para transmisiones de personas u objetos en movimiento constante. Para el caso particular de una sesión de video interactiva esta puede caer en cualquiera de las dos posibles aplicaciones [6] consideradas en la tabla 1.1, por lo tanto, el estándar de video a considerarse en esta tesis debe poder adaptarse a ambos casos.

Tabla 1.1. Diferentes aplicaciones de video.

Aplicaciones Flujos de Datos Almacenados Tiempo Real Interactivo

Punto a Punto Correo Multimedia (El cual incluye Videotelefonía imágenes o video) Videoconferencia

LAN TV (Información almacenada) Educación a Distancia Entrenamiento Corporativo Kioskos

Multipunto Broadcast Financiero Videoconferencia Difusión en Vivo

Por otro lado, vale la pena resaltar cuales son los beneficios potenciales que representa el reunir personas situadas en diferentes lugares geográficos a través de los servicios de video: pueden compartir ideas, conocimientos e información, para solucionar problemas y para planear estrategias de negocios utilizando técnicas audiovisuales sin las inconveniencias asociadas de viajar, gastar dinero y perder tiempo. La videoconferencia ha capturado la imaginación de las personas de negocios, lideres gubernamentales y educadores. El utilizar los servicios de video proporciona de entre otros los siguientes ahorros y ganancias[?]:

Ahorro en costo de viajes. Cuando se permanece en el lugar de trabajo y se hace uso de la videoconferencia punto a punto o multipunto, en vez de viajar, se ahorra a raíz de la reducción en los costos del viaje y los relacionados al mismo, tales como boletos de avión, hotel, viáticos, alquiler de vehículos, etc.

Ahorro en productividad. Es la reducción en el tiempo perdido por un individuo productivo con motivo del viaje, como por ejemplo, el tiempo empleado en la preparación del viaje, el desplazamiento, la instalación, etc. Dentro de este punto se pueden resaltar otras ganancias tales como: la participación de más miembros del personal, toma de decisiones más expedita, mayor fluidez de la comunicación dentro de la empresa, reducción de la fatiga y del tiempo de viaje, y evitar la acumulación de trabajo durante la ausencia.

Ganancias estratégicas. Son las fuertes ventajas en competitividad que alguna organización deriva del uso de servicios de video, dentro de los cuales se pueden citar los siguientes: ventaja competitiva, mejor servicio al cliente, comercialización más expedita, aprovechamiento de recursos escasos así como decisiones más eficaces.

11

1.2 OBJETIVO

El proyecto tiene como principal objetivo evaluar las técnicas, equipos, estándares, configuraciones e implementaciones necesarias para poder transmitir con una razonable eficiencia y calidad, el video interactivo de tiempo real a través de redes públicas de conmutación de paquetes "Frame Relay" o ATM

La documentación y justificación de la evaluación de las tecnologías más adecuadas para la incorporación del servicio de video interactivo de tiempo real transportado por "Frame Relay" y/o ATM, es un trabajo de importancia técnica y comercial para dar una solución real a Consorcio RedUno, que tiene contemplado incluir este "nuevo" servicio como uno más dentro de la gran gama que actualmente ofrece. Es importante resaltar que esta justificación se convertirá en un proyecto mayor de nivel comercial de la misma empresa, y además, ya que no existe un trabajo similar de evaluación, el proyecto llegará a satisfacer las demandas que requieren las empresas nacionales así como ser una base sólida para el futuro de este tópico en el sector académico y de investigación.

1.3 ORGANIZACIÓN DEL ESTUDIO

El capítulo 2 discute, el desarrollo de la tecnología de videoconferencia y el proceso de su desarrollo. Da un panorama general del "backbone" UniNet como tecnología de referencia para el desarrollo de este trabajo, así como del uso, función y crecimiento de "Frame Relay". El capítulo 3, ofrece una justificación del uso del formato de video H.261 implementado en los estándares H.320 y H.323, así como de los principales compromisos técnicos necesarios para su transporte por una red. El capítulo 4 define cuáles y que causas, limitan el transporte de video sobre una red pública "Frame Relay", y el cómo en ATM se incorporan diferentes tipos de servicio para variadas aplicaciones. Y por último el capítulo 5 ofrece una serie de recomendaciones y conclusiones para la implementación del transporte de video sobre las tecnologías en cuestión, y da algunas reomendaciones para trabajos futuros.

1.4 PROPÓSITO Y LIMITACIONES

Esta tesis presenta un punto de vista analítico y técnico que no pretende solucionar un problema, sino más bien recomendar una serie de aspectos que permitan integrar la videoconferencia de diferentes características sobre "Frame Relay y ATM, y que sirvan de referencia para pruebas posteriores en el laboratorio de RedUno, para crear una nueva área de oportunidad de negocios.

1.5 METODOLOGÍA DE LA INVESTIGACIÓN

El Internet ha sido una fuente invaluable para obtener información acerca de estos tópicos. Mucho del material referenciado en esta tesis se encuentra disponible en la red de redes. En la sección de referencias se han incluido todos los URL'S (Uniform Resource Locators, Localidades de Fuentes de Información) que se encuentran disponibles al momento de esta publicación. Debido a la naturaleza del Internet, y en especial del World Wide Web, no existe garantía de que esta información continúe disponible en el futuro en esas localidades.

12

CAPÍTULO 2. Tecnología.

El audio y el video son descritos como aplicaciones de tiempo real. Hay dos posibles significados para esta descripción[22]. El primero implica que los tiempos de "espera" para la llegada de paquetes en el receptor son aproximadamente iguales a las pausas entre los paquetes que están siendo transmitidos. En términos formales se dice que el ritmo de transmisión debe ser igual ( o casi igual) al ritmo de recepción de paquetes, no importa entonces si un paquete toma treinta minutos en alcanzar su destino siempre que el tiempo entre la llegada de paquetes sucesivos permanezca relativamente constante y en periodos de tiempo muy cortos. Esta definición de tiempo real es adecuada para los esquemas de distribución donde hay una fuente y varios receptores, estos últimos sin capacidad de transmisión. La segunda interpretación incluye la primera e implica, además, una mayor restricción: el tiempo de transmisión de los paquetes debe ser corto. Si esto se logra, se permite la interacción entre los participantes. En caso contrario la intervención de uno de ellos ( con una pregunta o comentario) no puede ser detectada por sus contra partes sino tiempo después de que está se generó, con lo que se pierde el sentido de "presencia". Como regla general un retraso de 0.2 segundos es aceptable para audio y video. Un retraso mayor resulta muy notable y afecta la comunicación. Esta última descripción es la que abordaremos en este trabajo

2.1 LOS SISTEMAS DE VIDEOCONFERENCIA.

Las señales de audio y video que se desean transmitir se encuentran por lo general en forma de señales analógicas, por lo que para poder transmitir esta información a través de una red digital, ésta, debe ser transformada mediante algún método a una señal digital, una vez realizado esto se debe comprimir y multiplexar estas señales para su transmisión. El dispositivo que se encarga de realizar este trabajo es el CODEC (Codificador / Decodificador) que en el otro extremo de la red realiza el trabajo inverso para poder representar y reproducir los datos provenientes desde el lugar remoto.

El mercado de la videoconferencia punto a punto estuvo restringido por muchos años debido a la falta de compatibilidad entre los fabricantes de estos equipos hasta que surgió la recomendación H. 261 [28] del Comité Consultivo Internacional para la Telefonía y Telegrafia CCITT, ahora conocido como ITU-T ("International Telecommunications Union, Telecommunications Standarization Sector", Unión Internacional de Telecomunicaciones, Sector de Estandarización en Telecomunicaciones) [9] en 1990. A partir de ello, el mercado de la videoconferencia ha crecido enormemente. El estándar H.261 esta basado en la estructura básica de 64 Kbps de RDSI y permite trabajar servicios audiovisuales a Px64 Kbps, donde P es igual a 1,2, ... ,30. (estándar europeo).

Hay otros tres factores que han influenciado este crec1m1ento: El primero de ellos fue el descubrimiento de la tecnología de videocompresión, a partir del cual, el estándar H. 261 está basado. Mediante la combinación de las técnicas de la codificación predictiva, la transformada discreta del coseno (DCT, "Discrete Cosine Transform"), la compensación de movimiento y la codificación de longitud variable.

13

El segundo factor que ha influenciado este crec1m1ento, es el desarrollo de la tecnología de integración a gran escala (VLSI, "Very Large Scale Integration"), mediante la cual se redujeron los costos de los codificadores de video. Hoy en día en el mercado se pueden encontrar chips a través de los cuales se pueden implantar las tecnologías DCT y de compensación de movimiento, partes del estándar de compresión de video. La tecnología ha llegado a un punto en el cual las estaciones de trabajo y muchas computadoras tienen el poder de procesamiento y las capacidades multimedia1 para originar y reproducir secuencias de audio y video.[23].

El tercer factor es el desarrollo de las redes públicas conmutadas de paquetes, que a diferencia de las redes de conmutación de circuitos, presentan las siguientes ventajas[14]:

• La eficiencia en la línea es mayor, debido al simple enlace nodo a nodo que puede ser dinámicamente compartido por muchos paquetes en todo el tiempo. Los paquetes son enfilados y transmitidos tan rápido como sea posible sobre el enlace. En contraste, con la conmutación de circuitos, el tiempo de enlace nodo a nodo es predefinido usando multiplexación por división de tiempo, mucho de este tiempo puede estar ocioso, debido a que la porción de este tiempo puede que este dedicada para una conexión de datos que esta ociosa.

• Una red de conmutación de paquetes puede transportar en su salida conversiones de velocidades de datos. Dos estaciones de diferentes velocidades de datos pueden intercambiar paquetes, ya que cada una se conecta a su conmutador con su velocidad apropiada.

• Cuando el tráfico llega a ser pesado en una red de conmutación de circuitos, algunas llamadas son bloqueadas; esto es, la red rechaza aceptar solicitudes adicionales de conexiones, hasta que la carga en la red se decremente. En una red de conmutación de paquetes, los paquetes siguen siendo aceptados, pero el retraso para la entrega se incrementa.

• Pueden ser usadas prioridades. De aquí que, si un nodo tiene un número de paquetes enfilados para transmitir, puede transmitir primero los paquetes de la más alta prioridad. Esos paquetes experimentaran por lo tanto menor retraso que los paquetes con menor prioridad.

La conmutación de paquetes también tiene algunas desventajas con respecto a la conmutación de circuitos:

• Cada vez que un paquete pasa a través de la red por un conmutador de conmutación de paquetes, ocurre un retraso que no se presenta en la conmutación de circuitos. Como mínimo, este retraso en la transmisión es igual a la longitud del paquete en bits dividido por la velocidad del canal entrante en bits por segundo; este, es el tiempo que toma el procesar el paquete hacía el "buffer" interno. En suma, puede haber un retraso variable debido al procesamiento y enfilado en el conmutador.

1 "Multimedia es una tecnología interdisciplinaria y orientada a la aplicación que capitaliza la naturaleza multisensorial de los seres humanos y la habilidad de las computadoras para almacenar, manipular y transportar información no numérica como video, gráficos y audio, además de datos numéricos y texto."

14

• Debido a que los paquetes entre una fuente dada y un destino pueden variar en longitud, pueden tomar diferentes rutas y pueden ser sujetos de variación en retraso en los conmutadores que ellos encuentren en su camino, de allí que, el retraso total del paquete puede variar sustancialmente. Este fenómeno llamado ''jitter'', puede ser indeseable para algunas aplicaciones (por ejemplo, en aplicaciones de tiempo real tales como voz telefónica y video).

• El ruteo de paquetes a través de la red, la información de encabezado incluyendo la dirección del destino y en ocasiones la información de secuenciación debe ser agregada a cada paquete, la cual, reduce la capacidad de comunicación disponible para transportar los datos del usuario. Esto no es necesario en la conmutación de circuitos una vez que el circuito es establecido.

• Un mayor procesamiento es involucrado en la transferencia de información usando conmutación de paquetes en vez de usar conmutación de circuitos para cada nodo. En el caso de conmutación de circuitos no hay procesamiento virtual en cada conmutador una vez que el circuito es establecido.

Las redes de conmutación de paquetes públicas, han enfocado sus esfuerzos para mejorar sus servicios haciendo cada vez más atractivo su uso ofreciendo principalmente lo siguiente:

• Bajo costo. El costo de líneas arrendadas y conexiones públicas están muy por debajo de las fuertes inversiones de las redes privadas.

• Capacidad de Transmisión. Los usuarios esperan tener una rápida respuesta cuando interconectan las aplicaciones de sus LAN's a través de las redes públicas.

• Flexibilidad. Los usuarios están buscando que las tecnologías W AN puedan trabajar con todos los protocolos y tipos de datos.

• Seguridad. El garantizar que la información va a llegar a su destino tal y como fue enviada, el garantizar que dificilmente un intruso pueda alterar o monitorear la misma que viaja a través de la W AN, y además garantizar que la red este disponible en el momento en que el usuario la requiera, son algunos de los aspectos más importantes que hacen de una red pública atractiva.

Podrían enumerarse varias características y ventajas que para una organización u empresa traería el incorporar los servicios de las redes públicas, dentro de ellos los más importantes son: No se requiere adquirir los equipos de comunicaciones para la transmisión de datos, tales como conmutadores y las grandes longitudes de cable o fibra óptica para su cometida, y además, no se requiere administrar y operar dichos equipos.

Por otra parte, y considerando que el tema en cuestión son las redes públicas de conmutación de paquetes de alta velocidad "Frame Relay" y ATM, estas añaden las siguientes características ( en comparación con RDSI): Ofrecen circuitos virtuales con velocidades acordes a las necesidades del usuario, permiten contratar únicamente los servicios necesarios según requerimientos, de aquí que se obtiene un ahorro representativo en recursos, inversión, reducción de equipos y gastos recurrentes, permitiéndole así al usuario dedicarse más a su propio negocio. En resumen, el

15

considerar la baja substancial en los equipos de videoconferencia, así como también el abaratamiento y disponibilidad de los servicios de comunicación han hecho que esta industria crezca enormemente y sea cada vez más accesible a más usuarios, lo que posibilita aún más la integración de este servicio multimedia como algo rentable y comercial [22].

2.2 LA RED PÚBLICA UNINET. DESCRIPCIÓN Y SERVICIOS

UniNet es una red pública de datos que opera sobre la red SDH ("Synchronous Digital Hierarchy", Jerarquía Digital Sincronía) de Telmex para enlaces de alta velocidad, la cual ofrece una alta seguridad y confiabilidad en términos de operación, evitando al máximo la pérdida de comunicación de los enlaces debido a fallas por cortes u otras causas, lo anterior es posible mediante el uso del concepto denominado "binado", el cual es un nodo redundante de conmutación con doble anillo de transmisión a fin de que en caso de contingencia el tráfico sea re-enrutado hacía el destino final sin sufrir interrupción. Cuenta con la mayor cobertura a nivel nacional (30,000 Km. de Fibra Optica).

El equipamiento de la red lo integran conmutadores de la marca Cascade©, Ruteadores Cisco© y servidores de comunicaciones de la marca Ascend©, los cuales, son productos líderes en el mercado de las comunicaciones. La red dorsal cuenta con 48 nodos a nivel nacional para tener cobertura en 41 ciudades del país, cuenta con 9 nodos con rutas alternas en las ciudades de México, Guadalajara, Monterrey, Puebla, Querétaro, Mérida, Hermosillo, Chihuahua y Tijuana. Los enlace para la interconexión de los nodos son N XE 1.

Dentro de los servicios que actualmente ofrece UniNet se encuentran los siguientes:

• Frame Relay

~ Dedicado

• X.25

~ Dedicado ~ Transaccional

• IP

~ Dedicado ~ Conmutado

• Internet Corporativo

• Interconexión a Redes Mundiales

~ X.25 y "Frame Relay" vía Global One.

Dentro de toda esta gama de servicios que ofrece UniNet y atendiendo al tema de esta tesis, vale la pena que se resalten algunas de sus principales características de "Frame Relay" para entrar en materia. (El servicio de ATM aún no esta disponible en UniNet).

16

2.3 CARACTERISTICAS GENERALES DE "FRAME RELAY"

Este servicio responde a la demanda de altos volúmenes de tráfico de datos, ofreciendo circuitos desde 16 Kbps hasta 2048 Kbps.

"Frame Relay" (en castellano Relevo de Tramas) es una alternativa para enlaces dedicados de alta velocidad para conexiones de múltiples usuarios. Soporta tráfico variable al ofrecer capacidades de transmisiones mínimas garantizadas y aceptando a la vez tráfico excedente en diferentes intervalos de tiempo. Utiliza el ancho de banda necesario dejando así el ancho de banda restante para el tráfico de otros usuarios o aplicaciones, además en un solo puerto pueden ser configurados varios circuitos virtuales2 que se conectan a otros puertos diferentes de la red y en diferentes topologías.

Las redes "Frame Relay" disponibles de hoy en día se basan en PVC' s ("Permanet Virtual Circuits", Circuitos Virtuales Permanentes), pero a medida que las redes vayan creciendo, estas conexiones permanentes deberán cambiarse a una operación más dinámica tipo SVC ("Switched Virtual Circuits", Circuitos Virtuales Conmutados").

"Frame Relay" ha evolucionado, proporcionando la integración de una única línea de los distintos tipos de tráfico de datos y voz y su transporte por una única red que responde a las siguientes necesidades:

• Alta velocidad y bajo retardo • Soporte eficiente para tráficos de ráfagas • Flexibilidad • Eficiencia • Transportes integrado de distintos protocolos de voz y datos • Interfaces estándares

Los servicios públicos de "Frame Relay" pueden constituir un reemplazo ( con ventajas en los costos) de las líneas dedicadas, o pueden ser una buena interfaz para ser usadas sobre estás líneas. Los servicios públicos de "Frame Relay" podrían permitir la justificación de un enlace con localidades remotas que de otra forma quedarían incomunicadas. "Frame Relay" ofrece ahorros inmediatos a los usuarios de multiplexadores, porque ofrece un mejor control sobre su ancho de banda y costos menores, gracias a un mejor desempeño y menos lastre en las tareas de interconexión de LAN's.

"Frame Relay" es principalmente usado en:

• Empresas con localidades centrales, regionales y remotas que cuenten con redes locales en cada sitio y requieran interconectarse para aprovechar sus recursos de información

• Empresas que requieran automatizar sus procesos al correr sus aplicaciones de datos en forma remota.

2 En la proposición de circuito virtual, lll1a ruta pre-planeada es establecida antes de que cualquier paquete sea enviado. Una vez que la ruta es establecida, todas las tramas entre un par de partes comunicantes seguirán la misma ruta a través de la red. Cada trama contiene un identificador de circuito virtual, así como sus datos.

17

• En redes con conexiones permanentes que utilicen larga distancia

• Múltíples nodos remotos concentrados en un nodo central (topología estrella) o regionalizados (topología de árbol) o nodos principales conectados entre sí (topología malla).

• Implantación de enlaces virtuales para la creación de redes de área amplia (WAN)

• Interconexión de redes mediante enrutadores y FRAD's (Frame Relay Access Device) para el encapsulamiento de otros protocolos.

• Y en general, podemos decir que todas aquellas redes que contengan infraestructura digital son potenciales usuarios de la tecnología "Frame Relay"

"Frame Relay" está optimizado para transportar tráfico ráfaga de LAN' s sobre redes de área amplia. En una red "Frame Relay" un enlace de un El puede soportar 975 circuitos virtuales (1024 menos algunos circuitos reservados), con un gran compromiso de flexibilidad en la capacidad de transmisión por circuito. La capacidad del enlace de acceso físico (mejor conocida como "Access Rate", AR ), impone limitaciones a la habilidad de la red "Frame Relay" para acomodar el tráfico de ráfaga. En efecto, el enlace de acceso físico combinado con la capacidad del puerto del conmutador establece el límite de capacidad de ráfaga superior. Es común monitorear que no todas las fuentes van a utilizar la máxima capacidad de transmisión disponible todo el tiempo. Por lo tanto, se requiere de un sistema para asignar la capacidad de desempeño de diferentes fuentes de tráfico y sus correspondientes circuitos virtuales. El sistema que "Frame Relay" utiliza para asignar capacidades de transmisión a diferentes fuentes de tráfico está gobernado por los conceptos de Capacidad de Información Acordada (CIR, Committed Information Rate), que es la tasa promedio (en bps) a la cual la red garantiza la transferencia de información sobre un intervalo de tiempo T, el cual es definido como: T = Bc/CIR, el Tamaño de Ráfaga Acordado (Be, "Commited Burst Síze"), que es el máximo número de unidades de información que pueden ser transmitidas en el intervalo T, y Capacidad de Ráfaga en Exceso (Be, Excess Burts Size). Véase figura 2.1. [9,37] Ofrecen una excelente explicación de esa tecnología.

Figura 2.1.Capacidades de transmisión "Frame Re/ay"

Port Spe~d

Be cm. = TI""'

No Delive1y

Best-Efforts DeJivery

Guaranteed Delivery

Time

18

Al desarrollo de este trabajo, el Foro Frame Relay3 a aprobado algunas implementaciones al estándar y otras más se encuentran en etapa de desarrollo, esto se resume en la siguiente tabla 2.1

Tabla 2.1 Acuerdos de Implementación. Fuente: Foro Frame Relay

Acuerdos de Implementación Acordados por el Foro Frame Relav

Aprobados: Trabajos Actuales:

U ser to Network SVC atNNI Network to Network Switched Permanent Virtual Connection (SPVC) Switched Virtual Circuit Voice over FR FR/ ATM lnterworking FR Customer Network Management FR/PVC Multicast Service FR ATM/PVC Service Interworking Data Compression over FR

2.3.1 EL CRECIMIENTO DE FRAME RELA Y.

En los dos años siguientes a su primera aparición pública en 1992, los servicios de "Frame Relay" crecieron lentamente. A principios de 1994 el uso de esta tecnología empezó a crecer bruscamente en las siguientes áreas:

• Ingresos del Servicio. En junio de 1995, "Yankee Group" predijo que las ganancias mundiales para los proveedores de servicios "Frame Relay" en E.U. crecerían de $1,633 billón USO para 1997. Un 68% arriba de los ingresos del 94[Fuente: Frame Relay Networks Devices: FRADs or Routers, The Yankee Group, June 1995]

• Ventas de Equipo. El "Yankee Group" también predijo que las ganancias de ventas de FRAD 's y ruteadores equipados con puertos "Frame Relay", crecerían de $543 millones USD en 1995 a $1. 931 billones USD en 1998.

• Número de "Sites" utilizando servicios "Frame Relay". En 1993, acorde a la consultoría de investigación de mercado de "Datapro", se esperaba que el número de puertos utilizados en 1997 fuera de 34,000 cifra que se rebaso por mucho.[Fuente: Re/ay Race, Computer Weekly, April 20, 1995].

[31] Ofrece un panorama más amplio del crecimiento, uso y futuro de esta tecnología.

3 El Foro Frame Relay es una organización sin lucro, dedicada a promover la aceptación e implementación de Frame Rclay, basandose en estándares internacionales. Se encuentra disponible en: http://www.frforum.com

19

CAPÍTULO 3. Delimitación del Marco de Trabajo

Como ya se ha mencionado, el proyecto en si tiene como principal objetivo evaluar los equipos, técnicas y tecnologías disponibles para poder transmitir con una razonable eficiencia y calidad, el video sobre "Frame Relay" y/o A TM, a través de una red pública. Para lograr esto, es indispensable el ubicar el formato y tipo de video digital más adecuado comercialmente para ser transportado por estas tecnologías.

La información de video es provista en una serie de imágenes o "cuadros" y el efecto del movimiento es llevado a cabo a través de cambios pequeños y continuos en los cuadros. Debido a que la velocidad de estas imágenes es de 30 cuadros por segundo, los cambios continuos entre cuadros darán la sensación al ojo humano de movimiento natural. Las imágenes de video están compuestas de información en el dominio del espacio y el tiempo. La información en el dominio del espacio es provista en cada cuadro, y la información provista en el dominio del tiempo es provista por imágenes que cambian en el tiempo (por ejemplo, las diferencias entre cuadros). Puesto que los cambios entre cuadros colindantes son diminutos, los objetos aparentan moverse suavemente.

En los sistemas de video digital, cada cuadro es muestreado en unidades de pixeles o elementos de imagen. El valor de luminancia de cada pixel es cuantificado con 8 bits por pixel para el caso de imágenes blanco y negro. En el caso de imágenes de color cada pixel mantiene la información de color asociada; por lo tanto, los tres elementos de la información de luminancia designados como rojo, verde y azul, son cuantificados a 8 bits. La información de video compuesta de esta manera posee una cantidad tremenda de información; por lo que, para su transmisión o almacenamiento, se requiere de la compresión de la imagen.

Una referencia que muestra diferentes tipos de aplicaciones de video, es la que a continuación se ilustra en la Tabla 3 .1.

De donde podemos observar claramente, que el área de nuestro interés se encuentra ubicado en el tipo de aplicación llamado "Distance Video", Video a Distancia, por las aplicaciones que esta incorpora, que dan concordancia y respuesta a las mencionadas en la parte de antecedentes del capítulo 1 de este documento.

Obsérvese que el estándar H.261/H.320 aparece con una de las opciones con capacidades de transmisión múltiples de 64 Kbps.

20

Tabla 3.1. Diferentes Aplicaciones de Video. Fuente: Cisco Systems /6/.

Application Type LAN-Based video Distance Video Video on Demand (Cable TV / Telco T\

Video Applications • Video courseware/training • Remote • Video on demand

• Desktop Videoconferencing classroom/distance • Near video on demand

• Application sharing learning • Interactive video game~

• Graphic visualization • Videoconferencing

• Video Kiosk • Teleconunuting

• Telejustice

Video codees and Servers • PC-based codees, hardware, and • Standalone codees • Standalone codees software • PC-based (other)

• Video servers hardware/software • Set-top box

• Video servers • Video servers

Video Codee Formats • MPEG, MPEG2, H.320 • MPEG,MPEG2 • MPEG2

• Proprietary-motion JPEG, A VI, • MPEG4 (future) • Existing analog protocc Indeo, Cinepak, others • H.320 I H. 261 (QAM RF modulation)

Network Infraestructure: • Packetized video running over • CBR video running over • Packetized video runni1 Protocol and format layer 2 or layer 3 circuit emulation natively over A TM perspetive • Layer 2 or layer 3 • Packetized video over (future) and Coax or

layer 2 or layer 3; ADSL intemetworking with A TM • Analog video using RF

modulation (today)

Network Infraestructure: • Highly segmented LANs whit • Dedicated or on-demand • A TM fiber networks to Configuration one or few users per segment W AN lines (leased lines, head-end and coaxial

• A TM backbone requirement ISDN, etc) cable to home (hybrid depending on number of videos • Minimun 64 kbps for fiber coax)

• A TM to desktop H.320 protocols • Fiber to the curb or hon

• Minimum 1. 5 Mbps for (FITC,FTTH) MPEG protocols • ADSL

Network Infrastructure: • A TM Quality of Service • A TM Quality of Service • A TM Quality of Servic1 Performance Guarentees • A TM switched multicast • A TM switched or • A TM switched or

circuits permanent circuits permanent virtual

• RSVP (Resource Reservation • RS VP (Resource circuits Protocol) Reservation Protocol)

Networ Infrastucture: • ATM switches • Enterprises switches that • Enterprise switches products • LAN switches support CBR. A TM and • RF nodulators for coaxi

• Routers with LAN switching LAN Conections conections and ATMports

21

Si quisiéramos conocer cuales son las capacidades típicas de transmisión para las diferentes aplicaciones de video digitalizado existentes en el mercado comercial, podemos observar que las aplicaciones interactivas de tiempo real se desenvuelven entre el rango de los 128 Kbps hasta los 1 O Mbps [ 17] (Véase figura 3 .1 ), lo cual, es principalmente debido a los altos costos presentados, para mayores capacidades de transmisión, tanto para su almacenamiento como para su transmisión. De allí que se hayan desarrollado enormemente las técnicas de codificación de imágenes para poderlas transportar en este rango de capacidades que algunos medios de transmisión tales, como el cable coaxial y el cable de par trenzado han restringido. Quizás en un futuro no muy lejano la incorporación de la fibra óptica en la última milla permita desarrollar aplicaciones de video de alta calidad como la del video bajo demanda ó los juegos de video interactivos.

Figura 3. J. Capacidades típicas para diferentes aplicaciones de video./17)

Shared Vi<joo Video Videoon tmaging Virtual Application Maíl Confer~ Demand Aeality

encíng

Virtual re~ lity I !

1

1

lmaging 1

1 1

1 1 MPEGvideol 1

1

Dístanc¡ learning

1

Conterencíng I 1

1 . i 1 I Still vídeo

IS~+ 1

1 I Shared whiteboard i 1 1 1 i 1 1

100 kbps 1 Mbps ~O Mbps 100Mbps

Los psicólogos han determinado que cuando hablamos cara a cara, solo el 7% de lo que es comunicado es transferido por el significado de las palabras, otro 38% proviene de cómo se dicen las palabras y el 55% son con señales de video. De aquí se justifica que la predilección del ser humano por las imágenes es sorprendente, por lo tanto, se debe insistir que en las aplicaciones de video interactivo de tiempo real no se deben tolerar grandes retrasos entre cuadros de imágenes, ya que por su naturaleza el ojo humano debe recibir la información con

1

1

1

22

cierta frecuencia que de al cerebro la impresión de movimiento mas no de aburrimiento y fatiga. Además, debe existir concordancia ó sincronía entre los movimientos de la boca de un locutor y el audio que se recibe de la misma fuente. La máxima tolerancia al retraso de video permisible sin causar aburrimiento en una aplicación de video interactiva, debe ser menor a 300 mili segundos, y el máximo retraso entre cuadro y cuadro debe ser menor a 130 mili segundos [6]. Véase Figura 3.2

Dentro de los principales estándares desarrollados para este tipo de video aplicación el más usado es el H.261, el cual como ya se menciono fue implementado para transportar el video a través de la red digital de servicios integrados RDSI (o por sus siglas en Inglés ISDN, "Integrated Service Digital Network").Véase Tabla 3.2 [6].

Figura 3. 2. Capacidades de Transmisión y Retardos para diferentes aplicaciones de Video

En un sentido: >300ms

Latencia

En dos sentidos: <300ms

Video Kioskos

Video Entrenamiento

Video conferencia

Video bajo Demanda

< 20 Mbps

Imágenes Médicas

Visualización

Video Interactivo de Alta

Resolución

Multiples Flujos de Video

> 20Mbps

Ancho de Banda por Usuario

Tabla 3. 2. Capacidades de Transmisión y Retardos para diferentes Estándares de video

Application Application Average Delay Average Jitter Type Tolerance, Tolerance,

msec. msec. Low end 64 Kbps (H.261) 300 130

Videoconferencing

(G.711, G.722. G.728) 30 130

High end 1.5 Mbps MPEG video 5 6.5

256 Kbps MPEG voice 7 9.1

Extremily high 20 Mbps HDTV video 0.8 1 end

23

3.1 EL ESTÁNDAR DE CODIFICACIÓN DE VIDEO H.261.

La recomendación ITU-T H.261 es un estándar de compresión de video diseñado para comunicaciones con anchos de banda entre 64 Kbps y 2Mbps, medidos en intervalos de 64 Kbps. Está técnica es también conocida como "Px64" donde P va desde 1 hasta 30. H.261 fue diseñado principalmente para videoconferencia sobre ISDN y es especificada en el formato H.320.(20]. H.261 únicamente soporta dos resoluciones de video, las cuales son: CIF (Common lntermediate Format), de 352x288 pixeles y QCIF (Quarter CIF) de 176 x 164 pixeles H.261 puede manejar hasta 30 imágenes codificadas por segundo bajo CIF. Los parámetros CIF y QCIF se definen en la siguiente tabla 3.3

Tabla 3.3. Parámetros de resolución de video para H261. CIF y QCIF.

CIF QCIF Imágenes codificadas por segundo 29.97 ( o submúltiplos

enteros)

Pixeles de luminancia codificados p/línea 352 176 Líneas de luminancia codificados p/imagen 288 144 Pixeles de color codificados por línea 176 88 Líneas de color codificadas por imagen 144 72

El estándar H.261 de codificación de video puede ser incorporado con otros estándares para el transporte de audio, datos, señalización, multiplexación, encriptación y estándares para sesiones de tipo multipunto tal y como se muestra en la tabla 5.

La técnica de compresión de video consiste de tres pasos fundamentalmente, primero el procesamiento de las diferentes fuentes de video de entrada, paso en el cual se realiza el filtrado de las señales de entrada para remover componentes no útiles (sincronización y temporización del monitor de televisión) y el ruido que pudiera haber en esta. El segundo paso es la conversión de la señal a un formato intermedio común (CIF ó QCIF), y por último el paso de la compresión. Las imágenes comprimidas son transmitidas a través de la línea de transmisión digital y se hace llegar al receptor donde son reconvertidos al formato común CIF y son representadas después de haber pasado por la etapa de post-procesamiento.

Mediante la comprensión de la imagen se elimina información redundante, principalmente la información redundante en el dominio de espacio y del tiempo. En general, las redundancias en el dominio del espacio son debidas a las similitudes existentes entre pixeles contiguos de un cuadro dado y aquellas dadas en el dominio del tiempo son debidas a las similitudes contenidas en cuadros contiguos causadas por la inmovilidad o pequeña variación en el movimiento de un objeto. El método para eliminar las redundancias en el dominio del espacio es llamado codificación intracuadros o "intra" simplemente, la cual puede ser dividida en codificación por predicción, codificación de la transformada y codificación de la sub-banda. En el otro extremo, las redundancias en el dominio del tiempo pueden ser eliminadas mediante el método de codificación de intercuadros, que también incluye los métodos de compensación/estimación del movimiento, el cual compensa el movimiento a través de estimación del mismo.

24

El estándar H.261 hace posible el transmitir imágenes de TV de calidad aceptable con bajos requerimientos de capacidad del canal; capacidades que se han reducido lo suficiente para lograr comunicaciones de bajo costo sobre redes públicas digitales conmutadas (por ejemplo ISDN). De la tabla 3.4, [32] se debe enfatizar que el estándar más utilizado comercialmente en nuestro país para aplicaciones de videoconferencia es el H.320. Aunque vale la pena resaltar que el estándar H.323 a acelerado su incorporación en la videoconferencia de escritorio debido principalmente a la facilidad de su uso y acceso, la reducción de los costos del equipo ( cámaras y software) para la PC, al explosivo crecimiento e implementación del Protocolo de Internet (IP), así como también de los nuevos protocolos de transporte para aplicaciones de tiempo real R TP ("Real Time Protocol") y RTCP ("Real Time Control Protocol") [14,29,32], definidos en enero de 1996 bajo el RFC4 (Request for Comment) 1889 por la IETF

Tabla 3.4. Formatos de Codificación de Video Digital que utilizan el Estándar H.261

Recomendación H.320 H.321 H.322 H.323 H.324

Aprobación 1990 1995 1995 1996/1998 1996 Red ISDN B-ISDN y Redes de Redes de PSTN o

ATM, LAN paquetes de paquetes que no POTS ancho de banda garantizan el garantizado ancho de banda

Video H. 261 H. 261 H. 261 H. 261 H. 261 H. 263 H.263 H.263 H.263 H.263

Audio G. 711 G. 711 G. 711 G. 711 G. 723 G. 722 G. 722 G. 722 G. 722 G. 728 G. 728 G. 728 G. 723

G. 728 G. 729

Multiplexaie H. 221 H. 221 H. 221 H. 225.0 H. 223 Control H. 230 H. 242 H. 230 H.245 H.245

H. 242 H. 242 Multipunto H. 231 H. 231 H. 231 H. 323

H. 243 H. 243 H. 243 Datos T. 120 T. 120 T. 120 T. 120 T. 120 Interfaz de Serie. 1.400 AALl 1.363 TCP/IP RTP/RTCP V. 34 comunicaciones ATM 1.361 Serie 1.400 TCPUDP Modem

Serie. 1.400 IP Encriptación ( en revisión) H. 233 (por referencia TBD H. 233

H.233 H. 234 al H. 320) (adaptado al H.234 H.324)

En esta tesis nos enfocaremos principalmente a analizar el desempeño de los estándares H.320 y H.323 sobre IP y estos a su vez sobre "Frame Relay" y ATM, por su tendencia comercial de uso. Por lo tanto, los esquemas de evaluación quedarán conformados de la siguiente forma: H.320 sobre "Frame Relay", H.323 con IP sobre "Frame Relay", H.320 sobre ATM y H.323 con IP sobre ATM.

4 RFC. Término de Internet. El contenido de un RFC puede ser desde una especificación de protocolo oficila, hasta resultados de investigación o propuestas de desarrollo.

1

25

3.2 EL ESTÁNDAR H.320.

La recomendación de ITU-T H.320 [24,28] define al interpelación entre las recomendaciones H.261, H.221. H.242 y H.230, las cuales definen en conjunto una terminal audiovisual para proveer los servicios de videoconferencia (VC) y videotelefonía (VT), sobre la red digital de servicios integrados (ISDN). (Véase figura 3.3). Entre las funciones de la recomendación H.320 se encuentra la definición de las fases del establecimiento de una llamada de un teléfono visual y la definición de 16 tipos diferentes de terminales audiovisuales y de sus respectivos modos de operación.

Figura 3.3. Sistema visual H.320

H.261

Equipo de Codee Entrada/Salida de video - de Video

Equipo de Entrada/Salida Codee de de Audio - Audio - Retardo -· MUX/

DMUX -Inteñase

JPEG, GJ, FAX - RED de red Equipo de Telemática

1

H.242, H.221, H.230 Unidad I Sistema de Control

Multipunto I

H Seiíalización Extremo a Extremo 1 1

1400 Series

Este estándar define la codificación, el entramado, la señalización, el establecimiento de la llamada y el establecimiento de conexiones para videoconferencia en medios de transmisión digital. El estándar incluye también tres algoritmos de audio, G.721, G.722 y G.728. El H.320 provee interoperabilidad entre diferentes fabricantes de codee' s, tales como Picture© Te!, VTEL© y CLI©.

26

3.3 EL ESTÁNDAR H.323

En 1996 la ITU aprobó la especificación H323 [25,27,28,32], la cual representa un conjunto de estándares multimedia para las infraestructuras corporativas existentes (por ejemplo redes basadas en IP). La recomendación H.323 describe terminales, equipos y servicios para comunicaciones multimedia sobre redes de área local (LAN), las cuales no provee una Calidad de Servicio garantizada. Las tenninales H.323 y el equipo pueden transportar voz en tiempo real, datos y video, o cualquier combinación incluyendo videotelefonía.

Las LAN sobre las cuales las tenninales H.323 se comunican pueden ser: Ethernet (IEEE 802.3), Fast Ethernet (IEEE 802.10), FDDI (modo de servicio sin garantía de calidad de servicio), Token Ring (IEEE 802.5).

Algunas de las razones por las que la recomendación H. 323 es importante son:

• H.323 provee estándares de multimedia para las infraestructuras de red existentes, pues está diseñado para compensar la latencia de las redes locales, pennitiendo así, el uso de aplicaciones multimedia sin cambiar la infraestructura de red con que se cuente actualmente.

• Las redes IP locales se vuelven día a día más poderosas. Por ejemplo, las redes Ethernet migran de 1 O a 100 Mbps, sin olvidar que la tecnología de Gigabit Ethernet en algunos años alcanzará la madurez.

• H. 323 provee estándares para la interoperabilidad entre LAN's y otras redes de comunicaciones. Los elementos necesarios para la interacción con redes ISDN y PSTN se encuentran dentro de su cobertura.

Los beneficios aportados por la recomendación H. 323 son:

1. lnteroperabilidad entre terminales que tengan capacidades y características distintas en el manejo de audio, de video o de los protocolos de control.

2. Flexibilidad de participantes. Una terminal que soporta sólo audio, puede interactuar con otras que soportan audio y video, por ejemplo.

3. Independencia del hardware y del sistema operativo de las tenninales.

4. Soporte multipunto o multiusuario. Se soportan conferencias entre dos o más personas.

5. H. 323 proporciona la administración de la carga deseada en la red, es decir, se puede restringir la cantidad de ancho de banda asignado a una conferencia.

La recomendación H.323 abarca las especificaciones técnicas para dar servicio de video y audio en LAN's que no garantizan la calidad de servicio. Dado que su cobertura no incluye el tipo de LAN, proporciona independencia del tipo de red. H.323 define cuatro componentes para un sistema de comunicaciones basado en redes: tenninales, "gateways", "gatekeepers" y unidades de control multipunto (MCU).

27

Las terminales son clientes en una LAN que proporcionan comunicaciones bidireccionales en tiempo real. Todas las terminales deben soportar comunicación de voz, mientras que el video y los datos son opcionales. Asimismo, todas las terminales deben soportar el protocolo H.245 usado para negociar el uso del canal y sus capacidades. Adicionalmente, pueden incorporar los protocolos: Q.931 para la señalización de la llamada y su establecimiento, "Real Time Protocol" (RTP) usado como protocolo de nivel de transporte para aplicaciones de tiempo real, y por último el componente llamado "Registration!Admision Status "(RAS) el cual, es un protocolo usado para comunicarse con un "gatekeeper" . La figura 3 .4 muestra los componentes de una terminal.

El "Gateway" es un elemento opcional en una conferencia H.323 . Este elemento proporciona varios servicios de traducción entre terminales H.323 y otras terminales ITU.

Los "Gatekeepers" son también elementos opcionales, que desempeñan sus funciones principalmente en el control de llamadas y ayudan a preservar la integridad en una red corporativa. Son altamente recomendables.

Por último las Unidades de Control Multipunto soportan conferencias entre tres o más puntos finales.

Figura 3.4. Componentes de una Terminal H.323.

~-------------------------------------------------Video 1/0 equipment Video Codee

1 H.261 , H.263 - - 1

1

Receive 1 Path Dela y

Audio Codee Audio 1/0 equipment G.711, G.722, - - ' G.723, G.728,

G.729. H.225.0 Local Area

Sesion Layer Network User Data Applications Interface

T 120, etc. System Control

H.245 Control •

System Control User '

Call Control Interface H.225.0

RAS Control H.225.0

Data

T-Share T.126

T.124

T.122 T.125

T.123

TCP

Figura 3.5. Protocolos H. 323

T.127

Conference Control & Call Signaling

H.245

1 Q.931 l RAS

IP

LAN

Audio Video

8 H.261

G.722 H.263 G.728 G.723 G.729

® p

UDP

3.3.1 EL PROTOCOLO DE TRANSPORTE DE TIEMPO REAL (RTP).

28

1

1

Sabemos que el protocolo más ampliamente usado de transporte es TCP. A pesar de que TCP ha probado su valor soportando un amplio rango de aplicaciones distribuidas, este no es apropiado para usarse con aplicaciones distribuidas de tiempo real, tales como conferencias de audio y video interactivo y de tiempo real.

Algunas características de TCP lo descalifican para usarse como un protocolo de transporte para tales aplicaciones:

1.- TCP es un protocolo punto a punto que establece una conexión entre dos puntos finales. Por lo tanto, no es apropiado para distribución "multicasf'.

2.- TCP incluye mecanismos para la retransmisión de segmentos perdidos, los cuales llegan después y fuera de orden. Tales segmentos no son utilizados en la mayoría de las aplicaciones de tiempo real.

3.- TCP contiene mecanismos no convenientes para asociar información de temporización, ( "timing '') con segmentos, lo cual es otro requerimiento del tiempo real.

El otro protocolo de transporte ampliamente usado es UDP, el cual no presenta las dos primeras características en la lista precedente, pero como TCP, no provee información de temporización.

29

Por si mismo UDP no provee ninguna herramienta apropiada para aplicaciones de tiempo real. A pesar de que cada aplicación de tiempo real pueda incluir sus propios mecanismos para soportar el transporte de tiempo real, hay algunas características comunes que garantizan la definición de un protocolo similar.

Un protocolo estandarizado definido para este propósito es el Protocolo de Transporte en Tiempo Real, definido en el RFC 1889(14,33].

El estándar H.323 utiliza comunicaciones orientadas a no conexión y orientadas a conexión. Las señales de control (H.245, H.225) y los datos (T.120) requieren de un transporte orientado a conexión debido a que estas señales deben recibirse en el orden en que fueron enviadas y obviamente no pueden perderse. Por otra parte, los flujos de audio y video son muy sensibles a los retardos, de esta manera si un paquete se retardara demasiado ya no tendría relevancia para el usuario. Es por esta sensibilidad a los retardos que el audio y video utilizan un protocolo de transporte no orientado a conexión y que no implique retransmisiones en caso de pérdidas. Para el transporte de datos que requiere transmisión confiable se utiliza TCP, el cual garantiza que los paquetes lleguen en orden y sin errores, además de controlar el flujo de paquetes, la desventaja de este protocolo para las aplicaciones sensitivas al tiempo vienen asociadas por los tiempos de retransmisión involucrados en la detección de errores y pérdida de tramas, así como también en el procesamiento de encabezados. Las recomendaciones H.245, T.120 y Q.931 utilizan TCP como transporte. Asimismo, el protocolo de transporte que se emplea para la comunicación no orientada a conexión es UDP, el cuál como ya mencionamos solo promete realizar su mejor esfuerzo para la entrega de los paquetes. UDP proporciona un control mínimo lo cual reduce el retraso en los paquetes, que es de vital importancia en la transmisión de datos multimedia. La recomendación H.323 utiliza UDP para el audio, video y el canal de RAS.

Para utilizar UDP como protocolo de transporte multimedia en tiempo real, es necesario añadirle cierta funcionalidad, la cual ha sido incorporada en RTP. Los servicios que RTP proporciona incluyen un campo con una estampilla de tiempo (cuándo se transmitió el paquete), un número de secuencia ( que permite ordenar los paquetes), un identificador del tipo de información que contiene (formato de audio o video, definidos en el RFC 1890 [14, 34]), y un identificador único por cada participante. Aunque R TP esta diseñado para ser independiente del protocolo de transporte, normalmente corre sobre UDP (véase la figuras 3.5 y 3.6), y puede usar transmisión "Unicast" y "Multicast". Para el control de RTP se usa el protocolo RTCP[l4], "Real-Time Control Protocol". Este protocolo monitoréa la calidad de la conferencia, intercambia información acerca de los participantes y periódicamente distribuye paquetes de control que contienen información de la calidad de sesión a todos los participantes de la conferencia. Estos paquetes utilizan los mismos mecanismos de transmisión de los paquetes de audio y video.

30

Figura 3. 6. Arquitectura del Protocolo RTP

H.261

MPEG JPEG

RTP

UDP

IP

Acceso a la red

En resumen, podríamos definir que las aplicaciones de video H.320 y H.323 pueden clasificarse en alguna de las siguientes dos categorías:

Video Paquetizado, el cual corre sobre LAN' s tradicionales en los niveles MAC (por ejemplo, Ethernet) o de Red (por ejemplo IP). Estas aplicaciones son por su naturaleza de velocidades variables de bit o conocidas también como de ráfaga, lo cual depende de la cantidad de movimiento que se tenga que procesar en la imagen.

Un algoritmo de compresión para este tipo de video, esta diseñado para ser entregado en paquetes, ya sean IP o equivalentes. Grupos de Analistas como "Gartner Group" [6] han proyectado que para 1999 el 75% del equipamiento de videoconferencia será paquetizado y agregado a las LAN' s, esto, por la ventaja de integrar en el escritorio los servicios de voz, video y datos, sobre las infraestructuras de datos existentes, por razones de costo-beneficio para las empresas y por la posibilidad de poder compartir aplicaciones de la PC con otros usuarios. El formato de video H.323 corresponde a esta categoría, y de allí su importancia y consíderación en esta tesis.

Video de Velocidad Constante, el cual corre sobre enlaces tradicionales de 64Kbps o múltiplos de este, ya sea a través de ISDN o TDM. Un claro ejemplo de esta tecnología es el estándar H.320 considerado en esta evaluación. Estos sistemas normalmente se implementan en sistemas de videoconferencia grupales y llegan a ser mucho más formales que los de escritorio, lo cual hasta cierto punto representa una ventaja, ya que no se prestan a entretenimiento entre los usuarios[20].

31

3.4 REQUERIMIENTOS TÉCNICOS PARA TRANSPORTAR VIDEO Y AUDIO INTERACTIVO DE TIEMPO REAL.

Las aplicaciones de video interactivas de tiempo real tanto paquetizadas como de tasa de bit constante (para este caso con H.261 ambas), requieren de algunos factores técnicos indispensables para llevarse a cabo con un razonable desempeño, dentro de los cuales se limitan principalmente los siguientes[ 17]:

! .-Adecuada Capacidad de Transmisión. Un medio de transporte debe tener suficíente ancho de banda para transmitír video voz y datos a niveles de calidad que permitan claramente ver expresiones faciales, movimientos, escuchar comentarios y trabajar en documentos.

2.- Latencia. Las opciones de transporte necesitan facilitar la transmisión de video y audio con un mínimo de retraso de tiempo para permitir las sesiones interactivas. Sin embargo las redes contribuyen a la latencia de diferentes formas:

• Retraso de propagación. Es la cantidad de tiempo que toma a la información vtaJar la distancia de la línea. Este retraso es más que nada determinado por la velocidad de la luz; de aquí que este factor no afecte significativamente la latencia.

• Retraso de transmisión. Es la cantidad de tiempo que un paquete toma para cruzar un medio dado. Este retraso es determinado por la capacidad del medio y el tamaño del paquete o trama.

• Retraso de almacenamiento y reenvío. Es la cantidad de tiempo que un dispositivo de interconexión ( como un conmutador, puente o ruteador) toma para reenviar un paquete o trama que ha recibido.

• Retraso de procesamiento. Es el tiempo requerido por un dispositivo de interconexión para encontrar la ruta, cambiar el encabezado y otras tareas de conmutación. En algunos casos, el paquete también debe ser manipulado. Por ejemplo, el tipo de encapsulamiento o el contador de "saltos" debe ser cambiado. Cada uno de estos pasos contribuyen al retraso del procesamiento.

3.- .litter. El "jitter" es la variación del retraso de una trama a la siguiente. Esto es critico para el video, ya que este requiere un flujo constante de bits y en orden para mantener una imagen.

4.- Disponibilidad. El medio de transporte debe ser ampliamente accesible y disponible en cualquier instante.

5.- Contención de recursos. Un medio ideal de transporte no requerirá que el usuario contienda con otros usuarios por el ancho de banda y por el acceso del medio. Un usuario debe tener garantizado una cantidad fija de capacidad de transmisión para transportar video, voz y datos.

32

CAPÍTULO 4. Planteamiento del Problema.

Como ya se ha mencionado, tenemos que trabajar con las dos tecnologías de redes en cuestión, para evaluar el transporte de video H.320 y H.323 sobre cada una de estas. Partiendo de lo anterior, esta sección es dividida dos partes:

1. Video sobre Frame Relay. La cual incluirá una descripción general de los problemas que presenta está tecnología para el transporte de video y las causas que originan estos problemas, y por último en el siguiente capítulo se darán una serie de recomendaciones tanto generales como particulares para el video de velocidad constante (H.320) y el video paquetizado (H.323).

2. Video sobre ATM. Esta sección incluirá una breve descripción de la naturaleza de ATM, sus categorías de servicio, los usos típicos de los mismos y permitirá abrir un panorama de las recomendaciones para la implementación del transporte de video, tanto constante como paquetizado atendiendo a la clase de servicio asociada a cada uno de estos.

4.1 VIDEO SOBRE "FRAME RELAY".

Históricamente "Frame Relay" ha sido desarrollado y vendido principalmente como una tecnología de transporte de datos y una solución para estos servicios. Esto se debió principalmente por una técnica de posicionamiento más no como una limitación técnica [3]. La exitosa transmisión de voz digitalizada sobre los servicios públicos de datos "Frame Relay" [3, FRF] durante los últimos años, ha dibujado la atención a la pregunta de que si también los servicios de video pueden ser transportados a través del mismo enlace. Hoy en día existe muy poca información de que también esta tecnología se pudiese desempeñar para el transporte de video. Esta tesis intenta dar algunas ideas básicas y recomendaciones para este propósito.

Los estándares de video a ser evaluados para transportarse sobre una red pública de datos "Frame Relay" son H.320 y el H.323 con IP, los cuales requieren de: Un ancho de banda mínimo para ofrecer una aceptable calidad de video (Pruebas en el laboratorio han demostrado que con una capacidad mínima de 384 Kbps se obtiene una buena calidad de video para aplicaciones relativamente estáticas, tales como la educación a distancia). El contar con la suficiente capacidad de transmisión no es en si un problema técnico para "Frame Relay" puesto que se puede definir un CIR adecuado a la calidad de video que el usuario desee tener.

Quizás los problemas técnicos más importantes que presenta "Frame Relay" para transportar video H.320 o H.323 con IP, son la Latencia y el "Jitter" definidos anteriormente. Los dos aspectos anteriores que podríamos resumir como retrasos de tiempo afectan al video críticamente ya que este requiere un flujo constante de bits y con un orden para mantener una imagen.

33

Otro problema asociado a la naturaleza de "Frame Relay" es la pérdida de paquetes; ya que, si un paquete se pierde puede causar un "brinco" en el audio y alguna pixelación5 en el video. Por supuesto que demasiadas pérdidas de paquetes degradarán considerablemente la calidad del video, además de que podrían ocasionar la pérdida de la conexión.

Como comentario, vale la pena mencionar que, en aplicaciones de líneas arrendadas utilizando TDM, los retrasos no son un problema, ya que los paquetes llegan a intervalos predecibles de tiempo, y no existen pérdidas de paquetes a no ser de que la línea funcione mal. TDM tiene la desventaja de mantener una capacidad del enlace fija la cual, en los esquemas tarifarios en México se cobra se use o no se use, y no puede ser dispuesta simultáneamente para otras aplicaciones como por ejemplo de voz y datos, así como también no puede crecer bajo demanda.

4.1.1 CAUSAS QUE ORIGINAN LOS PROBLEMAS TÉCNICOS EN FRAME RELA Y.

El "Jitter" puede ocurrir en una red pública de paquetes cuando un dispositivo intermedio, como un conmutador, ruteador o FRAD6

, está procesando algún otra trama y llega la trama de video. El segundo paquete entrante ( el de video) se mantiene en un "buffer" del dispositivo hasta que la transmisión del primer paquete sea completada. El retraso resultante es dependiente de la longitud del primer paquete y debido a que Frame Relay permite paquetes de tamaño variable, este retraso es variable e impredecible, lo cual da como resultado el ''jitter" y la latencia asociados. Si estos retrasos en conjunto exceden la habilidad de compensación por el almacenamiento del dispositivo receptor ("buffer"), la calidad de voz y video será degradada.

La pérdida de paquetes es un problema más serio, ya que el estándar Frame Relay controla la congestión descartando todos aquellos paquetes de los usuarios, que exceden su tasa de información acordada (CIR, "Commited Information Rate"); es decir, si se contrata un CIR = 128 Kbps y se envían ráfagas de datos a 192Kbps, los paquetes que excedan los 128Kbps del CIR tendrán el bit de Elegible a Descartar de la trama "Frame Relay" habilitado. Si algún conmutador intermedio en la red se llegase a congestionar, esos paquetes podrían ser descartados. La única manera cierta para garantizar una buena calidad de video, es tener el suficiente CIR que requiera la aplicación del usuario (por ejemplo CIR = 384 Kbps), pero esto no es necesario en muchos casos, ya que la mayoría de los usuarios de este servicio público trabajan bajo el concepto de sobresubscripción ("oversuscribed')[9]. En resumen, si se garantiza un CIR adecuado para la aplicación de video, esto no quiere decir que no habrá retrasos en la transmisión de las tramas, ya que estos se originarán cuando haya congestión en la red, por lo tanto se requiere más que esto para garantizar una adecuada recepción. Como vemos, son muchos los inconvenientes asociados para poder transmitir video por "Frame Relay", ¿por qué entonces insistir en ello?

La respuesta a esta pregunta y la motivación del trabajo son debidos a que: "Frame Relay" ofrece un costo menor comparado con enlaces dedicados y redes privadas, trabaja con circuitos virtuales, lo cual permite tener un solo puerto fisico con múltiples enlaces virtuales ( de nuevo un

5 Término de videoconferencia, el cual es usado para identificar el rompimiento de la imagen. Las imágenes de video digital están hechas de miles de pixeles, cada uno representando un color en la imagen. Los pixeles son agrupados en bloques. La pixelación es n término a menudo usado para describir una imagen la cual contiene errores en los colores de esos bloques, creando cuadros obvios de color erróneo en la pantalla. 6 Un FRAD (Frame Relay Access Device) es típicamente una unidad integrada que toma datos provenientes del ambiente interno de computo a través de una o más puertos seriales, encapsula los datos en tramas "Frame Relay" y los envía hacía afuera a través de sus puntos de acceso DSU o DSU/CSU. También recibe tramas "Frame Relay" del punto de acceso y desencapsula cada encabezado y verifica el "checksum". Hecho lo anterior, envía el dato hacía el puerto serial apropiado.

34

considerable ahorro por la utilización de menos puertos), aprovecha mejor el ancho de banda de los usuarios, es una de las tecnologías más ampliamente usadas en todo el mundo [21,30,31], y además, en muchos casos los esquemas de tarificación crecen bajo la demanda de la capacidad del canal en vez de la distancia a alcanzar por los usuarios (i.e. ISDN) (en el caso de UniNet si se cobra por distancia y capacidad demandada). Pero la mayor motivación para considerar esta implementación, es que el tamaño del campo de "payload" (campo de datos) de la trama "Frame Relay" es de tamaño variable y puede ser configurada a discreción desde 1 hasta 8000 bytes, aunque se recomienda no exceder los 4000 bytes. [9]

4.2 VIDEO SOBRE ATM

Para poder hablar de video sobre ATM (Asynchronous Transfer Mode, Modo de Transferencia Asíncrono), primeramente y a diferencia de "Frame Relay", tenemos que enmarcar que ATM si es una tecnología diseñada para el transporte de voz, video y datos, y además, ofrece diferentes calidades de servicio (QoS, "Quality of Service") para diferentes tipos de tráfico. Por ello, resulta entonces necesario repasar y analizar cuales son estas características actualmente definidas y sus principales parámetros de consideración, para así, poder recomendar un apropiado uso de las mismas y la o las mejores opciones para el transporte de video de velocidad constante de bit como H.320 y el video paquetizado como H.323 concernientes en este trabajo.

4.2.1 Servicios A TM

ATM es una tecnología de conmutación de celdas, orientada a conexión y de alta velocidad, que provee cinco categorías de servicio, definidas por el Foro ATM7

, y que permiten compartir rutas armoniosamente dentro de una red de trabajo con diferentes tipos de tráfico [16]:

Servicios de Tiempo Real

• Tasa Constante de Bit (CBR) • Tasa Variable de Bit de Tiempo Real (rt-VBR)

Servicios de No Tiempo Real

• Tasa Variable de Bit de No Tiempo Real (nrt-VBR) • Tasa Disponible de Bit (ABR) • Tasa No Especificada de Bit (UBR)

Aplicaciones de Tasa Constante de Bit (CBR).

Requiere que velocidades de datos fijas estén disponibles por el proveedor ATM. La red debe vigilar que el tráfico entrante en la conexión CBR no exceda su asignación de suscripción. Esta categoría está diseñada para aplicaciones de voz y video, así como también para servicios de emulación de circuitos (CES, "Circuit Emulation Services"). Ejemplos de este servicio son: Videoconferencia, Audio Interactivo

7 El Foro A TM, es una organización internacional sin fines de lucro, fonnada con el objetivo de acelerar el uso de productos y servicios A TM, a través de especificaciones de interoperabilidad. Disponible en http://atnúorum.com

35

Aplicaciones de Tasa Variable de Bit de Tiempo Real (rt-VBR).

Este servicio es diseñado para aplicaciones que son sensitivas al retraso ("delay") y variación de retraso (''jitter"), pero no exhibe capacidades de transmisión de datos fijas como CBR. En vez de tener una sola capacidad, una conexión VBR se define en términos de una capacidad de transmisión sostenida para uso normal y capacidades ráfaga para uso ocasional en periodos pico. La alta capacidad de transmisión se garantiza bajo el entendimiento de que el usuario no requerirá constantemente está alta velocidad. Para este servicio, se agregan las especificaciones para el retraso en la transmisión de celdas y la variación de retrasos.

Las aplicaciones interactivas de datos tradicionales, tales como las sesiones Telnet y las aplicaciones multimedia interactivas, como los codec's modernos y el LAN TV son más variables en naturaleza y fluctúan entre bajos y altos requerimientos de ancho de banda.

Aplicaciones de Tasa Variable de Bit de No Tiempo Real (nrt-VBR).

Es similar a rt-VBR, excepto que no hay especificaciones para la variación de retrasos y una baja relación de perdida de celdas es permitida.

Aplicaciones de Tasa Disponible de Bit (ABR).

Proveen al usuario con una capacidad mínima garantizada (MCR, "minimun cell rate"), que requiere la aplicación y una capacidad de transmisión de celdas pico (PCR, "peak cell rate") que podría llegar a usar. Cuando una capacidad adicional está disponible el usuario puede transmitir ráfagas de datos arriba de la capacidad mínima con un riesgo mínimo de perdida de celdas.

Las aplicaciones de datos tradicionales como la transferencia de archivos y nuevas aplicaciones, tales como el correo Multimedia y apuntes multimedia pueden funcionar con un amplio rango de ancho de banda disponible. Estas aplicaciones requieren poco ancho de banda para funcionar lentamente y corren más rápido tan pronto tengan acceso a más ancho de banda. Las redes de datos de conmutación de paquetes tradicionales, pueden adecuarse para soportar aplicaciones de tasa disponible de bit, con garantías de calidad de servicio del mejor esfuerzo. La ABR es la única categoría de servicio en la que la red proporciona una retroalimentación al transmisor, solicitándole que disminuya la velocidad de envío, al ocurrir congestionamientos.

Tasa No Especificada de Bit (UBR)

Este es un servicio del tipo "mejor esfuerzo", que no garantiza una cantidad de capacidad y cualquier celda puede ser descartada. En un momento dado, una cierta cantidad de la capacidad de una red ATM es consumida en transportar tráfico CBR y los dos tipos de tráfico VBR. Pero una capacidad adicional casi siempre se encuentra disponible por las razones siguientes: (1) No todo del total de recursos ha sido acordado por tráfico tipo CBR y ABR, y (2) la naturaleza de ráfaga del tráfico VBR significa que algunas veces menos capacidad acordada es usada. Toda esta capacidad no usada puede estar disponible para el servicio UBR. Este servicio es apropiado para aplicaciones que pueden tolerar variabilidad de retrasos y algunas perdidas de celdas. No retroalimenta con información acerca de los congestionamientos como lo hace ABR.

Las características de servicio de las diferentes categorías de servicio ATM, se resumen en la siguiente tabla 4.1.

36

Tabla 4.1. Características de las categorías de Servicio ATM

Características de Servicio CBR rtVBR nrtVBR ABR UBR

Garantía de ancho de banda Sí Sí Sí Opcional No Adecuado para tráfico en tiempo real Sí Sí No No No Adecuado para tráfico en ráfagas No No Sí Sí Sí Realimentación sobre congestionamientos No No No Sí No

En la siguiente tabla 4.2 se resumen las principales áreas de aplicación para cada categoría de servicio ATM, y su disponibilidad. [26].

Tabla 4.2. Areas de Aplicación para las categorías de servicio ATM

Area de aplicación CBR rt-VBR nrt-VBR ABR UBR

Datos críticos ** * *** * n/a Interconexión LAN. * * ** *** ** Emulación LAN Transporte de datos * * ** *** ** Emulación de circuitos. *** ** n/a n/a n/a Videoconferencia H.320 *** n/a n/a ISDN/POTS Audio comprimido * *** ** ** * Distribución de Video *** ** * n/a n/a Multimedia interactiva *** *** ** ** * H.323/IP Optimo:***, Bueno:**, Medio:*; sin marca no son aplicables ahora ( tal vez en el futuro); n/a = no aplicable

Los 5 servicios anteriores, están caracterizados por otros atributos ATM que caen dentro de las tres categorías siguientes:

Descriptores de Tráfico. Describe las características de tráfico de la fuente y de la conexión. Una red establecerá una conexión para esta fuente únicamente si están disponibles los recursos suficientes para soportar el volumen de este tráfico.

Parámetros de QoS. Caracteriza el desempeño de una conexión ATM, en términos de la calidad de servicio que está provee. Para una conexión dada, un usuario solicitará un particular QoS.

Otros. El único atributo definido hasta ahora es el de retro-alimentación para ABR

37

Descriptores de tráfico

El foro ATM ha definido algunos descriptores que caracterizan el patrón de tráfico de un fluJo de celdas sobre una conexión ATM. Este patrón de tráfico, debe ser visto desde dos diferentes perspectivas. Primero, existe una naturaleza intrínseca del tráfico generado por la fuente y sometido a la red a través de la UNI ("User to Network Interface", Interface Usuario Red). Segundo, este flujo de celdas puede ser modificado dentro de la red, a lo largo de la conexión ATM, lo cual es debido por la variabilidad de retardos sufridos y por el tratamiento de las celdas que no conforman el patrón de tráfico de la fuente.

Las características de la fuente de un tráfico ATM son capturadas en un descriptor de tráfico fuente, el cual incluye lo siguiente: tasa de celda pico (PCR, "peak cell rate"), tasa de celda sostenible (SCR, "sustainable cell rate"), y tamaño máximo de ráfaga (MBS, "maximum burst size"). No todos estos descriptores son usados para caracterizar todo tipo de tráfico. La tabla 4.3 (14] lista los atributos ATM e indica su aplicabilidad para cada categoría de servicio.

Las características de un tipo de tráfico sobre una conexión ATM son capturados en un descriptor de tráfico de la conexión, el cual incluye lo siguiente: El descriptor de tráfico de la fuente, la tolerancia a la variación de retardo de la celda (CDVT, "cell delay variation tolerance"), y una "definición acordada" que especifica inequívocamente una prueba para determinar cuando una celda dada en esa conexión, conforma el descriptor de tráfico de la fuente.

Por lo tanto la estructura del descriptor de tráfico de la conexión es de esta forma:

Descriptor de tráfico de la fuente Tasa pico de celda (PCR) Tasa sostenible de celda (SCR) Tamaño máximo de ráfaga (MBS) Tasa mínima de celda (MCR)

Tolerancia a la variación de la celda (CDVT)

Definición acordada

Los descriptores PCR, SCR, MBS y MCR caracterizan el tráfico sometido a la red y son suficientes para que la red tome decisiones de distribución de los recursos.

Sabemos también que una porción de la variación de retardo de las celdas es causada por la red, y por lo tanto no puede ser especificada por la fuente, pero esta, debe ser dada por la red. Ahora definiremos cada uno de esos descriptores.

Descriptores de Tráfico de la Fuente.

La tasa pico de celda, PCR, define un límite superior del tráfico que puede ser suministrado a la red, es decir, es la rapidez máxima con que el transmisor planea enviar celdas. El PCR es definido en términos de la variable T, que es el mínimo espaciamiento entre celdas, así que el PCR = 1 / T. La descripción PCR es obligatoria para los servicios CBR y VBR.

38

La tasa de celdas sostenible, SCR, es la tasa esperada o requerida de celdas promediada en un intervalo de tiempo grande. Para el tráfico CBR, la SCR será igual a la PCR, pero para las demás categorías de servicio será sustancialmente menor (SCR < PCR). La relación PCR/SCR es una medida de las ráfagas de tráfico.

El tamaño máximo de ráfaga, MBS, es el máximo número de celdas que pueden ser enviadas continuamente a una tasa de celdas pico. El SCR y el MBS deben ser especificados para fuentes VBR.

La tasa de celdas mínima, MCR, es la cantidad mínima de celdas/seg., que el cliente considera aceptable. Si la portadora es incapaz de garantizar esta cantidad de ancho de banda, debe rechazar la conexión. Cuando se solicita el servicio ABR, el ancho de banda real debe estar entre la MCR y la PCR, pero debe variar dinámicamente durante el intervalo de vida de la conexión. Si el cliente y la portadora acuerdan establecer la MCR en O, entonces el servicio ABR se vuelve similar al servicio UBR.

Descriptor de Tráfico de la Conexión.

En adición al descriptor de tráfico de la fuente, el descriptor de tráfico de la conexión, incluye la CDVT y una definición de acuerdo. La tolerancia a la variación de retardo de la celda CDVT es una medida de la cantidad de variación en retraso de la celda, que es introducida por la interface de red ( e.g. SDH) y la UNI. La definición acordada es usada para especificar de modo inequívoco las celdas que conforman la conexión hacía la UNI. La red puede imponer por acuerdo, que las celdas que excedan la definición acordada sean descartadas o marcadas.

Parámetros QoS

Los siguientes parámetros de QoS para ATM son definidos por el Foro ATM:

• Variación de retraso de celda pico a pico • Máximo retraso de transferencia de celda • Relación de perdida de celda

El retraso de transferencia de celda (CTD, "Cell Transfer Delay"), es el tiempo promedio de tránsito del origen al destino. En términos generales, CTD es una variable que típicamente tiene una función de densidad de probabilidad que sería como el de la figura 4.1. Como se indica, existe un retardo mínimo, llamado retardo fijo, el cual, incluye el retraso de propagación a través del medio fisico, retrasos inducidos por los sistemas de transmisión y componentes fijos con retrasos de procesamiento de conmutación. La porción variable de retardo de celda (CDV, "cell delay variation"), es debida al almacenamiento y la calendarización de celdas.

Con referencia a la figura 4.1, el máximo retraso de transferencia de celda (max. CTD), define la máxima solicitud de retraso para esta conexión. Una fracción a de todas las celdas excederá este límite y debe ser descartada o entregada más tarde. La porción restante (1 - a), se encuentra dentro del rango de QoS solicitado. La cantidad de retraso experimentado para tales celdas esta dentro del rango entre el retraso fijo y el máximo CTD; este rango es definido como variación de retraso de celda pico a pico (peak-to-peak CDV).

39

Finalmente, la relación de pérdida de celdas (CLR, Cell Loss Ratio) es simplemente la razón de celdas pérdidas contra el total de celdas transmitidas en una conexión.

La relación de perdida de celdas juega un rol crítico en la calidad del flujo de videocodificado. Esta relación depende de varios factores incluyendo el medio fisico en uso, la técnica de conmutación, el tamaño del "buffer" del conmutador, el número de conmutadores a través de la conexión, la clase de QoS usada para el servicio y si el flujo de video es CBR o VBR. [23].

La pérdida de celdas en una red ATM es a menudo un resultado de congestión en los conmutadores. El definir control de velocidad aprueba en una forma de limitar la perdida de celdas.

En base a lo anterior, podemos ahora delimitar fácilmente que tipo de servicios y QoS pueden ser utilizados por las aplicaciones multimedia de tiempo real definidas en esta tesis como H.320 y H.323 con IP, de donde observamos que CBR, rt-VBR y posiblemente ABR, como veremos más adelante, son las únícas disponibles por el momento para este cometido. En el siguiente capítulo hablamos de estas consideraciones y propuestas

Tabla 4.3. Atributos de las categorías de Servicio ATM [14]

A TM Layer Service Category Attribute CBR I Rt-VBR I Nrt-VBR UBR I ABR

1::m:t]tltititIItttIIIItIIIItfti[füjj[¡[ffütMtft:tI!MtittltiIIlfüfütttIII@tOCf.iffliilif.mlifilIIImmrntIIIIIIIIIIIIt:t: PCR and CDVT (4,5) Specified Specified (2) 1 Specified (3)

SCR, MBS, CDVT (4,5) N/A I Specified N/A MCR (4) N/A I Specified

II:!füfütftIItt[Itttittitfültim:@ttft:!fü!'fftift:!füilt]IIm=:rn:ttt]ttt:rn:mmit~ ilirimmiifüitIIlttttIII@tftffI]fM Peak-to-peak CDV Specified Unspecified

MaxCTD Specified Unspecified CLR (4) Specified Unspecified 1 (1)

·;:;';:;';';';::;\;;;;;;;;';.'.;.:':/:;::;;:::::'t'::/:::;:;:::;':':'·;·::';'·';';f::::~:/;:;';:;:::;';';:;:;:;;.:.:::':;:;:'.\::;:;;:;:·::::';'·:::;::::::;;:::::::;:'::\L;;~;;:;;=;:f;!U:'·:::!;:::::::;:;;;:;;;.;:;':'::;::;:.t:·'·:::·:;t;::':':':':';';';:O!Ki@'.iifffffiit~;/:::'·';';/;///;f/':.:':f:f:-:'::_:_:_:,:z}:·:·::::::>)

l.

2. 3. 4.

Feedback Unspecified I specified CLR is low for sources lhat adjust cell flow in response to control inforrnatton. Whether a quantiative value for CLR is specified is network specific May not be subjet to CAC and UPC procedures. Represents lhe maximum rate at wich ABR source may ever send. The actual rate is subject to the control inforrnation. These parameters are eilher explicity or implicity especified for PVCs.

5. CDVT is nor signaled. Ingeneral, CDVT need not have a unique value for connection. Different values may apply at each interface along the palh of a connection.

Probahílíty

Vi.xed delay

Figura 4.1. Función de densidad de probabilidad de retraso de celda.

Peak-to-peak ceU delay varíntíon (CDV)

Maximum

Cdls lost or ddívered too late

cell 1r.u1sfor delay (CTD)

40

41

CAPÍTULO 5. Desarrollo de la Contribución.

En este capítulo se da un panorama de recomendaciones para el transporte de video H.320 y H.323 sobre las tecnologías "Frame Relay" y ATM. Se discuten y justifican cada una de las propuestas, así como también recomendaciones particulares para cada formato de video.

5.1 REQUERIMIENTOS DE CALIDAD DE SERVICIO. PROPUESTAS TÉCNICAS GENERALES PARA "FRAME RELAY".

Atendiendo a los principales problemas delimitados anteriormente para transportar el video a través de Frame Relay, se proponen las siguientes recomendaciones generales, que en conjunto podrían servir de marco teórico para la evaluación del desempeño del transporte de video (H.320 y H.323 con IP) en el laboratorio, así como crear una garantizada Calidad de Servicio (QoS, "Quality of Service"), para está tecnología:

1.- Configuración del Tamaño de la Trama Frame Relay.

2.- Manejo de Esquemas Propietarios de Prioridades por Circuito Virtual.

3 - Adecuación del CIR atendiendo al requerimiento deseado.

4.- Ruteo Inteligente de los circuitos virtuales.

5.1.1 CONFIGURACIÓN DEL TAMAÑO DE LA TRAMA FRAME RELAY.

Un importante problema de diseño es delimitar el tamaño del paquete a ser usado en la red. Existe una relación significante entre el tamaño del paquete y el tiempo de transmisión como es ilustrado en el siguiente ejemplo (véase la figura 5.1). En éste, se asume que hay un circuito virtual de la estación X a través de los nodos a y b a la estación Y. El mensaje a ser enviado consta de 30 octetos, y cada paquete contiene 3 octetos de información de control, la cual es puesta al inicio de cada paquete y es referenciada como encabezado. Si el mensaje entero es enviado en un simple paquete de 33 octetos (3 octetos del encabezado y 30 de datos), entonces, el paquete es primeramente transmitido de la estación X hacía el nodo a (Figura 5 .1 a). Cuando el paquete entero es recibido, puede entonces ser transmitido de a hacía b, y cuando es recibido completamente por el nodo b, es entonces finalmente transferido a la estación Y. El tiempo total de transmisión de los nodos es de 99 tiempos de octeto (33 octetos x 3 transmisiones/paquete).

Supongamos ahora que fraccionamos el mensaje en dos paquetes cada uno conteniendo 15 octetos del mensaje y, por supuesto, 3 octetos de encabezado o control de información en cada uno. En este caso, el nodo a puede empezar a transmitir el primer paquete tan pronto como éste llegue del nodo X, sin esperar por el segundo paquete. Debido a este traslapo en la transmisión, el tiempo total de transmisión cae hasta 72 tiempos de octeto. Si se fracciona el mensaje nuevamente hasta en 5 paquetes, cada nodo intermedio puede iniciar su transmisión más pronto y los ahorros en tiempo son mayores, con un total de 63 tiempos de octeto. A pesar de esto, este

42

proceso de usar más y pequeños paquetes eventualmente resulta en incrementar, en vez de reducir el retraso, tal y como es ilustrado en la Figura 5. ld; esto es debido a que cada paquete contiene una cantidad fija de encabezado. Además, el ejemplo no muestra los retrasos de procesamiento y encolado en cada nodo. Esos retrasos también son grandes cuando más paquetes son manejados por un simple mensaje.

Figura 5.1. Procesamiento de Diferentes Tamaños de Tramas

- -n 1

1 1 1

!

1 Tiempo

i 't __________________ l__j

• • • • • • • • • • • • • • • • X a b y X a b y X a b y X a b y

1 paquete 2 paquetes 5 paquetes 10 paquetes a) b) e) d)

Por lo anterior, el primer punto de la recomendación es establecido, ya que si se reduce a un tamaño fijo el campo del "payload" de la trama "Frame Relay", esta reducción ocasionará que se entreguen más rápido las mismas para un óptimo desempeño de la sesión de video, este ajuste consecuentemente reducirá el efecto de tramas perdidas, ya que, como transportan menos información, si estas se llegarán a perder no degradarían críticamente la calidad del video o audio. Resulta interesante preguntarse que tan pequeñas deben ser las tramas que transportarán el video para que efectivamente garanticen una rápida entrega de las mismas y no una sobrecarga para los conmutadores debido al procesamiento de más encabezados ("headers").

La propuesta que sugiero incorpora tramas de un tamaño fijo del "payload" de 256 bytes. Esta sugerencia aparentemente aleatoria si tiene su razón de ser: Si consideramos el tiempo de encapsulamiento de una trama Frame Relay de 256 octetos para el tráfico de video a 384 Kbps sería de 0.00066 seg. (Cálculo lineal establecido como referencia que implica la relación

43

256/384Kbps), lo cual, es una cifra insignificante para la transmisión del video, pero es claro que hay que considerar otros retardos que se producen en la red, tales como el retraso de procesamiento en los conmutadores o en los FRAD' s, los cuales serían dificiles de estimar por la variedad de marcas y tecnologías existentes en el mercado y el porcentaje de carga de tráfico en la red, además por los "saltos" a cubrir por el enlace; sin embargo, como recomendación es válido considerar este tamaño de trama, que podría ser ajustado atendiendo al desempeño deseado y a las condiciones existentes en la red. Para el estándar H.261, se permite un retraso máximo de 300mseg y una tolerancia al ''jitter" máxima de 130 mili seg. (Véase tabla 3 2) En teoría, esta implementación podría funcionar muy bien mientras la suma de los retrasos asociados por los procesamientos de vanos conmutadores, los tiempos de espera en las caías baJo condiciones de severa congestión y otros dispositivos de interconexión no excedan los tiempos arriba señalados. En caso de que esto sucediera y se notara un retraso considerable, valdría la pena analizar nuevamente el tamaño del campo del "payload' de la trama "Frame Relay", ya sea aumentando su tamaño o reduciendo el mismo a intervalos regulares y observar el desempeño de la aplicación bajo condiciones de tráfico extremas. Es de mencionarse también, que el tamaño elegido cumple con ser un múltiplo de 8 o de base 2, lo que simplifica su procesamiento en los dispositivos.

Como una referencia del tiempo promedio de procesamiento de algunos dispositivos de interconexión de redes, se muestra la figura 5.2 la cual compara los mismos con la latencia máxima permitida por el formato de video H.261. [6]

Figura 5.2. Tolerancia de retraso de videoconferencia contra el retraso de algunos equipos.

ms,

1

1 300 ms 300 1

1

200 1

100

50 micro 50 micro 30 micro 1 ms o

LAN Routers ATM 2·way Speed Latency Switch es Switch es HDTV of Light Tolerance

S.F. to Video-Sosten conferencíng

44

5.1.2 MANEJO DE ESQUEMAS PROPIETARIOS DE PRIORIDADES POR CIRCUITO VIRTUAL.

Ya que consideramos una reducción del tamaño de la trama "Frame Relay" que transportará video, para acelerar la entrega y reducir el efecto de tramas perdidas por congestión, es necesario asegurar que los paquetes de video y audio lleguen primero que los de cualquier otra aplicación, ya que la simple reducción de las tramas no garantizará que estas no tengan que esperar a ser procesadas primero que otras. Por ello, es necesario manejar esquemas de entrega prioritarios que aseguren que las tramas de video y audio sean las primeras en salir. Por otra parte, es bien sabido que al momento de la elaboración de esta tesis, el Foro Frame Relay, ni ningún otro organismo de normalización internacional, ha liberado alguna estandarización para el manejo de prioridades en "Frame Relay", pero sin embargo, una vez más, son los fabricantes de equipos quienes se adelantan por ganar mercado y competitividad, quienes ya manejan capacidades de prioritización en "Frame Relay". También conocidas como SLA, "Service Level Agreements" en contraste con el QoS, "Quality of Services", manejado en ATM

Es de mencionarse que la ITU-T, en el grupo de estudio 7, se encuentra trabajando en la etapa final de la revisión del documento para X.36 y X.37, los cuales, definen el protocolo "Frame Relay" en la interface usuario-a-red y la interface red-a-red respectivamente. Esta revisión incluye procedimientos para proveer calidad de servicio (QoS) basado en clases de servicio, transferencia de tramas prioritarias y prioridades de descarte de tramas.[36]

El "backbone" UniNet de Frame Relay esta conformado por conmutadores Cascade©, los cuales permiten el manejo de esquemas propietarios de prioritización [ 18, 19] (Priority Frame). Estos esquemas de prioritización son muy similares a los esquemas establecidos en ATM, lo cual, fue establecido para propósitos de interconexión entre las dos tecnologías, como lo establecen FRF.5 y FRF.8 ("Frame Relay/ATM PVC Network/Services Internetworking Implementation Agreement") Véase Figura 5.3. Los priority Frame de Cascarle© se asumen garantizando un desempeño ("throughput") establecido en el CIR:

• Constant Frame Rate (CFR). Este es un servicio que garantiza un mínimo retraso (delay), una mínima variación de retraso (jitter) y una baja pérdida de tramas.

• Real Time Variable Frame Rate (rt VFR). Este servicio es muy similar a CFR, pero no exhibe capacidades de transmisión fijas como CFR, ya que permite capacidades mayores para ráfagas en usos ocasionales de periodos pico.

• Non Real Time Variable Frame Rate (nrt VFR). Este servicio garantiza una relación de pérdida parecida a lo que actualmente ofrece Frame Relay.

• Unspecified / Avalaible Frame Rate (UFR/AFR). Este servicio no tiene garantías, excepto para el "throughput".

45

Figura 5.3. lnteroperabilidad "Frame Relay" / ATM

Con un total de cuatro niveles de servicio Cascade garantiza en sus equipos conmutadores un QoS absoluto en "Frame Relay". El mapeo de esos niveles de servicio con hacía las aplicaciones típicas, se referencia en la tabla 5. l. [ 18, 19].

Tabla 5.1. Servicio, Parámetros QoS v aplicaciones. Service Name QoS Parameters Applications

CFR Delay, Delay Variation, Video, "pseudo" Circuit Switching, mission Frame Loss (minimum) critical, transaction processing.

rtVFR Delay, Delay Variation, Packetized Voice and Video, Frame Loss Mission critical (higher values than CFR)

nrt VFR Loss Ratio" LAN, Regular Frame Relay, Frame SVC's

UFR/AFR <none> CIR=O, Other best effort services

* Loss ratio only guaranteed for nrt VFR if device reacts to Frame Relay Flow Control mechanisms.

Como se observa en la tabla 5.1, es deseable entonces que las tramas de video a ser transportadas mantengan el servicio CFR ( de más alta prioridad), y para otras diferentes aplicaciones, se podría "jugar" con las prioridades atendiendo a la necesidad de los mismos. Es de mencionarse también, que estos servicios de prioridades son configurados por circuito virtual, es decir, en un mismo circuito virtual no se puede establecer más de un servicio. Por lo anterior, cada vez que se requiera transportar tráfico de diferentes servicios, cada uno de ellos deberá tener su propio circuito virtual. En la siguiente figura 5.4 se muestra una implementación diseñada por Cascad e©[ 18, 19] para la comunicación entre 2 estaciones de videoconferencia y un servidor de video bajo demanda por diferentes PVC's manejando CFR en la "nube" de "Frame Relay" con conmutadores Cascade©, tal y como los que tiene el "backbone" UniNet.

46

Figura 5.4. Video Servicios en la nube Frame Relay con CFR

Las redes "Frame Relay" del futuro deben soportar los siguientes parámetros de calidad:

• Máximo Retraso de Trama • Máxima Variación del Retraso de Trama • Máxima Relación de Pérdida de Tramas

Así como también las siguientes clases de servicio en adición al CIR:

• Servicio de Relación de Trama Constante • Servicio de Relación de Trama Variable (en tiempo real y no tiempo real) • Servicio No especificado o Disponible de Trama

Estas garantías darán a los proveedores de servicios como UniNet, la necesidad de proveer SLA' s a sus clientes para poder garantizar calidades para poder transportar voz y video en redes "Frame Relay".

5.1.3 ADECUACIÓN DEL CIR A TENDIENDO AL REQUERIMIENTO DESEADO.

El filósofo Griego Séneca decía que: "Ningú,n viento es favorable, para quien no sabe a donde va". Esta frase ilustra perfectamente bien la recomendación tratada en este punto, ya que si un usuario a final de cuentas únicamente se conforma con ver una imagen de buena calidad y una excelente calidad de audio, quizás no sea necesario poner mucho énfasis en contratar un CIR para la capacidad total requerida por el video, lo cual en el caso de que se requiera una buena definición de video si será necesario

47

En base a lo anterior, esta recomendación estaría enfocada a evaluar las necesidades del usuario y hacer pruebas con su equipo a diferentes capacidades de CIR adecuadas al desempeño y costo deseado por el mismo. Por supuesto sin dejar de considerar las recomendaciones anteriores empleando configuraciones tendientes a favorecer el tráfico de video.

El siguiente diagrama de flujo, es una guía/recomendación para considerar diferentes factores que lleven a satisfacer las necesidades del cliente, tanto en desempeño como en calidad, tecnología y costo.

Tecnología Requerimiento

5.1.4 RUTEO INTELIGENTE DE LOS CIRCUITOS VIRTUALES.

Sabemos que la tecnología Frame Relay utiliza circuitos virtuales, y que cada vez que se requiere definir un nuevo circuito virtual entre dos estaciones participantes, primeramente se busca un camino entre los nodos intermedios que asegura una ruta confiable y corta para el tráfico de datos. Para el caso de la red "Frame Relay" UniNet, el protocolo encargado de esta actividad es el OSPF ("Open Short Path First", Abrir Primero la Ruta más Corta), el cual como su nombre lo indica basa su búsqueda en el camino más corto entre las estaciones participantes en la red. Pero, por qué no considerar un algoritmo de ruteo que garantice algo más que eso, como por ejemplo lo siguiente:

• La mejor Ruta para cada Calidad de Servicio (QoS). • Que tenga habilidad de auto-enrutarse cuando existan fallas manteniendo el mismo de QoS • Pueda prevenir llamadas8 con un QoS insoportable por la red • Que soporte balanceo de carga • Y además que sea simple y fácil de entender y operar.

El alcance de esta tesis, se encuentra fuera de la investigación o propos1c1on de un nuevo protocolo de ruteo que pueda garantizar en una red Frame Relay y ATM lo anterior, de aquí que se deja una motivación de un nuevo panorama de investigación y desarrollo para generaciones futuras, sin embargo al desarrollo de este trabajo y en la investigación desarrollada, se puede sugerir la consideración y estudio de factibilidad del nuevo protocolo de ruteo RSVP, "Resource Resavation Protocol", Protocolo de Reservación de Recursos [6, 14], el cual, es una tecnología emergente para redes diseñadas para soportar servicios integrados, el cual permite reservar los recursos necesarios para diferentes clases de servicio. Este protocolo habilita a los participantes en sesiones multimedia el solicitar a la red un ancho de banda adecuado a sus necesidades, haciendo que se reserven esos recursos solicitados desde los puntos extremo a extremo. Actualmente RSVP es un protocolo que está siendo definido por IETF [6,16]". Véase figura 5.5[6].

8 Ténnino utilizado en la jerga telefónica para indicar solicitudes de conexión.

I Need 1 MbpsBandwidt

and200msec dela y

¿Cómo funciona RSVP?

Figura 5. 5. Resource Reservation Protocol

Reserve 1Mbps on this

link

Reserve 1Mbps on this

link

This application needs1Mbps

Bandwidth an~OO msec delay

48

Para hacer una reservación en un nodo, el "demonio" ("daemon", un programa) RSVP llama a dos procedimientos de decisión locales, el de control de admisión y el de control de vigilancia. El control de admisión determina cuando el nodo tiene suficientes recursos disponibles para responder a la solicitud de QoS. El control de vigilancia determina cuando el usuario tiene permiso administrativo para hacer uso de la reservación. Si alguno de los dos chequeos falla, el programa RSVP regresará una notificación de error a la aplicación en proceso que originó la solicitud. Si ambos chequeos son exitosos, el "demonio" RSVP establece parámetros en un clasificador de paquetes y en una lista de paquetes para obtener el QoS deseado.

El clasificador de paquetes determina la clase de QoS para cada paquete y la lista ordena la transmisión de paquetes para conseguir el QoS prometido para cada tráfico. Véase figura 5.6.

Figura 5. 6. Reservación en un nodo en la ruta de flujo de datos

Aplicació

Clasificador de paquetes

Control de vigilancia

Control de Admisión

Lista de Paquetes

49

5.2 PROPUESTAS TÉCNICAS PARTICULARES PARA FRAME RELA Y

Debido a la naturaleza de los dos formatos de video considerados, es necesario dividir el análisis de su implementación, tomando en cuenta los aspectos generales arriba mencionados y su posible implementación en las siguientes consideraciones particulares.

5.2.1 VIDEO H.320 SOBRE FRAME RELAY

En la investigación de este proyecto se descubrió que los FRAD 's actualmente disponibles para datos en el mercado, no permiten el encapsulamiento del formato de video H.320 sobre la trama "Frame Relay", lo cual, es debido a que el formato H.320 requiere de un flujo constante de bits (como lo garantiza ISDN, para quien fue concebido), lo que no garantiza "Frame Relay"; sin embargo, algunas compañías ya se han dedicado a fabricar y/o proponer algunas soluciones ha este respecto. Tal es el caso de Motorola y V-TEL, quienes definen una trama propietaria tipo HDLC ( de propósito específico) para garantizar un flujo de datos a velocidad constante de bit [35], sobre la cual encapsulan el formato de video y así paquetizan el estándar H.320; esta trama tipo HDLC, es luego enviada a la nube de "Frame Relay", a través del FRAD[36,40]. Esta solución tiene como desventaja que únicamente permite enlaces punto a punto y requiere una configuración manual del FRAD que transporta el tráfico HDLC para comunicarse con su destino. Otra desventaja a este respecto, es que HDLC consume más tramas por segundo en el FRAD que un uso genérico de "Frame Relay" [3]. Lo anterior es debido a que el tráfico HDLC tiene que ser convertido a "Frame Relay", lo que implica un procesamiento adicional indeseable.

Existen otros videocodecs para "Frame Relay" similares a los codec's utilizados en el mundo ISDN, que son capaces de paquetizar el flujo de video hacia "Frame Relay". Un ejemplo de ese tipo, son los productos ABL© [3], los cuales permiten sesiones punto a punto y multipunto, además de no requerir una reconfiguración manual de los FRAD 's. En particular el modelo ABL VT2C, permite trabajar con los estándares H.320 y H.323/IP e incorpora funciones de monotipo y control, además de permitir manejar un esquema propietario de prioridades para la preferencia de entrega del video. Quizás la recomendación más importante en este punto sería considerar que el equipo a utilizar debe tener al menos compatibilidad con múltiples interfaces, como V.11, X.21, V.35, V.36 o ISDN, un amplio rango de opciones de conectividad para el usuario, manejo de prioridades para diferentes tipos de tráfico y que soporte diferentes capacidades de transmisión. En la tabla 5.2 se muestran algunas características de estos equipos.

Otra recomendación a considerar, es que el cliente declare al proveedor de servicio que utilizará transporte de video, para que este, a su vez, considere los DLCI' s especificados para video con la prioridad más alta en los conmutadores del "backbone" y asegure un mejor desempeño. La referencia [ 41] ofrece un excelente enfoque de las características de diferentes proveedores de FRAD' s para insertar el estándar H.320 por "Frame Relay" existentes en el mercado.

50

Tabla 5.2. Diferentes Equipos para incorporar H.320 sobre "Frame Relay".

Connection DTE Clock Framing Packet Framer Packet FRAD Performance Lip Sync Rate (Kbps) Protocol Lenght (fps) De lay

(bytes) {ms) ABL Canada 384 H.221 VT2C Video Codee l,500 VT2C 15 100

672 H.221 VT2C Video Codee 1,500 VT2C 15 100

ACT Networks 256 SG3 ACT AVl 2000 256 SDM 9300 12 600 256 H.221 ACT AVl 2000 256 SDM 9300 26 100 256 H.221

ACT AVI 2000 1,500 SDM 9300 25 100

Memotec 256 H.221 Memotec Video Framer 1,500 CX900c 25 100 Cornmunication 384 H.221 Memotec Video Framer 1,500 CX900c 30 100 s RAD Vision 384 H.323 VJU 323 1.024 CX900c 30 100 ISDN baseline 384 H.221 PicTel 4000rfl N/A N/A 30 100 performance 384 SG3 PicTel 4000rfl N/A N/A 12 600

5.2.2 VIDEO H.323 SOBRE "FRAME RELA Y"

Para este caso si vale la pena tomar en cuenta las recomendaciones propuestas en esta tesis, ya que como se explico anteriormente el estándar H.323 es encapsulado sobre IP y este a su vez sobre "Frame Relay", además, todos los FRAD 's existentes en el mercado permiten el transporte de IP (precisamente por que se "supone" que transporta datos). Entonces, debemos asegurar que se tomen en cuenta las consideraciones siguientes:

l. Consideración de tamaños fijos de tramas "Frame Relay".

Ya se menciono la importancia en cuanto a la rapidez de la entrega de tramas de tamaño fijo y pequeño, y para este caso aún se debe tomar en cuenta la recomendación propuesta de 256 bytes del campo de "payload" de la trama "Frame Relay", que garantiza que los encabezados del datagrama IP (al menos 20 octetos) y 236 octetos de datos puedan ser transportados sin ningún inconveniente. Lo anterior, no es más que un punto de partida que puede tener un ajuste más fino en el laboratorio para diferentes equipos a incorporar y que bajo esquemas de prueba y error permita definir la diferencia en el desempeño de la aplicación y su calidad.

2. Manejo de Prioridades QoS.

Tenemos que asegurar que las tramas que transportan el video contengan siempre la más alta prioridad para que así sean éstas las primeras en salir y en entregarse, lo anterior para evitar al máximo su retraso y la variación del retraso entre tramas sucesivas. De allí que se debe considerar que el FRAD del usuario permita este manejo de prioridades para esta implementación.

51

3. Adecuación del CIR dependiendo del desempeño deseado.

Los equipos de videoconferencia permiten la configuración de diferentes capacidades de transmisión, la cual por supuesto viene asociada a la calidad y desempeño ("performance") deseado en el video. Pruebas en el laboratorio de RedUno con equipos LiveLan 3.0, Livemanager 3.0 y Livegateway 3.0 de la compañía Picture Te! Corp.[8], han permitido evaluar el desempeño del estándar H.323 sobre IP a través de la "nube" "Frame Relay" W AN. Las pruebas en cuestión llevaron a identificar los requerimientos de ancho de banda mínimos y óptimos para una videoconferencia de esta naturaleza (Véase anexo A). Los criterios de análisis y calificación de las pruebas arrojaron las siguientes recomendaciones:

Para el caso de la interconexión sobre redes de área amplia, se recomienda considerar los siguientes aspectos al realizar una implementación con LiveLan 3.0:

• Crear un circuito virtual dedicado para el tráfico de videoconferencia9 , de acuerdo a las

siguientes especificaciones:

Para topologías con hasta 3 conmutadores:

Si LiveLan 3.0 está configurado al 74Kbps: CIR = 192, BC = 192, BE= 64/128 y prioridad= 1, con puerto lógico a 320 Kbps.

Si LiveLan 3.0 está configurado a 384Kbps: CIR = 384, BC = 384, BE= 64/128 y prioridad= 1, con puerto lógico a 512Kbps.

Para topologías con hasta 6 conmutadores:

Si LiveLan 3.0 está configurado a 174Kbps: CIR = 192, BC = 192, BE = 128 y prioridad = 1, con puerto lógico a 3 20Kbps.

Si LiveLan 3.0 está configurado a 384Kbps: No hay recomendación.

• Procurar canalizar el tráfico de videoconferencia por troncales cuya utilización no supere el 60% de su capacidad.

Vale la pena resaltar que en estas pruebas no se manejo la configuración del tamaño de las tramas por haberse desarrollado las mismas previamente al desarrollo de esta recomendación, pero aún así queda demostrado que el transporte de vídeo H.323/IP sobre "Frame Relay" es posible de llevarse a cabo.

9 En esta evaluación se utilizó invariablemente un circuito virtual con CIR = 128, BC = 128, BE= O y prioridad= 3 para transportar tráfico de datos; es factible experimentar degradación de consideración en una videoconferencia si se emplea una configuración diferente tendiente a favorecer el tráfico de datos, en conjunción con las configuraciones de circuitos virtuales para videoconferencia recomendadas.

52

4. H.263 en vez de H.261.

El estándar H.263 fue introducido por la ITU como un estándar de video para los productos H.324, el cual, esta diseñado para sistemas de videoconferencia multimedia tipo POTS (Plain Old Telephone Service). El objetivo de ITU al crear H.263 fue el desarrollar un estándar de video que se desempeñara mejor que H.261 a 28.8Kbps o una menor capacidad.

H.263 esta basado en la tecnología H.261, e incorpora varios niveles opcionales de implementación. Las dos características principales de H.263 que lo hacen diferente a H.261 son:

• H.263 permite alta precisión para la etapa de la compensación de movimiento. • El flujo de información que transporta H.263 requiere menos encabezados que H.261

H.263 puede ser incorporado en los estándares H.320 y H.323 como lo muestra la siguiente tabla 5.3.[39]

Ti bl 53 S a a .. oporte 'd e estan ares d l l e argontmo H263 . Standard Mandatory Video Standard H.263 Support

H.320 H.261 Optional H.323 H.261 Optional, but preferred H.324 H.26l&H.263 Mandatory

Por otro lado H.263 permite el manejo de más formatos de imagen para videoconferencia [32], como se ilustra en la siguiente tabla 5.4.

Tabla 5.4. Formatos de imagen para videocon rerencia ITU-T Formato de Imagen para Tamaño de la imagen H.261 H.263

videoconferencia en Pixeles Sub-QCIF 128 X 96 Opcional Requerido

QCIF 176 X 144 Requerido Requerido CIF 352 X 288 Opcional Opcional

4CIF 702 X 576 N/D Opcional l6CIF 1408 X 1152 NID Opcional

H.263 ha demostrado en pruebas de fabricantes [39], tener un mejor desempeño que H.261. Por ello, sería recomendable no perder de vista este estándar y su incorporación en los nuevos productos de videoconferencia, que probablemente manejen en un futuro no muy lejano el estándar H.263 como una mejor opción.

5. H.323 Versión 2.

Aprobada en Enero de 1998, la versión 2 de este estándar pone atención a las deficiencias de la versión 1 e introduce nueva funcionalidad dentro de los protocolos existentes, tales como Q.931, H.245 y H.225, así como también introduce nuevos protocolos. Las ventajas más significativas son en seguridad (incorporando autenticación, Integridad, Privacidad y no rechazo de fuentes existentes), establecimiento rápido de llamada, servicios suplementarios

53

como transferencias de llamada, entre otros y la integración T.120/H.323. Para una discusión más completa sobre las características de esta nueva versión de H.323 véase [32].

Probablemente la tendencia en los nuevos productos de videoconferencia de escritorio, sea el incorporar este nuevo estándar y será necesario recomendar el no perder de vista la posibilidad de actualización en los equipos existentes así como el costo beneficio del mismo en cuanto a calidad y precio.

5.3 PROPUESTAS PARA EL MANEJO DE VIDEO SOBRE ATM.

Por la naturaleza de los estándares de video H.320 y H.323, tenemos que ubicar a cada uno de ellos sobre un nivel de adaptación ATM (AAL, "ATM adaptation layer"), que permita utilizar una calidad de servicio y/o clase de servicio adecuada a las necesidad del formato, ya sea de velocidad constante de bit o de velocidad variable de bit.

5.3.1 VIDEO H.320 SOBRE ATM.

Ya se ha mencionado que ATM provee al administrador de red, la habilidad de transmitir voz, datos y video. Pero esto requiere una apropiada configuración para poder transportar dichas aplicaciones.

Para el caso del formato de video H.320, que fue diseñado para "correr" sobre líneas dedicadas ISDN (por H.261) a velocidades de 64 Kbps, y requiere de una tasa constante de bit, es necesario entonces garantizar que ATM ofrezca un servicio similar para el que fue concebido H.320, es decir, que sea orientado a conexión y con parámetros sensitivos al tiempo.

La opción es conocida como Servicio de Emulación de Circuitos (CES "Circuit Emulation Services"), el cual, crea un circuito "virtual" TDM sobre una red ATM y utiliza el servicio de tasa de bit constante (CBR).

El servicio de emulación de circuitos se presenta en dos formas, estructurada y no estructurada, Los cuales difieren en como reconocen el tráfico que fluye a través del enlace.

El formato de emulación de circuitos no estructurado, toma la secuencia de tramas a enviar por un El o un TI y las fracciona en bloques de 47 bytes. (Retomando que el tamaño de la celda ATM es de 53 bytes. 5 de estos bytes son usados para el encabezado, 1 byte es usado para el encabezado AAL 1, lo cual deja 47 bytes para datos). Cada uno de esos bloques son entonces puestos en una celda ATM y son enviados de esta manera. Haciendo lo anterior, la red ATM no tiene ningún conocimiento del contenido en cada celda. Por ello, no puede procesar de forma especial cualquiera de las llamadas individuales en el enlace El o T l. Cada llamada entrante a través del enlace debe ser enviada con el resto de ellas, sin hacer caso de donde se encuentra el destino final.

54

Más aún, debido a que la red debe reservar la capacidad completa del enlace El o TI, no podrá usar cualquier ancho de banda que otros canales no usen en el evento. En otras palabras, cualquier capacidad del canal no usada es desperdiciada.

Este formato no estructurado es óptimo para conexiones punto a punto que normalmente utilizan la capacidad completa del enlace El o TI.

El formato de emulación de circuitos estructurados trabaja de una manera similar al anterior, excepto que reconoce cada uno de los canales individuales que conforman el enlace. Esto permite procesar cada llamada individualmente, lo que entonces provee dos importantes características. Primero, la red puede asignar la capacidad de canal como sea requerida. En vez de asignar los 1.544 Mbps para una línea TI o los 2.048 Mbps para una línea El, la red puede asignar 64 Kbps para cada llamada en la línea. Es decir, si únicamente se utilizarán 10 canales en la línea El o TI, la red asignará únicamente 640 Kbps (10X64 Kbps), permitiendo que la capacidad restante del enlace sea usada por otras aplicaciones. Y segundo, puede rutear cada una de las llamadas individualmente. Cada llamada puede entonces ser enviada por su propio circuito virtual a su destino final.

Una ventaja adicional de este método es que permite una fácil detección de errores, lo que no sucede en el formato no estructurado de emulación de circuitos.

5.3.1.1 Establecimiento del Circuito

Para establecer la emulación de un circuito, la aplicación solicitante debe enviar un mensaje de SETUP a través de la red al receptor. Este mensaje, contiene todos los parámetros necesarios para asegurar la calidad de servicio (QoS) deseada. Durante la transmisión de este mensaje de la fuente al destino, los conmutadores a lo largo de la ruta determinan si ellos pueden manejar la nueva solicitud. Esta determinación es hecha por un algoritmo de Control de Admisión de Conexión (CAC, "Connection Admission Control"), el cual, determina el impacto de la solicitud en el conmutador y en los enlaces establecidos. Si la carga adicional arriesga la calidad de servicio de los conmutadores para los enlaces ya establecidos, entonces la nueva solicitud será rechazada.

El mensaje que se envía para la solicitud, es llamado elemento de parámetros de información del nivel uno de adaptación ATM. (Véase figura 5.7). Los primeros cinco bytes de este elemento son comunes a todos los elementos de parámetros de información AAL. Entre otras cosas contiene un identificador, la longitud completa del elemento de información y el tipo de servicio a solicitarse. En este caso, el elemento solicitado es AAL 1.

El resto de los parámetros en la figura 5.7 son específicos de AALl. Dentro del elemento hay algunos de particular interés. El primero en el elemento representa el subtipo deseado. Este especifica el tipo de datos a ser transmitidos por AAL 1. El cual puede ser un solo canal de voz, un canal de alta calidad de audio, video o nulo.

Los bytes 9, 11 y 12 son usados para especificar la capacidad de bit deseada. Si uno desea emular un circuito entero, se puede seleccionar de una variedad de tasas de bit preestablecidas incluyendo 1.544 Mbps (OSI), 44.736 Mbps (DS3) y 2.048 Mbps (El). O incluso, el usuario puede especificar un múltiplo de 8 ó 64 Kbps si únicamente desea pequeñas cantidades de

55

capacidad del canal dedicadas. Para la implementación de H.320 sobre ATM, se debe reservar NX64 Kbps acorde a la calidad deseada por el usuario. Pruebas han demostrado que con una capacidad de 3 84 Kbps (N= 6) se consigue una excelente calidad de video y audio para este estándar.

Otro campo es el del método de recuperación de frecuencia del reloj de la fuente, el cual es importante ya que la señal de salida debe tener la misma tasa que la del receptor, es decir, la fuente y el destino deben de tener sus relojes sincronizados. Cualquier diferencia entre los dos relojes resultará en un dramático decremento de la calidad de video y audio transportados.

Figura 5. 7 Parámetros de Información para el nivel de adaptación 1 de ATM

Bits 8 7 6 5 4 3 2 1 lnfonnation Element ldentifier o 1 o 1 1 o o o } 1 Coding

1 IE Instruction Fiel

.Sld.

Leng of Contents

Lenght on Contents Cont.

AAL Type o o o o o o o

Subtype identifier 1 o o o o 1 o

Subtype

CBR Rate lndentifier 1 o o o o 1 1

CBR Rate

Multiplier Identifier l o o o o 1 o

Multiplier

Multiplier Cont.

Clock Frcq. Recovery Mthd. l o o o l o o

Clock Freq. Rcovery Mthd

Error Correcti on M th d ID 1 o o o l o o

Error Correction Mthd

Data Transfer Blocksize ID 1 o o o 1 o 1

Data Transfer Blocksize

Data Transfer Blocksize Cont

Partially Filled Cell ID 1 o o o l l o

Partially Filled Cell Mthd.

1

1

o

o

o

1

o

1

Octets 1

2

3 4 5

6

7 8

9 10

11 12 13

14 15

16 17

18 19 20

21

Por lo anterior, se recomienda utilizar el servicio CBR con emulación de circuitos Estructurados para obtener un mejor aprovechamiento del canal con el transporte de video bajo el estándar H.320, ya que este último garantiza excelentes resultados desde los 384Kbps. Pruebas en el Laboratorio de RedUno con equipo Picture Tel bajo H.320 han permitido evaluar el desempeño de este estándar a través de la "nube" ATM. (Véase anexo B). Los resultados de dichas evaluaciones fueron completamente exitosos.

56

Como recomendaciones en este punto, se sugiere: (1) no perder de vista la liberación del estándar para AAL2, que es diseñado para el servicio rt-VBR, que podría presentar otra alternativa excelente para el transporte de H.320 sobre ATM , configurando sus respectivos parámetros, como SCR (al menos 384 Kbps), PCR y MBS, así como los de QoS correspondientes para minimizar los tiempos de entrega de video y audio. CDV, CTD y CLR. (2) Seguir, al igual que en Frame Relay, la incorporación del estándar H.263 en vez de H.261.

5.3.2 VIDEO H.323 SOBRE ATM

La cantidad de información en una señal de video, depende de la actividad en la escena capturada. Cuando se comprime el video, la velocidad de bit resultante puede ser muy variante, lo cual es referenciado como tasa variable de bit (VBR, Variable Bit Rate). Cuándo únicamente se fuerza una capacidad de salida fija, (como en la transmisión de conmutación de circuitos y emulación de circuitos vista anteriormente), la compresión del video es ajustada para mantener la capacidad de transmisión dentro del límite prescrito por el canal. Cuando esto se hace, y sin tomar en cuenta el contenido de la información en la señal, la calidad de la señal recibida puede variar con la compresión. (Generalmente el efecto es reducido por un almacenamiento apropiado). En contraste, la multiplexación estadística en redes de paquetes permite que la velocidad de transmisión varíe para poder reflejar el contenido de la señal de información. Esto consecuentemente, hará que el receptor perciba una constante calidad de video.

Por ejemplo, la figura 5.8 muestra la transmisión de información de video a tasa de bit constante (como es para H.320). La cantidad de información generada por esta terminal, varía, dependiendo en parte de la imagen siendo transmitida y la presencia o ausencia de movimiento en dicha imagen. Como resultado, la cantidad de datos comprimidos variará enormemente en el tiempo. Los datos que exceden la tasa de transmisión acordada son descartados, y por ello la calidad de la imagen se ve degradada en el extremo receptor. Otra forma de observar la degradación de la calidad, es que cuando se requiriere una mayor capacidad, en vez de descartar esos datos, una "burda" compresión es usada para producir la cantidad apropiada, decrementando considerablemente la calidad del material codificado de video y audio.

En ATM, es posible variar la tasa de transmisión de bits para hacer concordancia con la cantidad de información a ser transmitida. Como se observa en la figura 5.8b, la calidad de video se mantiene constante durante un periodo de tiempo. El servicio ATM que logra lo anterior, como ya fue mencionado, es llamado Tasa Variable de Bit de Tiempo Real (rt- VBR), que precisamente es el que se debe incorporar para el transporte del estándar de video H.323 sobre IP, por la naturaleza de este descrita en el capítulo 3.

Pero por otro lado, para el servicio de Tasa Variable de Bit de Tiempo Real (rt-VBR), el ETSI (European Telecommunication Standards Institute, Instituto de Estándares de Telecomunicaciones Europeo) y el ITU-T se encuentran actualmente trabajando en la definición del nivel de adaptación 2 de ATM, AAL2 (basado en AALI), mientras que el Foro ATM se encuentra presionando fuertemente hacía la solución para el servicio rt-VBR con AAL5, que es diseñado para transportar tráfico de LAN en celdas ATM [42]. Por lo anterior, será este último por no existir aún un estándar para AAL2, sobre el cuál se propone el manejo del estándar de video H.323 por su encapsulación en IP, aunque por supuesto no se debe de perder de vista la liberación del estándar AAL2 apropiado para este estándar de video.

57

Figura 5. 8 Calidad de Imagen constante a través de comunicaciones de tasa variable de bit

Cantidad de Información

Cantidad de Información

Calidad de la imagen

} Transmisión de tasa constante de bit

Tiempo.

(a) Calidad de la imagen en comunicaciones de tasa constante de bit.

Tiempo.

Calidad de la imagen

}

Transmisión de tasa variable de bit

(b) Calidad de la imagen en comunicaciones de tasa variable de bit

5.3.2.1 Capa 5 de Adaptación ATM (AALS)

Tiempo

Tiempo.

Este servicio es utilizado para enviar paquetes de datos convencionales a través de una red ATM. Aún cuando ATM utiliza celdas pequeñas de tamaño fijo en el nivel más bajo, AAL5 presenta una interfaz que acepta y entrega paquetes largos y de longitud variable. En particular, AAL5 permite que cada paquete contenga entre 1 y 65,535 octetos de datos. La figura 5.9 ilustra el formato de paquete que utiliza AAL5.

A diferencia de la mayor parte de las tramas de red que colocan la información de control en un encabezado, AAL5 la coloca en un registro al final del extremo del paquete. Este registro de AAL5 contiene un campo de longitud equivalente a 16 bits, un verificador por redundancia cíclica de 32 bits (CRC), utilizado como una suma de verificación de trama, y dos campos de 8 bits llamados UU, usado para transferir información usuario a usuario transparentemente y CPI, que indica la interpretación de los campos restantes en la cola del paquete.

5.3.2.2

Figura 5. 9. Formato del paquete básico para AAL5

Octetos de datos Entre 1 y 65,535

l (a) Formato del paquete básico AAL5 acepta y entrega

8 bits 8 bits 16 bits 32 bits lJU CPI LONGITIJD SUMA DE VERF. DE TRAMA suma

(b) campo en el remolque de 8 octetos colocado después de los datos

Ventajas del Transporte de Video H.323 sobre VBR.

58

Remolque 8 octetos

l

Las comunicaciones de tasa variable de bit tienen importantes ventajas para la red. Una de ellas es la multiplexación quien favorece la utilización del canal de comunicación y eficientiza el manejo del tráfico ráfaga. Véase la figura 5.10.

Figura 5.10. Multiplexación Estadística en Comunicaciones de Tasa Variable de Bit

Capacidad del canal no usada

Multiplexeo fuentes 1,2 y 3

Tiempo. Tiempo.

(a) Multiplexación de tasas máximas. (b) Multiplexación estadística de tasas variables.

59

La figura 5. lOa muestra la transmisión de información de una fonna convencional, con una máxima capacidad del canal asignada para cada fuente de información. En este caso, existen algunos picos en los cuales la capacidad no es totalmente utilizada. La figura 5. lOb muestra que las comunicaciones de tasa variable, hacen posible la asignación de la capacidad del canal dinámicamente, así que el total promediado de capacidades netas de salida, ahorrarán una cierta capacidad del total requerido.

De esta forma, la multiplexación en comunicaciones de tasa variable de bit en ATM se convierte también en una eficiente manera de manejar la información de ráfaga (que para nuestro estudio es el video, dependiendo de la imagen a procesar). Comparado con la multiplexación de canales de máxima capacidad (por ejemplo, CBR), una mayor cantidad de información puede ser transmitida con la misma capacidad del canal. Y a la inversa, una menor capacidad es requerida para transmitir la misma cantidad de información. Esto definitivamente contribuirá a disminuir los costos de comunicación y eficientar su uso.

5.3.3 VIDEO PAQUETIZADO SOBRE ABR

Hasta ahora hemos visto que la tecnología A TM es diseñada para soportar una gran variedad de aplicaciones, las cuales van desde aquellas que no son de tiempo real, hasta las multimedia de tiempo real. Hemos ubicado a las aplicaciones multimedia con rigurosos requerimientos contra el retraso, con las categorías de servicio CBR y rt-VBR de ATM, dependiendo de la naturaleza del video, ya sea constante o paquetizado respectivamente; y hemos dicho también, que cuando los recursos de la red no se encuentran disponibles para soportar una aplicación multimedia, esta es rechazada. En tal circunstancia, plantearemos ahora la situación de sí la categoría de servicio de tasa disponible de bit (ABR), puede ser usada en ese momento y poder garantizar un adecuado desempeño y calidad mientras se vuelve a solicitar un servicio con CBR y rt-VBR.

ABR provee una tasa mínima de celdas (MCR) y garantías de pérdida baja de celdas, lo cual es debido a que utiliza un control de retroalimentación de ciclo cerrado, para indicar a las fuentes congestión en la red. Las fuentes ajustan su tasa permitida de celdas (ACR, "Allowed Cell Rate") basándose en la información de retroalimentación de la red. En una conexión ABR, las celdas de administración de recursos (RM, "resource management") son periódicamente enviadas por la fuente al destino. Los conmutadores a lo largo de la ruta reportan la velocidad máxima actual que ellos pueden soportar en la celda RM. Las celdas RM en dirección hacía adelante (fuente a destino), son llamadas FRM, "Forward RM' y las celdas RM en sentido contrario BRM, "Backward RM'.

Con este control de retroalimentación de ciclo cerrado se logra que las colas en los conmutadores de la red sean pequeñas, y además, las aplicaciones multimedia paquetizadas de video, pueden usar la información de retroalimentación para ajustar sus velocidades y así eficientar el uso de la capacidad del canal disponible. Aún más, el retraso por colas puede ser evitado, si parte de la capacidad del canal es reservada para tráfico multimedia por la conexión ABR.

Los principales problemas a resolverse, para soportar aplicaciones multimedia sobre el servicio ABR son:

60

• El servicio ABR provee garantías MCR, las cuales pueden ser usadas por las aplicaciones multimedia para conseguir una mínima calidad de servicio. Algunos de los actuales esquemas de conmutación ABR asumen que el MCR debe ser cero. Esos esquemas de conmutación tienen que ser modificados para soportar conexiones de no cero MCR.

• El servicio ABR fue diseñado para proveer soporte para aplicaciones de datos no sensitivas al retardo. Cuando se implementan aplicaciones multimedia sobre ABR, el retardo debe ser minimizado y la variación en la calidad de servicio también.

• Actualmente se están desarrollando varios estudios para poder implementar esta consideración. [43] muestra como la retroalimentación binaria puede ser usada para ajustar el tráfico generado por una aplicación de video. [ 44] discute como usar la retroalimentación de tasa explícita para transportar video sobre el servicio ABR y [45] desarrolla una serie de propuestas para aplicaciones multimedia sobre el servicio ABR de ATM.

En este punto se recomienda no perder de vista las implementaciones sugeridas por las investigaciones arriba mencionadas y establecer un marco de pruebas bajo los esquemas que se proponen, y evaluar así, la calidad de una videoconferencia sobre ABR.

61

CONCLUSIONES

Video sobre Frame Relay

Hemos visto como la tecnología "Frame Relay" efectivamente permite el transporte de videoconferencia y que bajo algunas simples implementaciones puede desempeñarse adecuadamente para las necesidades de los usuarios. Esta solución representa una importante consideración económica, principalmente para aquellos usuarios que no contemplan grandes gastos de inversión en un sistema de video, y por otro lado para los proveedores de este servicio, que como RedUno, podrán garantizar un buen desempeño atendiendo a las necesidades de sus clientes de videoconferencia, en el rango de los 64Kbps hasta los 2Mbps ofrecidos por "Frame Relay".

Además, "Frame Relay" se convierte no solo en una alternativa económica para la interconexión de redes privadas, sino más bien en una tecnología económica de integración de servicios de voz, video y datos, permitiendo ahorros sustanciales en comparación con ISDN y TDM; provocando con ello un mayor uso de las redes públicas "Frame Relay", lo que indudablemente acarreará una disminución en los costos tarifarías de este servicio y de los equipos.

Podemos decir también, que cuando se enlazan más de dos puntos en una videoconferencia en una W AN tipo ISDN, es requerida una unidad multipunto (MCU, "Multipoint Control Unit"), la cual sirve para establecer el puente entre varias localidades en una sola conferencia. Cada puerto del MCU usualmente cuesta en promedio $7000.00 USD., (Para cada sitio involucrado en la videoconferencia), más aparte el costo asociado a la capacidad del canal alquilada de cada línea involucrada en la videosesión, lo que resulta en un costo bastante alto. Con un solo enlace físico y múltiples circuitos virtuales "Frame Relay" garantiza un adecuado desempeño y por supuesto un ahorro sustancial para las empresas y usuarios para esta consideración, tanto en equipo como en contratos de líneas para cada sitio.

La videoconferencia puede trabajar muy bien sobre "Frame Relay", pero únicamente si seleccionamos y configuramos cuidadosamente el equipo involucrado en ello. Poniendo una estricta atención a la prioritización del tráfico de video y la disponibilidad de la capacidad del canal necesaria para la aplicación.

La tecnología de "Frame Relay" de hoy en día utiliza circuitos virtuales permanentes (PVC, "permanent virtual circuit") para establecer la comunicación entre los equipos de los usuarios, pero en un futuro no muy lejano incorporará el uso de circuitos virtuales conmutados (SVC, switched virtual circuit), haciendo aún más atractivo su uso, para voz, video y datos.

Video sobre A TM

Para ATM, podemos básicamente decir que si se trata de transportar video sobre un enlace dedicado punto a punto, y que se tiene contemplado distribuir una capacidad fija asignada para cada aplicación, y que además, la mayor parte del tiempo este enlace va estar ocupado, se recomienda utilizar emulación de circuitos no estructurados bajo CBR para cada fuente de datos, ya sea voz, video o datos. Garantizando con esto el desempeño deseado por el usuario.

62

Si por el contrario se desea trabajar con conexiones multipunto, se deben entonces definir diferentes rutas virtuales para cada sesión, y aún más si se incorpora el manejo de video de tasa variable de bit (como lo es H.323), entonces la recomendación debe ser definitivamente trabajar con rt-VBR ( que aún no esta liberado su nivel de adaptación, AAL2) o con VBR para encapsulamiento de video sobre IP. Lo anterior trae considerables ventajas, entre las que se encuentran: (1) Tasa de Calidad de Video Constante y (2) Ahorro en la capacidad del canal para ser usado por otras aplicaciones gracias a la multiplexación estadística con VBR.

No deben de perderse de vista los trabajos en el Foro ATM y otras investigaciones que proponen algunos algoritmos y esquemas para poder en un momento dado garantizar una conexión sobre un servicio ABR. Quizás esta solución, pueda servir para aquellos usuarios que no pretenden monitorear altas calidades de video y quizás solo les interese el audio o para aquellas aplicaciones de respaldo o uso esporádico considerando bajo costo de enlace.

Video sobre ATM y "Frame Relay"

En la tabla siguiente se resume la incorporación de video H.320 y H.323 sobre las tecnologías "Frame Relay" y ATM y algunos comentarios al respecto.

Formato de Video

H.320

H.320

H.323

H.323

Tecnología de Comentarios Red

No es posible mcorporar este estándar de video Frame Relay directamente a un FRAD. Se requiere de un dispositivo

especial para su transporte sobre Frame Relay.

Si es posible transportar este estándar de video a ATM NX64Kbps, a través de CBR, Emulación de Circuitos.

Frame Relay

ATM

Garantiza una calidad acorde a las necesidades del cliente. Requiere al menos un enlace de un E 1 o T 1 para ATM. Se sugiere para enlaces punto a punto y con una adecuada asignación de los canales para su utilización al 100%.

Si es posible transportar este estándar de video directamente por un FRAD, ya que maneJa encapsulamiento IP. Se sugiere hacer uso de las recomendaciones descritas en este trabajo para su meJor desempeño y calidad. Es muy económico comparado con ISDN y la propuesta ATM.

Si es posible transportar este estándar de video sobre ATM, a través de rt-VBR (AAL2 aún no se estandariza), y a través de VBR con AAL5. Garantiza una calidad de video constante y un ahorro substancial de la capacidad del canal. No debe de perderse de vista que en un futuro el uso del servicio ABR pueda también bajo algunas implementaciones servir para este tipo de video.

63

REFERENCIAS Y BIBLIOGRAFÍA

[l] ACT Networks, Inc., "Video Over Frame Relay White Paper". ACT Networks, Inc., January 1998.

[2] McCANNE, S and JACOBSON, V., "vic: A Flexible Framework for Packet Video," in Proc. Of ACM Multimedia '95, Nov. 1995

[3] PETROLEKAS, G., "Video Over Frame Relay: A discussion of the Current Status of Combining Video with Existing Voice, Fax, Data and LAN Communications Using Frame Relay Over Public and Privates Lines," ABL Canada Inc., September 1997

[4] DORGHAM, S., "Video Transmission over ATM and IP," GMD-Fokus Berlin, Nov. 1995

[5] KOSKELAINEN, P., "A Framework for Efficient MPEG-video Delivery in IP over ATM Networks," MSc Thesis, Univ. of Turku, Dept. of Computer Sciencie, Finland, December, 1995

[6] CISCO Systems, Inc., "Video Over ATM and Existing Networks," Cisco Systems, Inc. November 5, 1995

[7] ORNELAS, E., DIAZ F., "La utilización del Sistemas de Videoconferencia dentro del Instituto Politécnico Nacional" Tesis de Ingeniería. México, D.F. 1996

[81 Deighton John, "Picture Tel - Products -LiveLAN," Picture Tel Inc. Avalaible m http://www.top-copier.co.uk/livelanp.html

[9] TAVERA, FERNANDO, "Diseño e implementación de Redes Frame Relay y ATM," Tesis Maestría en Ciencias Computacionales, ITESM-CEM., Mayo de 1996

[10] UBC TEVIA Project, "Video and Audio Streams Over IP/ATM Wide Area Network," Technical Report 97-3, June 1997. Avalaible m: http ://www. cs. ubc. ca/nest/dsg/tevia fi les/techreport/techreport. html

[11] BARTLETT, John, "H.323 Videoconferencing Network Bandwidth Analysis," NSD Engieering Picture Tel Corporation, August 25, 1997

[12] FORD, Merilee. et al. "Internetworking Technologies Handbook". Cisco Systems, Cisco Press, New Riders Publishing 1997

[13] STALLINGS, W., "Data and Computer Communications"., Fifth Edition Prentice Hall, 1997

64

[14] STALLINGS, W., "High Speed Networks, TCP/IP and ATM Design Principies", First Edition, Prentice Hall, 1998

[15] CHIMIAK William. "A Comment on Packet Video Remate Conferencing and the Transport/Network Layers," Request for Comments 1453, IETF 1993.

[ 16] Packet TM Magazine Archives, "Building Consistent Quality of Service into the Network", Cisco Systems Inc. First Quarter 1995. http://www-rr.cisco.com/warp/public/674/6.html

[17] Cisco Systems Inc, "Cisco CCIE Fundamentals: Network Design and Cases Studies", Cisco Press, 1998.

[18] White Paper., "Guide to New Service Offerings, Priority Frame™", Cascade Communications Group. 1997. http://www.cascade.com

[19] White Paper, "Priority Frame™, Absolute Quality of Service in a Frame Relay Environment", Cascade Communications Group, January 1997. http://www.cascade.com

[20] RETTINGER Leigh A, "Desktop Videoconferencing: Technology and Use for Remate Seminar Delivery", Master Science Thesis, North Carolina State University, July 1995

[21] Motorola Info Center, "Frame Relay: Springboard to the Future ofHigh-Bandwidth Telecommunications", Motorola Inc. http://www.mot.com/MIMS/ISG/Papers/Springboard/spring.html

[22] CLARK, A, "Real-Time Services on the Internet", Computer Communications Networks - Specialist Course, University ofEssex, U.K., 1997

[23] MINOLI, D., y KEINATH, R., "Distributed Multimedia Through Broadband Communications Services, Artech House, Inc. Norwood, MA. USA 1994 pág.126

[24] ITU-T, "Recomendación H.320. Sistemas y Equipos Terminales Videotelefónicos de Banda Estrecha", Ginebra 1990

[25] Draft ITU-T, "H.323 Visual Telephone Systems and Equipment for Local Area Networks which provide a non-guaranted Quality of Service", May 28, 1996

[26] LIVIO, Lambarelli. "ATM Service Categories: The Benefits to the User". White Paper, ATM F orum, F ebruary 1997. http://atmfomm.com/atmforum/library/service categories.html

[27] "The Mistyfying Multimedia Referencing Over the Internet Using the H.323 set of Standars". http://www. interest. com/technology/itj

[28] International Telecommunications Union Sector Telecommunications (ITU-T). http://www.itu.ch

[29] TURLETTY, T., BELLCORE, C., "RFC:2032; RTP Payload Format for H.261 Video Streams"., Network Working Group. Octuber 1996

[30] SHARABI E., ROTEN Y., BEN-NAIM S., "Frame Relay". 1994. http://v.'\V\Y.rad.com/net\v·orks/l 994/fram rel/frame.htm

65

[31] GAREISS, Robín, "The Frame Relay Explosion", Data Communications, February 1995. http://www.data.com/Roundups/Framc Rclay.html

[32] DataBeam, "A Primer on the H.323 Series Standard", version 2.0, A Data Beam Corporation White Paper. http://www.databeam.com/standards

[33] "RFC 1889", ft_p.isi.edu/in-notes/rfc1889.txt

[34] "RFC 1890", ftp.isi.edu/in-notes/rfc1890.txt

[35] Real Time Multimedia Solutions For Business Networks, "Motorola Launches Major Initiative For Real-Time Multimedia Solutions For Business Networks", April 28, 1997 http://v....-,vw.mot.com/MJSM/ISG/PressAnnouncements/042897-3.html

[36] GREENSTEIN, Larry. "The Frame Relay Bandwagon", White Paper. Nwfusion special advertising. http ://www.nwfusion.com/whitepaper/fra relay/bandwagon. html

[37] PARADYNE. "Frame Relay Backgrounder". White Paper, 1998.

[38] ALDACO Yolanda, "La videoconferencia bajo Frame Relay: nueva herramienta para la empresa moderna". Revista Red, la Comunidad de Expertos en Redes. Año VII, Agosto de 1998, Número 95 http://w,vw.rcd.corn.mx/agosto98/avanccs.html

[39] GRINNELL, Rick. "Knowledge Note: H.263 Video Algorithm". PictureTel Corpooration. January 1 997.

[40] Motorola Inc., "Videoconferencing over Frame Relay",Application Note, June 19, 1997. http://www.mot.com/MIMS/ISG/Products/remote vu/appnote.html

[41] BROWN, D. & WILLIS, D., "Videoconferencing on Frame Relay Networks", Network Computing Online. 1997 http://\vww.networkcomputing.com/917/917fl.html

[42] LAPID Yael, "Video Communications in B-ISDN'', Rad Communications Corporation. F ebruary 199 5. http://www.rad.com/networks/1994/atm/videoatm.htm

[43] KANAKIA, H., MISHRA, P.P., and RAMAKRISHNAN, K.K., "An daptive congestion control scheme for real-time packet video transport". In Proc. Of ACM SIGCOMM, pages 20-3 1, Sept 1993

[44] LAKSHMAN, T.V., H., MISHRA, P.P., and RAMAKRISHNAN, K .. K., "Transporting compressed video over ATM networks with explicit rate feedback control". In Proc. Of IEEE INFOCOMM, 1997

[45] VANDAROLE, B., FAHNY, S., JAIN R., GOYAL, R., GOYAL, M., "Multimedia applications over the ATM ABR service", The Ohio State University, Octuber 1998.

66

ANEXO A

(Video H.323 con IP sobre Frame Relay)

67

Escenario de las Pruebas H.323 con IP sobre W AN Frame Relay

Descripción del producto

Livelan 3.0 es una aplicación de videoconferencia que cumple con el estándar H.323 y brinda capacidades integradas de audio y video a color sobre IP, además de cumplir con el estándar T.120 para colaboración de datos multipunto. Este producto incluye el siguiente material y componentes:

• CD-ROM (software, guía del producto, documentación de ayuda y notas de la versión) • Tarjeta de CODEC Livelan • Cámara de video con cable • 2 Bocinas multimedia con cable de alimentación y audio • Micrófono con cable de audio • Guía de instalación

Los requerimientos mínimos del sistema para instalar Livelan 3.0 son:

• Procesador Pentium a 100 MHz • 1 ranura de expansión PCI disponible • 70 MB libres de disco duro • 24MB en RAM • Monitor SVGA o VGA • Subsistema de video capaz de desplegar gráficos a color de 16 bits (alta densidad) • Tarjeta de red • Microsoft Windows 95 • Protocolo TCP/IP compatible con Winsock 1.1 y que soporte extensiones de Microsoft • Memoria virtual habilitada

La aplicación es configurable para trabajar bajo tres diferentes anchos de banda: 64 (audio solamente) 174 y 384 Kbps (video y audio en ambos casos). Incluye Liveshareplus una aplicación suplementaria de datos que permite: envío de mensajes, transferencia de archivos, control remoto y compartición de aplicaciones, entre otras facilidades.

Livemanager 3.0 es una aplicación cliente/servidor orientada al control y monitoreo de estaciones y traductores de videoconferencia que cumplen es estándar H.323. Livemanager 3.0 incluye las siguientes características.

• Soporta SNMP para la administración de Livegateway 3. O • Soporta el protocolo Cal! Setup para Livegateway 3.0 • Administración de ancho de banda • Monitoreo de eventos de videoconferencia

Livemanager 3.0 incluye un CD-ROM (software, guía del producto, documentación de ayuda y notas de la versión) y la guía de instalación. Los dos componentes que integran la aplicación son:

68

Livemanager service (servidor) y Livemanager configuration console (cliente). A continuación se detallan los requerimientos mínimo para instalar cada componente.

• •

Livemanager service Procesador 486 o Pentium compatible • Windows NT 4.0 (server workstation) con • stack de TCP/IP y serv1c10 SNMP configurados

Livemanager configuration console Procesador 486 o Pentium Compatible Windows 95 o Windows NT 4.0 con stack de TCP/IP configurado

Livegateway 3.0 es un traductor bidireccional de H.320/H.323 diseñado para perm1tir la interoperabilidad entre estaciones de videoconferencia en IP (H.323) conectada a través de una red pública digital de ISDN, así como con estaciones sobre ISDN (H.320) y unidades de aplicación también soporta el estándar T.120. Livegateway 3.0 incluye el siguiente material:

• CD-ROM (software, guía del producto, documentación de ayuda y notas de la versión) • Tarjeta Livegateway ISA/EISA • Cable ISDN • Disco de diagnostico de arranque • Guía de instalación

Livegateway 3.0 requiere Livemanager 3.0 instalado y configurado en la red. Por otro lado, existen tres requerimientos mínimos para poner en operación esta aplicación, a saber:

Hardware y software

• 19 MB libre en disco duro • 1 ranura de expansión ISA o EISA disponible • Línea BRI ISDN • Dispositivo de red NT 1 con fuente de poder ( o conexión digital PBX) • Procesador 486 a 66 MHz con 16 MB en RAM (1 tarjeta), procesador PS a 90 MHz con 32

MB en RAM (2 tarjetas) o procesador P6 a 200 MHz con 32 MB en RAM (4 tarjetas) • Windows NT 4.0 (server) • Winsock 1. 1 • Servicio SNMP

Servicio SNMP

Este servicío permite la administración remota del Livegateway 3.0 desde Livemanager configuration console.

Como nota complementaria se recomienda instalar Livegateway 3.0 en un segmento de red con una alta concentración de clientes Livelan 3.0 a fin de minimizar el tráfico de red.

Nota: Para estas pruebas no se manejo la configuración del tamaño de las tramas "Frame Relay".

69

PRUEBAS

Escenario 1: Montaje sobre una red de área amplia (Wide Area Network-WAN)

Las estaciones de videoconferencia (Livelan 3.00.beta.01.016) se configuraron para conectarlas en segmentos Ethernet separados y enlazarlos a través de una red de "Frame Relay"; se contemplaron dos esquemas para la red Frame Relay: con un nodo de conmutación (Figura 1) y con dos nodos de conmutación (Figura 2). Se incorporaron las otras dos computadoras personales del escenario anterior, una en cada segmento, para observar el desempeño de la videoconferencia con un tráfico simultáneo de datos y audio-video, así como para definir requerimientos mínimo de ancho de banda en circuitos virtuales (PVC's) y puestos fisicos.

Figura l. Montaje sobre una red de área amplia (un nodo de conmutación)

Router

Ethernet

Nodo de Conmutación

• Video Arquimides

Router Troncales

Ethernet

• Video Euclides

Para el montaje con un solo nodo de conmutación se utilizaron dos enrutadores Cisco 2500 ( 1 puerto ethemet; 2 puertos seriales) y un nodo de conmutación Cascad e 6000 (2 tarjetas 6 puertos seriales V.35). En el segundo esquina esquema se reemplazó el Cascade 6000 por un Cascade 9000 (1 tarjeta de 8 puertos seriales V.35, 1 tarjeta de 4 puertos El canalizada) y se agregó otro Cascade 9000 (1 tarjeta de 4 puertos El canalizada).

Los enrutadores (DTE) se conectaron a los nodos de conmutación (DCE) a través d las interfaces seriales V. 35 cuya velocidad se fijó a diferentes valores. En el caso específico del segundo montaje los nodos de conmutación se conectaron entre sí a través de dos troncales de 1920 Kbps cada una, configuradas sobre puertos E 1. Se declaró un puerto lógico en cada interfaz serial de los nodos de conmutación para definir los circuitos virtuales.

El primer ensayo consistió en enviar tráfico de videocoferencia y datos (transferencias de archivos entre PC's extras) en el mismo circuito virtual, pero se observo una degradación importante en el video. Para escindir cada tipo de tráfico se crearon dos circuitos virtuales: uno para videoconferencia ( diferentes configuraciones, prioridad= 1) y otros para datos (CIR=l28,BC=l28, BE=O; prioridad=3); se configuraron subinterfaces en los puertos seriales de los enrutadores, con mapas estáticos, a fin forzar el tráfico destinado a cierta subinterfaz por un DLCI específico.

70

Con el analizador de protocolos se observó el tráfico de uno de los enlaces seriales, míentras desde las consolas de los enrutadores se llevaban registros de utilización de procesador y memoria. Usando HP OpenView bajo Solaris 2.5 sé monitoreo el estado y estadísticas de los circuitos virtuales declarados.

Para simular una red compuesta por varios nodos de conmutación, sobre las cuales se declararon varios circuitos virtuales que intercambiaban entre sí el mismo tráfico de datos antes de pasarlo a su destino final. Se evaluó el desempeño simulado tres, seis y nueve nodos de conmutación.

Se identificaron algunas deficiencias en el desempeño de la aplicación, por lo cual se decidió actualizar las estaciones de videoconferencia a la versión 3.00.035 de Livelan para continuar con esta evaluación.

Aquellas configuraciones cuyos resultados fueron satisfactorios se retomaron para observar cual era el impacto, en la calidad de la videoconferencia, al incrementar la utilización de las troncales al 80%, con el objetivo de emular las condiciones de operación de los nodos de conmutación en la red de UniNet. Para recrear esta situación se abrieron varios "ping's" entre PC's, con diferente tamaño de paquete, cuyo tráfico se hizo circular seis veces por una sola troncal; se forzó la ruta del circuito virtual de videoconferencia para utilizar esta troncal.

Nodo de l Nodode

Conmutación ,

. Router Router

1111'; -E-n-la-ce-Se-n-.a-1 -"""ffi

Ethernet Ethernet

• Video Arquimdes Video Euclides

1

71

Resultados de las Pruebas.

A continuación se detallan, por escenario, los resultados obtenidos en esta evaluación. La calificación de una videoconferencia se compone de 4 parámetros: calidad de video, retraso en video, calidad de audio y retraso en audio, de cada estación participante. La calidad se expresa utilizando alguno de los valores descritos en la tabla 1; la acotación de retraso viene dada en segundos.

Se utilizó la siguiente convención para expresar las puntuaciones: calidad(retraso ); por ejemplo, si el video fue de buena calidad y se midió un retraso de 2 segundos, entonces dicha calificación debe indicarse como: ****(2).

Las puntuaciones registradas corresponden a las últimas versiones del software señaladas en la descripción del escenario, con excepción de aquellos casos donde se indique lo contrario en forma explícita.

Valor Video Audio

* Distorsionado, difuso, muy retrasado, muy Entrecortado, imperceptible, no (pésimo) discontinuo o disgregado entendible, muy retrasado, ruido de

estática.

** Difuso en imágenes con cambios o Entrecortado o poco entendible por (malo) movimientos de regular a rápido, poco momentos, ruido de estática, distorsión

disgregado o discontinuo, imágenes poco en modo de conversación fluida. finas en el detalle, poca fidelidad en color

*** Continuo, no disgregado, imágenes con Entendible, con alguna distorsión entre (regular) poca resolución en el detalle (aspecto de pausas de silencio o al hablar rápido.

cuadros), difusión mínima sólo en imágenes con mov1m1ento rápido, fidelidad media en color

**** Continuo, imágenes con buena resolución, Entendible, con ruido de estática (bueno) sin difusión en imágenes con cambios o apenas perceptible, sin distorsión.

movimientos rápidos, fidelidad aceptable en color

***** Equivalente a una señal local de video Equivalente a una conversación directa. (excelente)

Tabla}. Valores para medir la calidad de video y audio.

Para generar tráfico de datos se realizaron transferencias de archivos de la PC en el segmento de Euclídes hacía la PC del segmento de Arquímides.

La leyenda Abortó sesión indica una inicialización incompleta de la videoconferencia o su cancelación ulterior después de unos minutos de interacción.

La leyenda Lento significa una transferencia de archivos con un retardo apreciable en su desarrollo comparada con su ejecución sin tráfico de audio y video.

1

72

La leyenda No evaluado aplica en aquellos casos donde se observó una videoconferencia de mala calidad con tráfico de audio y video solamente, la cual no ameritó ser considerada en el caso de tráfico simultaneo de audio-video y datos. En general, la utilización de CPU y memoria RAM en los enrutadores no alcanzó niveles críticos, incluso al someterlos a un tráfico de audio-video y datos simultaneo. La utilización del procesador alcanzó picos de alrededor del 40% y promediaron 18% en períodos de cinco minutos.

Escenario 1.- PARA UN NODO DE CONMUTACIÓN:

Ancho de banda configurado en LiveLan: l 74Kbps.

Nota: En las siguientes tablas de resultados se utilizó la siguiente notación para indicar las puntuaciones otorgadas a cada videoconferencia: puntuación_ arquimideslpuntuación _ euclides.

Vel. Pto. Serial/lógico PVC Video Audio

1

Otros 1

(Kbps) (CIR,BC,BE) !

192/192 (192, 192,0) Aborto sesión 256/256 ( 192, 192,64) ***(4)/ ***(l) ****(4)/ ****O) 1 Lento 320/320 (192,192,128) ***(2)/ ***(l) ****(2)/ ****O) 1 Lento

Puntuación de la calidad de video y retardo de video y audio a l 74Kbps (audio+video+datos)

Ancho de banda configurado en LiveLan: 384Kbps.

Vel. Pto. Serial/lógico PVC Video

1

Audio

1

Otros (Kbps) (CIR,BC,BE) 384/384 (384,384,0) Aborto sesión 448/448 (384,384,64) ***(4)/ ****(2) I ****(4)/ ****O) 1 Lento 512/512 (384,384, 128) ****<3)1 ***O) 1 ****(3)/ ****O) 1 Lento

Puntuación de la calidad de video y retardo de video y audio a 384Kbps (audio+video+datos)

Escenario 2. - PARA DOS NODOS DE CONMUTACIÓN:

Se definieron 2,5 y 8 PVC' s en los puertos lógicos NNI para simular 3,6 y 9 enlaces entre nodos de conmutación

Para: a) 3 enlaces entre nodos de conmutación y 174Kbps de ancho de banda configurado en LiveLan.

Vel. Pto. Serial/lógico PVC Video Audio Otros (Kbps) (CIR,BC,BE) 192/192 ( 192, 192,64) No evaluado 192/192 ( 192, 192, 128) No evaluado 256/256 (192, 192,64) ***(1)/* *(8) ****0)/ ****O) Lento 256/256 (192,192,128) ***(1)/ ***(8) ****(1)/ ****(l) Lento 320/320 (192, 192,64) ***0)1 ***(6) ****(1)/ ****O) Lento 320/320 (192,192,128) ***0)/ ***(6) ****0)1 ****O) Lento

Puntuación de la calidad y retardo de video y audio a 174 Kbps (audio+video+datos)

73

Para: b) 3 enlaces entre nodos de conmutación y 384Kbps de ancho de banda configurado en LiveLan.

Vel. Pto. Serial/lógico PVC Video Audio Otros (Kbps) ( CIR,BC,BE) 384/384 (384,384,64) **(3)/ **(4) ****(1)/ ****(l) Lento 384/384 (384,384, 128) **(3)/ **(5) ****0)1 ****O) Lento 448/448 (384,384,64) ****(1)/ ***(4) ****< l )/ ****( l) Lento 448/448 (384,384,128) ****(1)/ ***(3) ****( l )/ ****( l) Lento 512/512 (384,384,64) ****0)1 ****O) ****º )/ ****º) Lento 512/512 (384,384, 128) ****º )/ ****º) ****(1)/ ****(l) Lento

Puntuación de la calidad y retardo de video y audio a 384 Kbps (audio+video+datos)

Para: c) 6 enlaces entre nodos de conmutación y 174Kbps de ancho de banda configurado en LiveLan.

Vel. Pto. Serial/lógico PVC Video Audio Otros (Kbps) (CIR,BC,BE) 256/256 (192,192,64) ***(1)/ **(10) ****(1)/ ****(l) Lento 256/256 ( 192, 192, 128) ***( l )/ **(9) ****(1)/ ****(l) Lento 320/320 (192,192,64) ***(1)/ ***(2) ****0)/ ****(l) Lento 320/320 ( 192, 192, 128) ***(1)/ ***(2) ****O)/ ****O) Lento

Puntuación de la calidad y retardo de video y audio a l 74 Kbps (audio+video+datos)

Para: d) 6 enlaces entre nodos de conmutación y 384Kbps de ancho de banda configurado en LiveLan.

Vel. Pto. Serial/lógico PVC Video Audio Otros (Kbps) (CIR,BC,BE) 448/448 (384,384,64) Aborto 448/448 (384,384, 128) Aborto 512/512 (384,384,64) Aborto 512/512 (3 84,384, 128) Aborto

Puntuación de la calidad y retardo de video y audio a 384 Kbps (audio+video+datos)

Para: e) 9 enlaces entre nodos de conmutación y 174Kbps de ancho de banda configurado en LiveLan.

Vel. Pto. Serial/lógico PVC Video Audio Otros (Kbps) (CIR,BC,BE) 320/320 (192, l 92,64) Aborto 320/320 ( 192, 192, 128) Aborto

Puntuación de la calidad y retardo de video y audio a 174 Kbps (audio+video+datos)

74

RECOMENDACIÓNES

Para la interconexión sobre redes de área amplia, se deben considerar los siguientes aspectos al realizar una implementación con LiveLan 3.0:

• Crear un circuito virtual dedicado para el tráfico de videoconferencia· , de acuerdo a las siguientes especificaciones:

Para topologías con hasta 3 enlaces remotos:

Si LíveLan 3.0 está configurado al 74Kbps: CIR = 192, BC = 192, BE= 64/128 y prioridad= 1, con puerto lógico a 320 Kbps.

Si LiveLan 3.0 está configurado a 384Kbps: CIR = 384, BC = 384, BE= 64/128 y prioridad= 1, con puerto lógico a 512Kbps.

Para topologías con hasta 6 enlaces remotos:

Si LiveLan 3.0 está configurado a 174Kbps: CIR = 192, BC = 192, BE = 128 y prioridad = 1, con puerto lógico a 3 20Kbps.

Si LiveLan 3.0 está configurado a 384Kbps: No hay recomendación.

• Procurar canalizar el tráfico de videoconferencia por troncales cuya utilización no supere el 60% de su capacidad.

En esta evaluación se utilizó invariablemente un circuito virtual con CIR = 128, BC = 128, BE = O y prioridad = 3 para transportar tráfico de datos; es factible experimentar degradación de consideración en una videoconferencia si se emplea una configuración diferente tendiente a favorecer el tráfico de datos, en conjunción con las configuraciones de circuitos virtuales para videoconferencia recomendadas.

Configuración implementada en uno de los enrutadores Cisco 2500.

version 11"1 service udp-small-servers service udp-small-servers

hostname cabos

interface EthernetO no ip address 200.200.5.1 255.255.255.0 secondary no ip address 200.200.2.1 255.255.255.0

interface SerialO no ip address

!

no ip mroute-cache encapsulation frame-relay no ip route-cache frame-relay lmi-type ansi

Interface serialO.l point-to-point ip address200.200.6.2 255.255.255.0 no ip mroute-cache no ip route-cache frame-relay interface-dlci 20

interface serial0.2 point-to-point ip address 200.200.6.2 255.255.255.0 no ip mroute-cache no ip route-cache frame-relay interface-dici 22

1

interface Seriall ip address 100.1.1.2 255.255.255.0 encapsulation frame-relay IETF frame-relay lmi-type ansi

no ip classless ip route 200.200.1.0 255.255.255.0 200.200.3.1 ip route 200.200.4.0 255.255.255.0 200.200.6.1

line con O line aux O line vty O 4

end

75

76

ANEXO B

(video H.320 sobre A TM)

77

REPORTE TÉCNICO DE PRUEBAS ATM CON EQUIPO CISCO

Equipo: BPX Stratacom y AXIS Stratacom Compañía: Cisco Systems

Inicio de las pruebas: Marzo 1998 Termino de las pruebas: Abril 1998

Objetivo General

Durante el proceso de selección tecnológica para los switches ATM que son candidatos para formar la dorsal de UniNet, es necesario que los proveedores sometan a pruebas de laboratorio los equipos evaluados, con el fin de comprobar que funcionarán correctamente en la red UniNet.

Descripción del equipo

BPX

El equipo de Cisco BPX es un switch de A TM basado en estándares que soporta servicios de broadband, IP y broadband/narrowband.

El BPX ofrece confiabilidad, densidad de puertos, escalabilidad en IP.

Especificaciones del BPX

Configuración Física

• 15 slots Dos slots reservados para módulos de redundancia. Un slot reservados para el módulo de monitoreo de

estatus de alarmas (ASM). Doce slots para módulos de propósitos generales.

Dimensiones

• 17.72" W x 22.75" H x 27" D • 45 cm W x 57.8 cm H x 68.6 cm D 0 19" (48.3 cm) montable en rack

Requerimientos de Energía

• 1400W disipación (max.) • -48V DC o 208/240V AC

Crosspoint Switch Fabric

• Capacidad del switch de 20 Gbps • Doce puertos del switch a 800/ 1600 Mbps que soportan OC-12 cell rate • Establece hasta 20 millones de conexiones de celdas por segundo.

78

Interfaces de Red

• T3 (44.736 Mbps) con PLCP porTA-TY-000773 • E3 (34.368 Mbps) por ITU-T Rec. G.804 • OC-3/STM-l (155.520 Mbps) • OC-12/STM-4 (622.08 Mbps

Características comunes de las interfaces de red

• Más de 16 colas independientes para class-based queuing • Colas programables: tamaño máximo, servicio mínimo, ancho de banda, umbrales de CLP y EFCI • Marcado de velocidad explícita • Marcado de EFCI • Administración de congestión

Interfaces de Servicios Broadband

• Conforme a la Especificación del Foro de ATM v3.0 y v3.l: T3/DS-3 UNI (44.736 Mbps) OC-3 UNI (155.520 Mbps) SONET OC-12 UNI (622 Mbps) SONET E3 UNI (34.368 Mbps) STM-1 UNI (155.520 Mbps) SDH STM-4 UNI (622 Mpbs) SDH

Redundancia opcional

Todos los componentes son opcionalmente redundantes para tener un 100% de redundancia en el sistema, incluyendo el procesador de control, crosspoint switch, interfaz de red, interfaz de servicio, fuentes, y ventiladores

Administración de Red

• SNMP (StataView Plus)

AXIS

AXIS es un concentrador multiservicios de ATM. El concentrador multiservicios AXIS provee una variedad de servicios de ATM estándar en puertos con interfaz de usuario (UNI) o interfaz de red (NNI). El AXIS puede ser utilizado como una caja integrada a la línea de productos de switches de ATM de Cisco. Además puede servir como una unidad aparte que inyecta tráfico a una red ATM.

El AXIS adapta los datos entrantes a celdas ATM de 53 bytes usando el estándar de capa de adaptación de ATM (AAL) para transportarlos sobre una red de ATM. Integra interfaces de narrowband y broadband en una sola plataforma, con la cual se puede expandir su capacidad según las necesidades.

79

Pruebas

Esta fase contiene 5 pruebas que evalúan distintos aspectos de un switch ATM y su posible comportamiento al insertarse en la red:

• Prueba J. Jnteroperabilidad FR/A 1M (FRF 5). • Prueba 2. Interoperabilidad FRIA 1M (FRF 8). • Prueba 3. Emulación de circuitos por medio de CBR • Prueba 4. Interacción de clases de servicio. • Prueba 5. Evaluación del Sistema de Administración.

NOTA: Solo se detallan las pruebas 3 y 4 que son del interés de esta tesis. Las demás son omitidas por razones de confidencialidad.

Escenario de Pruebas

Prueba 3. Emulación de circuitos por medio de CBR

Alcance

La prueba 3 pretende probar la operación de la emulación de circuitos por medio de CBR y, aprovechando esta función, la transmisión de voz y vídeo sobre redes A TM.

Objetivo

En dos escenarios diferentes, en los que difieren los usuarios terminales, se configurarán circuitos digitales para transmitir tráfico CBR y circuitos con clase de servicio para datos (VBR de preferencia) para probar la interacción de diferentes clases de servicio en la red ATM y la capacidad de llevar voz y vídeo. En esta prueba, también se evaluará el manejo de buffers y congestión.

Desarrollo y Resultados

En los dos escenarios

• Se tenían los switches de ATM interconectados por medio de dos troncales una E3 y otra STMl

• Se conectó un analizador para congestionar al 80% la troncal STMI al BPX en una interfaz ATM STMI. Se configuró un PVC con clase de servicio VBR para este fin, teniendo como VPI/VCI 1/32. Configurando el BPX de tal forma que permitiera un efecto escalera, es decir que el tráfico empezara a transmitir a su MCR (Minimum Cell Rate) y subiendo hasta al PCR (Peak Cell Rate), el MCR= 2000 cps PCR=8000 cps.

Escenario l. Transmisión de Voz

PBX swtich AXIS/BPX

switch AXIS/BPX

PBX

Figura l. Escenario 1 para emulación de circuitos de CBR

80

1. Se configuraron los PBX Mitel para recibir un enlace E 1 y extensiones en los dos conmutadores. Y se conectaron por medio de un E 1 ( cable coaxial) a los switches Stratacom.

2. Se configuró un PVC con clase de servicio CBR del primer BPX al segundo BPX en sus puertos E 1 donde estaban conectados los conmutadores.

Una vez configurado lo anterior:

• Se hizo una llamada cuando la troncal estaba al 80% de utilización, y se escuchó muy bien, claro, sin cortes, ni eco y sin retraso.

3. Se simuló que el circuito virtual previamente definido pasaba por varios switches. Esto se logró haciendo PVCs de un switch a otro con interfaces NNI, pasando todos los PVCs por la troncal.

Se verificó con esto:

l. Después de simular diez switches la calidad de la voz es la misma que con un solo salto (dos switches).

2. Se simularon 15 saltos y la calidad de la voz siguió siendo la misma, sin tener retardo por los saltos.

3. Con esto se verificó que la clase de servicio CBR funciona bien, ya que reserva ancho de banda para la conexión. Además se comprobó que el CAC funciona adecuadamente.

4. Al subir el tráfico de CBR, el tráfico VBR que estaba transmitiendo a su PCR, empezó a bajar su velocidad automáticamente.

Escenario 2. Transmisión de Videoconferencia.

Equipo de Videoconferencia

•,.-..... -.· .. , .. -

Analizador

' ATMSTMI : j'

FC 02

' ' ~.-.- ···-:;:;··--.-El ;;..:-: ··-:x-:-·

switch AXIS/BPX

Cisco 7000

fi°8 "I A1MS1Ml ATME3 .... El

switch AXIS/BPX

FCD2 Equipo de Videoconferencia

Figura 2. Escenario 2 para emulación de circuitos de CBR

81

1. Se configuraron los equipos de videoconferencia PictureTel a 384 Kbps en el CODEC y se conectaron a los BPX por medio de un enlace E 1, para realizar la videoconferencia sólo era necesario que los relojes se sincronizaran para levantar el enlace y con esto la voz y el vídeo.

2. Se configuró un PVC con clase de servicio CBR del primer BPX al segundo BPX en sus puertos E 1 donde estaban conectados los equipos de videoconferencia ..

Una vez configurado lo anterior:

• Se hizo una videoconferencia cuando la troncal estaba al 80% de utilización, la calidad tanto del vídeo como de la voz era muy buena. En la voz no existían cortes, ni eco y en el vídeo la imagen era nítida y continua. Había un retraso que solamente era perceptible si se estaba viendo a la otra persona, sin embargo la voz y el vídeo estaban muy bien sincronizados. Se midió el retraso con las estadísticas del BPX y se observó que se tenían 5 milisegundos de retraso.

3. Se simuló que el circuito virtual previamente definido pasaba por varios switches. Esto se logró haciendo PVCs de un switch a otro con interfaces NNI, pasando todos los PVCs por la troncal.

Se verificó con esto:

1. Después de simular diez switches la calidad de la videoconferencia es la misma que con un solo salto (dos switches). Y el retraso sigue siendo de 5 milisegundos.

2. Se simularon 15 saltos y la calidad de la videoconferencia siguió siendo la misma, sin tener más retardo por los saltos, es decir se volvió a medir el retraso y seguían siendo 5 milisegundos.

3. Con esto se verificó que la clase de servicio CBR funciona bien, ya que reserva ancho de banda para la conexión. Además se comprobó que el CAC funciona adecuadamente.

4. Al subir el tráfico de CBR, el tráfico VBR que estaba transmitiendo a su PCR, empezó a bajar su velocidad automáticamente.

82

En cuanto al manejo de buffers en los dos escenarios se debe decir que el BPX tiene buffers de entrada del doble que de los de salida. Es decir, que en la entrada de una interfaz STMI aunque en el analizador se veía que estaba transmitiendo a 155 Mbps en las estadísticas del BPX se veía solamente el 46% de utilización, y eso se debe a que en la entrada tiene buffers para el doble de la capacidad del puerto.

Prueba 4. Interacción de Clases de Servicio.

Alcance

ATM tiene la premisa de transmitir varios tipos de tráfico sobre una misma plataforma.

Objetivo

Durante esta prueba se comprobará la coexistencia de las diferentes clases de servicio en los switches ATM. El objetivo es observar el manejo de buffers, prioridades, el CAC (Conection Admission Control), y el establecimiento de SVCs. Consta de un sólo escenario que agrupa todas las pruebas anteriores.

Escenario de Prueba

lf NMSde Cascade

Ethernet

NMSde Stratacom

1-r·:;:f:j Cisco 2500 j I V.35 ~-----~----'----~------'--~

1

L ... :::::::::::?:::::t::i FR E 1

r:~!!o:~~ ~ f ' ATMSTMI PBX

Cisco 7010

• El E I

E I ATMSTMI

Equipo de Videoconferencia

Figura 3. Escenario general de prueba (interacción de clases de servicio)

83

Desarrollo y Resultados

No se probaron los SVCs debido a que el equipo BPX que se tenía para realizar las pruebas no contaba con el hardware necesario para llevar a cabo está función por lo que queda pendiente el realizar pruebas para observar el funcionamiento de los SVCs.

1. Se activaron todos los PVCs descritos anteriormente, para tener interacción de clientes Frame Relay a Frame Relay, ATM a Frame Relay y emulación de circuitos.

2. Se conectó el analizador para generar una cantidad de tráfico que permitió saturar una troncal STMI

Se observó que:

1. Debido a los PVCs configurados y al tráfico inyectado por el analizador a la red se tenía una troncal al 103% de utilización y todos los circuitos virtuales configurados seguían operando.

2. Los pings y ftp llegaban a su destino. Sin embargo en el circuito configurado con clase de servicio ABR se perdían algunos pings debido al retraso que tenía por los demás circuitos virtuales. Lo anterior demuestra que el uso de prioridades en cuanto a clases de servicios funciona.

3. Los circuitos de CBR seguían funcionando bien, sin tener retraso, eco y teniendo claridad en la voz y en la imagen se tenía nitidez y continuidad. Con esto se volvió a comprobar el buen funcionamiento del CAC, ya que se reserva ancho de banda para este tipo de conexiones asegurando con esto la calidad de la aplicación.

4. Se hicieron las mismas pruebas de fallas que en la prueba 1: Falla de troncal, de fuente de poder, CPU redundante y tarjetas hot swap:

• En la falla de troncal se observó que las conexiones se iban inmediatamente por la otra troncal activa sin perjudicar a la aplicación; solamente en cuanto a la videoconferencia se perdía la comunicación debido a la sincronización de relojes, sin embargo se cae e inmediatamente después vuelve a marcar y se tiene otra vez la videoconferencia en menos de 30 segundos.

• La fuente redundante entra inmediatamente por lo que no se observa ningún cambio en los circuitos, solamente se muestra una alarma en las estadísticas del switch.

• La tarjeta redundante también entra inmediatamente sin haber interrupciones de ningún tipo. En este punto se debe tener cuidado en que las dos tarjetas tengan la misma configuración, ya que si se acaba de introducir el BPX hace una verificación de la configuración existente en el switch y en la tarjeta redundante y le copia a la redundante la configuración actual, este proceso tarda un poco (2-5 minutos).

• Se removió la tarjeta E3 estando en operación el switch, sin tener ninguna reacción negativa hacia el funcionamiento del switch, solamente un aviso de falta de tarjeta. Se volvió a insertar la tarjeta quitándose con esto el aviso.

5. Se hicieron respaldos de puertos lógicos tanto con Cascade como con el BPX, teniendo los mismos resultados que en las pruebas anteriores.

84

Observaciones Finales

Dentro de los puntos a evaluar quedaron pendientes algunos debido a falta de equipo por parte del laboratorio y otros por falta de equipo de Cisco.

Además se observó que se tienen que hacer algunas mediciones más profundas en algunos puntos para dar una evaluación correcta y justa para todos los proveedores participantes.