9 CALIDAD DE SERVICIO (QoS)

Autor: Rogelio Montañana

Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

9.1 CALIDAD DE SERVICIO EN ETHERNET.. 6-1

9.2 CALIDAD DE SERVICIO EN INTERNET.. 6-1

9.2.1 Arquitectura IntServ y Protocolo RSVP. 6-2

9.1 CALIDAD DE SERVICIO EN ETHERNET

El subcomité 802.1Q ha elaborado un estándar que permite etiquetar tramas en una LAN. Esto se utiliza normalmente con dos finalidades diferentes:

Distinguir tramas pertenecientes a diferentes VLANs (Virtual LANs) cuando se mezclan en un enlace troncal. Para esto se utiliza un campo de 12 bits.

Marcar un nivel de prioridad a cada trama. El funcionamiento de prioridades en LAN lo especifica el subcomité 802.1p. Esto permite establecer calidad de servicio en una LAN para satisfacer las exigencias de aplicaciones en tiempo real, por ejemplo.

Es dudosa la utilidad que los mecanismos de asignación de prioridades puedan tener en la red local, ya que el ancho de banda es tan barato que en la mayoría de casos puede ser más sencillo sobredimensionar los enlaces adecuadamente para evitar la congestión. Probablemente esto cambie con las futuras aplicaciones de Ethernet de 10 Gigabits en redes metropolitanas o de área extensa, donde el aumento de capacidad puede tener unos costos mayores.

Por otro lado, el uso de un sistema de prioridades o reserva de recursos requiere mecanismos de control de acceso y posiblemente contabilidad de recursos consumidos, a fin de que el usuario utilice los privilegios con moderación. A modo de ejemplo cabe mencionar aquí el caso histórico de Token Ring, que dispone de ocho niveles de prioridad (similar a 802.1p pero incompatible con éste), de forma que en teoría sería una red más adecuada que por ejemplo Ethernet para tráfico en tiempo real. Prácticamente todas las aplicaciones que se han escrito para Token Ring emiten sus tramas en la prioridad más alta, ya que ningún programador consideraba que sus aplicaciones eran menos importantes que el resto, y el costo para el usuario era el mismo, es decir ninguno. Como consecuencia de esto el campo prioridad solo ha servido para complicar inútilmente las implementaciones de Token Ring, y con ello el costo de esta red.

En todo caso los desarrollos en 802.1p se centran en la definición de prioridades o ‘clases de servicio’ más que en calidad de servicio propiamente dicha, entendiendo por esta última la posibilidad de reservar a priori y con garantía recursos en la red. La calidad de servicio está muy relacionada con las redes orientadas a conexión, por lo que no es un mecanismo que se pueda implementar de manera fácil en redes no orientadas a conexión, como es el caso de las LANs habituales o de Internet. Parece no obstante que la combinación de un mecanismo de prioridades y la flexibilidad de redimensionar adecuadamente los enlaces críticos de la red puede dar una respuesta aceptable a las necesidades de tráfico en tiempo real, tales como aplicaciones multimedia.

9.2 CALIDAD DE SERVICIO EN INTERNET

El diseño original de Internet contemplaba un servicio ‘best effort’, es decir sin ninguna garantía de calidad de servicio. Con la proliferación, a partir de 1994 aproximadamente, de aplicaciones de videoconferencia y multimedia en tiempo real en Internet, muy sensibles a situaciones de congestión, creció el interés de adaptar los protocolos de Internet para ofrecer algún tipo de Calidad de Servicio.

En realidad ya había algo de Calidad de Servicio desde el principio en IPv4, pues en la cabecera del datagrama se encontraba como luego comentaremos el campo denominado TOS (Type Of Service) de ocho bits de los cuales los tres primeros representaban una prioridad (allí denominada precedencia) que permitía marcar los datagramas según su importancia, marcado que permitía establecer en principio políticas o prioridades en la transmisión de los datagramas por la red.

Aunque la prioridad representa una cierta calidad de servicio, por cuanto que permite clasificar los datagramas en categorías, no es capaz en general de ofrecer una garantía estricta, al estilo de la ofrecida por ATM, donde es posible reservar un caudal determinado para un circuito, aplicación o flujo determinado, asignándole un circuito virtual CBR, por ejemplo. Aunque un flujo concreto marque sus datagramas con máxima prioridad no es posible, en general, garantizarle un caudal mínimo o un retardo máximo ya que podría sufrir congestión debido a un caudal excesivo de datagramas de esa prioridad producido por el tráfico agregado de otros flujos.

