Tema 3: Calidad de Servicio (QoS)

(1)

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

(2)

Redes - 2º cuatrimestre 3

Introducción

Aplicaciones multimedia: audio y vídeo

(“medios continuos”)

La red proporciona a las aplicaciones el nivel de

rendimiento para operar

adecuadamente.

QoS

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ídeo-conferencia)

(3)

Introducción

Internet históricamente ha ofrecido un solo

nivel de servicio:

“Best effort”

Necesidad de diferenciación de servicio en

Internet y redes IP:

Aplicaciones multimedia (unicast/multicast)

Aplicaciones en tiempo real

⇒ QoS + IP

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

(4)

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

Transmisión multimedia almacenada

1. vídeo

2. vídeo

enviado _{3. vídeo recibido,} visualizad en el cliente D at os a cu m ul ad os

Transmisión: en este momento, el

cliente reproduce el inicio del vídeo, mientras el servidor continua

retardo de red

(5)

Transmisión multimedia en directo

Transmisión:

Buffer para transmisión retardada

La transmisión se puede retardar hasta décimas de segundo

Restricciones temporales importantes

Ejemplos:

Programas radiofónicos en directo

Eventos deportivos

Interactividad:

fast forward imposible

rebobinado y pausa posibles

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, ...?

(6)

Multimedia en Internet hoy en día

TCP/UDP/IP: servicio “best-effort” Î No

garantiza retardos ni pérdidas

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 Pero, las transmisiones multimedia

requieren QoS y un nivel de rendimiento para ser efectivas!

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:

(7)

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).

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

(8)

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.

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

(9)

Compresión de audio

0 0,2 0,4 0,6 0,8 1 1,2 1,4 1,6

Valor Binario Onda PCM 0 0,1 0,2 ... 1,5 0000 0001 0010 ... 1111 Muestreo

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).

(10)

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

Best-effort: multimedia almacenado

Acceso a través de un servidor Web (1):

1. El navegador establece una conexión TCP con el servidor Web y

solicita el archivo multimedia (utiliza HTTP).

2. El servidor Web envía el archivo multimedia en un mensaje HTTP

de respuesta.

3. El cliente, reconoce la cabecera HTTP y la codificación multimedia

del contenido Î Lanza el reproductor de medios asociado.

4. 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.

(11)

Best-effort: multimedia almacenado

Acceso a través de un servidor Web (2):

1. El usuario pulsa un enlace al archivo multimedia.

2. El hiperenlace apunta a un archivo meta que contiene la URL del

archivo multimedia. La cabecera HTTP indica la codificación del archivo multimedia.

3. El navegador reconoce la codificación, abre el reproductor y le

pasa el cuerpo del mensaje HTTP (el archivo meta).

4. El reproductor establece una conexión TCP con el servidor HTTP,

solicitando el archivo multimedia.

5. 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, …)

Best-effort: multimedia almacenado

Acceso a través de un servidor de transmisión:

Mejor interacción del usuario con la transmisión multimedia

Posibilidad de usar UDP.

Navegador Servidor Web

Reproductor multimedia

Servidor Streaming

(3) Solicitud y envío del fichero multimedia (1) Petición y respuesta HTTP para el fichero meta

(2) Fichero meta Cliente

(12)

Best-effort: multimedia almacenado

Buffer en el cliente: compensa el retardo de

la red y el jitter.

Transmisión de vídeo velocidad constante D at os a cu m ul ad os tiempo Retardo de red variable Recepción de vídeo

en el cliente Reproducción en el _{cliente a velocidad} constante Retardo de reproducción en el cliente vi de o en bu ffer

Best-effort: multimedia almacenado

Buffer en el cliente:

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 desde la

red

velocidad de llenado = x(t)

buffer del cliente

velocidad de consumo = d

al reproductor

Datos recibidos del vídeo

(13)

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.

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, ...

(14)

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).

RTSP: Ejemplo

Navegador Servidor Web

Reproductor multimedia Servidor Streaming SETUP HTTP GET Cliente Servidor Mefa fichero PLAY TEARDOWN PAUSE Fichero multimedia

(15)

RTSP: Ejemplo

Metafile enviado por el navegador:

<title>Twister</title> <session>

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=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

(16)

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.

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)

(17)

Telefonía en Internet: Limitaciones

Transmisión de vídeo velocidad constante D at os a cu m ul ad os tiempo Retardo de red variable (jitter) Recepción de vídeo

en el cliente Reproducción en el _{cliente a velocidad} constante Retardo de reproducción en el cliente vi de o en bu ffer

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

(18)

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.

Telefonía en Internet: Retardo fijo

packets time packets generated packets received loss r playout schedule p' - r playout schedule p - r

(19)

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)

Pérdida de paquetes

Se pretende preservar una calidad de audio aceptable en presencia de pérdida de paquetes.

Un paquete se pierde si: No llega nunca.

O llega después de su tiempo de reproducción.

La retransmisión de paquetes no es efectiva:

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.

(20)

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.

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

(21)

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.

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.

(22)

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.

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)

(23)

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

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.

(24)

RTP: Cabecera

Versión (V): identifica la versión de RTP (2 bits).

Versión actual 2

Relleno (P): indica que el paquete contiene uno o más bytes de relleno, que no son parte de la carga útil (1 bit).

El último byte de la carga útil indica cuantos bytes deben ser ignorados. V P X CC M Tipo carga Número secuencia

Timestamp Identificador SSRC Identificador CSRC

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

(25)

RTP: Cabecera

