6. redes multimedia 2012 ii.ppt

7: Multimedia Networking 7-1

Redes Multimedia

Tomado de: Kurose J., ross K. “Computer Networking: A Top Down Approach”.

Multimedia y calidad de servicio (QoS): ¿Qué es?

Aplicaciones multimedia: audio y video via red(“continuous media”)

La red prove a las aplicaciones un nivel de rendimiento necesario para que estas funcionen

Objetivos

Principios• Clasificar las aplicaciones multimedia• Identificar los servicios de red que necesitan las aplicaciones• Hacer el mejor servicio de mejor esfuerzo• Mecanismos para proveer QoS

Protocolos y Arquitecturas • Protocolos especificos para usar en una red de mejor

esfuerzo• Arquitecturas para QoS

Aplicaciones multimedia de red

Aplicaciones multimedia (MM) de red

Características fundamentales:• Típicamente sensibles al

retardo• Retardo extremo a extremo• jitter de retardo

• Pero tolerante a pérdidas: pérdidas esporádicas causan fallos menores

• La antítesis de datos, que no son tolerantes a pérdidas pero si tolerantes al retardo

Clases de aplicaciones MM:1) Flujo de audio y video

almacenado (Streaming stored audio and video)

2) Flujo de audio y video en vivo (Streaming live audio and video)

3) Audio y video interactivo en tiempo real (Real-time interactive audio and video)

Jitter es la variabilidad del retardo de paquetes dentro del mismo flujo de paquetes

Flujo Multimedia Almacenado

Flujo: • Medio almacenado en el origen• Se transmite al cliente• Flujo: reproducción en el cliente

comienza antes que lleguen todos los datos

• Restricciones de tiempo para datos aun por transmitir: llegar a tiempo para reproducción

Flujo Multimedia Almacenado: ¿Qué es?

1. videograbado

2. videoenviado

3. video recibido,Reproducido en el cliente

flujo: en este momento, el cliente reproducelas primeras partes del video, mientras queel servidor aun envia las partes finales del video

retardode red

tiempo

Flujo Multimedia Almacenado: Interactividad

Funcionalidad VCR: el cliente puede pausar, rebobinar, adelantar, push slider bar Retardo inicial de 10s OK 1-2s hasta que orden se ejecute OK Se suele usar RTSP Restricciones de tiempo para datos aun por

transmitir: llegar a tiempo para reproducirse

RTSP - Real Time Streaming Protocol

Flujo Multimedia en Vivo

Ejemplos: Talk show de radio por internet (Internet radio talk show) Eventos deportivos en vivoFlujo Buffer de reproducción La reproducción puede retrasarse décimas de segundo

despues de su transmisión Aun tiene restricciones de tiempoInteractividad Es imposible adelantar Es posible pausar y rebobinar

Multimedia de tiempo real, Interactivo

Requerimientos de retardo extremo a extremo: audio: < 150 ms delay bueno, < 400 msec OK

• Incluye retardos de red y nivel de aplicación (paquetización)• Retardos más grandes – notorios, interactividad reducida

Inicialización de sesión ¿Cómo anuncia el destinatario su dirección IP, número de

puerto, algoritmo de codificación?

Aplicaciones: telefonía IP, video conferencia, mundos interactivos distribuidos

Multimedia sobre la Internet de hoy

TCP/UDP/IP*: “servicio de mejor esfuerzo” NO brinda garantias de retardo o pérdida

Las aplicaciones multimedia de Internet actual usan tecnicas del nivel de aplicación para mitigar

(lo mejor posible) los efectos del retardo y la pérdida

Pero Ud. dijo que las plicaciones multimediarequieren QoS y niveles de desempeño

Para ser efectivas!

?? ???

* y RTSP/IP

¿Cómo debe cambiar Internet para soportar mejor multimedia?

Filsofia de Servicios Integrados (Integrated services):

Cambios fundamentales en Internet para que las apps puedan reservar ancho de banda extremo-a-extremo

Requiere software nuevo y complejo en hosts y enrutadores

Liberalismo (Laissez-faire) Sin grandes cambios Más ancho de banda cuando se

necesita Distribución de contenidos,

multicast de capa de aplicacion Capa de aplicación

Filosofia de Servicios Diferenciados (DiffServ):

Menores cambios a la infraestructura de Internet, proveyendo a la vez servicios de 1ra y 2da clase.

¿Qué opina?

Algunas palabras sobre la compresión de audio

Señal analógica muestreada a tasa constante telefono: 8,000 muestras/s CD de musica: 44,100

muestras/s Cada muestra se cuantiza o

redondea ejm., 28=256 posibles valores

de cuantización Cada valor cuantizado se

representa por bits 8 bits para 256 valores

