Tema 3: Calidad de Servicio (QoS) Índice Introducción Aplicaciones multimedia Servicio “best-effort” Políticas de planificación y vigilancia Servicios Integrados (IntServ) RSVP Servicios Diferenciados (DiffServ) Redes - 2º cuatrimestre 2 1 Introducción Aplicaciones multimedia: audio y vídeo (“medios continuos”) QoS La red proporciona a las aplicaciones el nivel de rendimiento para operar adecuadamente. Redes - 2º cuatrimestre 3 Introducción Heterogeneidad en aplicaciones, sistemas finales y redes Definir una métrica objetiva: Retardo (delay) Variación del retardo (jitter) Ancho de banda Fiabilidad (pérdida de paquetes) Sensibilidad a estas medidas: Tráfico elástico (FTP, e-mail, telnet, HTTP). Tráfico no elástico (tráfico en tiempo real: vídeoconferencia) Redes - 2º cuatrimestre 4 2 Introducción Internet históricamente ha ofrecido un solo nivel de servicio: Necesidad de diferenciación de servicio en Internet y redes IP: “Best effort” Aplicaciones multimedia (unicast/multicast) Aplicaciones en tiempo real ⇒ QoS + IP Redes - 2º cuatrimestre 5 Introducción Aplicaciones multimedia en Internet: Transmisión de audio y vídeo almacenado Transmisión de audio y vídeo en directo Transmisión de audio y vídeo interactivo en tiempo real Redes - 2º cuatrimestre 6 3 Trasmisión multimedia almacenada Transmisión: Contenido almacenado en el origen Transmitido al cliente La reproducción en el cliente se inicia antes de haber recibido todo el contenido Restricciones temporales para los datos siguientes: a tiempo para ser reproducidos Redes - 2º cuatrimestre 7 Datos acumulados Transmisión multimedia almacenada 1. vídeo 2. vídeo enviado retardo de red 3. vídeo recibido, visualizad en el cliente tiempo Transmisión: en este momento, el cliente reproduce el inicio del vídeo, mientras el servidor continua enviando el resto del vídeo Redes - 2º cuatrimestre 8 4 Transmisión multimedia en directo Transmisión: Ejemplos: Buffer para transmisión retardada La transmisión se puede retardar hasta décimas de segundo Restricciones temporales importantes Programas radiofónicos en directo Eventos deportivos Interactividad: fast forward imposible rebobinado y pausa posibles Redes - 2º cuatrimestre 9 Transmisión interactiva en tiempo real Aplicaciones: Telefonía IP, videoconferencias Retardos extremo a extremo: Audio: < 150 msegs muy bien, < 400 msegs OK Retardos superiores Î Comunicación muy deteriorada Inicialización: ¿Cómo identifica un receptor su dirección IP, número de puerto, codificación, ...? Redes - 2º cuatrimestre 10 5 Multimedia en Internet hoy en día TCP/UDP/IP: servicio “best-effort” Î No garantiza retardos ni pérdidas Pero, las transmisiones multimedia requieren QoS y un nivel de rendimiento para ser efectivas! Las aplicaciones multimedia de hoy en día en Internet, utilizan técnicas a nivel de aplicación para mitigar (si es posible) los efectos de los retardos y las pérdidas Redes - 2º cuatrimestre 11 Mecanismos de QoS Tres mecanismos básicos: Seguir con “best-effort” Î Sobre-dimensionar capacidades Reservar a priori recursos: Servicios Integrados (IntServ) Priorizar determinados servicios/usuarios: Servicios Diferenciados (DiffServ) Redes - 2º cuatrimestre 12 6 Mecanismos para tráfico multimedia No es necesario realizar ningún cambio en la red Î Se sigue utilizando el “best effort”: Aumento de la capacidad (ancho de banda y capacidad de conmutación) en los ISPs Î Mejor servicio para los usuarios Î Más usuarios y mayor cuota. Las redes de distribución de contenidos replican su contenido y ubican este contenido en los extremos de Internet Î Reducción de la carga en los ISPs. Multimedia en directo Î Desplegar redes de superposición multidifusión (a nivel de aplicación). Redes - 2º cuatrimestre 13 Mecanismos para tráfico multimedia Las aplicaciones pueden reservar recursos entre los sistemas finales (IntServ): Protocolo para reservar recursos entre el emisor y el receptor. Modificar las políticas de planificación en las colas de los routers. Las aplicaciones deben “describir” el tráfico que van a enviar por la red (para poder reservar). Redes - 2º cuatrimestre 14 7 Mecanismos para tráfico multimedia Servicios diferenciados: Requiere cambios relativamente pequeños en las capas de red y transporte. Introducir un pequeño número de clases de tráfico (normalmente, dos) y asignar cada datagrama a una de estas clases. Cada datagrama recibe un servicio diferente en las colas de los routers. Se factura a los usuarios en función de los paquetes que envían por la red. Redes - 2º cuatrimestre 15 Compresión de audio Conversión analógico-digital Muestreo cada 125 microsegundos (8000 muestras/seg) Cuantización: cada muestreo es aproximado a un valor entre un número finito (p.e. 256). Cada valor se representa mediante un número binario (p.e. 1 byte para 256 valores). Codificación PCM (Pulse Code Modulation) o modulación Delta Compresión: MP3 (MPEG 1 layer 3) Compresión a 96 kbps, 128 kbps, 160 kbps, 192 kbps, … Se basa en máscaras psicoacústicas, reducción de la redundancia y buffers de reserva de bits Redes - 2º cuatrimestre 16 8 Compresión de audio 1,6 1,4 1,2 1 0,8 0,6 0,4 0,2 0 Muestreo Valor Binario Onda PCM 0 0000 0,1 0001 0,2 0010 ... ... 1,5 1111 Redes - 2º cuatrimestre 17 Compresión de vídeo Vídeo: secuencia de imágenes visualizadas a una tasa constante (p.e. 24 imágenes por segundo). Compresión: Redundancia espacial: una imagen con fondo blanco puede ser comprimida eficientemente. Redundancia temporal: repetición de una imagen con la imagen siguiente Estándares: MPEG 1 (vídeo calidad CD – 1.5 Mbps), MPEG 2 (vídeo calidad DVD – 3-6 Mbps) y MPEG 4 (compresión orientada al objeto). Redes - 2º cuatrimestre 18 9 Best-effort: multimedia almacenado Los clientes solicitan los archivos de audio y vídeo en los servidores (web o especiales para la transmisión multimedia). El archivo es segmentado y encapsulado mediante cabeceras especiales para tráfico multimedia (RTP – Real Time Protocol) El usuario puede interactuar con la reproducción (parar, rebobinar, …) Î RTSP – Real Time Streaming Protocol Reproductor de medios: Descompresión Eliminación de fluctuaciones Corrección de errores Interfaz gráfica + controles de interactividad Redes - 2º cuatrimestre 19 Best-effort: multimedia almacenado Acceso a través de un servidor Web (1): 1. 2. 3. 4. El navegador establece una conexión TCP con el servidor Web y solicita el archivo multimedia (utiliza HTTP). El servidor Web envía el archivo multimedia en un mensaje HTTP de respuesta. El cliente, reconoce la cabecera HTTP y la codificación multimedia del contenido Î Lanza el reproductor de medios asociado. El reproductor de medios procesa el archivo multimedia. Problema: el navegador actúa de intermediario Î descarga completa del archivo multimedia para reproducirlo. Normalmente, el envío del archivo se hace directamente al reproductor. Redes - 2º cuatrimestre 20 10 Best-effort: multimedia almacenado Acceso a través de un servidor Web (2): 1. 2. 3. 4. 5. El usuario pulsa un enlace al archivo multimedia. El hiperenlace apunta a un archivo meta que contiene la URL del archivo multimedia. La cabecera HTTP indica la codificación del archivo multimedia. El navegador reconoce la codificación, abre el reproductor y le pasa el cuerpo del mensaje HTTP (el archivo meta). El reproductor establece una conexión TCP con el servidor HTTP, solicitando el archivo multimedia. El archivo se envía en la respuesta HTTP al reproductor. Problema: la comunicación se establece sobre HTTP, y por lo tanto TCP. No permite al usuario interactuar fácilmente (pause/play, …) Redes - 2º cuatrimestre 21 Best-effort: multimedia almacenado Acceso a través de un servidor de transmisión: Cliente Navegador Servidores (1) Petición y respuesta HTTP para el fichero meta Servidor Web (2) Fichero meta Reproductor multimedia (3) Solicitud y envío del fichero multimedia Servidor Streaming Mejor interacción del usuario con la transmisión multimedia Posibilidad de usar UDP. Redes - 2º cuatrimestre 22 11 Best-effort: multimedia almacenado Buffer en el cliente: compensa el retardo de la red y el jitter. Recepción de vídeo en el cliente Retardo de red variable Reproducción en el cliente a velocidad constante video en buffer Transmisión de vídeo velocidad constante Datos acumulados tiempo Retardo de reproducción en el cliente Redes - 2º cuatrimestre 23 Best-effort: multimedia almacenado Buffer en el cliente: velocidad de desde la llenado = x(t) buffer del cliente velocidad de consumo = d red al reproductor Datos recibidos del vídeo En teoría x(t) == d, excepto con pérdidas de paquetes. Si x(t) >>> d durante períodos grandes Î No se producirán desabastecimientos si buffer suficiente. Si el buffer es pequeño y x(t) fluctúa mucho alrededor de d Î Posible desabastecimiento. Redes - 2º cuatrimestre 24 12 Best-effort: multimedia almacenado UDP: El servidor transmite a un ratio adecuado para el cliente (sin ser consciente de la congestión en la red) Pequeño retardo de reproducción (2-5 segs), para compensar los retardos de la red + jitter. Recuperación de errores: si el tiempo lo permite. TCP: Enviar a la máxima velocidad posible con TCP. La velocidad fluctúa debido al control de congestión en TCP Î Requiere un retardo de reproducción mayor. HTTP/TCP atraviesa fácilmente la mayoría de los cortafuegos. Redes - 2º cuatrimestre 25 RTSP Real-Time Streaming Protocol (RFC 2326) HTTP no gestiona adecuadamente el contenido multimedia No dispone de comandos para rebobinar, pausa, ... Protocolo cliente-servidor del nivel de aplicación Permite al usuario controlar la reproducción del archivo multimedia: Pausa, continuar, rebobinar (adelante y atrás), reposicionar, ... Redes - 2º cuatrimestre 26 13 RTSP RTSP no hace: No define como se encapsula el audio o vídeo para ser transmitido por la red. No restringe como se debe transportar el archivo por la red: UDP o TCP. No especifica como utilizar los buffers en el cliente RTSP es un protocolo “fuera de banda”: Los mensajes de control RTSP utilizan puertos diferentes al flujo multimedia (puerto 554). Redes - 2º cuatrimestre 27 RTSP: Ejemplo Cliente Servidor HTTP GET Navegador Servidor Web Mefa fichero SETUP PLAY Reproductor multimedia Fichero multimedia PAUSE Servidor Streaming TEARDOWN Redes - 2º cuatrimestre 28 14 RTSP: Ejemplo Metafile enviado por el navegador: <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> Redes - 2º cuatrimestre 29 RTSP: Ejemplo Comandos RTSP intercambios entre el reproductor multimedia y el servidor de streaming: 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=0C: 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 Redes - 2º cuatrimestre 30 15 Telefonía en Internet Alternar períodos de habla con períodos de silencio 64 kbps durante los períodos de habla Los paquetes se generan únicamente durante los períodos de habla: Grupos de 20 milisegundos a 8 Kbytes/seg = 160 bytes. A cada paquete se le incluye una cabecera de aplicación. Datos + cabecera encapsulados en un segmento UDP. La aplicación envía un segmento UDP mediante sockets cada 20 milisegundos. Redes - 2º cuatrimestre 31 Telefonía en Internet: Limitaciones Pérdidas de paquetes: pérdida de datagramas IP debido a la congestión de la red (sobrecarga de los buffers de un router). Retardos: un datagrama IP es recibido demasiado tarde para ser reproducido. Retardos de transmisión, de cola en la red, de procesamiento en los sistemas finales. Retardo máximo tolerable: 400 milisegundos. Variabilidad del retardo (jitter) Redes - 2º cuatrimestre 32 16 Telefonía en Internet: Limitaciones Recepción de vídeo en el cliente Retardo de red variable (jitter) Reproducción en el cliente a velocidad constante video en buffer Datos acumulados Transmisión de vídeo velocidad constante tiempo Retardo de reproducción en el cliente Redes - 2º cuatrimestre 33 Telefonía en Internet: Limitaciones El jitter se elimina mediante: Números de secuencia. Marcas de tiempo: el emisor marca cada porción con el instante de tiempo en que fue generada. Retrasando la reproducción. Se definen dos estrategias de reproducción: De retardo fijo De retardo adaptativo Redes - 2º cuatrimestre 34 17 Telefonía en Internet: Retardo fijo El receptor intenta reproducir cada porción exactamente q milisegundos después de ser generada: Si la porción tiene la marca de tiempo t Î Reproducir en t+q Si se recibe más tarde de t+q Î demasiado tarde y se descarta. Balance del valor para q: Cuanto mayor sea q Î Menor número de paquetes descartados. Cuanto menor sea q Î Mejor será la interactividad. Un buen valor para q es 400 milisegundos. Redes - 2º cuatrimestre 35 Telefonía en Internet: Retardo fijo packets loss packets generated packets received playout schedule p' - r playout schedule p-r time r p p' Redes - 2º cuatrimestre 36 18 Telefonía en Internet: Retardo adaptativo Objetivo: minimizar el retardo de reproducción, intentando mantener el porcentaje de paquetes descartados bajo. Solución: ajuste del retardo de reproducción adaptativo Estimar el retardo de la red y ajustar el retardo de reproducción para cada período de habla. Los períodos de silencio serán comprimidos o extendidos Las porciones son reproducidas cada 20 milisegundos (en períodos de habla) Redes - 2º cuatrimestre 37 Pérdida de paquetes Se pretende preservar una calidad de audio aceptable en presencia de pérdida de paquetes. Un paquete se pierde si: La retransmisión de paquetes no es efectiva: No llega nunca. O llega después de su tiempo de reproducción. Retransmitir un paquete que se perdió en un router probablemente no se pueda realizar a tiempo. Retransmitir un paquete que llegó tarde no sirve para nada. Î Se sigue un esquema de anticipación de pérdidas: Corrección de errores hacia delante (FEC) Entremezclado. Reparación en el receptor Redes - 2º cuatrimestre 38 19 Pérdida de paquetes: FEC Esquema simple: Para cada grupo de n porciones, se crea una porción redundante mediante el EXOR de las n porciones originales. Se envían n+1 porciones Î Incremento del ancho de banda necesario en 1/n. Es posible reconstruir las n porciones originales, si se ha perdido como máximo 1 de los n+1. Problema: el retardo de reproducción debe ser fijado al tiempo para recibir los n+1 porciones. Balance del valor de n: Cuanto mayor sea n, menor desperdicio de AB, mayor retardo de reproducción y mayor probabilidad de que 2 ó más porciones se pierdan. Redes - 2º cuatrimestre 39 Pérdida de paquetes: FEC Segunda variante: enviar un flujo de audio de baja resolución como información redundante. Por ejemplo, codificación PCM a 64 kbps y redundante codificación GSM a 13 kbps. Redes - 2º cuatrimestre 40 20 Pérdida de paquetes: Entremezclado Cada porción se divide en unidades más pequeñas (p.e. 4 ó 5 milisegundos). Cada paquete contiene unidades de diferentes porciones. Redes - 2º cuatrimestre 41 Pérdida de paquetes: Reparación Se intenta realizar una “reparación” en el receptor. Para un paquete perdido, intentan producir un paquete similar al original. Posible para señales de audio, especialmente de habla. Funciona bien para tasas pequeñas (<15%) y paquetes pequeños (4-40 msegs). Técnicas: Repetir los paquetes recibidos inmediatamente después de la pérdida. Interpolación. Redes - 2º cuatrimestre 42 21 Telefonía en Internet: Resumen Utilizar UDP para evitar los retardos de control de congestión de TCP. Retardo de reproducción adaptativo en el cliente: para compensar las variaciones de los retardos. Recuperación de errores (por encima de UDP): FEC y entremezclado Retransmisiones (si el tiempo lo permite) Reparación en el receptor: repetir lo último recibido. Redes - 2º cuatrimestre 43 Protocolos para aplicaciones interactivas Las aplicaciones interactivas en tiempo real (telefonía IP y videoconferencia) centran una parte importante del crecimiento futuro de Internet. Se han definido varios estándares: RTP (Real-Time Protocol) SIP (Session Initiation Protocol) H.323 Redes - 2º cuatrimestre 44 22 RTP Real-Time Transport Protocol – RFC 1889. Especifica un formato de paquete para transportar audio y vídeo. Independiente de la codificación. Válido para: PCM, GSM, MP3, MPEG, ... Se ejecuta en los sistemas finales, encapsulando los paquetes sobre UDP. RTP proporciona: Identificación del tipo de carga Numeración de la secuencia de paquetes Marcas de tiempos Redes - 2º cuatrimestre 45 RTP Codificación de voz PCM a 64 kbps, sobre RTP La aplicación recoge los datos en porciones cada 20 milisegundos Î porciones de 160 bytes. Paquete RTP = Cabecera RTP + porción (160 bytes), encapsulado en un paquete UDP. La cabecera RTP especifica la codificación de cada paquete: Posibilidad para cambiar la codificación durante la comunicación. También números de secuencia y timestamps. Redes - 2º cuatrimestre 46 23 RTP: Cabecera V PX CC M Tipo carga Número secuencia Timestamp Identificador SSRC Identificador CSRC Versión (V): identifica la versión de RTP (2 bits). Relleno (P): indica que el paquete contiene uno o más bytes de relleno, que no son parte de la carga útil (1 bit). Versión actual 2 El último byte de la carga útil indica cuantos bytes deben ser ignorados. Redes - 2º cuatrimestre 47 RTP: Cabecera Extensión (X): cuando está a 1 indica que la cabecera va seguida de una cabecera de extensión (1 bit). Contador CSRC (CC): especifica el número de CSRC’s que siguen a la cabecera (4 bits). Marcador (M): utilizado para marcar eventos significativos y definido en el perfil (1 bit). Tipo de carga (7 bits): indica el tipo de codificación utilizada. Si la carga se modifica durante la comunicación, el emisor lo notifica mediante este campo. Tipo 0: PCM low, 64 kbps. Tipo 3: GSM, 13 kbps Tipo 7: LPC, 2.4 kbps Tipo 26: Motion JPEG Tipo 31: H.261 Tipo 33: MPEG2 vídeo Redes - 2º cuatrimestre 48 24 RTP: Cabecera Número de secuencia (16 bits): incrementado en uno por cada paquete RTP enviado. Timestamp (32 bits): instante de tiempo del primer byte del campo de datos. Utilizado para detectar pérdidas de paquetes y recuperar la secuencia. Para audio, se incrementa en uno para cada período de muestreo (p.e., cada 125 microsegs para 8KHz). Identificador SSRC (32 bits): identifica al origen del flujo RTP ÎCada flujo en una sesión RTP debe disponer de un identificador diferente. Lista CSRC: contiene de 0 a 15 elementos de 32 bits, que especifican la fuente que ha contribuido a la carga útil del paquete. El número de identificadores se especifica en el campo CC. Redes - 2º cuatrimestre 49 RTP y QoS RTP no proporciona ningún mecanismo para garantizar la recepción en tiempo u otro mecanismo de calidad de servicio. La encapsulación RTP es característica de los sistemas finales (nivel de transporte) Î Los routers no conocen el protocolo. Una fuente puede operar con flujos independientes de paquetes. Por ejemplo, utilizar 4 flujos para una vídeo-conferencia: 2 de audio (transmisión y recepción) y de 2 vídeo (transmisión y recepción). RTP también es válido para árboles multidifusión (uno-amuchos y muchos-a-muchos). Redes - 2º cuatrimestre 50 25 RTCP Real-Time Control Protocol (también en RFC 1889). Opera junto con RTP. Cada participante en una sesión RTP transmite periódicamente paquetes RTCP al resto de participantes. Contiene informes del emisor y/o receptor: estadísticas útiles para las aplicaciones (número de paquetes enviados, perdidos, jitter, ...). Feedback: las aplicaciones pueden controlar el rendimiento, modificando su transmisión en base a la información recibida. Redes - 2º cuatrimestre 51 RTCP Para una sesión RTP se define una dirección multicast Î Todos los paquetes RTP y RTCP utilizan esa dirección multicast. Los paquetes RTP y RTCP se diferencian al ir a puertos diferentes. Se limita el tráfico cuando el número de participantes se RTCP incrementa, reduciendo el Receptor tráfico RTCP. Emisor RTP RTCP Internet RTCP Receptor Redes - 2º cuatrimestre 52 26 RTCP: Mensajes Informe de recepción: generado por el receptor para cada flujo RTP y enviado a todos los participantes (multidifusión): Id. de fuente de sincronización del flujo RTP Porcentaje de paquetes perdidos Último número de secuencia recibido Media de la variación entre las llegadas Informe del emisor: para cada flujo RTP que transmite: Id. de fuente de sincronización del flujo RTP Timestamp y tiempo absoluto del último paquete generado. Número de paquetes enviados en el flujo Número de bytes enviados en el flujo Redes - 2º cuatrimestre 53 RTCP: Ancho de banda Problema (potencial): escalabilidad Una sesión RTP con un emisor y múltiples receptores Î Si cada receptor genera múltiples informes los paquetes RTCP pueden superar a los paquetes RTP. El tráfico RTP no aumenta aunque aumente el número de receptores, pero el tráfico RTCP aumenta linealmente. RTCP limita su tráfico a un 5% del AB de la sesión. Por ejemplo, una sesión con un emisor enviando a 2 Mbps Î RTCP limita su tráfico a 100 Kbps. Redes - 2º cuatrimestre 54 27 RTCP: Ancho de banda 75% para los receptores (75 kbps) y 25% para los emisores (25 kbps). Si hay R receptores, cada uno puede enviar a una tasa de 75/R kbps. Cada emisor o receptor determina el período de transmisión de paquetes RTCP calculando la media del tamaño de los paquetes RTCP (para toda la sesión), dividido por la tasa asignada. Redes - 2º cuatrimestre 55 QoS en IP Hasta ahora se ha intentado aprovechar al máximo el “best-effort”. Futuro: Internet con garantías de QoS RSVP: reserva de recursos Servicios diferenciados: garantías diferenciadas Servicios integrados: garantías de las compañías Redes - 2º cuatrimestre 56 28 QoS en IP Ejemplo 1: 1 Mbps para audio y una transferencia FTP Una explosión de tráfico FTP puede congestionar el router Î Pérdida de paquetes en el audio Dar más prioridad al audio Principio 1 Marcado de paquetes para distinguir en los routers entre diferentes clases de paquetes, y nuevas políticas para tratar los paquetes Redes - 2º cuatrimestre 57 QoS en IP Ejemplo 2: ¿qué sucede si la aplicación de audio se pasa de su cuota? Vigilancia: fuerza el ajuste del emisor a los límites de AB. Principio 2 Proporcionar protección (aislamiento) de una clase frente al resto Redes - 2º cuatrimestre 58 29 QoS en IP Reserva fija (no compartida) de AB para el flujo Î uso ineficiente del AB si el flujo no lo utiliza Marcado y vigilancia en los extremos de la red (routers o sistemas finales) Principio 3 Proporcionar protección, pero utilizando los recursos de la forma más eficiente posible Redes - 2º cuatrimestre 59 QoS en IP No se pueden soportar demandas de tráfico por encima de la capacidad del enlace. Principio 4 Admisión de llamadas: el flujo declara sus necesidades y la red puede bloquear una solicitud si no puede cubrir sus necesidades Redes - 2º cuatrimestre 60 30 QoS en IP: Resumen Redes - 2º cuatrimestre 61 Mecanismos de planificación Planificación: determinar el siguiente paquete a enviar. FIFO (First In First Out): enviar en el orden de llegada a la cola. Si no hay suficiente espacio en el buffer Î política de descarte: ¿cuál se descarta? Eliminar por la cola: eliminar el paquete que acaba de llegar. Prioridad: eliminar según prioridades Aleatorio: eliminar aleatoriamente Redes - 2º cuatrimestre 62 31 Mecanismos de planificación Colas con prioridad: transmitir los paquetes en colas de mayor prioridad Múltiples clases, con diferentes prioridades Clases en función de información de la cabecera (etiquetas, TOS, direcciones IP, nº puerto, ...) Redes - 2º cuatrimestre 63 Mecanismos de planificación Planificación round robin: Múltiples clases Recorrer las colas de cada clase (cíclicamente), atendiendo a un paquete de cada cola (si lo hay). Redes - 2º cuatrimestre 64 32 Mecanismos de planificación Espera equitativa ponderada (WFQ): Round robin generalizado Cada clase obtiene una cantidad de servicio proporcional a su peso. Si el enlace opera a R Mbps, la cola 1 tendrá una tasa de R w1/ w1 + w2 + w3 Mbps Redes - 2º cuatrimestre 65 Mecanismos de vigilancia Objetivo: limitar el tráfico para no exceder de los parámetro declarados. Criterios de vigilancia: Tasa media (largo plazo): número de paquetes que se pueden enviar por unidad de tiempo (a largo plazo). ¿Longitud del intervalo: 100 paquetes/seg ó 6000 paquetes/min? 2º caso, posibilidad de enviar 1000 paquetes en 1 seg. Tasa pico: por ejemplo, 6000 paquetes/min (media), y tasa pico de 1500 paquetes/seg. Tamaño de impulso: número máximo de paquetes enviados consecutivamente (sin pausas). Redes - 2º cuatrimestre 66 33 Mecanismos de vigilancia Cubeta agujereada: limita el tamaño de impulso y la tasa media. En la cubeta caben b tokens Los tokens se generan a una tasa de r tokens/segundo (excepto si la cubeta está llena) En un período de t segundos, el número de paquetes admitidos es menor o igual que: rt + b. Redes - 2º cuatrimestre 67 Mecanismos de vigilancia Cubeta agujereada + WFQ: Router multiplexando n flujos Cada flujo se controla mediante una cubeta agujereada (ri y bi), y planificación WFQ. Si para el flujo i, el AB es: R*wi /Σ wj El retardo máximo para el flujo: Cubeta llena (bi) dmax = bi / (R*wi /Σ wj) Redes - 2º cuatrimestre 68 34 Servicios Integrados (IntServ) 1ª solución propuesta por el IETF: Servicios integradosRSVP Arquitectura para proporcionar QoS garantizada en redes IP para aplicaciones mediante sesiones individuales. Identifica flujos individuales y asocia cada flujo a una clase de tráfico. Reserva de recursos: los routers mantiene información de estado de los recursos reservados. Establecimiento de llamada. Problemas: Complejidad: información de estado en todos los nodos y señalización en cada router Escalabilidad Redes - 2º cuatrimestre 69 Servicios Integrados (IntServ) Reserva de recursos: un router identifica sus recursos ya reservados y determina si es posible atender nuevas solicitudes. Caracterización del tráfico: declaración de QoS Establecimiento de la llamada: señalización (RSVP) Control de admisión por cada nodo request/ reply Planificación QoS (p.e. WFQ) Redes - 2º cuatrimestre 70 35 Servicios Integrados (IntServ) Admisión de llamada: Caracterización del tráfico y especificación de la QoS deseada: una sesión declara sus requisitos de QoS Señalización para el establecimiento de la llamada: R-spec (resource-spec): define la QoS solicitada T-spec (traffic-spec): caracteriza el tráfico que el emisor enviará a la red (o que el receptor recibirá). Comunicación de R-spec y T-spec a los routers de la red. Se realiza mediante RSVP Admisión de llamada por cada nodo Redes - 2º cuatrimestre 71 Servicios Integrados (IntServ) Se definen dos clases principales de servicio Servicio garantizado (RFC 2212): proporciona límites firmes sobre los retardos de cola de los paquetes en un router. Caracterización de tráfico mediante cubeta agujereada y una tasa de R paquetes/seg. Garantiza R paquetes/seg y un retardo máximo (mediante la cubeta agujereada). Servicio de carga controlada (RFC 2211): proporciona “una QoS muy próxima a la QoS que un flujo recibiría en un elemento de red sin carga”. Un porcentaje alto de los paquetes pasará con éxito por el router sin ser descartados y con un retardo de cola próximo a cero. Redes - 2º cuatrimestre 72 36 Servicios Integrados: Funciones Control de admisión: se requiere una reserva de recursos previa. Algoritmo de enrutamiento: basado en varios parámetros de QoS, no sólo retardo mínimo (p.e. OSPF). Disciplinas de atención en cola: tiene en cuenta las necesidades de los diferentes flujos. Si el router no dispone de suficientes recursos para garantizar el QoS Î Se descarta el flujo. RSVP se utiliza para hacer las reservas. Determina el siguiente paquete a enviar. Política de descarte: para gestionar la congestión y satisfacer la QoS garantizadas. Redes - 2º cuatrimestre 73 Servicios Integrados: Componentes Protocolo de enrutam. Protocolo de reserva Control de admisión BdD enrutam. BdD control de tráfico Clasificador y selección ruta Gestor de cola de paquetes Agente de gestión QoS Besteffort Redes - 2º cuatrimestre 74 37 Servicios Integrados: Componentes Protocolo de reserva: reservar recursos para flujos nuevos a una determinada QoS Î RSVP. Entre routers y entre routers y sistemas finales. Mantiene información de estado: para cada flujo, a través del camino en todos los routers y sistemas finales. Control de admisión: determina si hay recursos suficientes, para cada flujo nuevo. Agente de gestión: establece políticas de control de admisión. Protocolo de enrutamiento: mantiene la BdD de enrutamiento (siguiente salto). Redes - 2º cuatrimestre 75 Servicios Integrados: Componentes Clasificador y selección de ruta: Los paquetes entrantes se clasifican en clases. Una clase = uno o varios flujos. La clase se determina en función de algunos campos de la cabecera IP. Determina el siguiente salto en función de: clase del paquete e IP destino. Gestor de la cola de salida: Determina el orden en el que se transmiten los paquetes, en base a la clase del paquete, el contenido de la BdD de control de tráfico y la actividad (pasada y actual) del puerto de salida. Selecciona paquetes para descartarlos. Aplica las políticas de vigilancia, para detectar flujos que se excedan. Redes - 2º cuatrimestre 76 38 RSVP Resource ReSerVation Protocol (RFC 2205). RSVP es un protocolo de señalización para Internet: Permite a las aplicaciones reservar recursos en Internet. Recurso = ancho de banda o memoria (buffers). RSVP permite a las aplicaciones reservar ancho de banda para sus flujos de datos. Características básicas: Opera directamente sobre IP. Reserva de ancho de banda en árboles multidifusión. Orientado al receptor. Redes - 2º cuatrimestre 77 RSVP En una red “best-effort”, la distribución de información desde una fuente a uno o más destinos con una QoS puede resultar complicada. Los protocolos dinámicos de enrutamiento permiten: Balancear la carga, suavizando la carga global de la red. Encaminar alrededor de las áreas congestionadas, utilizando un encaminamiento del menor coste. Además, incorporan mecanismos para el enrutamiento multicast y así compartir caminos desde una fuente a los destinos multicast, para minimizar el número de paquetes a duplicar. En entornos monodistribución Î Reservar los recursos antes de empezar a intercambiar datos. Incremento en el número de usuarios Incremento de la velocidad de transmisión Utilización del multicast. Si un router considera que no puede satisfacer la QoS Î Se informa a la aplicación que puede escoger entre: reducir la QoS o intentarlo más tarde. En entornos multicast, la situación es más problemática: Generar un gran volumen de datos, p.e. vídeo. Puede ser un grupo grande y disperso, o ambas cosas. Redes - 2º cuatrimestre 78 39 RSVP Lo que hace interesante la reserva de recursos es que la carga de la fuente multicast se puede prever de forma fácil, por: Algunos miembros del grupo multicast pueden no necesitar la información desde una fuente determinada (p.e. si hay dos fuentes transmitiendo simultáneamente, con recibir una es suficiente). Algunos receptores pueden sólo tener la capacidad para recibir una porción de la transmisión. P.e. una transmisión a dos calidades, donde unos receptores sólo pueden procesar correctamente la más baja. Reserva de recursos con un enrutamiento dinámico Î Estado flexible (“soft state”): información de estado en un router que expira si no se refresca periódicamente. Redes - 2º cuatrimestre 79 Objetivos de RSVP Que receptores heterogéneos puedan realizar reservas específicas según sus necesidades. Especificar los recursos requeridos. Permitir que los receptores puedan seleccionar una fuente entre varias, en un grupo multicast. Gestionar los cambios de rutas y restablecer automáticamente las reservas de recursos. Controlar el overhead del protocolo. Tratar los cambios en las rutas entre un emisor y un receptor independientemente del protocolo de encaminamiento. Redes - 2º cuatrimestre 80 40 Características de RSVP Se diseña para trabajar con cualquier servicio de QoS (los objetos propios de la QoS no están definidos por el protocolo). Permite multicast y unicast (caso particular). No es un protocolo de encaminamiento, sino que está pensado para trabajar conjuntamente con éstos. Los protocolos de encaminamiento determinan dónde se reenvían los paquetes mientras que RSVP se preocupa por la QoS de los paquetes reenviados de acuerdo con el encaminamiento. No especifica cómo se debe proporcionar el AB reservado para los flujos de datos. Especifica el AB necesario, pero son los routers los que deben proporcionarlo (mecanismos de planificación). Redes - 2º cuatrimestre 81 Características de RSVP Es un protocolo simplex: petición de recursos sólo en una dirección Î Diferencia entre emisor y receptor. El intercambio entre dos sistemas finales requiere de reservas diferenciadas en ambas direcciones. Reserva iniciada por el receptor (protocolo orientado al receptor). Mantenimiento del “estado de la reserva flexible” (soft state) en los routers. Permite diferentes tipos de reservas. Protocolo transparente para los routers no RSVP. Redes - 2º cuatrimestre 82 41 Reserva iniciada por el receptor Una reserva iniciada por el emisor es válida para entornos de monodistribución. En un entorno de multidifusión: Cada receptor puede requerir una calidad determinada (distintos tipos de flujo). Un receptor puede seleccionar entre las fuentes disponibles. Las necesidades de QoS de cada receptor pueden ser diferentes (potencia procesamiento, velocidad enlace, etc.) Î Cada receptor debe seleccionar su QoS. El receptor utilizará RSVP para solicitar una QoS determinada a la red. Los routers usan RSVP para distribuir las peticiones de QoS a todos los nodos del camino. Redes - 2º cuatrimestre 83 Estado de reserva flexible El estado de una reserva se almacena temporalmente en los nodos intermedios (routers). Debe ser refrescado periódicamente por los receptores: Si no se refresca en un tiempo límite Î Se descarta. Si cambia la ruta Î Se liberan los recursos automáticamente. Aunque es necesario reservar recursos en la nueva ruta. Redes - 2º cuatrimestre 84 42 Flujos de datos RSVP Paquetes que pasan el filtro Flowspec Distribución de QoS Filterspec Otros paquetes Paquetes de una sesión (dirigidos a un destino) Distribución best-effort Gestor de la cola de salida Redes - 2º cuatrimestre 85 Flujos de datos RSVP Sesión: flujo de datos identificado por su destino. Descriptor de flujo: solicitud de reserva emitida por un receptor. Se divide en dos partes: El contenido de la especificación del flujo no es parte de RSVP. En general, contiene: Especificación de flujo (flowspec) Filtro de flujo (filterspec) R-spec: especificación de la reserva (describe la QoS) T-spec: especificación del tráfico (describe el flujo) La especificación de filtro y la sesión definen el conjunto de paquetes que van a recibir la QoS solicitada El resto de paquetes Î Best-effort. Redes - 2º cuatrimestre 86 43 Funcionamiento de RSVP Dos tipos de mensajes: Mensajes de Path (generados por el emisor): Describen el flujo del emisor. Proporcionan la información del camino de retorno hacia el emisor. Mensajes de Resv (generados por el receptor): Petición de reserva de recursos. Crean el “estado de la reserva” en los routers. Se fusionan según ascienden en el árbol de difusión. Redes - 2º cuatrimestre 87 Funcionamiento de RSVP Resv: 0’15 Mbps C Resv: 0’5 Mbps A Path: 3, 1’5, 0’5 o 0’15 Mbps B D2 500 Kbps Resv: 0’5 Mbps Resv: 3 Mbps Emisor D1 150 Kbps Resv: 3 Mbps D D3 1,5 Mbps Resv: 1’5 Mbps Resv: 3 Mbps D4 3 Mbps Redes - 2º cuatrimestre 88 44 Servicios Diferenciados (DiffServ) Problemas de IntServ: Implementación compleja. Falta de escalabilidad (para grandes volúmenes de datos): Mucha información de control (señalización). Mantenimiento del estado en los routers complejo con muchos flujos. Servicios poco flexibles: mejor definiciones cualitativas (servicio Platino, Oro, Plata, ...) Solución Î Servicios Diferenciados (RFC 2475): Funciones simples en el núcleo de la red y relativamente complejas en los extremos. Poca información suplementaria. Servicios flexibles: no define servicios o clases, proporciona componentes funcionales para construir los servicios. Redes - 2º cuatrimestre 89 Servicios Diferenciados (DiffServ) Se etiquetan los paquetes para un tratamiento de QoS diferenciado (IPv4: TOS e IPv6: Class) Î No se necesitan cambios en IP. Antes de usar DiffServ se establece un acuerdo de nivel de servicio (Service Layer Agreement, SLA): ISP y cliente. Proporciona un mecanismo de agregación integrado Î Todo el tráfico con el mismo byte DS se trata por el mismo servicio de red Î Escalabilidad. Los routers no guardan información sobre el estado de los flujos. Cada paquete se trata individualmente (DS). Redes - 2º cuatrimestre 90 45 Servicios Diferenciados (DiffServ) Un servicio DS se proporciona en un dominio DS. Dominio DS: porción continua de Internet sobre la que se administra un conjunto consistente de políticas DS. Los servicios proporcionados a través de un dominio DS se definen en el SLA (contrato cliente-ISP). Una vez establecido el SLA, el cliente envía paquetes con el campo DS marcado para indicar la QoS requerida. El ISP debe garantizar la QoS asociada para cada paquete. Si el destino está en el dominio DS Î Se debe mantener la QoS. Si el destino está en otro dominio DS Î el dominio DS deberá reenviar los paquetes y re-marcarlos. Redes - 2º cuatrimestre 91 Objetivos de DiffServ Proporcionar una arquitectura que posibilite una discriminación de servicios escalable en Internet. En el reenvío (forwarding) se utiliza un comportamiento por salto (PHB: Per-Hop-Behavior) Caracteriza el tratamiento diferenciado que recibe un paquete individual. Este tratamiento se implementa por las disciplinas de servicio de colas (no es parte de la estandarización). Basado únicamente en las marcas de cada paquete. Los PHB se realizan en cada nodo de la red para proporcionar tratamientos diferenciados, con independencia de cómo se construyan los servicios extremo a extremo o intradominio. Se definen 2 tipos de PHB (+ uno implícito = “best effort”): Assured Forwarding y Expedited Forwarding Redes - 2º cuatrimestre 92 46 Campo TOS (RFC 1349) Cabecera IPv4: 0 8 Versión Long. (4 bits) Cabec. 16 TTL (8 bits) Longitud total (16 bits) TOS (8 bits) Identificación (16 bits) Protocolo (8 bits) 31 Flags (3 bits) Offset de fragmentación (13 bits) Checksum cabecera (16 bits) 20 bytes Dir. IP origen (32 bits) Dir. IP destino (32 bits) Opciones (opcional y variable) Datos (opcional y variable) Redes - 2º cuatrimestre 93 Campo TOS (RFC 1349) TOS Prec. D T R C Precedencia 111 Control de Red 110 Control encaminamiento 101 Crítico 100 Muy urgente 011 Urgente 010 Inmediato 001 Prioridad 000 Rutina TOS 1000 Minimizar retardo 0100 Maximizar throughput 0010 Maximizar fiabilidad 0001 Minimizar coste 0000 Servicio normal Redes - 2º cuatrimestre 94 47 Campo DS (RFC 2474) Campo DS: 6 bits 2 bits DS CU Formato: TOS de IPv4 Class de IPv6 6 bits: código DS 2 bits: no utilizado actualmente En principio, 64 clases de tráfico diferentes: Compatibilidad con campo Precedencia de TOS en IPv4. No intención de compatibilidad con TOS en IPv4. Agrupados en 3 conjuntos de códigos. Redes - 2º cuatrimestre 95 Campo DS (RFC 2474) Códigos DS: Códigos xxxxx0: acción estándar (asignados por ICANN). Códigos xxxx11: Experimental/Local Use Códigos xxxx01: Experimental/Local Use + asignación a futuros estándares si se requiere. xxx000 reservados para compatibilidad con Precedencia IPv4. El campo de precedencia indica el grado de prioridad del datagrama. Un router puede actuar de tres maneras para gestionar el datagrama: Selección de ruta Servicio de red Disciplina de atención en cola. Redes - 2º cuatrimestre 96 48 Arquitectura DiffServ Dominio DS SLA SLA Nodo frontera Entrada DS Nodo frontera Salida DS Nodos Interiores DS Redes - 2º cuatrimestre 97 Arquitectura DiffServ r b Marcado Dominio DS SLA Nodo frontera Entrada DS SLA Nodo frontera Salida DS Nodos Interiores DS Redes - 2º cuatrimestre 98 49 Arquitectura DiffServ r b Planificación Marcado .. . Dominio DS SLA SLA Nodo frontera Entrada DS Nodo frontera Salida DS Nodos Interiores DS Redes - 2º cuatrimestre 99 Arquitectura DiffServ Nodos frontera: clasificación de paquetes y acondicionamiento del tráfico Gestión del tráfico por flujos de datos. Marcan los paquetes. Nodos interiores: re-envío Gestión del tráfico por clases Î Mecanismos simples para tratar los paquetes en base a su código DS. Implementan el PHB: especificaciones DS que indican el tratamiento de reenvío. Planificación en base al marcado de los nodos frontera. Redes - 2º cuatrimestre 100 50 Arquitectura DiffServ Región DS SLA + TCA Dominio DS Dominio DS Nodos Interiores DS Nodos Interiores DS Flujos SLA + TCA Nodo frontera Entrada DS Nodo frontera Salida DS Redes - 2º cuatrimestre 101 Arquitectura DiffServ Elementos de un nodo con función de acondicionamiento de tráfico: Medidor Paquetes Clasificador Marcador Modelador /Descarte Redes - 2º cuatrimestre 102 51 Arquitectura DiffServ Clasificador: entidad que selecciona paquetes en base al contenido de las cabeceras, según unas reglas definidas. Medidor: mide el tráfico enviado que se ajusta a un perfil. Marcador: controla el tráfico mediante el re-marcado de los paquetes con un código diferente (si es necesario). Clasificador de Agregados de Comportamiento (BA): Selecciona paquetes basándose exclusivamente en el campo DS. Clasificador MultiCampo (MF): Selecciona paquetes en base a varios campos: protocolo, puerto, direcciones IP. Entre dos dominios. Paquetes que excedan un perfil determinado. Modelador: controla el tráfico retardando paquetes para no exceder la velocidad especificada. Elemento de descarte: descarta paquetes cuando la velocidad de transferencia excede de la especificada. Redes - 2º cuatrimestre 103 Arquitectura DiffServ Nodo frontera: clasificador + medidor + marcador + modelador/elemento de descarte Marca los paquetes, siempre que se ajusten al SLA Si no se cumple el SLA, se marcan de manera diferente (eliminados, retardados, ...) Nodo interior: clasificador + gestor de cola Únicamente re-envía los paquete, según la clasificación previa. Redes - 2º cuatrimestre 104 52 DiffServ: Problemas Problemas de cooperación entre diferentes ISPs. Para proporcionar servicios diferenciados extremo a extremo, todos los ISPs intermedios debe: Proporcionar servicios diferenciados Y cooperar y establecer acuerdos para que el usuario final obtenga el mismo servicio (o equivalente) en todos los ISPs. Política de autenticación para evitar fraudes: Compleja y costosa: facturación por volumen y no cuota fija mensual. Redes - 2º cuatrimestre 105 Resumen Aplicaciones multimedia y sus requisitos. Aprovechar al máximo el servicio “besteffort” de la Internet de hoy en día. Mecanismos de planificación y vigilancia En el futuro: servicios integrados, RSVP, servicios diferenciados Redes - 2º cuatrimestre 106 53 Referencias Computer Networking: A Top-Down Approach Featuring the Internet. James F. Kurose, Keith W. Ross. 2nd ed. Addison Wesley. 2003. http://www.awl.com/kurose-ross Comunicaciones y Redes de Computadores, Stallings, Prentice-Hall, 2003. Redes - 2º cuatrimestre 107 54