6. Redes Multimedia 2012 II.ppt
-
Upload
edgar-saloma -
Category
Documents
-
view
58 -
download
1
Transcript of 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”.
7: Multimedia Networking 7-2
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
QoS
7: Multimedia Networking 7-3
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
7: Multimedia Networking 7-4
Aplicaciones multimedia de red
7: Multimedia Networking 7-5
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
7: Multimedia Networking 7-6
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
7: Multimedia Networking 7-7
Flujo Multimedia Almacenado: ¿Qué es?
1. videograbado
2. videoenviado
3. video recibido,Reproducido en el cliente
Dat
os a
cum
ulad
os
flujo: en este momento, el cliente reproducelas primeras partes del video, mientras queel servidor aun envia las partes finales del video
retardode red
tiempo
7: Multimedia Networking 7-8
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
7: Multimedia Networking 7-9
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
7: Multimedia Networking 7-10
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
7: Multimedia Networking 7-11
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
7: Multimedia Networking 7-12
¿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?
7: Multimedia Networking 7-13
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
kbps
7: Multimedia Networking 7-14
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)
7: Multimedia Networking 7-15
Flujo de audio y video almacenado
7: Multimedia Networking 7-16
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
7: Multimedia Networking 7-17
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
7: Multimedia Networking 7-18
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
7: Multimedia Networking 7-19
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.
7: Multimedia Networking 7-20
transmisión de video a tasa de bits constante
Cum
ulati
ve d
ata
time
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
buffe
red
vide
o
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)
7: Multimedia Networking 7-21
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)
7: Multimedia Networking 7-22
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
7: Multimedia Networking 7-23
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
7: Multimedia Networking 7-24
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
7: Multimedia Networking 7-25
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
7: Multimedia Networking 7-26
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.
7: Multimedia Networking 7-27
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>
7: Multimedia Networking 7-28
RTSP – Operación
Los encabezados de flujo de medios RTSP tienen un ID de flujo y una marca de tiempo
7: Multimedia Networking 7-29
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
7: Multimedia Networking 7-30
MULTIMEDIA DE TIEMPO REAL: CASO DE ESTUDIO DE TELEFONIA IP
7: Multimedia Networking 7-31
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
7: Multimedia Networking 7-32
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.
7: Multimedia Networking 7-33
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%.
7: Multimedia Networking 7-34
constant bit ratetransmission
Cum
ulati
ve d
ata
time
variablenetwork
delay(jitter)
clientreception
constant bit rate playout at client
client playoutdelay
buffe
red
data
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
7: Multimedia Networking 7-35
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
7: Multimedia Networking 7-36
Retardo de reproducción fijo
packets
tim e
packetsgenerated
packetsreceived
loss
r
p p '
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’
7: Multimedia Networking 7-37
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
i
ii
i
i
i
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.
7: Multimedia Networking 7-38
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
7: Multimedia Networking 7-39
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.
7: Multimedia Networking 7-40
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
7: Multimedia Networking 7-41
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
7: Multimedia Networking 7-42
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
7: Multimedia Networking 7-43
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
7: Multimedia Networking 7-44
PROTOCOLOS PARA APLICACIONES INTERACTIVAS DE TIEMPO REAL: RTP,RTCP,SIP
7: Multimedia Networking 7-45
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
7: Multimedia Networking 7-46
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
7: Multimedia Networking 7-47
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
RTSP
Media DataUDPIP RTP
Sockets TCP y UDP
Control DataTCPIP
7: Multimedia Networking 7-48
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
7: Multimedia Networking 7-49
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.
7: Multimedia Networking 7-50
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
7: Multimedia Networking 7-51
RTCP
- 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
7: Multimedia Networking 7-52
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.
7: Multimedia Networking 7-53
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
7: Multimedia Networking 7-54
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.
7: Multimedia Networking 7-55
SIP
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.
7: Multimedia Networking 7-56
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.
7: Multimedia Networking 7-57
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
Bob
193.64.210.89
port 38060
Law audio
G SMport 48753
7: Multimedia Networking 7-58
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.
7: Multimedia Networking 7-59
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
7: Multimedia Networking 7-60
Registro SIP
REGISTER sip:domain.com SIP/2.0Via: SIP/2.0/UDP 193.64.210.89 From: sip:[email protected]: sip:[email protected]: 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:
7: Multimedia Networking 7-61
Proxy SIP
Alice envia un mensaje invite a su servidor proxy Contiene la dirección sip:[email protected]
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.
7: Multimedia Networking 7-62
Ejemplo:Llamador [email protected] con IP 217.123.56.89Llama a [email protected]
(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 [email protected]
(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
1
2
34
5
6
7
8
9
7: Multimedia Networking 7-63
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.
7: Multimedia Networking 7-64
DISTRIBUCION MULTIMEDIA: REDES DE DISTRIBUCION DE CONTENIDOS
7: Multimedia Networking 7-65
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
7: Multimedia Networking 7-66
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
7: Multimedia Networking 7-67
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
1
2
3
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
7: Multimedia Networking 7-68
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
7: Multimedia Networking 7-69
MAS ALLA DEL MEJOR ESFUERZO
7: Multimedia Networking 7-70
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:
7: Multimedia Networking 7-71
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
7: Multimedia Networking 7-72
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
7: Multimedia Networking 7-73
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
7: Multimedia Networking 7-74
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
7: Multimedia Networking 7-75
Resumen de principio QoS
Veamos los mecanismos paa conseguir esto ….
7: Multimedia Networking 7-76
MECANISMOS DE PLANIFICACION Y VIGILANCIA
7: Multimedia Networking 7-77
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
7: Multimedia Networking 7-78
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.
7: Multimedia Networking 7-79
Políticas de planificación: mas
Planificación round robin: Múltiples clases Recorre cíclicamente las colas de clases, atendiendo una
de cada clase (si existe)
7: Multimedia Networking 7-80
Políticas de planificación: mas
Encolamiento justo ponderado (Weighted Fair Queuing): Round Robin generalizado Cada clase obtiene una cantidad ponderada de servicio en
cada ciclo
7: Multimedia Networking 7-81
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)
7: Multimedia Networking 7-82
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).
7: Multimedia Networking 7-83
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
WFQ
Tasa de fichas, r
Tamaño de cubeta, b
Tasa por flujo, R
D = b/R max
Tráficoentrante
7: Multimedia Networking 7-84
SERVICIOS INTEGRADOS Y SERVICIOS DIFERENCIADOS
7: Multimedia Networking 7-85
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?
7: Multimedia Networking 7-86
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
7: Multimedia Networking 7-87
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
7: Multimedia Networking 7-88
RSVP
7: Multimedia Networking 7-89
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]
7: Multimedia Networking 7-90
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
7: Multimedia Networking 7-91
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)
7: Multimedia Networking 7-92
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