Número de secuencia (16 bits): incrementado en uno por cada paquete RTP enviado.

Utilizado para detectar pérdidas de paquetes y recuperar la secuencia.

Timestamp (32 bits): instante de tiempo del primer byte del campo de datos.

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.

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-a-muchos y (uno-a-muchos-a-(uno-a-muchos).

(26)

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.

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

incrementa, reduciendo el

tráfico RTCP.

Emisor Receptor Receptor Internet RTCP RTCP RTCP RTP

(27)

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

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.

(28)

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.

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

(29)

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

Marcado de paquetes para distinguir en los routers entre diferentes clases de paquetes, y nuevas políticas para tratar los paquetes

Principio 1

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.

(30)

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)

Proporcionar protección, pero utilizando los recursos de la forma más eficiente posible

Principio 3

QoS en IP

No se pueden soportar demandas de tráfico por

encima de la capacidad del enlace.

(31)

QoS en IP: Resumen

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

(32)

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, ...)

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).

(33)

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 w₁/ w₁+ w₂+ w₃Mbps

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).

(34)

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.

Mecanismos de vigilancia

Cubeta agujereada + WFQ:

Router multiplexando n flujos

Cada flujo se controla mediante una cubeta agujereada (riy 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 (b_i)

(35)

Servicios Integrados (IntServ)

1ª solución propuesta por el IETF: Servicios

integrados-RSVP

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

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

Planificación QoS (p.e. WFQ)

request/ reply

(36)

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

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á).

Señalización para el establecimiento de la llamada: 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

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.

(37)

Servicios Integrados: Funciones

Control de admisión: se requiere una reserva de recursos

previa.

Si el router no dispone de suficientes recursos para garantizar el QoSÎ Se descarta el flujo.

RSVP se utiliza para hacer las reservas.

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.

Determina el siguiente paquete a enviar.

Política de descarte: para gestionar la congestión y satisfacer la QoS garantizadas.

Servicios Integrados: Componentes

Control de

admisión Agente de gestión Protocolo de reserva Protocolo de enrutam. Clasificador y selección ruta BdD control de tráfico BdD enrutam. Gestor de cola de paquetes QoS

(38)

Best-Redes - 2º cuatrimestre 75

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).

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.

(39)

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.

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.

Incremento en el número de usuarios Incremento de la velocidad de transmisión Utilización del multicast.

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.

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.

(40)

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.

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.

(41)

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).

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.

(42)

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.

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.

(43)

Flujos de datos RSVP

Filterspec

Flowspec Distribución _{de QoS}

Distribución best-effort Gestor de la cola de salida Otros paquetes Paquetes que pasan el filtro Paquetes de una sesión (dirigidos a un destino)

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:

Especificación de flujo (flowspec)

Filtro de flujo (filterspec)

El contenido de la especificación del flujo no es parte de RSVP. En general, contiene:

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

(44)

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.

Funcionamiento de RSVP

A 150 Kbps B C D Emisor D1 D2 D3 500 Kbps 1,5 Mbps Path: 3, 1’5, 0’5 o 0’15 Mbps Resv: 0’15 Mbps Resv: 0’5 Mbps Resv: 3 Mbps Resv: 3 Mbps Resv: 0’5 Mbps Resv: 3 Mbps Resv: 1’5 Mbps

(45)

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.

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).

(46)

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.

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”):

(47)

Campo TOS (RFC 1349)

Cabecera IPv4:

Dir. IP destino (32 bits) Dir. IP origen (32 bits)

Checksum cabecera (16 bits)

Protocolo (8 bits)

Identificación (16 bits) Offset de fragmentación_{(13 bits)} Longitud total (16 bits)

TTL (8 bits) TOS (8 bits) Long. Cabec. Versión (4 bits)

Opciones (opcional y variable) Datos (opcional y variable)

0 8 16 31 20 bytes Flags (3 bits)

Campo TOS (RFC 1349)

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 D T R Prec. C TOS

(48)

Campo DS (RFC 2474)

Campo DS: TOS de IPv4 Class de IPv6 Formato: 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.

CU DS

6 bits 2 bits

Campo DS (RFC 2474)

Códigos DS:

Códigos xxxxx0: acción estándar (asignados por ICANN).

xxx000 reservados para compatibilidad con Precedencia IPv4.

Códigos xxxx11: Experimental/Local Use

Códigos xxxx01: Experimental/Local Use + asignación a futuros estándares si se requiere.

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

(49)

Arquitectura DiffServ

Nodo frontera Entrada DS Nodos Interiores DS Nodo frontera Salida DS SLA SLA Dominio DS

Arquitectura DiffServ

Dominio DS Nodo frontera Entrada DS Nodos Interiores DS Nodo frontera Salida DS SLA SLA r b Marcado

(50)

Arquitectura DiffServ

Dominio DS Nodo frontera Entrada DS Nodos Interiores DS Nodo frontera Salida DS SLA SLA r b Marcado Planificación

..

.

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.

(51)

Arquitectura DiffServ

Dominio DS Nodos Interiores DS Dominio DS Nodos Interiores DS Nodo frontera

Entrada DS _{Nodo frontera}

Salida DS Región DS SLA + TCA SLA + TCA Flujos

Arquitectura DiffServ

Elementos de un nodo con función de

acondicionamiento de tráfico:

Modelador /Descarte Marcador Clasificador Medidor Paquetes

(52)

Arquitectura DiffServ

Clasificador: entidad que selecciona paquetes en base al contenido de las cabeceras, según unas reglas definidas. 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.

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).

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.

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

(53)

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.