1 / 15

Nuevos Servicio en Redes de datos: Videoconferencia y Streaming

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. Índice. 1.- Introducción

pennie
Download Presentation

Nuevos Servicio en Redes de datos: Videoconferencia y Streaming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related