Al parecer la única forma de ofrecer una calidad de servicio garantizada es realizando una reserva previa de capacidad en todo el trayecto, al estilo de los circuitos ATM; para ello es preciso que cada router intermedio tenga conocimiento de la existencia de dicho flujo. Esto supone pasar del modelo no orientado a conexión, utilizado en Internet, al orientado a conexión. Hacia 1995 había una tendencia en Internet a desarrollar ese modelo y fruto de esta filosofía es la denominada arquitectura de Servicios Integrados o IntServ (de Integrated Services). El elemento más conocido y representativo de la arquitectura IntServ es el protocolo RSVP que describiremos a continuación. Curiosamente a pesar del interés que el modelo IntServ suscitó entre la comunidad Internet su uso no se ha difundido, ni entre los fabricantes que han sido reacios a implementarlo en los equipos, ni entre los ISPs, que tampoco lo han desarrollado en sus redes. Según los expertos el fracaso del modelo IntServ se debe a su no escalabilidad, es decir a que el costo de su implementación crece cuando menos linealmente con la complejidad de la red. El problema está en que, al ser RSVP un protocolo orientado a conexión los routers han de mantener una información de estado de todos los flujos activos que pasan por ellos. Esta información de estado puede ser aceptable en los routers de la periferia, pero resulta inmanejable en los routers del ‘core’ de la red que han de soportar miles de conexiones activas.

Dado que la arquitectura IntServ seguía sin resolver el problema de la calidad de servicio en Internet hacia 1997 apareció un modelo alternativo denominado Arquitectura de Servicios Diferenciados o DiffServ (de Differentiated Services). La idea básica de DiffServ consiste en que cada paquete lleva escrito un código que indica a que clase pertenece; se supone que los routers saben el tratamiento que han de dar a cada una de las clases posibles, por lo que no han de mantener ninguna información sobre conexiones o flujos concretos; el número de clases posibles es limitado e independiente del número de hosts o de flujos que pasan por los routers, por lo que la arquitectura DiffServ es escalable. En realidad el modelo DiffServ ‘reinventó’ hasta cierto punto el olvidado y denostado campo TOS de IPv4, que incluía entre otras cosas el subcampo precedencia que ya hemos comentado.

A continuación describiremos brevemente las dos arquitecturas descritas.

9.2.1 Arquitectura IntServ y Protocolo RSVP

En la arquitectura IntServ ocupa un papel fundamental el concepto de flujo. Entendemos por flujo un tráfico continuo de datagramas relacionados entre sí que se produce como consecuencia de una acción del usuario y que requiere una misma Calidad de Servicio. Un flujo es unidireccional y es la entidad más pequeña a la que puede aplicarse una determinada Calidad de Servicio. Los flujos pueden agruparse en clases; todos los flujos de una misma clase reciben la misma calidad de servicio.

En IPv4 los flujos se identifican por las direcciones de origen y destino, el puerto de origen y destino (a nivel de transporte) y el protocolo de transporte utilizado (TCP o UDP). En IPv6 la identificación puede hacerse de la misma forma que en IPv4, o alternativamente por las direcciones de origen y destino y el valor del campo Etiqueta de Flujo. Aunque el campo Etiqueta de Flujo en IPv6 se definió con este objetivo la funcionalidad aún no se ha implementado en la práctica.

En la arquitectura IntServ se definen tres tipos de servicio:

Servicio Garantizado: garantiza un caudal mínimo y un retardo máximo. Cada router del trayecto debe ofrecer las garantías solicitadas, aunque a veces esto no es posible por las características del medio físico (por ejemplo en Ethernet compartida).

Servicio de Carga Controlada: este servicio debe ofrecer una calidad comparable a la de una red de datagramas poco cargada, es decir en general un buen tiempo de respuesta, pero sin garantías estrictas. Eventualmente se pueden producir retardos grandes.

Servicio Best Effort: este servicio no tiene ninguna garantía.

Para conseguir sus objetivos IntServ dispone del protocolo RSVP. El protocolo RSVP (Resorce reSerVation Protocol) está pensado fundamentalmente para tráfico multicast, ya que este tipo de tráfico es especialmente adecuado para la distribución de flujos de audio y vídeo en tiempo real que requieren unas condiciones estrictas de calidad de servicio. Sin embargo nada impide la utilización de RSVP en tráfico unicast.

