Arquitectura DiffSer

Los principales componentes de la arquitectura DiffServ para proveer QoS en Internet son:

• Campo DS: la diferenciación de servicios requiere el marcado de bits seleccionados en los headers de los paquetes IP. Esto es llamado el campo DS (“DS field”) en el contexto de DiffServ. La RFC 2474 “Definition of te differentiated services field in los headers IPv4 and IPv6” define el campo DS coincidente con el byte ToS en el header IP. Pero sólo seis bits son usados para transportar los códigos DS (DSCP: DS codepoint) y los dos bits que restan son usados actualmente para notificaciones de congestión explícita (ECN). DSCP es usado para determinar el comportamiento de forwarding

que experimenta un paquete en un típico nodo DiffServ. Este comportamiento de forwarding es llamado “per-hop behavior” (PHB. DiffServ se basa en definir un número pequeño de PHB’s que implementan la diferenciación de servicios en los routers participantes y marcan los bits DSCP para asignar paquetes entrantes a uno de estos PHB’s. Hay un PHB (class selector PHB) definido para tener compatibilidad con los bits IP Precedence del byte ToS, y los otros dos PHB’s son definidos para implementar los servicios premium (expedited forwarding EF) y asegurado (assured forwarding AF).

• CS PHB: como se mencionó antes, sirve para mantener la compatibilidad con los bits IP Precedence del byte ToS. Puede ser usado para crear ocho diferentes niveles de prioridad con el mayor valor que indica una más alta prioridad de forwarding.

• EF PHB: está diseñado para implementar un servicio con bajo delay, jitter y pérdidas en añadidura al ancho de banda asegurado, como se especifica en la RFC 3246 [79]. La idea atrás de EF PHB es que los paquetes marcados con un EF DSCP se encuentren con colas de tamaño muy pequeño en los nodos de forwarding. Esto a menudo es alcanzado por medio de la asignación de recursos de forwarding con un velocidad mayor que la velocidad de llegada de los paquetes EF. EF se usa en servicios que tienen requerimientos estrictos de delay y jitter tale como las aplicaciones de tiempo crítico y multimedia. • AF PHB: se usa para diagramar servicios con una pérdida controlada

y un ancho de banda asegurado. Tales servicios no tienen garantías de delay o jitter. El grupo AF PHB consiste de tres comportamientos de forwarding con diferentes precedencias de descarte de paquetes (drop). El AF PHB define dos velocidades: una velocidad de información comprometida (CIR: commited information rate) que es el mínimo ancho de banda de red para ser asegurado, y una velocidad de información pico (PIR: peak information rate) para una velocidad por encima del CIR para acomodar las ráfagas (burst). AF PHB se hace importante en losd casos de congestión de red cuando se deben descartar paquetes.

• Per-Domain Behavior (PDB): son diseñados para que sean instalados en nodos individuales o routers. Se denomina “behavior agrégate” (BA) a un grupo de paquetes que experimentan el mismo comprtamiento en cada nodo mientras atraviesan un dominio. El término BA leugo se hará sinónimo e PDB, que es uno de los principales bloques para construir una red DiffServ. Un PDB se usa

para definir un conjunto de servicios edge-to-edge que tienen parámetros de red medibles como los que experimentan un conjunto de paquetes con el mismo DSCP cuando atraviesan un dominio DiffServ. Se entiende por dominio DiffServ a parte de la red bajo una única administración y compatible con los estándares DiffServ. Entonces, los PDB’s se usan para construir servicios entre puntos de ingreso y egreso de un dominio. Los atributos de los PDB’s (throughput, tasa de pérdidas, etc.) se publican como especificaciones de niveles de servicios en los límites del dominio. Más de un PDB puede estar basado en el mismo PHB, y por otro lado un PDB se basa en un único PHB dentro de un único dominio. • Arquitectura DiffServ: una red DiffServ consiste de múltiples

dominios DiffServ (DS’s) que pueden ser vistos como sistemas autónomos (AS’s). Los routers de cada extremo del dominio hacen el acondicionamiento del tráfico necesario en los extremos. Cada dominio DS hace dos acuerdos con cada uno de sus dominios vecinos: un SLA especificando los servicios que este dominio proverá y un acuerdo de acondicionamiento de tráfico (TCA) al cual estará sujeto el tráfico entrante a este dominio. Los dominios adyacentes negocian SLA’s ente ellos y con loc clientes que acceden a sus redes. Cada dominio DS configura y provee sus nodos internos para que los SLA’s puedan ser cumplidos. Esta distribución de las responsabilidades de configuración agrega flexibilidad a la arquitectura Diffserv. Es importante remarcar que aquí, a diferencia del moldelo IntServ, DiffServ emplea “provisión de recursos” con la ayuda de los SLA’s y no usa “reservación de recursos” para establecer diferentes servicios.

Ahora seguiremos el trayecto completo que recorre un paquete típico en una red DiffServ, desde que sale del origen hasta que llega al destino. Primero el paquete es medido contra un cierto perfil de tráfico negociado entre el cliente y el proveedor de servicios de red. Luego el paquete es marcado con un DSCP apropiado para encontrar un cierto nivel de servicios en la red del ISP. El paquete puede ser marcado ya sea en el host (origen) o en el “firts-hop” router (conocido como “leaf router”) o incluso hasta en los routers de borde. De hecho, un paquete puede ser remarcado sucesivamente desde el momento que deja las premisas del cliente y entra al dominio del ISP:

Una vez que el paquete ha sido marcado, pasa a formar parte de un comportamiento agregado específico con todos los otros paquetes marcados con el mismo DSCP. En el router de ingreso del dominio DS, el paquete se somete a un acondicionamiento de tráfico.

El paquete entonces es clasificado usando ya sea clasificadores MF o BA. El paquete entonces es medido contra un contrato de tráfico negociado y pasa por un policer/shaper, en el caso de ser necesario. En este punto, el paquete puede ser también remarcado con un DSCP diferente para indicar una degradación en el nivel de servicio. La siguiente figura muestra el funcionamiento de un router extremo DiffServ:

Los routers internos o del centro de la red implementan los tratamientos necesarios de forwarding de tráfico para diferentes PHB’s soportados por el dominio DS.

A la salida del dominio DS, el paquete puede pasar a través de otro nivel de acondicionamiento de tráfico en el router de egreso del dominio. Este nivel de acondicionamiento de tráfico garantiza que el tráfico que abandona un dominio DS y entra al dominio adyacente sigue el contrato de tráfico acordado entre dichos dominios.

Entonces queda claro que la arquitectura DiffServ lleva la complejidad de la administración de la red hacia los extremos y deja el manejo y forwarding de los paquetes para el centro de la red tan simple y rápido como sea posible. Esta propiedad de escalabilidad es importante en DiffServ y marca la diferencia sobre otros esquemas de QoS como IntServ. Aunque por un lado el manejo del tráfico agregado reduce la flexibilidad de las garantías de provisión de QoS a los flujos individuales, por el otro mejora el total de la escalabilidad de la arquitectura.

Bandwidth Broker y marco de políticas: se necesita una infraestructura de administración para montar servicios e2e a lo largo de múltiples dominios DS. La arquitectura DiffServ de dos bits propuso el uso de BB’s para el mencionado propósito. Un BB es un agente que reside ya sea en cada dominio DS o entre dominios. Los BB’s se comunican entre ellos para establecer los servicios e2e y mantener el estado de la información necesaria en lugar de mantenerlo en los routers de los dominios participantes. Los BB’s son parte de lo que se llama marco de políticas. Las políticas se usan para regular el acceso a los recursos y servicios de red, basadas en un criterio administrativo. El marco de políticas es usualmente responsable por el control de admisión y la provisión de recursos a través de dos entidades principales: un punto de decisión de políticas (PDP) y un punto de refuerzo de políticas (PEP).

11.11.4.Evaluación de la arquitectura DiffServ La arquitectura DiffServ tiene las siguientes ventajas sobre IntServ:

Escalabilidad: DiffServ provee diferentes niveles de servicios a tráficos agregados en lugar de flujos individuales, no haciendo usao de esta manera de la necesidad de mantener los estados por flujo en cada router del camino e2e. Esto hace a DiffServ más atractiva para Internet.

No tiene un tiempo de establecimiento: no hay necesidad de señalización en DiffServ, y generalmente los servicios se construyen con SLA’s y forwarding y acondicionamiento del tráfico a través de los nodos y dominios de la red.

Control de admisión “on-the-fly”: esto se hace a través de políticas y remarcado de tráfico en los routers de borde, y así no hay necesidad de tomar una decisión de control de admisión en cada nodo del camino e2e.

Compatibilidad con IPSec: dado que el tratamiento de paquetes en DiffServ requiere sólo el IP header, puede ser usado conjuntamente con IPSec contrariamente a lo que sucede con IntServ. Sin embargo existen algunos temas de la arquitectura acerca del manejo de los campos DS en los túneles IPSec que imponen algunas trabas.

Y por otro lado, existen en DiffServ algunos problemas operativos que necesitan ser resueltos antes que la arquitectura DiffServ pueda ser puesta en práctica:

El estándar DiffServ propuesto de esta manera no provee aseguramiento de e2e QoS para el tráfico de Internet. Sólo especifica cómo los dominios individuales pueden ser configurados para proveer diferenciación de servicios a diferentes clases de tráfico. La arquitectura DiffServ no tiene un esquema específico para un control de admisión exacto. Sí usa una política y shaping de tráfico para proveer un control de admisión al instante (on-the-fly) en los routers extremos y de borde.

DiffServ necesita de mapeo e interoperabilidad con otros esquemas (como MPLS y ATM) para ser implementado a través de muchos dominios. Existen muchas propuestas pero se necesita mayor investigación aún.

Es necesario desarrollar interfaces de programación de aplicaciones (API’s) apropiadas en los hosts finales para que las aplicaciones puedan sacar provecho de las capacidades de DiffServ.