Ejemplo: 8,000 muestras/s, 256 valores cuantizados --> 64,000 bps

El receptor convierte de vuelta a una señal analógica: Cierta reducción de calidad

Tasas de ejemplo CD: 1.411 Mbps MP3: 96, 128, 160 kbps Telefonía Internet: 5.3 - 13

Algunas palabras sobre la compresión de video

Video es una secuencia de imágenes mostradas a tasa constante e.g. 24 imágenes/s

Una imagen digital es un arreglo de pixels

Cada pixel se representa por bits

Redundancia espacial temporal

Ejemplos:

MPEG 1 (CD-ROM) 1.5 Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (frecuentemente

usado en Internet, < 1 Mbps)

Flujo de audio y video almacenado

Flujo de Multimedia Almacenado

Técnicas de flujo de nivel de aplicación para obtener lo mejor del servicio de mejor esfuerzo: buffering en el lado del cliente Uso de UDP versus TCP Codificación múltiple de

multimedia

Remoción de jitter descompresión Disimulación de errores Interfaz gráfica de usuario con

controles para interactividad

Aplicación Media Player

Multimedia Internet: el enfoque más simple

audio, video no son transmitidos como flujo: retardos largos hasta su reproducción!

audio o video almacenado en un archivo Archivos transferidos como objetos

HTTP Recibido en su totalidad en el cliente luego pasado al reproductor

Multimedia Internet : enfoque de flujo

1. El browser recupera (GET) el metafile2. El browser lanza el reproductor, pasandole el metafile3. El reproductor contacta al servidor y el servidor envia el flujo

de audio/video al reproductor

Enviando flujo desde un servidor de flujo

Esta arquitectura permite protocolos no-HTTP entre el servidor y el reproductor de medios

Tambien puede usar UDP en vez de TCP.

transmisión de video a tasa de bits constante

retardode red

variable

Recepción de video en el

cliente

reproducción de videoen el cliente atasa de bit constante

Retardo dereproducciónEn el cliente

Transmisión de flujo Multimedia: Buffering en el cliente

Buffering en el cliente, retardo de reproducción compensan el retardo de red y de fluctuación (jitter)

Transmisión de flujo Multimedia: Buffering en el cliente

bufferedvideo

variable fillrate, x(t)

constant drainrate, d

Buffering en el cliente, retardo de reproducción compensan el retardo de red y de fluctuación (jitter)

Transmisión de flujo Multimedia: ¿UDP o TCP?

UDP El servidor envia a una tasa apropiada para el cliente (ajeno al

congestionamiento de red!) Tasa de envio frecuente = tasa de codificación = tasa constante Entonces, tasa de llenado = tasa constante – pérdida de paquetes

retardos de reproducción cortos (2-5 segundos) para compensar el retardo de fluctuación de red

Recuperación de errores: si el tiempo lo permite

TCP Enviar a la tasa máxima posible bajo TCP Tasa de llenado fluctúa debido a el control de congestionamiento TCP Retardos de reproducción largos: tasa de entrega TCP suave HTTP/TCP pasa más fácilmente a través de firewalls

Transmisión de flujo Multimedia: tasa(s) de cliente

P: ¿Cómo manejar las capacidades diferentes de tasas de recepción de los clientes? 28.8 Kbps dialup 100Mbps Ethernet

R: el servidor almacena múltiples copias de video, codificados a diferentes tasas. Puede transmitir el mejor para la conexión del cliente.

Codificación a 1.5 Mbps

Codificación a 28.8 Kbps

Control de usuario de medios de flujo: RTSP*

HTTP No fue pensado para contenido multimedia No tiene comandos para adelantar, etc.

RTSP: RFC 2326 Protocolo cliente/servidor de capa de aplicación. Permite al usuario controlar: rebobinado, adelantado, pausa, reiniciar,

etc…

Lo que no hace: No define como se encapsula el

audio/video para su envio por la red.

No restringe como se transportan los medios de flujo; pueden transportarse sobre UDP o TCP

No especifica la forma en que el reproductor de medios almacena en buffer el audio/video

* Real Time Streaming Protocol

RTSP: control fuera de banda

FTP usa un canal de control “fuera de banda”:

Un archivo se transfiere por una conexión TCP.

La información de control (cambio de directorio, eliminación de archivo, etc.) se envia por una conexión TCP separada.

Los canales “fuera de banda” y “en banda” usan números de puerto diferentes.

Los mensajes RTSP tambien se envian fuera de banda:

Los mensajes de control RTSP usan un número de puerto diferente al del flujo de medios: fuera de banda.

Puerto 554 El flujo de medios se considera

“en banda”. Puerto 332

RTSP Ejemplo