En una emisión multicast los usuarios pueden apuntarse o borrarse del grupo multicast de forma dinámica y sin advertencia previa; imaginemos por ejemplo que en una red se emiten de forma multicast diversos programas simultáneamente (equivalente a ‘canales’ de televisión) y que los usuarios desde sus hosts van continuamente haciendo 'zapping' de un canal a otro; en un momento dado los usuarios que estén viendo un determinado canal forman un grupo multicast, pero el grupo puede cambiar con rapidez.

Suponiendo que todos los programas se emiten desde el mismo host, este host será la raíz del árbol de expansión (spanning tree) de la emisión multicast; para cada programa multicast que se emite hay un conjunto de receptores que configuran un árbol de expansión diferente; esto es tarea del protocolo de routing multicast, no de RSVP. Por tanto a partir de aquí supondremos resuelta esa parte del problema.

El primero de los receptores del programa provoca la creación por parte del protocolo de routing del árbol de expansión y envía un mensaje de reserva hacia el emisor empleando el encaminamiento del camino inverso que hemos visto al hablar de routing multicast. Cada router por el que pasa el mensaje de reserva toma nota del ancho de banda solicitado y lo reserva, o bien devuelve un mensaje de error si no hay capacidad disponible. Si todo va bien al final del proceso el receptor ha reservado el ancho de banda necesario en todo el camino hasta la raíz del árbol.

Cuando aparece en la red un segundo receptor de esa misma emisión multicast envía su mensaje de reserva, pero la reserva sólo se efectuará en aquella parte del trayecto (o rama del árbol) que no sea común con el primer receptor y no haya sido por tanto ya reservada por éste. De esta forma se asegura un uso óptimo de la red, no reservando caudal dos veces en el mismo enlace, a la vez que se evita por completo la congestión (suponemos que RSVP no realiza sobresuscripción, es decir que no asigna recursos por encima de la capacidad disponible).

Es evidente, como ya hemos comentado, que aunque se trate de un protocolo Internet RSVP es un protocolo orientado a conexión, ya que los routers tienen que guardar una cierta información de estado de cada flujo para el que se efectúa reserva, algo equivalente a un circuito virtual. Decimos entonces que los routers con RSVP ya no son 'stateless' sino 'statefull'.

9.2.2 Arquitectura DiffServ

La arquitectura DiffServ se basa en la idea de que la información sobre calidad de servicio se escribe en los datagramas, no en los routers. Esta es la diferencia fundamental con IntServ y es la que nos va a permitir implementar una calidad de servicio escalable a cualquier cantidad de flujos.

Para escribir la información sobre la calidad de servicio de cada datagrama se utiliza un campo de un byte en la cabecera denominado DS. El campo DS se estructura de la siguiente forma:

Subcampo	Longitud (bits)
DSCP (Differentiated Servcies CodePoint)	6
ECN (Explicit Congestion Notification)	2

Tabla 3.1.- Estructura del campo 'Differentiated Services’

El subcampo ECN tiene que ver con la notificación de situaciones de congestión, cosa que trataremos más adelante. En cuanto al subcampo DSCP nos permite definir en principio hasta 2⁶ = 64 posibles categorías de tráfico, aunque en la práctica se utilizan bastante menos, como veremos a continuación. Los valores de DSCP se dividen en los tres grupos siguientes:

Codepoint	Posibles Valores	Uso
Xxxyy0	32	Estándar
xxxx11	16	Local/Experimental
xxxx01	16	Reservado

Tabla 3.2.- Grupos de ‘CodePoints’ del campo DS

Así pues, de momento se contemplan 32 posibles categorías de datagramas, correspondientes a los cinco primeros bits del campo DS.

En DiffServ se definen tres tipos de servicio, que son los siguientes:

Servicio ‘Expedited Forwarding’ o ‘Premium’: Este servicio es el de mayor calidad. Se supone que debe ofrecer un servicio equivalente a una línea dedicada virtual, o a un circuito ATM CBR o VBR-rt. Debe garantizar un caudal mínimo, una tasa máxima de pérdida de paquetes, un retardo medio máximo y un jitter máximo. El valor del subcampo DSCP relacionado con este servicio es ‘101110’.

Servicio ‘Assured Forwarding’: Este servicio asegura un trato preferente, pero no garantiza caudales, retardos, etc. Se definen cuatro clases posibles pudiéndose asignar a cada clase una cantidad de recursos en los routers (ancho de banda, espacio en buffers, etc.). La clase se indica en los tres primeros bits del DSCP. Para cada clase se definen tres categorías de descarte de paquetes (probabilidad alta, media y baja) que se especifican en los dos bits siguientes (cuarto y quinto). Existen por tanto 12 valores de DSCP diferentes asociados con este tipo de servicio, que son:

	Precedencia de descarte
