Nuevos Servicio en Redes de datos: Videoconferencia y Streaming

1. Nuevos Servicio en Redes de datos: Videoconferencia y Streaming I Jornadas de Arquitectura de Redes Seguras Universidad Pablo Olavide (Sevilla) 4,5 Marzo de 2003 Francisco Cruz Argudo: paco@di.uc3m.es Jose Juan Lopez Abellán: jose@di.uc3m.es

2. Índice 1.- Introducción 2.- Videoconferencia 2.1.- Baja calidad 2.2.- Alta calidad 3.- Streaming 3.1.- Directo 3.2.- VoD 4.- Algunas ¿Soluciones? 5.- El punto de vista de la red 6.- ¿Dudas?

3. Introducción • Aparición en las redes de datos de: • - Espacios dedicados y mixtos para la realización de • videoconferencias y distribución de vídeo • - salas de teledocencia: generación y recepción de • tráfico (+ requerimientos) • - salas de reuniones(- requerimientos) • - Puntos de recepción: • - soluciones software (+ masivas). • - soluciones HW (+ más requerimientos) • Equipos CODEC’s y de comunicaciones. • Aplicaciones de catalogación de contenidos digitales. • Nuevos protocolos y puertos. • - Tráfico muy sensible a los retardos • Nuevas necesidades de ancho de banda • Utilización de tráfico multicast de forma “masiva”

4. Videoconferencia Elementos a ubicar en la red: - CODEC’s - Set top box - PC’s (con o sin HW dedicado) - Elementos adicionales: - MCU’s - Gatekeeper. - Gateways.

5. Videoconferencia Alta calidad - ATM: codificación MJPEG en ATM a 15 Mbits: ¿Alternativas? - H.323: codificación H.261/H.263 4CIF (704*576) a 2 Mbits (60 fps) Baja calidad - H.323: codificación H.261/H.263 a CIF (352*288) a 768 Kbits (30 fps) - H.320: codificación H.261/H.263 a CIF a 512 Kbits. - H.323: soluciones de PC hasta CIF a 1.5 Mbits (30 fps) Mixta - ¿MPEG4?

6. Videoconferencia MCU - H.323 altas prestaciones: 6 sitios presencia continua hasta 2 Mbits (60 fps) - ATM altas prestaciones: - Conexión entre MCU’s (Cascading) Gatekeeper - Creación de una jerarquía a nivel nacional(plan de numeración)

7. Streaming Elementos a ubicar en la red - CODEC’s - Hardware - PC’s + Hardware - Receptores - Hardware - PC’s (con o sin HW) - Elementos adicionales - Servidores de streaming - Servidores de almacenamiento (VoD): acceso público/privado - Servidores de catalogación de contenidos digitales

8. Streaming Elementos a ubicar en la red - Alta calidad & Gran ancho de banda MPEG-1/MPEG-2 - Mixta MPEG4 ? - “Baja calidad” & menos ancho de banda WM Real QT - Servidores Streaming - Formatos - Dimensionamiento Almacenamiento (horas) - Comunicación CODEC’s y/o Servidores - Clientes: ¿cuantos y dónde?

9. Algunas ¿soluciones? • Creación de VLAN’s para los distintos CODEC’s lo más cercanos al router de salida. • Información de planificación y actividades con el Servicio de Comunicaciones (evitar “sustos”). • Actualizar equipamiento de red para evitar problemas con el tráfico multicast (nivel 2, especial atención a LANE) • Software con capacidad de proporcionar info.

10. EL OTRO PUNTO DE VISTAInfraestructura de la red

11. Problemas con tráfico multicast (I) • A partir de flujos con cierto ancho de banda (1Mbps) cualquier conmutador no da las prestaciones mínimas necesarias (p.ej. FORE ES3810) • Si se usa LANE/ATM el número de LEClients en la VLAN puede ser un problema (p.ej. Más de 10) • El equipo donde resida el BUS de la VLAN también puede ser un problema (p.ej. FORE LE155, mínimo ASX200BX o mejor Catalyst 5500). BUS cerca de las fuentes multicast.. • Deseables protocolos tipo CGMP de CISCO, o IGMP Snooping, para que se replique el tráfico multicast en los puertos estrictamente necesarios.

12. Problemas con tráfico multicast (II) • Prepara tus routers : tarjetas procesadoras tope de gama, memoria a tope, (p.ej. CISCO 7200 con NPE 400 y 256Mbytes). • Medir consumo de CPU de los routers permanentemente (60% susto!). • Limitar ancho de banda por subinterfaz para tráfico multicast. • Registrar los flujos multicast. (p.ej. CISCO Netflow a partir de IOS 12.3, si no, p.ej. sonda con NeTraMet con reglas para registrar flujos multicast).

13. Problemas con tráfico UDP en general • Limitar en cada subinterfaz de los routers IP el máximo ancho de banda utilizable por el tráfico UDP inyectado desde las subredes IP asociadas a cada uno de ellos (p.ej. Usando “Traffic policing”). • Esto nos defenderá además de “UDP flooding” proviniente de máquinas “infectadas” (gusanos,...), o mal configuradas, o simplemente incontroladas. • Tambi₫n nos permitirá medir los niveles de tráfico UDP habituales en cada subinterfaz, incluyendo el tráfico multicast. • No debe ser necesario que nos avisen ... (-;

14. Problemas con el tráfico en general • Acceso externo : ¿ Limitar el ancho de banda en salida desde subredes conflictivas ? ¿ Necesitan igual ancho de banda en entrada que en salida ? ¿ Para ofrecer contenidos MP3, “pelis”, etc ? • ¿ Por qué no gestionar anchos de banda asimétricos en entrada/salida ? (p.ej. Con “Traffic policing”). • El usuario no tiene porqué enterarse ... • Pruebas de esfuerzo de equipos : cuidado con lo que se compra ...

15. ¿Dudas? ¿Qué servicios? ¿Para quién? ¿Cómo? ¿RRHH? ¿Dimensionamiento y alcance?