Escenario: Se envia metafile al navegador web El navegador lanza el reproductor El reproductor establece una conexión de control RTSP y una

conexión de datos al servidor de flujos

Servicio U-verse: el set top box se conecta a la red IP AT&T y es el host, con navegador y reproductor propietario para múltiples canales de musica y TV.Tambien actúa como “cable modem” y gateway para acceder a Internet.

Metafile de ejemplo

<title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>

RTSP – Operación

Los encabezados de flujo de medios RTSP tienen un ID de flujo y una marca de tiempo

RTSP – Ejemplo de intercambio C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OK Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0-

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231

S: 200 3 OK

MULTIMEDIA DE TIEMPO REAL: CASO DE ESTUDIO DE TELEFONIA IP

Aplicaciones interactivas de tiempo real

PC-2-PC phone Son proveidos por servicios

de mensajeria instantánea PC-2-phone

Dialpad Net2phone

Videoconferencia con Webcams

Se verá un ejemplo de telefonía Internet PC – 2 – PC en detalle

Multimedia Interactiva: Telefonia Internet

Explicar la Telefonía Internet a traves de un ejemplo Audio del locutor: rafagas alternadas de conversación y

periodos de silencio. 64 kbps durante rafagas de conversación

pkts generados solo durante las rafagas de conversación Bloques de 20ms a 8000Bytes/s: datos de 160 bytes.

Se agrega un encabezado de capa de aplicacion a cada bloque.

Bloque + encabezado se encapsulan en un segmento UDP. Durante las rafagas de conversación un segmento UDP es

transmitido cada 20 ms.

Telefonía Internet: Pérdida de paquetes y retardo

Pérdida de red: datagrama IP perdido por congestion en la red (desbordamiento de buffer de enrutador)

Pérdida por retardo: datagrama IP llega muy tarde para reproducirse en el receptor retardos: procesamiento y encolamiento en la red; retardos de

sistema final (emisor, receptor) Retardo no percibido por un escucha humano : < 150ms Retardo aceptable pero no ideal: 150 a 400 ms Retardo inaceptable : > 400 ms Retardo máximo tolerable típico: 400 ms

Tolerancia a pérdidas: dependiendo de la codificación de voz, perdidas escondidas, se puede tolerar tasas de pérdida de paquetes entre 1% y 10%.

constant bit ratetransmission

variablenetwork

delay(jitter)

clientreception

constant bit rate playout at client

client playoutdelay

Fluctuación de retardo (Delay Jitter)

Considere los retardos entremo a extremo de dos paquetes consecutivos: la diferencia puede ser mayor o menor a 20ms

Telefono Internet : retardo de reproducción fijo

El receptor intenta reproducir cada bloque exactamente q ms despues que el bloque fue generado. El bloque tiene un sello de tiempo t: reproducir bloque

en t+q. El bloque llega despues de t+q: los datos llegan muy

tarde para reproduccion, datos “perdidos” Compromiso for q:

q grande: menor pérdida de paquetes q pequeño: mejor experiencia de interactividad

Retardo de reproducción fijo

packets

packetsgenerated

packetsreceived

playout schedulep' - r

playout schedulep - r

• El emisor genera paquetes cada 20ms durante rafagas de conversación.• Primer paquete recibido en el instante r• Primer plan de reproducción: comienza en p• Segundo plan de reproducción: comienza en p’

Retardo de reproducción adaptivo, I

paquete esimo-i elrecibir de despues red de promedio retardo del Estimaciónd

paquete esimo-i el para red de retardotr

receptor elen reproduce se i paquete el queen instante Elp

receptor elpor recibido es i paquete el queen instatnte Elr

paquete esimo-i del timepode marcat