Clase	Baja	Media	Alta
4	10001	10010	10011
3	01101	01110	01111
2	01001	01010	01011
1	00101	00110	00111

Tabla 3.3.- ‘CodePoints’ utilizados en el servicio Assured Forwarding

Podemos imaginar la prioridad de descarte como algo equivalente al bit DE de Frame Relay o al bit CLP de ATM, solo que en este caso se pueden marcar tres prioridades de descarte diferentes en vez de dos. En muchas implementaciones se ignora el quinto bit del campo DSCP, con lo que las precedencias media y alta son equivalentes. En estos casos el cuarto bit del DSCP desarrolla un papel equivalente al bit DE de Frame Relay o al CLP de ATM.

En el servicio Assured Forwarding el proveedor puede aplicar traffic policing al usuario, y si el usuario excede lo pactado el proveedor puede descartar datagramas, o bien aumentar la precedencia de descarte.

Servicio Best Effort: este servicio se caracteriza por tener a cero los tres primeros bits del DSCP. En este caso los dos bits restantes pueden utilizarse para marcar una prioridad, dentro del grupo ‘best effort’. En este servicio no se ofrece ningún tipo de garantías.

El servicio Expedited Forwarding es aproximadamente equivalente al Servicio Garantizado de IntServ, mientras que el Assured Forwarding corresponde más o menos al Servicio de Carga Controlada de IntServ.

Algunos ISPs (proveedores de servicios Internet) ofrecen servicios denominados ‘olímpicos’ con categorías denominadas oro, plata y normal (o tiempo-real, negocios y normal). Generalmente estos servicios se basan en las diversas clases del servicio Assured Forwarding.

El campo DS es una incorporación reciente en la cabecera IP. Anteriormente existía en su lugar un campo denominado TOS o ‘Tipo de Servicio’ que tenía la siguiente estructura:

Subcampo	Longitud (bits)
Precedencia	3
Flags D, T, R, C	4
Reservado	1

Tabla 3.4.- Estructura del campo ‘Tipo de servicio’

El subcampo ‘Precedencia’ permitía especificar una prioridad entre 0 y 7 para el datagrama (7 máxima prioridad). Este campo es en cierto modo el antecesor del campo DS. A continuación se encontraba un subcampo compuesto por cuatro bits que actuaban como indicadores o ‘flags’ mediante los cuales el usuario podía indicar sus preferencias respecto a la ruta que seguiría el datagrama. Los flags, denominados D, T, R y C permitían indicar si se prefería una ruta con servicio de bajo retardo (D=Delay), elevado rendimiento (T=Throughput), elevada fiabilidad (R=Reliability) o bajo costo (C=Cost). El campo TOS ha sido muy impopular: el subcampo precedencia se ha implementado muy raramente en los routers. En cuanto a los flags D,T,R,C prácticamente no se han utilizado y su inclusión en la cabecera IP ha sido muy criticada. Estos problemas facilitaron evidentemente la ‘transformación del campo TOS en el DS, aunque existen todavía routers en Internet que interpretan este campo con su antiguo significado de campo TOS. Dado que DiffServ casi siempre utiliza solo los tres primeros bits del DSCP para marcar los paquetes, y que los servicios de mas prioridad, como es el caso del Expedited Forwarding, se asocian con los valores más altos de esos tres bits, en la práctica hay bastante compatibilidad entre el nuevo campo DSCP del byte DS y el antiguo campo Precedencia del byte TOS, como puede verse en la tabla siguiente:

Valor Campo Precedencia	Servicio DiffServ correspondiente
7	Reservado
6	Reservado
5	Expedited Forwarding
4	Assured Forwarding clase 4
3	Assured Forwarding clase 3
2	Assured Forwarding clase 2
1	Assured Forwarding clase 1
0	Best Effort

Tabla 3.5.- Correspondencia del campo precedencia con los servicios DiffServ

Evidentemente esta compatibilidad no es accidental. Tradicionalmente el campo Precedencia no hacía uso de los dos niveles de prioridad más altos, que quedaban reservados para mensajes de gestión de la red, como datagramas del protocolo de routing. En DiffServ se han reservado también los dos valores más altos de los tres primeros bits con lo que se mantiene la compatibilidad con el campo precedencia.