Estimación dinámica del retardo promedio en el receptor:

)()1( 1 iiii trudud

donde u es una constante preestablecida (e.g., u = .01).

Objetivo: minimizar retardo de reproducción, manteniendo baja la tasa de pérdida tardía.

Estrategia : ajuste adaptivo de retardo de reproducción: Estimar retardo de red, ajustar retardo de reproducción al inicio de cada rafaga

de conversación. Periodos de silencio comprimidos y estirados. Los bloques aun se reproducen cada 20ms durante rafagas de conversación.

Retardo de reproducción adaptivo II

Tambien útil para estimar la desviación promedio del retardo, vi :

||)1( 1 iiiii dtruvuv

Los estimados di y vi se calculan para cada paquete recibido, aunque solo se usan al inicio de una rafaga de conversación.

Para el primer paquete en una rafaga de conversación, el tiempo de reproducción es:

iiii Kvdtp

El instante de reproducción de los paquetes subsecuentes se calcula como un desplazamiento desde el instante en que el primer paquete se reprodujo. Sea:

iii tpq la longitud de tiempo desde que el primer paquete es generado hasta que es reproducido

donde K es una constante positiva.

Si elpaquete jtambien pertenece a la rafaga de conversación, este se reproduce en el instante

ijj qtp

Retardo de reproducción adaptivo III

Q: Cómo determina el receptor si un paquete es el primero en una rafaga de conversación?

Si no hay pérdida, el receptor verifica los sellos de tiempo sucesivos. Diferencia de sellos sucesivos > 20ms --> rafaga de conversación

comienza. Con posible pérdida, el receptor debe ver los sellos de

tiempo y los números de secuencia. Diferencia de sellos sucesivos > 20ms y números de secuencia sin

huecos --> rafaga de conversación comienza.

Recuperación de pérdida de paquetes

forward error correction (FEC): esquema simple

Para cada grupo de n bloques crear un bloque redundante calculado como la suma O excluyente de los bloques originales.

Enviar n+1 bloques, subiendo la velocidad de transmisión en un factor de 1/n.

Se puede reconstruir los n bloques originales si hay como mucho un bloque perdido de los n+1 bloques

El retardo de reproducción necesita ser fijados al tiempo que se necesita para recibir todos los n+1 paquetes.

Compromiso: Incrementar n, menos ancho

de banda perdido Incrementar n, mayor retardo

de reproducción Incrementar n, mayor

probabilidad que 2 o mas bloques se pierdan

Recuperación de pérdida de paquetes (2)

2° esquema FEC• “piggyback flujo de

menor calidad” • Enviar flujo de audio de

menor resolución como información redundante

• Por ejemplo, flujo PCM nominal a 64Kbps y flujo GSM redundante a 13Kbps

• Cuando no hay pérdida consecutiva, el receptor puede ocultar la pérdida• Tambien puede adjuntar los bloques (n-1) y (n-2) de menor calidad

Recuperación de pérdida de paquetes(3)

Intercalado Los bloques se dividen en unidades

más pequeñas Por ejemplo, 4 unidades de 5ms por

bloque Un pqeute contiene pequeñas

unidades de diferentes bloques

Si un paquete se pierde, aun se tiene la mayor parte de cada bloque

No tiene la sobrecarga de redundancia

Pero incrementa el retardo de reprodución

Resumen: Multimedia por Internet: bolsa de trucos

use UDP para evitar el (retardo) control de congestionamiento TCP para tráfico sensible al retardo

Retardo de reproducción adaptivo en el cliente: para compensar el retardo

Emparejar ancho de banda del flujo en el servidor para ancho de banda cliente-a-servidor disponible Escoger entre tasas de flujo pre-codificadas Tasa de codificacion dinámica en el servidor

Recuperacion de errores (sobre UDP) FEC, intercalado Retransmisiones, time permitting Ocultar errores: repetir datos cercanos

Hechos por el servidor y el cliente – no por Internet

PROTOCOLOS PARA APLICACIONES INTERACTIVAS DE TIEMPO REAL: RTP,RTCP,SIP

Real-Time Protocol (RTP)

RTP especifica una estructura de paquete para paquetes que transportan datos de audio y video

RFC 1889. Un paquete RTP provee

Identificacion del tipo de payload Numeración de secuencia de paquetes Sello de tiempo

RTP se ejecuta en los sistemas finales. Los paquetes RTP se encapsulan en segmentos UDP Interoperabilidad: si dos aplicaciones de telefonia por

Internet usan RTP, estos pueden trabajar juntos

RTP corre sobre UDP

Las librerias RTP proporcionan una interface de capa de transporte que extiende UDP:

• números de puerto, direcciones IP• Identificación del tipo de payload• Numeración de secuencia de paquetes• Sellos de tiempo e.g., RTSP

RTP – Ejemplo

Considere el envio de voz a 64Kbps, codificada con PCM sobre RTP.

La aplicacion recopila los datos codificados en bloques, e.g., cada 20ms = 160 bytes en un bloque.

El bloque de audio junto con el encabezado RTP forman el paquete RTP, que es encapsulado en un segmento UDP.

El encabezado RPT indica el tipo de codificación de audio en cada paquete El emisor puede cambiar la

codificación durante una conferencia.

El encabezado RTP tambien contiene los números de secuencia y los sellos de tiempo

Media DataUDPIP RTP

Sockets TCP y UDP

Control DataTCPIP

RTP y QoS

RTP no proporciona ningun mecanismo para asegurar la entrega oportuna de datos o para proporcionar otras garantias de calidad de servicio.

La encapsulación RTP solo es visible en los sistemas finales: no es visible a los enrutadores intermedios. Los enrutadores que proveen un servicio de mejor esfuerzo no

hacen ningun esfuerzo especial para asegurar que los paquetes RTP arriben a su destino de manera oportuna

RTP – Encabezado

Payload Type (7 bits): Indica el tipo de codificacion actualmente utilizada. Si el emisor cambia la codificacion en medi ode una conferencia, el emisor informa al receptor mediante este campo.

• Payload tipo 0, PCM mu-law, 64 kbps• Payload tipo 3, GSM, 13 kbps• Payload tipo 7, LPC, 2.4 kbps• Payload tipo 26, Motion JPEG• Payload tipo 31, H.261• Payload tipo 33, MPEG2 video

Sequence Number (16 bits): Se incrementa en 1 por cada paquete RTP enviado, y puede usarse para detectar paquetes perdidos y para restaurar la secuencia de paquetes.

Real-Time Control Protocol (RTCP)

Trabaja en conjunto con RTP. Cada participante en una sesión RTP transmite periodicamente

paquetes de control RTCP a todos los demas participantes Cada paquete RTCP contiene reportes del emisor y/o del receptor.

Las estadisticas reportadas son utilies para las aplicaciones

Las estadísticas incluyen el número de paquetes enviados, perdidos, la fluctuación de llegada, etc.

Se puede utilizar retroalimentación para controlar el desempeño El emisor puede modificar sus transmisiones basados en la

retroalimentación. Se usa con IP-TV Multicasting

- Para una sesión RTP tipicamente hay una única direccion multicast. Todos los paquetes RTP y RTCP pertenecientes a la sesión usan la dirección multicast.

- Los paquetes RTP y RTCP se distinguen unas de otras por el uso de numeros de puerto distintos

- Para limitar el tráfico, cada participante reduce su tráfico RTCP a medida que el número de participantes en la conferencia aunmenta

RTCP – Paquetes

Paquetes de reporte del receptor:

Fracción de paquetes perdidos, ultimo número de secuencia, fluctuación promedio de arribo.

Paquetes de reporte del emisor:

SSRC del flujo RTP, el tiempo actual, el número de paquetes enviados y el número de bytes enviados.

Paquetes de descripcion de origen:

e-mail del emisor, nombre del emisor, SSRC del flujo RTP asociado.

Proporciona mapeo entre el SSRC y el nombre del usuario/host.

Sincronización de flujos

RTCP puede sincronizar diferentes flujos de medios dentro de una sesion RTP.

Considere una aplicación de videoconferencia para la cual cada emisor genera un flujo RTP para video y uno para audio.

Sellos de tiempo en paquetes RTP ligados a los relojes de muestreo de audio y video No ligados al tiempo actual de reloj

Cada paquete de reporte RTCP del emisor contiene (para el paquete mas recientemente generado en el flujo RTP asociado): Sello de tiempo del paquete RTP Tiempo de reloj actual cuando el

paquete fue creado. Los receptores pueden utilizar esta

asociación para sincronizar la reproducción del audio y video

RTCP - Escalamiento de ancho de banda

RTCP intenta limitar su tráfico al 5% del ancho de banda de la sesión.

Eejmplo Suponga un emisor,

enviando video a la tasa de 2Mbps. Luego RTCP intenta limitar su tráfico a 100Kbps.

RTCP da 75% de esta tasa a los receptores; el sobrante 25% al emisor.

Los 75 Kbps se comparte equitativamente entre los receptores: Con R receptores, cada receptor

consigue enviar tráfico RTCP a 75/R Kbps.

El emisor consigue enviar tráfico RTCP a 25 Kbps.

Un participante determina el periodo de transmision de paquetes RTCP calculando el tamaño de paquete promedio (durante la sesión entera) y dividiendolo por la tasa asignada.

Session Initiation Protocol Desarrollado por IETFSIP – visión a largo plazo Todas las llamadas telefónicas y las llamadas de

videoconferencia se realizan via Internet La gente se identifica por nombres o emails, no

por números telefónicos. Se puede contactar al llamado, sin importar

donde yerra, ni el tipo de dispositivo IP que este usando.

SIP – Servicios

Establecer una llamada

Provee mecanismos para que el llamador deje saber al llamado que este quiere establecer una llamada

Provee mecanismos para que tanto el llamador como el llamado puedan acordar el tipo de medio y la codificación

Provee mecanismos para terminar la llamada.

Determinar la direción IP actual del llamado. Mapea un identificador

nemotécnico a una dirección IP actual

Gestion de llamada Agregar nuevos flujos

multimedia durante una llamada

Cambiar la codificación durante una llamada

Invitar a otros Retener y transferir llamadas.

Estableciendo una llamada a una dirección IP conocida

• El mensaje SIP de invitación de Alice indica su número de puerto y dirección IP. Indica la cadificación en que prefiere recibir Alice (PCM uLaw)

• El mensaje 200 OK de Bob indica su nro de puerto, dirección IP y la codificación preferida (GSM)

• Los mensajes SIP pueden enviarse sobre TCP o UDP; en este caso se enviaron sobre RTP/UDP.

• El puerto SIP por defecto es el 5060

time time

Bob'stermina l rings

A lice

167.180.112.24

193.64.210.89

port 38060

Law audio

G SMport 48753

Estableciendo una llamada (mas) Negociación del Codec:

Supongamos que Bob no tiene el codificador PCM uLaw

Bob responderá con la respuesta 606 Not Acceptable y listará los codificadores que puede usar.

Alice puede entonces enviar un nuevo mensaje INIVITE, notificando un codificador apropiado.

Rechazando la llamada Bob puede rechazar con

respuestas “busy,” “gone,” “payment required,” “forbidden”.

El flujo multimedia puede enviarse sobre RTP o algun otro protocolo.

Traducción de nombre y ubicación de usuario

El llamador quiere llamar al llamado, pero solo tiene su nombre o email.

Necesita obtener la dirección IP del host actual del llamado:

El usuario es movil Protocolo DHCP El usuario tiene diferentes dispositivos IP (PC, PDA, etc.)

Los resultados pueden basarse en:

Momento del dia (trabajo, casa) El llamador (no queremos que el

jefe nos llame a casa) Estado del llamado (llamadas

enviadas al correo de voz cuando el llamado esta ocupado hablando con otro)

Servicio proveido por servidores SIP:

Servidor de registros SIP Servidor proxy SIP

Registro SIP

REGISTER sip:domain.com SIP/2.0Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.comTo: sip:bob@domain.comExpires: 3600

Cuando Bob inicia un cliente SIP, el cliente envia un mensaje SIP REGISTER al servidor de registro de Bob (función similar a la usada en mensajeria instantánea)

Mensaje de registro:

Proxy SIP

Alice envia un mensaje invite a su servidor proxy Contiene la dirección sip:bob@domain.com

El proxy es responsible de enrutar los mensajes SIP al llamado Posiblemente a través de múltiples proxies.

El llamado responde a través del mismo grupo de proxies. El proxy devuelve el mensaje de respueta SIP a Alice

Contiene la dirección IP de Bob

Nota: un proxy es análogo a un servidor DNS local.

Ejemplo:Llamador jim@umass.edu con IP 217.123.56.89Llama a keith@upenn.edu

(1) Jim envia un mensaje INVITE al proxy SIP unass.

(2) El proxy reenvia la petición al servidor de registro upenn.

(3) El servidor upenn devuelve una respuesta de redirección, indicando que debe intentar keith@eurecom.fr

(4) El proxy umass envia INVITE al servidor de registro eurecom.(5) eurecom reenvia INVITE a 197.87.54.21, que ejecuta el cliente SIP de keith.(6-8) la respuesta SIP se envia de vuelta .(9)El flujo multimedia se envia directamente entre clientes. Nota: tambien un mensaje SIP ack, que no se muestra.

SIP client217.123.56.89

SIP client197.87.54.21

SIP proxyum ass.edu

SIP registrarupenn.edu

SIPregistrareurecom .fr

Comparación con H.323

H.323 es otro protocolo de señalización para audio y videoconferencia en tiempo real.

H.323 es una suite completa de protocolos verticalmente integrados para conferencias multimedia: señalización, registro, control de acceso, transporte y codecs.

SIP es un componente único. Trabaja con RTP, pero no lo controla. Puede combinarse con otros protocolos y servicios

H.323 proviene de ITU (telefonía). SIP proviene de IETF: adopta

muchos de sus conceptos de HTTP. SIP tiene influencia Web, mientras que H.323 tiene más influencia del sisetma de telefonía convencional.

SIP usa el principio KISS: Keep it simple stupid.

DISTRIBUCION MULTIMEDIA: REDES DE DISTRIBUCION DE CONTENIDOS

Redes de distribución de contenidos (CDNs)

Replicación de contenido Es complicado transmitir archivos

grandes (e.g. video) de un solo servidor en tiempo real

Solución: replicar contenido en cientos de servidores por toda Internet

El contenido se descarga a servidores CDN antes de tiempo

Al poner el contenido “cerca” del usuario se evita impedimentos (pérdida, retardo) para el envio de contenidos sobre rutas largas

Los servidores CDN se ubican preferentemente en redes de acceso/borde

Servidor de origenen Norteamerica

Nodo de distribución CDN

Sevidor CDNen Sudamerica Servidor CDN

en Europa

Servidor CDNen Asia

Redes de distribución de contenidos (CDNs)

Replicación de contenidos Un cliente CDN (e.g., Akamai) es

proveedor de contenidos (e.g., CNN)

CDN replica contenido de clientes en servidores CDN. Cuando el proveedor actualiza contenido, CDN actualiza los servidores

Servidor de origenen Norteamerica

Nodo de distribución CDN

Sevidor CDNen Sudamerica Servidor CDN

en Europa

Servidor CDNen Asia

CDN – Ejemplo

Servidor origen (www.foo.com) distribuye HTML reemplaza: http://www.foo.com/sports.ruth.gif

con http://www.cdn.com/www.foo.com/sports/ruth.gif

HTTP request for www.foo.com/sports/sports.html

DNS query for www.cdn.com

HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif

Origin server

CDNs authoritative DNS server

NearbyCDN server

Compañia CDN (cdn.com) Distribuye archivos gif Usa su servidor DNS

autoritario para enrutar peticiones de redirección

Mas sobre CDNs

Peticiones de enrutamiento CDN crea un “mapa”, indicando las distancias desde ISPs

hoja y nodos CDN Cuando llega una peticion a un servidor DNS autoritario:

El servidor determina el ISP del cual se origina la petición Usa el “mapa” para determinar el mejor servidor CDN

Los nodos CDN crean una red superpuesta de capa de aplicacion

MAS ALLA DEL MEJOR ESFUERZO

Mejorando QoS en redes IPHasta ahora: “haciendo lo mejor del mejor esfuerzo”Futuro: Internet de siguiente generación con garantías QoS

RSVP: señalización para reservación de recursos Differentiated Services: garantías diferenciales Integrated Services: garantías estrictas

Modelo simple para estudios de compartición y congestión:

Principios para garantías QoS Ejemplo: teléfono IP de 1Mbps, conexión FTP de 1.5 Mbps.

Ráfaga FTP puede congestionar el enrutador y causar pérdida de audio

Es deseable priorizar el audio sobre FTP

Es necesario marcar los paquetes para que el router distinga entre diferentes clases, y nuevas politicas de enrutamiento para tratar los paquetes apropiadamente

Principio 1

Principios para garantías QoS (mas) ¿Qué pasa si las aplicaciones se comportan mal? (audio envia a

una tasa más alta que la declarada) Vigilancia: forzar a la fuente adherirse a la asignación de ancho de banda

Marcar y vigilar en el borde de la red: Similar a UNI (User Network Interface) de ATM

Proveer protección (aislamiento) para una clase respecto de otrasPrincipio 2

Principios para garantías QoS (mas)

Asignar ancho de banda fijo (no compartible) al flujo: uso ineficiente de ancho de banda si el flujo no usa la asignación

Al proveer aislamiento, es deseable usar los recursos de la forma más eficiente posible

Principio 3

Principios para garantías QoS (mas)

Verdad básica: no se puede soportar demándas de tráfico mayores a la capacidad del enlace

Admisión de llamada: el flujo declara sus necesidades, la red puede bloquear una llamada (e.g. señal de ocupado) si no puede satisfacer los requerimientos

Principio 4

Resumen de principio QoS

Veamos los mecanismos paa conseguir esto ….

MECANISMOS DE PLANIFICACION Y VIGILANCIA

Mecanismos de planificación y vigilancia

Planificación: seleccionar el siguiente paquete para enviar por el enlace

Planificación FIFO: envio en orden de llegada a la cola Política de descartado: si un paquete llega a una cola llena: ¿a quién

descartar?• Tail drop: descartar paquete entrante• Prioridad: descartar/retirar en base a prioridades• Aleatorio: descartar/retirar aleatoriamente

Políticas de planificación: mas

Planificación por prioridades: transmitir el paquete en cola con más alta prioridad

Múltiples clases, con prioridades diferentes La clase puede depender del marcado u otra información del

encabezado, e.g. IP origen/destino, nro de puerto, etc.

Planificación round robin: Múltiples clases Recorre cíclicamente las colas de clases, atendiendo una

de cada clase (si existe)

Encolamiento justo ponderado (Weighted Fair Queuing): Round Robin generalizado Cada clase obtiene una cantidad ponderada de servicio en

cada ciclo

Mecanismos de vigilancia

Objetivo: limitar el trafico para que no exceda los parámetros declarados

Tres criterios comúnmente usados: tasa promedio (largo plazo): ¿Cuántos paquetes pueden

enviarse por unidad de tiempo (a largo plazo) Cuestión crucial: ¿cuál es la longitud de intervalo: 100 paquetes por

segundo o 6000 paquetes por minuto tienen el mismo promedio! Tasa pico: e.g., promedio de 6000 paquetes por minuto (ppm);

tasas pico de 1500 ppm Tamaño de ráfaga (Max.) : máximo numero de paquetes

enviados consecutivamente (sin pausas)

Mecanismos de vigilancia

Cubeta de fichas: limitar el ingreso al tamaño de ráfaga y tasa promedio especificado.

La cubeta puede retener b fichas Las fichas se generan a una tasa de R fichas/s, a menos que

la cubeta este llena Durante un intervalo de longitud t: el número de paquetes

admitidos es menor o igual a (r t + b).

Mecanismos de vigilancia (mas)

La cubeta de fichas y WFQ se combinan para proveer un limite superior garantizado de retardo, i.e., garantía QoS

Tasa de fichas, r

Tamaño de cubeta, b

Tasa por flujo, R

D = b/R max

Tráficoentrante

SERVICIOS INTEGRADOS Y SERVICIOS DIFERENCIADOS

Servicios integrados IETF Arquitectura para proveer garantías QoS en redes IP para

sesiones de aplicacion individual reservación de recursos: los enrutadores mantienen

información de estado de los recursos asignados (a la VC) y de los reqerimientos QoS

Admite/rechaza peticiones nuevas de establecimiento de llamadas:

Pregunta: ¿Puede el nuevo flujo entrante ser admitido con garantias de desempeño sin violar las garantias QoS hechas a los flujos ya admitidos?

Intserv: escenario de garantía QoS

Reservación de recursos Establecimiento de llamada, señalización

(RSVP) Tráfico, declaración QoS Control de admisión por elemento

Planificación sensiblea QoS (e.g., WFQ)

petición/respuesta

Admisión de llamada

La sesión entrante debe : Declarar sus requerimientos QoS

R-spec: define la QoS que se solicita Caracterizar el tráfico que enviará a la red

T-spec: define las características del tráfico Protocolo de señalización: necesario para transportar R-

spec y T-spec a los enrutadores (donde se requiere la reservación) RSVP

Señalización en Internet

Reenvio sin conexión (sin estado) por los

enrutadores IPServicio de

mejor esfuerzo

Sin protocolo de señalización de red

en el diseño IP inicial+ =

Nuevo requerimiento: reservar recursos en toda la ruta de extremo a extremo (sistemas finales, enrutadores) para QoS para aplicaciones multimedia

RSVP: Resource Reservation Protocol [RFC 2205] “ … permite a los usuarios comunicar sus requerimientos a la red de

forma robusta y eficiente” i.e., señalización ! Protocolo de señalización Internet anterior: ST-II [RFC 1819]

RSVP – Objetivos de diseño

1. Acomodar receptores heterogéneos (ancho de banda diferente en el trayecto)

2. Acomodar aplicaciones diferentes con requerimientos de recursos diferentes

3. Hacer del multicast un servicio de primera clase, con adaptación a la membresía de grupos multicast

4. Potenciar el enrutamiento multicast/unicast existente, con adaptación a cambios en las rutas unicast y multicast subyascentes

5. Controlar la sobrecarga de protocolo para crecer (en el peor caso) linealmente en # de receptores

6. Diseño modular para tecnologias heterogéneas subyascentes

RSVP: no…

Especifica como se reservan los recursos Mas bien: un mecanismo para comunicar necesidades

Determina la ruta que tomarán los paquetes Ese es trabajo de los protocolos de enrutamiento La señalización esta desacoplada del enrutamiento

Interactúa con el reenvio de paquetes Separación de los planos de control (signaling) y datos

(forwarding)

RSVP: vision general de operación

Emisores, receptor se unen a un grupo multicast Se hace fuera de RSVP Los emisores no necesitan unirse a grupo

Señalización emisor-a-red Mensaje de ruta: hacer conocer la presencia del emisor a los enrutadores Remoción de trayecto: borrar el estado del rayecto de los enrutadores

Señalización receptor-a-red Mensaje de reservación: reservar recursos desde el emisor(es) al receptor Remoción de reservación: remover las reservaciones del receptor

Señalización red-a-sistema-final Error de trayecto Error de reservación

6. redes multimedia 2012 ii.ppt

Documents

krismin-pertemuan ii.ppt

derecho financiero ii.ppt

conciencia fonologica ii.ppt

levitico_numeros ii.ppt

kuliah i-ii.ppt

acond amb ii.ppt

multimedia y redes de comunicacion

guÍa docente de redes multimedia

quimica ii.ppt

3. metalurgia_pate ii.ppt

exposicion elementos ii.ppt

6 intro redes 2011-ii.ppt

anatomie curs ii.ppt

kimia anorganik ii.ppt

acidos nbucleicos ii.ppt

redes industriales ii.ppt

fisica ii.ppt 2

redes multimedia material

aula cfsd ii.ppt

chpater ii.ppt